From report at bugs.python.org  Tue Nov  1 00:01:07 2011
From: report at bugs.python.org (Florent Xicluna)
Date: Mon, 31 Oct 2011 23:01:07 +0000
Subject: [issue13305] datetime.strftime("%Y") not consistent for years < 1000
In-Reply-To: <1320091957.61.0.759691422668.issue13305@psf.upfronthosting.co.za>
Message-ID: <1320102067.45.0.298368879004.issue13305@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

Proposed patch to fix the issue in xmlrpc.client

----------
keywords: +patch
Added file: http://bugs.python.org/file23577/issue13305_xmlrpc_patch.diff

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

From report at bugs.python.org  Tue Nov  1 00:07:20 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 31 Oct 2011 23:07:20 +0000
Subject: [issue13305] datetime.strftime("%Y") not consistent for years < 1000
In-Reply-To: <1320091957.61.0.759691422668.issue13305@psf.upfronthosting.co.za>
Message-ID: <E1RL0wi-0001Mk-Sx@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 3f025427f02b by Florent Xicluna in branch 'default':
Fix regression due to changeset 2096158376e5 (issue #13305).
http://hg.python.org/cpython/rev/3f025427f02b

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

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

From report at bugs.python.org  Tue Nov  1 00:23:57 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 31 Oct 2011 23:23:57 +0000
Subject: [issue13304] test_site assumes that site.ENABLE_USER_SITE is True
In-Reply-To: <1320085868.02.0.130211137087.issue13304@psf.upfronthosting.co.za>
Message-ID: <E1RL1Cn-0002TX-DT@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 1689b9cf6b1c by Ned Deily in branch '2.7':
Issue #13304: Skip test case if user site-packages disabled (-s or
http://hg.python.org/cpython/rev/1689b9cf6b1c

New changeset c497011a4769 by Ned Deily in branch '3.2':
Issue #13304: Skip test case if user site-packages disabled (-s or
http://hg.python.org/cpython/rev/c497011a4769

New changeset c343c095d08b by Ned Deily in branch 'default':
Issue #13304: Skip test case if user site-packages disabled (-s or
http://hg.python.org/cpython/rev/c343c095d08b

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

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

From report at bugs.python.org  Tue Nov  1 00:25:41 2011
From: report at bugs.python.org (Ned Deily)
Date: Mon, 31 Oct 2011 23:25:41 +0000
Subject: [issue13304] test_site assumes that site.ENABLE_USER_SITE is True
In-Reply-To: <1320085868.02.0.130211137087.issue13304@psf.upfronthosting.co.za>
Message-ID: <1320103541.94.0.771604999446.issue13304@psf.upfronthosting.co.za>


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

LGTM. Thanks for the patch!  Committed to 27 (for release in 2.7.3), 32 (3.2.3), and default (3.3).

----------
assignee:  -> ned.deily
nosy: +ned.deily
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
versions: +Python 2.7, Python 3.2, Python 3.3

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

From report at bugs.python.org  Tue Nov  1 00:47:44 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 31 Oct 2011 23:47:44 +0000
Subject: [issue13279] Add memcmp into unicode_compare for optimizing
	comparisons
In-Reply-To: <4EAF09D5.90800@v.loewis.de>
Message-ID: <1320104603.3382.14.camel@localhost.localdomain>


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

> > Note we only really see the effect if we make sure that gcc
> > isn't emitting its "special" memcmp: that's why the -fno-builtin-memcmp
> > is SO important on gcc builds!
> 
> I'd rather infer the opposite: given how GCC generates code, this patch
> is not worthwhile. Given that it actually slows down Python in the
> default system configuration, I'm -1 on applying it. This is really not
> a route we should take; it leads to maintenance pain.

I agree with Martin. This patch would be very nice if there wasn't the
memcmp() perf problem. A possible solution would be to write a simple
optimized memcmp()-alike for our own purposes.
But I'm not sure it's really worth the hassle: comparing long unicode
strings doesn't strike me as a very common operation. Finding a short
substring, conatenating strings together, are all much more common.

----------
title: Add memcmp into unicode_compare for optimizing	comparisons -> Add memcmp into unicode_compare for optimizing comparisons

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

From report at bugs.python.org  Tue Nov  1 01:18:59 2011
From: report at bugs.python.org (Florent Xicluna)
Date: Tue, 01 Nov 2011 00:18:59 +0000
Subject: [issue2979] use_datetime in SimpleXMLRPCServer
In-Reply-To: <1211846989.94.0.031553096454.issue2979@psf.upfronthosting.co.za>
Message-ID: <1320106739.27.0.124030438833.issue2979@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

Latest comment is unrelated to this feature request.
It goes with issue #13305.

----------

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

From report at bugs.python.org  Tue Nov  1 01:20:25 2011
From: report at bugs.python.org (Florent Xicluna)
Date: Tue, 01 Nov 2011 00:20:25 +0000
Subject: [issue3173] external strftime for Python?
In-Reply-To: <1214189093.82.0.548435251403.issue3173@psf.upfronthosting.co.za>
Message-ID: <1320106825.83.0.804103302035.issue3173@psf.upfronthosting.co.za>


Changes by Florent Xicluna <florent.xicluna at gmail.com>:


----------
nosy: +flox

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

From report at bugs.python.org  Tue Nov  1 05:56:31 2011
From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=)
Date: Tue, 01 Nov 2011 04:56:31 +0000
Subject: [issue12105] open() does not able to set flags, such as O_CLOEXEC
In-Reply-To: <1305745889.2.0.237560021123.issue12105@psf.upfronthosting.co.za>
Message-ID: <1320123391.9.0.647659458692.issue12105@psf.upfronthosting.co.za>


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

Why it is closed as duplicate? nothing said about CLOEXEC in issue12797

----------

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

From report at bugs.python.org  Tue Nov  1 05:56:45 2011
From: report at bugs.python.org (Ross Lagerwall)
Date: Tue, 01 Nov 2011 04:56:45 +0000
Subject: [issue12797] io.FileIO and io.open should support openat
In-Reply-To: <1313874003.0.0.755289779326.issue12797@psf.upfronthosting.co.za>
Message-ID: <1320123405.02.0.397308827749.issue12797@psf.upfronthosting.co.za>


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

Thanks (and for the English lesson ;-) )

----------
assignee:  -> rosslagerwall
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Tue Nov  1 07:56:14 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Tue, 01 Nov 2011 06:56:14 +0000
Subject: [issue13279] Add memcmp into unicode_compare for optimizing
	comparisons
In-Reply-To: <1319737961.76.0.990787408068.issue13279@psf.upfronthosting.co.za>
Message-ID: <1320130574.42.0.313015377621.issue13279@psf.upfronthosting.co.za>


Changes by Martin v. L?wis <martin at v.loewis.de>:


----------
resolution:  -> wont fix
status: open -> closed

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

From report at bugs.python.org  Tue Nov  1 07:56:37 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Tue, 01 Nov 2011 06:56:37 +0000
Subject: [issue13279] Add memcmp into unicode_compare for optimizing
	comparisons
In-Reply-To: <1319737961.76.0.990787408068.issue13279@psf.upfronthosting.co.za>
Message-ID: <1320130597.09.0.209891769699.issue13279@psf.upfronthosting.co.za>


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

Ok, closing the issue.

----------

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

From report at bugs.python.org  Tue Nov  1 08:27:45 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Tue, 01 Nov 2011 07:27:45 +0000
Subject: [issue12105] open() does not able to set flags, such as O_CLOEXEC
In-Reply-To: <1320123391.9.0.647659458692.issue12105@psf.upfronthosting.co.za>
Message-ID: <CAH_1eM3bS-nmNLe6ZF9GPebWFTFDOrpNj=BxhR50JzR=7QxMZA@mail.gmail.com>


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

> Why it is closed as duplicate? nothing said about CLOEXEC in issue12797

See http://bugs.python.org/issue12760#msg146686

----------

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

From report at bugs.python.org  Tue Nov  1 09:33:02 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 01 Nov 2011 08:33:02 +0000
Subject: [issue12105] open() does not able to set flags, such as O_CLOEXEC
In-Reply-To: <1305745889.2.0.237560021123.issue12105@psf.upfronthosting.co.za>
Message-ID: <1320136382.83.0.137731910711.issue12105@psf.upfronthosting.co.za>


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

And to be explicit, you can now write:

def open_cloexex(filename, mode='r'):
  return open(filename, mode,
              opener=lambda path, mod: os.open(path, mod|os.O_CLOEXEC))

----------

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

From report at bugs.python.org  Tue Nov  1 09:55:54 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Tue, 01 Nov 2011 08:55:54 +0000
Subject: [issue13308] fix test_httpservers failures when run as root
Message-ID: <1320137754.01.0.106611498358.issue13308@psf.upfronthosting.co.za>


New submission from Charles-Fran?ois Natali <neologix at free.fr>:

Here's a patch fixing test_httpservers failures when run as root (a couple buildbots are consistently failing on this, e.g. http://python.org/dev/buildbot/all/builders/x86 FreeBSD 7.2 3.x/builds/2282/steps/test/logs/stdio).
The test is failing for two reasons:
1) test_get does a chmod(0) on a directory, and checks that the server returns an error when requesting a file under this directory: unfortunately, filesystem permissions are ignored by root
2) CGI tests fail because they try to execute CGI scripts, created in a temporary directory: unfortunately, the temp directory is created as root with mkdtemp() (mode == 0700), and the http server changes to user "nobody" before running the scripts => EACCES

----------
components: Tests
files: test_httpserver_root.diff
keywords: needs review, patch
messages: 146762
nosy: haypo, neologix, pitrou
priority: normal
severity: normal
stage: patch review
status: open
title: fix test_httpservers failures when run as root
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file23578/test_httpserver_root.diff

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

From report at bugs.python.org  Tue Nov  1 10:00:02 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Tue, 01 Nov 2011 09:00:02 +0000
Subject: [issue13308] fix test_httpservers failures when run as root
In-Reply-To: <1320137754.01.0.106611498358.issue13308@psf.upfronthosting.co.za>
Message-ID: <1320138002.59.0.346871555254.issue13308@psf.upfronthosting.co.za>


Petri Lehtinen <petri at digip.org> added the comment:

You should change "issue #XXXX" with the real issue number now that there's an issue for this :)

----------
nosy: +petri.lehtinen

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

From report at bugs.python.org  Tue Nov  1 10:53:58 2011
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 01 Nov 2011 09:53:58 +0000
Subject: [issue13152] textwrap: support custom tabsize
In-Reply-To: <1318338300.67.0.514985359705.issue13152@psf.upfronthosting.co.za>
Message-ID: <1320141238.72.0.1276249256.issue13152@psf.upfronthosting.co.za>


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

Two comments:

* The new parameter to __init__ should be added at the end of the parameter list.

* A documentation update would be nice.

----------

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

From report at bugs.python.org  Tue Nov  1 11:04:09 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 01 Nov 2011 10:04:09 +0000
Subject: [issue13305] datetime.strftime("%Y") not consistent for years < 1000
In-Reply-To: <E1RL0wi-0001Mk-Sx@dinsdale.python.org>
Message-ID: <4EAFC40C.2010901@haypocalc.com>


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

Le 01/11/2011 00:07, Roundup Robot a ?crit :
>
> Roundup Robot<devnull at psf.upfronthosting.co.za>  added the comment:
>
> New changeset 3f025427f02b by Florent Xicluna in branch 'default':
> Fix regression due to changeset 2096158376e5 (issue #13305).
> http://hg.python.org/cpython/rev/3f025427f02b

I don't like this hack. If there is a bug in time.strftime(), we need to 
fix time.strftime(), not xmlrpclib.

Is there a test for the hack?

----------

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

From report at bugs.python.org  Tue Nov  1 12:55:58 2011
From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=)
Date: Tue, 01 Nov 2011 11:55:58 +0000
Subject: [issue12105] open() does not able to set flags, such as O_CLOEXEC
In-Reply-To: <1305745889.2.0.237560021123.issue12105@psf.upfronthosting.co.za>
Message-ID: <1320148558.33.0.548497321433.issue12105@psf.upfronthosting.co.za>


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

Well, I understand. So why not to add 'e' (and 'N', which is the same meaning) character, which:

* use O_CLOEXEC in modern Linux
* generate Exception if O_CLOEXEC is not supported (or does not work) on platform. 

Also, implement O_CLOEXEC for open() in Windows using appropriate securityattributes with CreateFile()

?

----------

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

From report at bugs.python.org  Tue Nov  1 12:56:50 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 01 Nov 2011 11:56:50 +0000
Subject: [issue13305] datetime.strftime("%Y") not consistent for years < 1000
In-Reply-To: <1320091957.61.0.759691422668.issue13305@psf.upfronthosting.co.za>
Message-ID: <E1RLCxP-0000SF-2w@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 230f0956aaa3 by Florent Xicluna in branch 'default':
Strengthen the tests for format '%Y', in relation with issue #13305.
http://hg.python.org/cpython/rev/230f0956aaa3

----------

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

From report at bugs.python.org  Tue Nov  1 13:07:17 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 01 Nov 2011 12:07:17 +0000
Subject: [issue12105] open() does not able to set flags, such as O_CLOEXEC
In-Reply-To: <1305745889.2.0.237560021123.issue12105@psf.upfronthosting.co.za>
Message-ID: <1320149237.97.0.362500242072.issue12105@psf.upfronthosting.co.za>


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

> So why not to add 'e' character
You said it: because it can't be written consistently on all platforms.
For example, python does not use CreateFile on Windows, see #12939.

----------

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

From report at bugs.python.org  Tue Nov  1 13:12:36 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 01 Nov 2011 12:12:36 +0000
Subject: [issue12939] Add new io.FileIO using the native Windows API
In-Reply-To: <1315523941.29.0.146575875409.issue12939@psf.upfronthosting.co.za>
Message-ID: <1320149556.55.0.578691892106.issue12939@psf.upfronthosting.co.za>


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

Instead of rewriting your own RawIO implementation, why not use _open_osfhandle?
This should be simple now with the "opener" argument.
http://msdn.microsoft.com/en-us/library/bdts1c9x.aspx

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

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

From report at bugs.python.org  Tue Nov  1 13:14:39 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 01 Nov 2011 12:14:39 +0000
Subject: [issue670664] HTMLParser.py - more robust SCRIPT tag parsing
Message-ID: <E1RLDEa-0002hm-Lj@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 0a5eb57d5876 by Ezio Melotti in branch '2.7':
#670664: Fix HTMLParser to correctly handle the content of ``<script>...</script>`` and ``<style>...</style>``.
http://hg.python.org/cpython/rev/0a5eb57d5876

New changeset a6f2244b251f by Ezio Melotti in branch '3.2':
#670664: Fix HTMLParser to correctly handle the content of ``<script>...</script>`` and ``<style>...</style>``.
http://hg.python.org/cpython/rev/a6f2244b251f

New changeset b40752e227fa by Ezio Melotti in branch 'default':
#670664: merge with 3.2.
http://hg.python.org/cpython/rev/b40752e227fa

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

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

From report at bugs.python.org  Tue Nov  1 13:18:11 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 01 Nov 2011 12:18:11 +0000
Subject: [issue670664] HTMLParser.py - more robust SCRIPT tag parsing
Message-ID: <1320149891.34.0.450131334122.issue670664@psf.upfronthosting.co.za>


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

Fixed, thanks to everyone who contributed to this over the years!

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

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

From report at bugs.python.org  Tue Nov  1 13:44:13 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 01 Nov 2011 12:44:13 +0000
Subject: [issue12008] HtmlParser non-strict goes wrong with unquoted attributes
In-Reply-To: <1304592448.01.0.0813052297129.issue12008@psf.upfronthosting.co.za>
Message-ID: <E1RLDhF-0005Po-6A@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 6107a84e3c44 by Ezio Melotti in branch '3.2':
#12008: add a test.
http://hg.python.org/cpython/rev/6107a84e3c44

New changeset 495b31a8b280 by Ezio Melotti in branch 'default':
#12008: merge with 3.2.
http://hg.python.org/cpython/rev/495b31a8b280

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

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

From report at bugs.python.org  Tue Nov  1 13:46:40 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 01 Nov 2011 12:46:40 +0000
Subject: [issue12008] HtmlParser non-strict goes wrong with unquoted attributes
In-Reply-To: <1304592448.01.0.0813052297129.issue12008@psf.upfronthosting.co.za>
Message-ID: <1320151600.96.0.302651428438.issue12008@psf.upfronthosting.co.za>


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

This seems to be already fixed in 3.2/3.3, so I extracted the test from your script and added to the test suite.  If you can find a way to break the parser let me know.

----------
assignee:  -> ezio.melotti
nosy: +ezio.melotti
resolution:  -> out of date
stage:  -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Tue Nov  1 14:21:42 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 01 Nov 2011 13:21:42 +0000
Subject: [issue12629] HTMLParser silently stops parsing with malformed
	attributes
In-Reply-To: <1311532507.83.0.00235537878353.issue12629@psf.upfronthosting.co.za>
Message-ID: <1320153702.19.0.00632884125491.issue12629@psf.upfronthosting.co.za>


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

I think <x><y z=""o"" /></x> should be parser as <x><y z="" /></x>, and the o"" should be ignored.
<x><y z="""" /></x> should be parser as <x><y z="" /></x>, and the last two "" should be ignored.  This is what Firefox seems to do.

Currently the parser doesn't seem to handle extraneous data in the start tag too well, because the locatestarttagend_tolerant regex looks for (more or less) well-formed attributes.
Attached a patch for test_htmlparser with the two examples provided by Kevin.

----------
keywords: +patch
nosy: +ezio.melotti
stage:  -> needs patch
Added file: http://bugs.python.org/file23579/issue12629.diff

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

From report at bugs.python.org  Tue Nov  1 15:04:01 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Tue, 01 Nov 2011 14:04:01 +0000
Subject: [issue12578] Erratic socket.gaierror: [Errno 11004] when using smtplib
In-Reply-To: <1310902779.89.0.705938348131.issue12578@psf.upfronthosting.co.za>
Message-ID: <1320156241.73.0.801056719677.issue12578@psf.upfronthosting.co.za>


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

Please provide more information, because this looks really strange...

----------
nosy: +neologix
stage:  -> test needed
status: open -> pending

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

From report at bugs.python.org  Tue Nov  1 15:05:04 2011
From: report at bugs.python.org (Florent Xicluna)
Date: Tue, 01 Nov 2011 14:05:04 +0000
Subject: [issue13309] test_time fails: time data 'LMT' does not match format
	'%Z'
Message-ID: <1320156304.27.0.1872899991.issue13309@psf.upfronthosting.co.za>


New submission from Florent Xicluna <florent.xicluna at gmail.com>:

After changeset 55a3b563f0db the Gentoo buildbot is complaining.


======================================================================
FAIL: test_strptime (test.test_time.TimeTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/buildbot/buildarea/3.x.ochtman-gentoo-amd64/build/Lib/test/test_time.py", line 159, in test_strptime
    time.strptime(strf_output, format)
ValueError: time data 'LMT' does not match format '%Z'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/home/buildbot/buildarea/3.x.ochtman-gentoo-amd64/build/Lib/test/test_time.py", line 162, in test_strptime
    (format, strf_output))
AssertionError: conversion specifier '%Z' failed with 'LMT' input.

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

----------
components: Tests
keywords: buildbot
messages: 146776
nosy: flox
priority: normal
severity: normal
stage: test needed
status: open
title: test_time fails: time data 'LMT' does not match format '%Z'
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Tue Nov  1 15:05:41 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Tue, 01 Nov 2011 14:05:41 +0000
Subject: [issue13303] Sporadic importlib failures: FileNotFoundError on
	os.rename()
In-Reply-To: <1320058871.09.0.581986884521.issue13303@psf.upfronthosting.co.za>
Message-ID: <1320156341.91.0.789039148835.issue13303@psf.upfronthosting.co.za>


Changes by Charles-Fran?ois Natali <neologix at free.fr>:


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

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

From report at bugs.python.org  Tue Nov  1 15:07:11 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 01 Nov 2011 14:07:11 +0000
Subject: [issue13302] Clarification needed in C API arg parsing
In-Reply-To: <1320057763.71.0.58387430149.issue13302@psf.upfronthosting.co.za>
Message-ID: <1320156431.44.0.975152156322.issue13302@psf.upfronthosting.co.za>


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

It's already in the 3.x docs (but not 2.x):

?Strings and buffers

These formats allow to access an object as a contiguous chunk of memory. You don?t have to provide raw storage for the returned unicode or bytes area. Also, you won?t have to release any memory yourself, except with the es, es#, et and et# formats.?

http://docs.python.org/dev/c-api/arg.html#strings-and-buffers

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

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

From report at bugs.python.org  Tue Nov  1 15:12:52 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 01 Nov 2011 14:12:52 +0000
Subject: [issue13309] test_time fails: time data 'LMT' does not match format
	'%Z'
In-Reply-To: <1320156304.27.0.1872899991.issue13309@psf.upfronthosting.co.za>
Message-ID: <E1RLF52-0005SK-5o@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 2771f7e96a52 by Florent Xicluna in branch 'default':
Add temporary tests to troubleshoot issue #13309 on Gentoo buildbot.
http://hg.python.org/cpython/rev/2771f7e96a52

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

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

From report at bugs.python.org  Tue Nov  1 15:27:50 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Tue, 01 Nov 2011 14:27:50 +0000
Subject: [issue9897] multiprocessing problems
In-Reply-To: <1284890791.64.0.603170640253.issue9897@psf.upfronthosting.co.za>
Message-ID: <1320157670.79.0.140347101286.issue9897@psf.upfronthosting.co.za>


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

The first problem is a duplicate of issue #6056.

As for the second problem, no, it doesn't limit the number of concurrent connections. Server.serve_forever() creates a new thread for each new incoming connection.

Closing as duplicate.

----------
nosy: +neologix
resolution:  -> duplicate
status: open -> closed
superseder:  -> socket.setdefaulttimeout affecting multiprocessing Manager

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

From report at bugs.python.org  Tue Nov  1 16:07:42 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 01 Nov 2011 15:07:42 +0000
Subject: [issue13309] test_time fails: time data 'LMT' does not match format
	'%Z'
In-Reply-To: <1320156304.27.0.1872899991.issue13309@psf.upfronthosting.co.za>
Message-ID: <E1RLFw6-0002Pc-FK@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset bb0ae7df08f8 by Florent Xicluna in branch 'default':
Troubleshoot issue #13309 on Gentoo buildbot.
http://hg.python.org/cpython/rev/bb0ae7df08f8

----------

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

From report at bugs.python.org  Tue Nov  1 16:20:52 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 01 Nov 2011 15:20:52 +0000
Subject: [issue13287] urllib.request exposes too many names
In-Reply-To: <1319814075.5.0.569025067527.issue13287@psf.upfronthosting.co.za>
Message-ID: <E1RLG8q-0003sT-4c@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 70dedd8ce8f3 by Senthil Kumaran in branch 'default':
issue13287 - Define __all__ for urllib.request and urllib.error and expose only
http://hg.python.org/cpython/rev/70dedd8ce8f3

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

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

From report at bugs.python.org  Tue Nov  1 16:28:45 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Tue, 01 Nov 2011 15:28:45 +0000
Subject: [issue13287] urllib.request exposes too many names
In-Reply-To: <1319814075.5.0.569025067527.issue13287@psf.upfronthosting.co.za>
Message-ID: <1320161325.19.0.420672606106.issue13287@psf.upfronthosting.co.za>


Senthil Kumaran <senthil at uthcode.com> added the comment:

Thanks flox for the patch.

Just the News item is added. I don't think, this requires any Docs update. One change I had to make in the patch is to remote HTTPSHandler from __all__ because that is only conditionally available when http.client supports HTTPSConnection.  Neither might this require a docs update because Handlers may be used only within urllib.request namespace and not standalone.

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

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

From report at bugs.python.org  Tue Nov  1 16:55:19 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 01 Nov 2011 15:55:19 +0000
Subject: [issue1745761] Bad attributes/data handling in SGMLib
Message-ID: <1320162919.9.0.0718990784705.issue1745761@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/issue1745761>
_______________________________________

From report at bugs.python.org  Tue Nov  1 17:04:40 2011
From: report at bugs.python.org (Xavier de Gaye)
Date: Tue, 01 Nov 2011 16:04:40 +0000
Subject: [issue13310] asyncore handling of out-of-band data fails
Message-ID: <1320163480.19.0.535971932001.issue13310@psf.upfronthosting.co.za>


New submission from Xavier de Gaye <xdegaye at gmail.com>:

Add the following lines to test_handle_expt (this makes sense, a
dispatcher instance is supposed to implement handle_read and call recv
in order to detect that the remote end has closed the socket):

--- a/Lib/test/test_asyncore.py
+++ b/Lib/test/test_asyncore.py
@@ -677,6 +677,9 @@
             def handle_expt(self):
                 self.flag = True
 
+            def handle_read(self):
+                self.recv(1)
+
         class TestHandler(BaseTestHandler):
             def __init__(self, conn):
                 BaseTestHandler.__init__(self, conn)

With these lines added, the test now fails on linux with Python 3.3,
see the following backtrace: select (an poll) returns a read event and
an exceptional condition for the socket, but there is no normal data
to read, only out-of-band data.

The attached patch fixes the problem.


======================================================================
ERROR: test_handle_expt (test.test_asyncore.TestAPI_UseIPv4Poll)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/path_to/src/cpython/cpython-hg-default/Lib/test/test_asyncore.py", line 690, in test_handle_expt
    self.loop_waiting_for_flag(client)
  File "/path_to/src/cpython/cpython-hg-default/Lib/test/test_asyncore.py", line 523, in loop_waiting_for_flag
    asyncore.loop(timeout=0.01, count=1, use_poll=self.use_poll)
  File "/path_to/src/cpython/cpython-hg-default/Lib/asyncore.py", line 215, in loop
    poll_fun(timeout, map)
  File "/path_to/src/cpython/cpython-hg-default/Lib/asyncore.py", line 196, in poll2
    readwrite(obj, flags)
  File "/path_to/src/cpython/cpython-hg-default/Lib/asyncore.py", line 117, in readwrite
    obj.handle_error()
  File "/path_to/src/cpython/cpython-hg-default/Lib/asyncore.py", line 108, in readwrite
    obj.handle_read_event()
  File "/path_to/src/cpython/cpython-hg-default/Lib/asyncore.py", line 439, in handle_read_event
    self.handle_read()
  File "/path_to/src/cpython/cpython-hg-default/Lib/test/test_asyncore.py", line 681, in handle_read
    self.recv(1)
  File "/path_to/src/cpython/cpython-hg-default/Lib/asyncore.py", line 379, in recv
    data = self.socket.recv(buffer_size)
BlockingIOError: [Errno 11] Resource temporarily unavailable

----------
components: Library (Lib)
files: handle_expt.diff
keywords: patch
messages: 146783
nosy: xdegaye
priority: normal
severity: normal
status: open
title: asyncore handling of out-of-band data fails
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file23580/handle_expt.diff

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

From report at bugs.python.org  Tue Nov  1 17:06:54 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 01 Nov 2011 16:06:54 +0000
Subject: [issue13309] test_time fails: time data 'LMT' does not match format
	'%Z'
In-Reply-To: <1320156304.27.0.1872899991.issue13309@psf.upfronthosting.co.za>
Message-ID: <E1RLGrO-0000Nm-Vk@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 5b1e1967ea9d by Florent Xicluna in branch 'default':
Replace temporary tests with the real test case for issue #13309 on Gentoo.
http://hg.python.org/cpython/rev/5b1e1967ea9d

----------

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

From report at bugs.python.org  Tue Nov  1 17:08:30 2011
From: report at bugs.python.org (Xavier de Gaye)
Date: Tue, 01 Nov 2011 16:08:30 +0000
Subject: [issue13311] asyncore handle_read should call recv
Message-ID: <1320163710.5.0.667995234807.issue13311@psf.upfronthosting.co.za>


New submission from Xavier de Gaye <xdegaye at gmail.com>:

When the remote end disconnects, handle_close is only called if recv
is called (from handle_read). The default implementation of
handle_read does not call recv.

Not having the default implementation of handle_read call recv, has
the following drawbacks:

    an implementation of a subclass of dispatcher that only sends
    data, a logger for example, may believe that it does not have to
    implement handle_read since it does not expect any data and since
    there is no hint in the code or in the documentation that it
    should

    test_handle_expt currently succeeds when it should fail since the
    current handling of out-of-band data is broken (see issue 13310),
    but if the default implementation of handle_read had called recv,
    then test_handle_expt would have failed, allowing to detect the
    problem

The attached patch adds a call to recv in handle_read, updates the
documentation and adds a test case.

Note that when this patch is applied, test_handle_expt fails
as expected, issue 13310 should be fixed first.

----------
components: Library (Lib)
files: handle_read.diff
keywords: patch
messages: 146785
nosy: xdegaye
priority: normal
severity: normal
status: open
title: asyncore handle_read should call recv
type: behavior
versions: Python 2.7, Python 3.3
Added file: http://bugs.python.org/file23581/handle_read.diff

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

From report at bugs.python.org  Tue Nov  1 17:11:56 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 01 Nov 2011 16:11:56 +0000
Subject: [issue755670] improve HTMLParser attribute processing regexps
Message-ID: <1320163916.02.0.437245826875.issue755670@psf.upfronthosting.co.za>


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

Attached patch includes the tests in diff.txt.  On Python 3, with strict=False, the first test (adjacent attributes) passes, but the other two still fail.
See also #12629.

----------
nosy: +ezio.melotti -BreamoreBoy
type: feature request -> behavior
versions: +Python 3.3
Added file: http://bugs.python.org/file23582/issue755670.diff

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

From report at bugs.python.org  Tue Nov  1 17:22:04 2011
From: report at bugs.python.org (Ross Lagerwall)
Date: Tue, 01 Nov 2011 16:22:04 +0000
Subject: [issue13309] test_time fails: time data 'LMT' does not match format
	'%Z'
In-Reply-To: <1320156304.27.0.1872899991.issue13309@psf.upfronthosting.co.za>
Message-ID: <1320164524.52.0.0741297980273.issue13309@psf.upfronthosting.co.za>


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

"""
import time
import sys

t = time.gmtime(time.time())
s = time.strftime('%Z', t)
print(s)

time.mktime((-1, 1, 1, 0, 0, 0, -1, -1, -1))

t = time.gmtime(time.time())
s = time.strftime('%Z', t)
print(s)
"""
outputs:
SAST
LMT

on my Gentoo box. I'm still figuring out why...

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

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

From report at bugs.python.org  Tue Nov  1 17:26:00 2011
From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=)
Date: Tue, 01 Nov 2011 16:26:00 +0000
Subject: [issue12939] Add new io.FileIO using the native Windows API
In-Reply-To: <1315523941.29.0.146575875409.issue12939@psf.upfronthosting.co.za>
Message-ID: <1320164760.16.0.929559034037.issue12939@psf.upfronthosting.co.za>


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

why not use _open_osfhandle?

Because it is wrapper for other CRT functions for Windows, like close(). In other words it is an emulation. I think Python should not create wrapper around wrapper around wrapper...

For example, in Python3, open() implemented using open() and not using fopen(). Why we should use another wrapper on Windows platform?

----------

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

From report at bugs.python.org  Tue Nov  1 17:33:09 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 01 Nov 2011 16:33:09 +0000
Subject: [issue12939] Add new io.FileIO using the native Windows API
In-Reply-To: <1320164760.16.0.929559034037.issue12939@psf.upfronthosting.co.za>
Message-ID: <1320164926.3355.0.camel@localhost.localdomain>


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

> why not use _open_osfhandle?
> 
> Because it is wrapper for other CRT functions for Windows, like
> close(). In other words it is an emulation. I think Python should not
> create wrapper around wrapper around wrapper...

Why do you think it makes a difference?

----------

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

From report at bugs.python.org  Tue Nov  1 17:40:16 2011
From: report at bugs.python.org (Florent Xicluna)
Date: Tue, 01 Nov 2011 16:40:16 +0000
Subject: [issue13309] test_time fails: time data 'LMT' does not match format
	'%Z'
In-Reply-To: <1320156304.27.0.1872899991.issue13309@psf.upfronthosting.co.za>
Message-ID: <1320165616.95.0.355704019379.issue13309@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

It seems that "mktime" is buggy on Gentoo.
You can try to reset its state in some way before to retry strftime:


t = time.gmtime(time.time())
s = time.strftime('%Z', t)
print(s)

time.mktime((-1, 1, 1, 0, 0, 0, -1, -1, -1))
s = time.strftime('%Z', t)
print(s)

time.mktime((1, 1, 1, 0, 0, 0, 0, 0, -1))
s = time.strftime('%Z', t)
print(s)


I guess it could output:
SAST
LMT
SAST

----------

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

From report at bugs.python.org  Tue Nov  1 17:45:49 2011
From: report at bugs.python.org (Ross Lagerwall)
Date: Tue, 01 Nov 2011 16:45:49 +0000
Subject: [issue13309] test_time fails: time data 'LMT' does not match format
	'%Z'
In-Reply-To: <1320156304.27.0.1872899991.issue13309@psf.upfronthosting.co.za>
Message-ID: <1320165949.42.0.855509415865.issue13309@psf.upfronthosting.co.za>


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

It outputs:
SAST
LMT
LMT

An equivalent C program to the first test:
"""
#include <time.h>
#include <stdlib.h>
#include <stdio.h>

int main() {

    time_t t;
    struct tm *tmp;

    t = time(NULL);
    tmp = localtime(&t);

    char str[200];
    strftime(str, sizeof(str), "%Z", tmp);

    puts(str);

    struct tm tmp2;
    tmp2.tm_sec = 0;
    tmp2.tm_min = 0;
    tmp2.tm_hour = 0;
    tmp2.tm_mday = 1;
    tmp2.tm_mon = 1;
    tmp2.tm_year = -1;
    tmp2.tm_wday = -1;
    tmp2.tm_yday = -1;
    tmp2.tm_isdst = -1;
    mktime(&tmp2);

    t = time(NULL);
    tmp = localtime(&t);

    strftime(str, sizeof(str), "%Z", tmp);

    puts(str);

    return 0;
}
"""

Outputs (as expected):
SAST
SAST

Perhaps it's not mktime?

----------

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

From report at bugs.python.org  Tue Nov  1 17:49:26 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 01 Nov 2011 16:49:26 +0000
Subject: [issue12939] Add new io.FileIO using the native Windows API
In-Reply-To: <1315523941.29.0.146575875409.issue12939@psf.upfronthosting.co.za>
Message-ID: <1320166166.97.0.590987843343.issue12939@psf.upfronthosting.co.za>


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

An implementation of RawIO with the win32 API can be useful (and I'd be interested to compare the performance)
But maybe not for all usages: some Python interfaces are defined in terms of file descriptors, imp.load_module(), and PyTokenizer_FindEncoding for example.

----------

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

From report at bugs.python.org  Tue Nov  1 17:52:39 2011
From: report at bugs.python.org (Florent Xicluna)
Date: Tue, 01 Nov 2011 16:52:39 +0000
Subject: [issue13312] test_time fails: strftime('%Y', y) for negative year
Message-ID: <1320166359.06.0.160451222607.issue13312@psf.upfronthosting.co.za>


New submission from Florent Xicluna <florent.xicluna at gmail.com>:

On builder "AMD64 FreeBSD 8.2 3.x" for the TIME_MINYEAR:


======================================================================
FAIL: test_negative (test.test_time.TestStrftime4dyear)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/home/buildbot/buildarea/3.x.krah-freebsd/build/Lib/test/test_time.py", line 397, in test_negative
    return super().test_negative()
  File "/usr/home/buildbot/buildarea/3.x.krah-freebsd/build/Lib/test/test_time.py", line 425, in test_negative
    self.assertEqual(self.yearstr(TIME_MINYEAR), str(TIME_MINYEAR))
AssertionError: '2147483648' != '-2147483648'
- 2147483648
+ -2147483648
? +

----------
components: Library (Lib)
keywords: buildbot
messages: 146793
nosy: belopolsky, flox
priority: normal
severity: normal
stage: needs patch
status: open
title: test_time fails: strftime('%Y', y) for negative year
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Tue Nov  1 17:56:44 2011
From: report at bugs.python.org (Florent Xicluna)
Date: Tue, 01 Nov 2011 16:56:44 +0000
Subject: [issue13313] test_time fails: tzset() do not change timezone
Message-ID: <1320166603.97.0.58939508903.issue13313@psf.upfronthosting.co.za>


New submission from Florent Xicluna <florent.xicluna at gmail.com>:

On builder "x86 FreeBSD 7.2 3.x" :

======================================================================
FAIL: test_tzset (test.test_time.TimeTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/test/test_time.py", line 246, in test_tzset
    self.assertTrue(time.tzname[0] == 'AEST', str(time.tzname[0]))
AssertionError: False is not true : EST


(See also issue #13309 for tzname on Gentoo)

----------
components: Library (Lib)
keywords: buildbot
messages: 146794
nosy: belopolsky, flox
priority: normal
severity: normal
stage: test needed
status: open
title: test_time fails: tzset() do not change timezone
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Tue Nov  1 17:56:44 2011
From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=)
Date: Tue, 01 Nov 2011 16:56:44 +0000
Subject: [issue12939] Add new io.FileIO using the native Windows API
In-Reply-To: <1315523941.29.0.146575875409.issue12939@psf.upfronthosting.co.za>
Message-ID: <1320166604.48.0.520699842693.issue12939@psf.upfronthosting.co.za>


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

> Why do you think it makes a difference?
Because adding one more dependency on unneeded libraries add the pain. Also it limit us on very restricted API of that wrapper. Windows native API is stable. So it's OK to rely on it's documented imlementation.

Suppose, we receive file-descriptor from _open_osfhandle.... For example it is a socket. It still unusable for stdin. Many standard functions does not work with such handle. The list of available functions : http://msdn.microsoft.com/en-us/library/kdfaxaay.aspx . As we see it is very narrow and function names are not POSIX-compatible (_chsize vs ftruncate). Documentation is very poor. For example, _close() is documented only here: http://msdn.microsoft.com/en-US/library/40bbyw78(v=VS.80).aspx .

----------

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

From report at bugs.python.org  Tue Nov  1 17:58:28 2011
From: report at bugs.python.org (Florent Xicluna)
Date: Tue, 01 Nov 2011 16:58:28 +0000
Subject: [issue13309] test_time fails: time data 'LMT' does not match format
	'%Z'
In-Reply-To: <1320156304.27.0.1872899991.issue13309@psf.upfronthosting.co.za>
Message-ID: <1320166708.03.0.418089580269.issue13309@psf.upfronthosting.co.za>


Changes by Florent Xicluna <florent.xicluna at gmail.com>:


----------
nosy: +belopolsky

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

From report at bugs.python.org  Tue Nov  1 18:02:45 2011
From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=)
Date: Tue, 01 Nov 2011 17:02:45 +0000
Subject: [issue12939] Add new io.FileIO using the native Windows API
In-Reply-To: <1315523941.29.0.146575875409.issue12939@psf.upfronthosting.co.za>
Message-ID: <1320166965.5.0.784407055829.issue12939@psf.upfronthosting.co.za>


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

The good example of implemetation is QT. I think we can get some things from this library. (Like using  "\\?\" for long paths (or always, as in QT)).

----------

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

From report at bugs.python.org  Tue Nov  1 18:11:10 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 01 Nov 2011 17:11:10 +0000
Subject: [issue12939] Add new io.FileIO using the native Windows API
In-Reply-To: <1320166604.48.0.520699842693.issue12939@psf.upfronthosting.co.za>
Message-ID: <1320167208.3355.4.camel@localhost.localdomain>


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

> > Why do you think it makes a difference?
> Because adding one more dependency on unneeded libraries add the pain.

MSVCRT is unneeded?? What are you talking about?

> Also it limit us on very restricted API of that wrapper. Windows
> native API is stable. So it's OK to rely on it's documented
> imlementation.

Please provide a patch to demonstrate the claimed improvement.

> Like using  "\\?\" for long paths

That's completely unrelated to this issue.

----------

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

From report at bugs.python.org  Tue Nov  1 18:49:44 2011
From: report at bugs.python.org (Florent Xicluna)
Date: Tue, 01 Nov 2011 17:49:44 +0000
Subject: [issue13309] test_time fails: time data 'LMT' does not match format
	'%Z'
In-Reply-To: <1320156304.27.0.1872899991.issue13309@psf.upfronthosting.co.za>
Message-ID: <1320169784.47.0.561545299261.issue13309@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

See also issue #13313 on timezone, seen on x86 FreeBSD 7.2

----------

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

From report at bugs.python.org  Tue Nov  1 19:02:27 2011
From: report at bugs.python.org (Rob Bairos)
Date: Tue, 01 Nov 2011 18:02:27 +0000
Subject: [issue13314] ImportError ImportError: Import by filename,
	should be deferred until sys.meta_path hooks are processed
Message-ID: <1320170547.3.0.447612016778.issue13314@psf.upfronthosting.co.za>


New submission from Rob Bairos <rbairos at gmail.com>:

When adding hooks to sys.meta_path, to correctly deal with arbitrarily named non-disk module definitions, module names with slashes should still be processed.

As it stands when executing statements such as:

import my_module_123#/123
or
even
__import__('my_module_123#/123')

the following exception is raised:

ImportError: Import by filename is not supported.

This stops sys.meta_path from handling arbitrarily named modules.

Shouldn't the ImportError be raised *after* the meta_path processing, at which point, its safe to assume the name is a disk name, in which case slashes are relevant?

----------
components: Interpreter Core
messages: 146799
nosy: Rob.Bairos
priority: normal
severity: normal
status: open
title: ImportError ImportError: Import by filename, should be deferred until sys.meta_path hooks are processed
versions: Python 3.2

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

From report at bugs.python.org  Tue Nov  1 19:05:34 2011
From: report at bugs.python.org (Rob Bairos)
Date: Tue, 01 Nov 2011 18:05:34 +0000
Subject: [issue13314] ImportError ImportError: Import by filename,
	should be deferred until sys.meta_path hooks are processed
In-Reply-To: <1320170547.3.0.447612016778.issue13314@psf.upfronthosting.co.za>
Message-ID: <1320170734.86.0.517436144638.issue13314@psf.upfronthosting.co.za>


Changes by Rob Bairos <rbairos at gmail.com>:


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

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

From report at bugs.python.org  Tue Nov  1 19:17:21 2011
From: report at bugs.python.org (Dave Flogeras)
Date: Tue, 01 Nov 2011 18:17:21 +0000
Subject: [issue13315] Unable to deal with large tarfile
Message-ID: <1320171441.51.0.618008041157.issue13315@psf.upfronthosting.co.za>


New submission from Dave Flogeras <dflogeras2 at gmail.com>:

I am trying to unpack boost_1_46_1.tar.bz2 (you can grab it here http://mirror.its.dal.ca/gentoo/distfiles/boost_1_46_1.tar.bz2) with the following code:

import tarfile
t = tarfile.open( "boost_1_46_1.tar.bz2" );
t.extractall()

On OSX (both Lion and Snow Leopard, so python 2.7.1 and 2.6.1 resp.) this works as a normal user, but not as root failing with:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/tarfile.py", line 2028, in extractall
    self.extract(tarinfo, path)
  File "/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/tarfile.py", line 2065, in extract
    self._extract_member(tarinfo, os.path.join(path, tarinfo.name))
  File "/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/tarfile.py", line 2157, in _extract_member
    self.chown(tarinfo, targetpath)
  File "/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/tarfile.py", line 2269, in chown
    os.chown(targetpath, u, g)
OverflowError: signed integer is greater than maximum

I have confirmed that Python is running as a 64bit application on OSX.


On my 64bit Linux (gentoo) machine, this works both as a user and as root. I tried with Python 2.7.2 as well as downgrading to 2.7.1.

This could be related to 1215928

----------
messages: 146800
nosy: Dave.Flogeras
priority: normal
severity: normal
status: open
title: Unable to deal with large tarfile
versions: Python 2.7

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

From report at bugs.python.org  Tue Nov  1 20:29:20 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Tue, 01 Nov 2011 19:29:20 +0000
Subject: [issue13254] maildir.items() broken
In-Reply-To: <1319447699.1.0.36723918452.issue13254@psf.upfronthosting.co.za>
Message-ID: <1320175760.01.0.173486103354.issue13254@psf.upfronthosting.co.za>


Petri Lehtinen <petri at digip.org> added the comment:

More specifically, this happens if the Maildir instance is created two seconds before items() is called:

>>> import time
>>> from mailbox import Maildir
>>> x = Maildir('test')  # has messages
>>> time.sleep(2.5)
>>> x.items()
[]

This happens because __init__() doesn't populate _toc, and mtimes haven't changed either, so _refresh() doesn't populate _toc either.

----------

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

From report at bugs.python.org  Tue Nov  1 20:38:37 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Tue, 01 Nov 2011 19:38:37 +0000
Subject: [issue7777] Support needed for AF_RDS family
In-Reply-To: <1264404460.15.0.913920533968.issue7777@psf.upfronthosting.co.za>
Message-ID: <1320176317.2.0.0434208933419.issue7777@psf.upfronthosting.co.za>


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

Here's a patch adding support for RDS sockets (with test and documentation update).

----------
keywords: +needs review, patch
nosy: +haypo, neologix, pitrou
stage: needs patch -> patch review
versions: +Python 3.3 -Python 2.7, Python 3.2
Added file: http://bugs.python.org/file23583/socket_rds.diff

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

From report at bugs.python.org  Tue Nov  1 21:04:04 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Tue, 01 Nov 2011 20:04:04 +0000
Subject: [issue13254] maildir.items() broken
In-Reply-To: <1319447699.1.0.36723918452.issue13254@psf.upfronthosting.co.za>
Message-ID: <1320177844.88.0.356537313223.issue13254@psf.upfronthosting.co.za>


Petri Lehtinen <petri at digip.org> added the comment:

Attached a patch. It makes _refresh() re-read the _toc uncoditionally when called the first time.

----------
keywords: +needs review, patch
stage: needs patch -> patch review
Added file: http://bugs.python.org/file23584/issue13254.patch

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

From report at bugs.python.org  Tue Nov  1 21:41:56 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 01 Nov 2011 20:41:56 +0000
Subject: [issue13315] Unable to deal with large tarfile
In-Reply-To: <1320171441.51.0.618008041157.issue13315@psf.upfronthosting.co.za>
Message-ID: <1320180116.05.0.114652332707.issue13315@psf.upfronthosting.co.za>


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

It's more likely an issue with the chown call. Indeed, the tar file contains a gid of 4294967295, which is too large for an int.  Normally this was fixed by issue1747858, which was included in Python 2.6.5 and 2.7.
Are you sure you have the same error with Python 2.7?

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

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

From report at bugs.python.org  Tue Nov  1 21:44:44 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 01 Nov 2011 20:44:44 +0000
Subject: [issue7777] Support needed for AF_RDS family
In-Reply-To: <1264404460.15.0.913920533968.issue7777@psf.upfronthosting.co.za>
Message-ID: <1320180284.7.0.497597595215.issue7777@psf.upfronthosting.co.za>


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

A couple of things:
- the tests are skipped with "unable to bind RDS socket" here (even under root). Is it expected?
- socket.error is the same as OSError now
- there are some ResourceWarnings abount unclosed sockets when running the tests

----------

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

From report at bugs.python.org  Tue Nov  1 21:45:31 2011
From: report at bugs.python.org (Eric V. Smith)
Date: Tue, 01 Nov 2011 20:45:31 +0000
Subject: [issue13314] ImportError ImportError: Import by filename,
	should be deferred until sys.meta_path hooks are processed
In-Reply-To: <1320170547.3.0.447612016778.issue13314@psf.upfronthosting.co.za>
Message-ID: <1320180331.89.0.0381297042011.issue13314@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/issue13314>
_______________________________________

From report at bugs.python.org  Tue Nov  1 22:01:06 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Tue, 01 Nov 2011 21:01:06 +0000
Subject: [issue13310] asyncore handling of out-of-band data fails
In-Reply-To: <1320163480.19.0.535971932001.issue13310@psf.upfronthosting.co.za>
Message-ID: <1320181266.08.0.55662939097.issue13310@psf.upfronthosting.co.za>


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

Hello Xavier,

> select (an poll) returns a read event and an exceptional condition 
> for the socket, but there is no normal data to read, only out-of-band
> data.

That's against POSIX:
"""
POLLIN
Data other than high-priority data may be read without blocking. For STREAMS, this flag is set in revents even if the message is of zero length. 
"""

And indeed, that's a known kernel regression introduced in 2.6.28, and fixed by this commit:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=b634f87522dff87712df8bda2a6c9061954d552a
http://kerneltrap.org/mailarchive/linux-netdev/2010/3/15/6271951

Note that there might still be a problem with the current code:
recv() can return EAGAIN on a FD reported readable/writable by select() (for example if the network stack received an input packet and then discards it because of an invalid checksum, or because the output socket buffer has room left but not enough to accomodate the packet we're trying to send): I'll have to think a bit to see if we can do something about this, but that's another issue.
Closing as invalid.

----------
nosy: +neologix
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Tue Nov  1 22:22:20 2011
From: report at bugs.python.org (simohe)
Date: Tue, 01 Nov 2011 21:22:20 +0000
Subject: [issue13316] build_py_2to3 does not execute when there was an error
	before
Message-ID: <1320182540.3.0.985799836702.issue13316@psf.upfronthosting.co.za>


New submission from simohe <simohe at besonet.ch>:

When I use build_py_2to3 and there is an error while converting a file with 2to3, convert is skipped on the next run.

The reason is that build_module in build_py_2to3 (in module distutils.command.build_py) only appends the file for converting when it is newly copied. Something safer should be used.
The simplest possibility is to always convert.

----------
components: Build
messages: 146807
nosy: simohe
priority: normal
severity: normal
status: open
title: build_py_2to3 does not execute when there was an error before
type: behavior
versions: Python 3.1

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

From report at bugs.python.org  Tue Nov  1 22:32:13 2011
From: report at bugs.python.org (simohe)
Date: Tue, 01 Nov 2011 21:32:13 +0000
Subject: [issue13317] building with 2to3 generates wrong import paths because
	build_ext is run after build_py
Message-ID: <1320183133.27.0.209500697705.issue13317@psf.upfronthosting.co.za>


New submission from simohe <simohe at besonet.ch>:

We need build_ext before build_py. Otherwise, when 2to3 is called (in build_py), it will not find ext modules, thinking that those modules are global and, consequently, making a mess, now that all module imports are global.

----------
components: 2to3 (2.x to 3.x conversion tool), Build
messages: 146808
nosy: simohe
priority: normal
severity: normal
status: open
title: building with 2to3 generates wrong import paths because build_ext is run after build_py

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

From report at bugs.python.org  Tue Nov  1 22:32:45 2011
From: report at bugs.python.org (simohe)
Date: Tue, 01 Nov 2011 21:32:45 +0000
Subject: [issue13316] build_py_2to3 does not execute when there was an error
	before
In-Reply-To: <1320182540.3.0.985799836702.issue13316@psf.upfronthosting.co.za>
Message-ID: <1320183165.8.0.671962491712.issue13316@psf.upfronthosting.co.za>


Changes by simohe <simohe at besonet.ch>:


----------
components: +2to3 (2.x to 3.x conversion tool)

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

From report at bugs.python.org  Tue Nov  1 22:33:16 2011
From: report at bugs.python.org (Florent Xicluna)
Date: Tue, 01 Nov 2011 21:33:16 +0000
Subject: [issue13254] maildir.items() broken
In-Reply-To: <1319447699.1.0.36723918452.issue13254@psf.upfronthosting.co.za>
Message-ID: <1320183196.56.0.047118760436.issue13254@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

The patch by Petri looks good.
I've uploaded a variant which set the initial mtimes to epoch instead of creating a _toc_read attribute. The tests are not changed.

----------
nosy: +flox
Added file: http://bugs.python.org/file23585/issue13254_v2.diff

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

From report at bugs.python.org  Tue Nov  1 22:34:37 2011
From: report at bugs.python.org (simohe)
Date: Tue, 01 Nov 2011 21:34:37 +0000
Subject: [issue13316] build_py_2to3 does not convert when there was an error
	in the last run
In-Reply-To: <1320182540.3.0.985799836702.issue13316@psf.upfronthosting.co.za>
Message-ID: <1320183277.71.0.948928220864.issue13316@psf.upfronthosting.co.za>


Changes by simohe <simohe at besonet.ch>:


----------
title: build_py_2to3 does not execute when there was an error before -> build_py_2to3 does not convert when there was an error in the last run
type: behavior -> 

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

From report at bugs.python.org  Tue Nov  1 22:36:31 2011
From: report at bugs.python.org (Florent Xicluna)
Date: Tue, 01 Nov 2011 21:36:31 +0000
Subject: [issue13254] maildir.items() broken
In-Reply-To: <1319447699.1.0.36723918452.issue13254@psf.upfronthosting.co.za>
Message-ID: <1320183391.29.0.427393900986.issue13254@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

Re-uploaded, because we can set initialize _last_read to 0 instead of time.time(). It is more consistent.

----------
Added file: http://bugs.python.org/file23586/issue13254_v2.diff

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

From report at bugs.python.org  Tue Nov  1 22:37:07 2011
From: report at bugs.python.org (Florent Xicluna)
Date: Tue, 01 Nov 2011 21:37:07 +0000
Subject: [issue13254] maildir.items() broken
In-Reply-To: <1319447699.1.0.36723918452.issue13254@psf.upfronthosting.co.za>
Message-ID: <1320183427.48.0.568034685018.issue13254@psf.upfronthosting.co.za>


Changes by Florent Xicluna <florent.xicluna at gmail.com>:


Removed file: http://bugs.python.org/file23585/issue13254_v2.diff

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

From report at bugs.python.org  Tue Nov  1 22:44:22 2011
From: report at bugs.python.org (Florent Xicluna)
Date: Tue, 01 Nov 2011 21:44:22 +0000
Subject: [issue13254] maildir.items() broken
In-Reply-To: <1319447699.1.0.36723918452.issue13254@psf.upfronthosting.co.za>
Message-ID: <1320183862.52.0.99725721348.issue13254@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

Finally, the patch can be only 5 lines...

----------
Added file: http://bugs.python.org/file23587/issue13254_v3.diff

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

From report at bugs.python.org  Tue Nov  1 22:44:43 2011
From: report at bugs.python.org (Ned Deily)
Date: Tue, 01 Nov 2011 21:44:43 +0000
Subject: [issue13315] Unable to deal with large tarfile
In-Reply-To: <1320171441.51.0.618008041157.issue13315@psf.upfronthosting.co.za>
Message-ID: <1320183883.96.0.814356999261.issue13315@psf.upfronthosting.co.za>


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

The issue is indeed with chown call. The call that fails has a gid of -1, truncated to 4294967295, which is a valid gid on OS X ('nogroup').  The Apple-supplied Python 2.7.1 in OS X 10.7 fails running under sudo as root:

Python 2.7.1 (r271:86832, Jun 16 2011, 16:59:05) 
[GCC 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2335.15.00)] on darwin
>>> os.chown('/tmp/c', 0, 4294967295)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
OverflowError: signed integer is greater than maximum

But the 64-bit OS X python.org 2.7.2 and current Python 2.7 builds do not fail.  The fix for Issue1747858 should be in all of them.  Investigating further.

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

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

From report at bugs.python.org  Tue Nov  1 22:50:55 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Tue, 01 Nov 2011 21:50:55 +0000
Subject: [issue7777] Support needed for AF_RDS family
In-Reply-To: <1264404460.15.0.913920533968.issue7777@psf.upfronthosting.co.za>
Message-ID: <1320184255.76.0.973225227257.issue7777@psf.upfronthosting.co.za>


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

> - the tests are skipped with "unable to bind RDS socket" here (even
> under root). Is it expected?

Oops. I did a quick test to force the socket family (because RDS sockets really use sockaddr_in), and apparently I overwrote my original patch... Here's the correct one.
As long as the `rds` module is loaded, all the tests should pass.

> - socket.error is the same as OSError now

I changed this in this patch.
I'll update the other occurrences in test_socket in a separate patch.

> - there are some ResourceWarnings abount unclosed sockets when
> running the tests

Same thing here, I fixed those in my original patch, then somehow overwrote it with a previous version...

----------
Added file: http://bugs.python.org/file23588/socket_rds-1.diff

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

From report at bugs.python.org  Tue Nov  1 23:06:00 2011
From: report at bugs.python.org (Ned Deily)
Date: Tue, 01 Nov 2011 22:06:00 +0000
Subject: [issue13315] Unable to deal with large tarfile
In-Reply-To: <1320171441.51.0.618008041157.issue13315@psf.upfronthosting.co.za>
Message-ID: <1320185160.0.0.0469402443648.issue13315@psf.upfronthosting.co.za>


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

For some reason, Apple is patching Modules/posixmodule.c in a way that reverts the fixes to chown in Issue1747858.  You can see the patches for their 10.7.2 python 2.7 here:

http://opensource.apple.com/source/python/python-57/2.7/fix/posixmodule.c.ed

It probably should be filed as a bug to Apple. They also have a number of other patches to posixmodule in there.  Ronald, any opinions?  In the mean time, marking this issue as pending invalid.

----------
nosy: +ronaldoussoren
resolution:  -> invalid
status: open -> pending

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

From report at bugs.python.org  Tue Nov  1 23:09:25 2011
From: report at bugs.python.org (Ned Deily)
Date: Tue, 01 Nov 2011 22:09:25 +0000
Subject: [issue13315] tarfile extract fails on OS X system python due to chown
	of gid=-1
In-Reply-To: <1320171441.51.0.618008041157.issue13315@psf.upfronthosting.co.za>
Message-ID: <1320185365.8.0.40968165806.issue13315@psf.upfronthosting.co.za>


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


----------
status: pending -> open
title: Unable to deal with large tarfile -> tarfile extract fails on OS X system python due to chown of gid=-1

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

From report at bugs.python.org  Tue Nov  1 23:09:49 2011
From: report at bugs.python.org (Ned Deily)
Date: Tue, 01 Nov 2011 22:09:49 +0000
Subject: [issue13315] tarfile extract fails on OS X system python due to chown
	of gid=-1
In-Reply-To: <1320171441.51.0.618008041157.issue13315@psf.upfronthosting.co.za>
Message-ID: <1320185389.71.0.700855428214.issue13315@psf.upfronthosting.co.za>


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


----------
status: open -> pending

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

From report at bugs.python.org  Tue Nov  1 23:35:25 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 01 Nov 2011 22:35:25 +0000
Subject: [issue2892] improve cElementTree iterparse error handling
In-Reply-To: <1210940435.5.0.243679200602.issue2892@psf.upfronthosting.co.za>
Message-ID: <E1RLMvN-0006Vu-Aa@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 23ffaf975267 by Florent Xicluna in branch '3.2':
Closes #2892: preserve iterparse events in case of SyntaxError.
http://hg.python.org/cpython/rev/23ffaf975267

New changeset ca1e2cf2947b by Florent Xicluna in branch 'default':
Merge 3.2: issue #2892
http://hg.python.org/cpython/rev/ca1e2cf2947b

New changeset e1dde980a92c by Florent Xicluna in branch '2.7':
Issue #2892: preserve iterparse events in case of SyntaxError
http://hg.python.org/cpython/rev/e1dde980a92c

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

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

From report at bugs.python.org  Tue Nov  1 23:54:07 2011
From: report at bugs.python.org (Chris Piekarski)
Date: Tue, 01 Nov 2011 22:54:07 +0000
Subject: [issue13318] Shelve second tier array subscript "[ ]" key creation
	doesn't work
Message-ID: <1320188047.41.0.331815392706.issue13318@psf.upfronthosting.co.za>


New submission from Chris Piekarski <chris at cpiekarski.com>:

Shelve object second tier array subscript key generation doesn't behave the same way dictionary object do.

>>> import shelve
>>> x = shelve.open("tst1.shelve")
>>> x["one"] = {}
>>> x
{'one': {}}
>>> x["one"]["two"] = 2
>>> x
{'one': {}}

Whereas with a dictionary it works:

>>> y = {}
>>> y["one"] = {}
>>> y["one"]["two"] = 2
>>> y
{'one': {'two': 2}}

----------
components: None
messages: 146816
nosy: cpiekarski
priority: normal
severity: normal
status: open
title: Shelve second tier array subscript "[ ]" key creation doesn't work
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Wed Nov  2 00:23:59 2011
From: report at bugs.python.org (Ned Deily)
Date: Tue, 01 Nov 2011 23:23:59 +0000
Subject: [issue13318] Shelve second tier array subscript "[ ]" key creation
	doesn't work
In-Reply-To: <1320188047.41.0.331815392706.issue13318@psf.upfronthosting.co.za>
Message-ID: <1320189839.92.0.283273971606.issue13318@psf.upfronthosting.co.za>


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

shelve is behaving as documented.  Because the shelve dictionary entry is mutable (a dictionary), you need to set writeback=True to get the behavior you expect.  http://docs.python.org/library/shelve.html

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

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

From report at bugs.python.org  Wed Nov  2 01:28:37 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 02 Nov 2011 00:28:37 +0000
Subject: [issue13312] test_time fails: strftime('%Y', y) for negative year
In-Reply-To: <1320166359.06.0.160451222607.issue13312@psf.upfronthosting.co.za>
Message-ID: <E1RLOgu-0007NV-Pm@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 9cb1b85237a9 by Florent Xicluna in branch 'default':
Issue #13312: skip the single failing value for now.
http://hg.python.org/cpython/rev/9cb1b85237a9

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

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

From report at bugs.python.org  Wed Nov  2 02:03:57 2011
From: report at bugs.python.org (Roger Serwy)
Date: Wed, 02 Nov 2011 01:03:57 +0000
Subject: [issue13319] IDLE: Menu accelerator conflict between Format and
	Options
Message-ID: <1320195837.58.0.031082649983.issue13319@psf.upfronthosting.co.za>


New submission from Roger Serwy <roger.serwy at gmail.com>:

This is a minor interface issue. The accelerator for opening the _Options menu in an editor conflicts with the F_ormat menu. 

I suggest changing the Options accelerator to "i" since Alt-t is for toggling tabs. (Perhaps the accelerator for <<toggle-tabs>> should be dropped, so that the options menu could be accessed by Alt-t.)

----------
components: IDLE
messages: 146819
nosy: serwy
priority: normal
severity: normal
status: open
title: IDLE: Menu accelerator conflict between Format and Options
type: feature request
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/issue13319>
_______________________________________

From report at bugs.python.org  Wed Nov  2 02:04:47 2011
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 02 Nov 2011 01:04:47 +0000
Subject: [issue13306] Add diagnostic tools to importlib?
In-Reply-To: <1320098820.25.0.925823454462.issue13306@psf.upfronthosting.co.za>
Message-ID: <1320195887.22.0.0516093847443.issue13306@psf.upfronthosting.co.za>


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

If it is importlib._diagnostics then I'm fine with it, but I definitely don't want it exposed in a public API.

----------

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

From report at bugs.python.org  Wed Nov  2 02:17:14 2011
From: report at bugs.python.org (Inverness)
Date: Wed, 02 Nov 2011 01:17:14 +0000
Subject: [issue13320] _remove_visual_c_ref in distutils.msvc9compiler causes
	DLL load fail with embedded Python and multiple CRT versions
Message-ID: <1320196634.59.0.302796026714.issue13320@psf.upfronthosting.co.za>


New submission from Inverness <inverness910 at gmail.com>:

I am using a custom Python executable for an application I'm developing. I also build PYDs to extend this Python environment. I decided to upgrade them and my executable to use Visual C++ 10 while the Python DLL and other third party PYDs, specifically wxPython, continued to use Visual C++ 9. Doing this did not cause an issue in and of itself, however, my wxPython release, but not debug, PYDs were failing to load the VC9 CRT.

I discovered this is a result of MSVCCompiler._remove_visual_c_ref() being called in the module disutils.msvc9compiler. I had to comment out this line in order to rebuild wxPython and get my program running correctly.

I'm requesting this feature of the compiler be made optional.

----------
components: Library (Lib)
messages: 146821
nosy: Inverness
priority: normal
severity: normal
status: open
title: _remove_visual_c_ref in distutils.msvc9compiler causes DLL load fail with embedded Python and multiple CRT versions
type: feature request
versions: Python 2.7

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

From report at bugs.python.org  Wed Nov  2 03:00:15 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 02 Nov 2011 02:00:15 +0000
Subject: [issue13320] _remove_visual_c_ref in distutils.msvc9compiler causes
	DLL load fail with embedded Python and multiple CRT versions
In-Reply-To: <1320196634.59.0.302796026714.issue13320@psf.upfronthosting.co.za>
Message-ID: <1320199215.22.0.910655049709.issue13320@psf.upfronthosting.co.za>


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


----------
assignee:  -> tarek
components: +Distutils, Distutils2
nosy: +alexis, eric.araujo, loewis, tarek
versions: +Python 3.3 -Python 2.7

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

From report at bugs.python.org  Wed Nov  2 03:17:10 2011
From: report at bugs.python.org (Meador Inge)
Date: Wed, 02 Nov 2011 02:17:10 +0000
Subject: [issue13298] Result type depends on order of operands for bytes and
	bytearray
In-Reply-To: <1320020077.78.0.866789839878.issue13298@psf.upfronthosting.co.za>
Message-ID: <1320200230.4.0.538650657249.issue13298@psf.upfronthosting.co.za>


Changes by Meador Inge <meadori at gmail.com>:


----------
nosy: +meador.inge

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

From report at bugs.python.org  Wed Nov  2 03:22:57 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 02 Nov 2011 02:22:57 +0000
Subject: [issue13312] test_time fails: strftime('%Y', y) for negative year
In-Reply-To: <1320166359.06.0.160451222607.issue13312@psf.upfronthosting.co.za>
Message-ID: <E1RLQTS-0007CP-Od@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset d877d7f3b679 by Florent Xicluna in branch 'default':
Actually, there's more than one failing value. (changeset 9cb1b85237a9, issue #13312).
http://hg.python.org/cpython/rev/d877d7f3b679

----------

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

From report at bugs.python.org  Wed Nov  2 05:04:12 2011
From: report at bugs.python.org (Matt Joiner)
Date: Wed, 02 Nov 2011 04:04:12 +0000
Subject: [issue13321] fstat doesn't accept an object with "fileno" method
Message-ID: <1320206652.2.0.972235455602.issue13321@psf.upfronthosting.co.za>


New submission from Matt Joiner <anacrolix at gmail.com>:

os.fstat doesn't not accept an object with the fileno() method.

Probably a bunch of other similar functions will not either.

In some parts of the standard library it's common practice to call PyObject_AsFileDescriptor on fd-wrapping arguments.

http://hg.python.org/cpython/file/d877d7f3b679/Modules/posixmodule.c#l7319
http://hg.python.org/cpython/file/d877d7f3b679/Objects/fileobject.c#l196

----------
components: Library (Lib)
messages: 146823
nosy: anacrolix
priority: normal
severity: normal
status: open
title: fstat doesn't accept an object with "fileno" method
type: behavior
versions: Python 3.2, Python 3.3

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

From report at bugs.python.org  Wed Nov  2 05:05:18 2011
From: report at bugs.python.org (Matt Joiner)
Date: Wed, 02 Nov 2011 04:05:18 +0000
Subject: [issue12684] profile does not dump stats on exception like cProfile
	does
In-Reply-To: <1312335798.44.0.743453347572.issue12684@psf.upfronthosting.co.za>
Message-ID: <1320206718.09.0.516759321699.issue12684@psf.upfronthosting.co.za>


Changes by Matt Joiner <anacrolix at gmail.com>:


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

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

From report at bugs.python.org  Wed Nov  2 05:06:22 2011
From: report at bugs.python.org (Matt Joiner)
Date: Wed, 02 Nov 2011 04:06:22 +0000
Subject: [issue12684] profile does not dump stats on exception like cProfile
	does
In-Reply-To: <1312335798.44.0.743453347572.issue12684@psf.upfronthosting.co.za>
Message-ID: <1320206782.91.0.792894630171.issue12684@psf.upfronthosting.co.za>


Matt Joiner <anacrolix at gmail.com> added the comment:

Also affects 3.3.

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

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

From report at bugs.python.org  Wed Nov  2 07:09:09 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Wed, 02 Nov 2011 06:09:09 +0000
Subject: [issue13254] maildir.items() broken
In-Reply-To: <1319447699.1.0.36723918452.issue13254@psf.upfronthosting.co.za>
Message-ID: <1320214149.98.0.333337271722.issue13254@psf.upfronthosting.co.za>


Petri Lehtinen <petri at digip.org> added the comment:

The last patch looks good to me and is a clever approach indeed :)

----------

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

From report at bugs.python.org  Wed Nov  2 07:34:33 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Wed, 02 Nov 2011 06:34:33 +0000
Subject: [issue13271] When -h is used with argparse,
	default values that fail should not matter
In-Reply-To: <1319664352.05.0.511704738067.issue13271@psf.upfronthosting.co.za>
Message-ID: <1320215673.67.0.856961090449.issue13271@psf.upfronthosting.co.za>


Petri Lehtinen <petri at digip.org> added the comment:

Sounds like a but to me, too.

----------
stage:  -> test needed
versions: +Python 2.7, Python 3.2

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

From report at bugs.python.org  Wed Nov  2 08:04:32 2011
From: report at bugs.python.org (Florent Xicluna)
Date: Wed, 02 Nov 2011 07:04:32 +0000
Subject: [issue13312] test_time fails: strftime('%Y', y) for negative year
In-Reply-To: <1320166359.06.0.160451222607.issue13312@psf.upfronthosting.co.za>
Message-ID: <1320217472.3.0.653912921389.issue13312@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

It fails for very low negative years:
  -2147481749     <= year <= -2147483648
  (-1<<31) + 1900 <= year <= (-1<<31)

Every other value behaves correctly on this FreeBSD buildbot:
 - (-1<<31) + 1900 < year < (+1<<31) : correctly formatted with '%Z'
 - year <  (-1<<31) : raises OverfowError
 - year >= (+1<<31) : raises OverfowError

----------

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

From report at bugs.python.org  Wed Nov  2 08:09:11 2011
From: report at bugs.python.org (Florent Xicluna)
Date: Wed, 02 Nov 2011 07:09:11 +0000
Subject: [issue13312] test_time fails: strftime('%Y', y) for negative year
In-Reply-To: <1320166359.06.0.160451222607.issue13312@psf.upfronthosting.co.za>
Message-ID: <1320217751.02.0.267420580632.issue13312@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

It fails for very low negative years:
  -2147483648 <= year < -2147481748 
  (-1<<31)    <= year < (-1<<31) + 1900 

Every other value behaves correctly on this FreeBSD buildbot:
 - (-1<<31) + 1900 <= year < (+1<<31) : correctly formatted with '%Z'
 - year <  (-1<<31) : raises OverfowError
 - year >= (+1<<31) : raises OverfowError

----------

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

From report at bugs.python.org  Wed Nov  2 08:09:26 2011
From: report at bugs.python.org (Florent Xicluna)
Date: Wed, 02 Nov 2011 07:09:26 +0000
Subject: [issue13312] test_time fails: strftime('%Y', y) for negative year
In-Reply-To: <1320166359.06.0.160451222607.issue13312@psf.upfronthosting.co.za>
Message-ID: <1320217766.41.0.886076121888.issue13312@psf.upfronthosting.co.za>


Changes by Florent Xicluna <florent.xicluna at gmail.com>:


----------
Removed message: http://bugs.python.org/msg146827

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

From report at bugs.python.org  Wed Nov  2 08:11:13 2011
From: report at bugs.python.org (Florent Xicluna)
Date: Wed, 02 Nov 2011 07:11:13 +0000
Subject: [issue13312] test_time fails: strftime('%Y', y) for negative year
In-Reply-To: <1320166359.06.0.160451222607.issue13312@psf.upfronthosting.co.za>
Message-ID: <1320217873.37.0.878952319471.issue13312@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

I mean formatted with '%Y', of course.

----------

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

From report at bugs.python.org  Wed Nov  2 08:14:15 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 02 Nov 2011 07:14:15 +0000
Subject: [issue13312] test_time fails: strftime('%Y', y) for negative year
In-Reply-To: <1320166359.06.0.160451222607.issue13312@psf.upfronthosting.co.za>
Message-ID: <E1RLV1T-00044w-6O@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 1a0bfc26af57 by Florent Xicluna in branch 'default':
Issue #13312: skip the failing negative years for now.
http://hg.python.org/cpython/rev/1a0bfc26af57

----------

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

From report at bugs.python.org  Wed Nov  2 08:14:38 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Wed, 02 Nov 2011 07:14:38 +0000
Subject: [issue13321] fstat doesn't accept an object with "fileno" method
In-Reply-To: <1320206652.2.0.972235455602.issue13321@psf.upfronthosting.co.za>
Message-ID: <1320218078.09.0.474756676821.issue13321@psf.upfronthosting.co.za>


Petri Lehtinen <petri at digip.org> added the comment:

This is a request for new functionality, so marking as a feature request for 3.3. If implemented, the change should be applied to many other functions, in the os module at least.

I'm not sure whether this is very useful, though. The fstat(f.fileno()) idiom doesn't require that much writing and makes it explicit that we're operating on an underlying file descriptor. Furthermore, funtions in the os module are low-level and map very closely to the underlying C API.

----------
nosy: +benjamin.peterson, petri.lehtinen, pitrou, stutzbach
type: behavior -> feature request
versions:  -Python 3.2

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

From report at bugs.python.org  Wed Nov  2 08:41:34 2011
From: report at bugs.python.org (Jyrki Pulliainen)
Date: Wed, 02 Nov 2011 07:41:34 +0000
Subject: [issue13147] Multiprocessing Pool.map_async() does not have an
	error_callback parameter
In-Reply-To: <1318289870.89.0.681252830912.issue13147@psf.upfronthosting.co.za>
Message-ID: <1320219694.73.0.248776060968.issue13147@psf.upfronthosting.co.za>


Jyrki Pulliainen <jyrki at dywypi.org> added the comment:

Python 3.x seems to have the error_callback parameter on all *_async operations. However, 2.7 lacks it. I think adding the actual error_callback would be deemed as a new feature, so the right thing would just be removing the documentation.

I'll whip up a patch to remove this from the documentation

----------
nosy: +nailor

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

From report at bugs.python.org  Wed Nov  2 08:50:01 2011
From: report at bugs.python.org (Jyrki Pulliainen)
Date: Wed, 02 Nov 2011 07:50:01 +0000
Subject: [issue13147] Multiprocessing Pool.map_async() does not have an
	error_callback parameter
In-Reply-To: <1318289870.89.0.681252830912.issue13147@psf.upfronthosting.co.za>
Message-ID: <1320220201.61.0.204516555811.issue13147@psf.upfronthosting.co.za>


Jyrki Pulliainen <jyrki at dywypi.org> added the comment:

Patch attached. This patch removes the error_callback from 2.7's documentation.

----------
keywords: +patch
Added file: http://bugs.python.org/file23589/issue13147.patch

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

From report at bugs.python.org  Wed Nov  2 08:53:07 2011
From: report at bugs.python.org (Jyrki Pulliainen)
Date: Wed, 02 Nov 2011 07:53:07 +0000
Subject: [issue13147] Multiprocessing Pool.map_async() does not have an
	error_callback parameter
In-Reply-To: <1318289870.89.0.681252830912.issue13147@psf.upfronthosting.co.za>
Message-ID: <1320220387.31.0.743737905258.issue13147@psf.upfronthosting.co.za>


Jyrki Pulliainen <jyrki at dywypi.org> added the comment:

Also: note that 2.6 does not document this error_callback, so the issue is present only in 2.7

----------

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

From report at bugs.python.org  Wed Nov  2 08:55:08 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Wed, 02 Nov 2011 07:55:08 +0000
Subject: [issue13147] Multiprocessing Pool.map_async() does not have an
	error_callback parameter
In-Reply-To: <1318289870.89.0.681252830912.issue13147@psf.upfronthosting.co.za>
Message-ID: <1320220508.62.0.260555272549.issue13147@psf.upfronthosting.co.za>


Changes by Petri Lehtinen <petri at digip.org>:


----------
keywords: +needs review
nosy: +petri.lehtinen
stage:  -> patch review

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

From report at bugs.python.org  Wed Nov  2 09:24:16 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Wed, 02 Nov 2011 08:24:16 +0000
Subject: [issue12709] In multiprocessing,
	error_callback isn't documented for map_async
In-Reply-To: <1312798209.69.0.295149725931.issue12709@psf.upfronthosting.co.za>
Message-ID: <1320222256.58.0.43519095861.issue12709@psf.upfronthosting.co.za>


Petri Lehtinen <petri at digip.org> added the comment:

Sandro: The error_callback parameter is not available on 2.7. See #13147.

----------
nosy: +petri.lehtinen

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

From report at bugs.python.org  Wed Nov  2 11:29:08 2011
From: report at bugs.python.org (Xavier de Gaye)
Date: Wed, 02 Nov 2011 10:29:08 +0000
Subject: [issue13310] asyncore handling of out-of-band data fails
In-Reply-To: <1320163480.19.0.535971932001.issue13310@psf.upfronthosting.co.za>
Message-ID: <1320229748.8.0.167105610758.issue13310@psf.upfronthosting.co.za>


Xavier de Gaye <xdegaye at gmail.com> added the comment:

Hi Charles-Fran?ois,

> And indeed, that's a known kernel regression introduced in 2.6.28,
> and fixed by this commit:
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=b634f87522dff87712df8bda2a6c9061954d552a
> http://kerneltrap.org/mailarchive/linux-netdev/2010/3/15/6271951

The BlockingIOError exception occurs on linux 2.6.30 for me.


> Note that there might still be a problem with the current code:
> recv() can return EAGAIN on a FD reported readable/writable by
> select() (for example if the network stack received an input packet
> and then discards it because of an invalid checksum, or because the
> output socket buffer has room left but not enough to accomodate the
> packet we're trying to send): I'll have to think a bit to see if we
> can do something about this, but that's another issue.

It is not clear why recv() can return EAGAIN because we're trying to
_send_ a packet ;-)


> Closing as invalid

Ok, 2.6.30 is an old kernel and urgent data is mostly never used.

----------

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

From report at bugs.python.org  Wed Nov  2 13:54:23 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 02 Nov 2011 12:54:23 +0000
Subject: [issue12939] Add new io.FileIO using the native Windows API
In-Reply-To: <1320149556.55.0.578691892106.issue12939@psf.upfronthosting.co.za>
Message-ID: <201111021355.46524.victor.stinner@haypocalc.com>


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

> Instead of rewriting your own RawIO implementation, why not use
> _open_osfhandle?

I don't know yet what is the best approach. One important point is to keep the 
HANDLE, to be able to manipulate the open file using the Windows API (e.g. call 
WriteFile instead of write).

I propose a RawIO to call directly the Windows API: file.write() would call 
directly WriteFile() instead of the POSIX wrapper (write()).

We may use it to implement new features like async I/O on Windows (e.g. 
WriteFileEx).

Modules/_multiprocessing/win32_functions.c exposes already some low-level 
Windows functions like WriteFile(). We may reuse the RawIO to offer an object 
oriented API for the Windows multiprocessing pipes. Such RawIO would have 
extra methods, maybe a file.WriteFile() method to give access to extra options 
like "overlapped".

----------

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

From report at bugs.python.org  Wed Nov  2 14:00:04 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 02 Nov 2011 13:00:04 +0000
Subject: [issue13321] fstat doesn't accept an object with "fileno" method
In-Reply-To: <1320206652.2.0.972235455602.issue13321@psf.upfronthosting.co.za>
Message-ID: <1320238804.23.0.906959367767.issue13321@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <benjamin at python.org>:


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

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

From report at bugs.python.org  Wed Nov  2 15:17:39 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Wed, 02 Nov 2011 14:17:39 +0000
Subject: [issue13310] asyncore handling of out-of-band data fails
In-Reply-To: <1320229748.8.0.167105610758.issue13310@psf.upfronthosting.co.za>
Message-ID: <CAH_1eM15yo-3m_d5Arc6rRiDPpEFChKm2vjEGCbMkqY6hMsfaw@mail.gmail.com>


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

> It is not clear why recv() can return EAGAIN because we're trying to
> _send_ a packet ;-)

Well, I was refering to a problem with the current implementation, not
limited to this specific example.

>> Closing as invalid
>
> Ok, 2.6.30 is an old kernel and urgent data is mostly never used.

I'll update test_asyncore to actually call recv(MSG_OOB), it's
probably a good idea to check that (hopefuly it won't break on OS
X...).

----------

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

From report at bugs.python.org  Wed Nov  2 15:27:28 2011
From: report at bugs.python.org (Mikhail I. Izmestev)
Date: Wed, 02 Nov 2011 14:27:28 +0000
Subject: [issue13284] email.utils.formatdate function does not handle
	timezones correctly.
In-Reply-To: <1319797564.66.0.629117270841.issue13284@psf.upfronthosting.co.za>
Message-ID: <1320244048.96.0.227503445028.issue13284@psf.upfronthosting.co.za>


Mikhail I. Izmestev <izmmishao5 at gmail.com> added the comment:

I have strange behavior too:

im at cgt-serv ~ $ python
Python 2.6.6 (r266:84292, Feb 28 2011, 09:01:15)
[GCC 4.3.4] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from email.Utils import formatdate
>>> import time
>>> time.strftime("%a, %d %b %Y %T %z")
'Wed, 02 Nov 2011 18:21:08 +0400'
>>> formatdate(localtime=True)
'Wed, 02 Nov 2011 18:21:28 +0300'
>>>

----------
nosy: +izmmisha

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

From report at bugs.python.org  Wed Nov  2 15:53:48 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 02 Nov 2011 14:53:48 +0000
Subject: [issue3990] The Linux2 platform definition is incorrect for alpha,
	hppa, mips, sparc
In-Reply-To: <1222622636.83.0.91904211749.issue3990@psf.upfronthosting.co.za>
Message-ID: <1320245628.7.0.995945072098.issue3990@psf.upfronthosting.co.za>


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

A proposal by Martin in a python-dev email:

> I'd generate four versions of CDROM.py (with differing names), and
> provide a CDROM.py that imports the right one.

----------
keywords: +easy -patch
stage:  -> needs patch

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

From report at bugs.python.org  Wed Nov  2 16:08:55 2011
From: report at bugs.python.org (sbt)
Date: Wed, 02 Nov 2011 15:08:55 +0000
Subject: [issue13322] buffered read() and write() does not raise
	BlockingIOError
Message-ID: <1320246535.71.0.465783773129.issue13322@psf.upfronthosting.co.za>


New submission from sbt <shibturn at gmail.com>:

According to the the documentation, BufferedReader.read() and BufferedWriter.write() should raise io.BlockingIOError if the file is in non-blocking mode and the operation cannot succeed without blocking.

However, BufferedReader.read() returns None (which is what RawIOBase.read() is documented as doing), and BufferedWriter.write() raises IOError with a message like

    raw write() returned invalid length -1 (should have been 
    between 0 and 5904)

I tested this on Linux with Python 2.6, 2.7 and 3.x.

Attached is a unit test.

----------
files: blockingioerror.py
messages: 146841
nosy: sbt
priority: normal
severity: normal
status: open
title: buffered read() and write() does not raise BlockingIOError
Added file: http://bugs.python.org/file23590/blockingioerror.py

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

From report at bugs.python.org  Wed Nov  2 16:12:32 2011
From: report at bugs.python.org (sbt)
Date: Wed, 02 Nov 2011 15:12:32 +0000
Subject: [issue13322] buffered read() and write() does not raise
	BlockingIOError
In-Reply-To: <1320246535.71.0.465783773129.issue13322@psf.upfronthosting.co.za>
Message-ID: <1320246752.26.0.0968701657001.issue13322@psf.upfronthosting.co.za>


Changes by sbt <shibturn at gmail.com>:


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

From report at bugs.python.org  Wed Nov  2 16:39:12 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 02 Nov 2011 15:39:12 +0000
Subject: [issue13322] buffered read() and write() does not raise
	BlockingIOError
In-Reply-To: <1320246535.71.0.465783773129.issue13322@psf.upfronthosting.co.za>
Message-ID: <1320248352.82.0.381256609125.issue13322@psf.upfronthosting.co.za>


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


----------
components: +IO, Library (Lib)
nosy: +pitrou
versions:  -Python 2.6, Python 3.1, Python 3.4

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

From report at bugs.python.org  Wed Nov  2 17:06:06 2011
From: report at bugs.python.org (David Fischer)
Date: Wed, 02 Nov 2011 16:06:06 +0000
Subject: [issue13323] urllib2 does not correctly handle multiple
	www-authenticate headers in an HTTP response
Message-ID: <1320249966.17.0.892468926199.issue13323@psf.upfronthosting.co.za>


New submission from David Fischer <dfischer at ucsdmail.com>:

I ran into an application that responded with two www-authenticate challenges  to an HTTP request. First, it sends a standard Basic authentication challenge and then it also returns a www-authenticate header referencing another scheme. This looks legal to me according to rfc2617.

However, the regex in AbstractBasicAuthHandler that parses the www-authenticate header only grabs one of the challenges (the last one) and therefore urllib2 will not respond to the challenge with credentials.

----------
messages: 146842
nosy: dfischer
priority: normal
severity: normal
status: open
title: urllib2 does not correctly handle multiple www-authenticate headers in an HTTP response
versions: Python 2.7

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

From report at bugs.python.org  Wed Nov  2 17:20:26 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Wed, 02 Nov 2011 16:20:26 +0000
Subject: [issue13323] urllib2 does not correctly handle multiple
	www-authenticate headers in an HTTP response
In-Reply-To: <1320249966.17.0.892468926199.issue13323@psf.upfronthosting.co.za>
Message-ID: <1320250826.83.0.870922970107.issue13323@psf.upfronthosting.co.za>


Changes by Senthil Kumaran <senthil at uthcode.com>:


----------
assignee:  -> orsenthil
nosy: +orsenthil

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

From report at bugs.python.org  Wed Nov  2 17:29:00 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Wed, 02 Nov 2011 16:29:00 +0000
Subject: [issue13303] Sporadic importlib failures: FileNotFoundError on
	os.rename()
In-Reply-To: <1320058871.09.0.581986884521.issue13303@psf.upfronthosting.co.za>
Message-ID: <1320251340.89.0.927849038846.issue13303@psf.upfronthosting.co.za>


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

mkstemp() creates the file with mode 0600, which can be surprising.
I'm note sure about the best way to handle this:
1) change the file mode after creating it with fchmod(), using the source file mode. But we must also take into account the umask, so we'd have to do:
mask = umask(0); 
umask(mask);
[...]
fd = mkstemp(cpathname_tmp)
fchmod(fd, mode & ~mask);

The double call to umask() is necessary because we can't just retrieve the umask
2) don't use mkstemp(), and use something like:

    sprintf(cpathname_tmp, "%s.%x", cpathname, 0xffff & getpid());

    d = open(cpathname_tmp, O_WRONLY|O_CREAT|O_EXCL);

to mimic what's done in Lib/importlib/_bootstrap.py (pseudo-temp file).

3) Fall back to the original ".tmp" suffix (with the risk of stale tmp file).

Thoughts?

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

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

From report at bugs.python.org  Wed Nov  2 17:31:12 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 02 Nov 2011 16:31:12 +0000
Subject: [issue13224] Change str(class) to return only the class name
In-Reply-To: <1319053532.35.0.636674659737.issue13224@psf.upfronthosting.co.za>
Message-ID: <1320251472.15.0.803496603612.issue13224@psf.upfronthosting.co.za>


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

I?ve updated my patch to handle modules and functions too, but there is a decision to make.  The functions of built-in modules are implemented by methodobject.c, not functionobject.c (that?s for Python functions), so if we want str(sys.exc_info) to be equal to 'exc_info', then we?ll have str(dict.update) == 'update'.  Is this okay?

The patch needs a review.

- I tried using PyUnicode_FromString(name) instead of PyUnicode_FromFormat("%U", name), just like in Python I would use str(x) instead of '%s' % x, but this caused segfaults.  Is there a simpler function to use?

- I?ve used copy-paste-tweak and checked the results; I?m still learning C and know very little about Python?s types and refcounting internals, so review mercilessly!  I forgot to run the tests in findleaks mode, so I?m doing it right now.

----------
Added file: http://bugs.python.org/file23591/change-some-__str__.diff

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

From report at bugs.python.org  Wed Nov  2 17:50:09 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 02 Nov 2011 16:50:09 +0000
Subject: [issue13307] bdist_rpm: INSTALLED_FILES does not use __pycache__
In-Reply-To: <1320100717.66.0.765161985418.issue13307@psf.upfronthosting.co.za>
Message-ID: <1320252609.15.0.474981484581.issue13307@psf.upfronthosting.co.za>


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

bdist_rpm uses the record option of install to create INSTALLED_FILES.

install delegates to the get_output method of install_* commands to build its record.

install_lib has buggy code that appends 'c' or 'o' instead of using imp functions.  I have expanded one test and successfully reproduced the bug; next I will fix the code.

----------
assignee:  -> eric.araujo
components: +Distutils, Distutils2
nosy: +alexis
title: test_bdist_rpm: INSTALLED_FILES does not use __pycache__ -> bdist_rpm: INSTALLED_FILES does not use __pycache__
versions: +3rd party, Python 3.2

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

From report at bugs.python.org  Wed Nov  2 17:51:14 2011
From: report at bugs.python.org (Alex Stewart)
Date: Wed, 02 Nov 2011 16:51:14 +0000
Subject: [issue13324] fcntl module doesn't support F_NOCACHE (OS X specific)
	results in high 'inactive' memory performance issues
Message-ID: <1320252674.88.0.834289126042.issue13324@psf.upfronthosting.co.za>


New submission from Alex Stewart <alexs.mac at gmail.com>:

----------------------------
ISSUE DESCRIPTION: 
----------------------------
In 2.6.7, 2.7.2 and also HEAD (r 73301) the fcntl module does not support the F_NOCACHE OSX specific mode.  

The affect of this is that the default behaviour (data caching enabled) is used when parsing files etc.  When data caching is enabled, OSX caches the data parsed from a file by python, keeping it available as 'inactive memory' even when it has been freed by python.  In *theory*, this should be fine as OSX *should* recycle the inactive memory as it is required.  

Unfortunately, at least under OSX 10.6.8 (and it seems 10.7) the system will do almost anything to avoid recycling inactive memory, including swallowing up all 'pure' free memory and then paging manically to the disk.  The net affect of this is significantly degraded system performance.

For most users, operating with relatively small files and a large quantity of RAM this issue is probably not that obvious.  However, for various reasons I'm working with files of 5-125+GB and thus it rapidly becomes a major issue.

----------------------------
FIX
----------------------------
Very simply, all the attached patch does it add support for F_NOCACHE to fcntl just like F_FULLFSYNC (another fcntl OSX specific flag) - it's a trivial change that allows you to control whether OSX uses data caching on a file handle, e.g, the following turns OFF data caching for the specified file:

fcntl.fcntl(theFile.fileno(), fcntl.F_NOCACHE, 1)

With this patch in place the inactive memory on my system stays (low) and flat, without it it rises until it maxes out all available memory and then starts paging.

----------
components: Extension Modules
files: fcntlmodule.patch
keywords: patch
messages: 146846
nosy: Alex.Stewart, ned.deily, ronaldoussoren
priority: normal
severity: normal
status: open
title: fcntl module doesn't support F_NOCACHE (OS X specific) results in high 'inactive' memory performance issues
type: resource usage
versions: Python 2.6, Python 2.7
Added file: http://bugs.python.org/file23592/fcntlmodule.patch

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

From report at bugs.python.org  Wed Nov  2 17:51:44 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 02 Nov 2011 16:51:44 +0000
Subject: [issue13320] _remove_visual_c_ref in distutils.msvc9compiler causes
	DLL load fail with embedded Python and multiple CRT versions
In-Reply-To: <1320196634.59.0.302796026714.issue13320@psf.upfronthosting.co.za>
Message-ID: <1320252704.12.0.379004737353.issue13320@psf.upfronthosting.co.za>


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

Mark, can you give feedback?

----------
nosy: +mhammond

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

From report at bugs.python.org  Wed Nov  2 17:53:01 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 02 Nov 2011 16:53:01 +0000
Subject: [issue12629] HTMLParser silently stops parsing with malformed
	attributes
In-Reply-To: <1311532507.83.0.00235537878353.issue12629@psf.upfronthosting.co.za>
Message-ID: <1320252781.05.0.675211612199.issue12629@psf.upfronthosting.co.za>


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

> This is what Firefox seems to do.
I think more confidence would be good.  Doesn?t the HTML5 spec define that?  Have you found their test suite?  Do you have more than one browser known to be compliant (trick: not sure there is even one)?

----------

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

From report at bugs.python.org  Wed Nov  2 17:54:11 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 02 Nov 2011 16:54:11 +0000
Subject: [issue13307] bdist_rpm: INSTALLED_FILES does not use __pycache__
In-Reply-To: <1320100717.66.0.765161985418.issue13307@psf.upfronthosting.co.za>
Message-ID: <1320252851.36.0.283679991765.issue13307@psf.upfronthosting.co.za>


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


----------
dependencies: +distutils doesn't byte-compile .py files to __pycache__ during installation

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

From report at bugs.python.org  Wed Nov  2 17:55:02 2011
From: report at bugs.python.org (Xavier de Gaye)
Date: Wed, 02 Nov 2011 16:55:02 +0000
Subject: [issue13325] no address in the representation of asyncore dispatcher
	after connection established
Message-ID: <1320252902.0.0.0833758767698.issue13325@psf.upfronthosting.co.za>


New submission from Xavier de Gaye <xdegaye at gmail.com>:

When an asyncore dispatcher initiates a tcp connection, its
representation lacks the peer address. The output of the attached
script 'dispatcher_addr.py' gives on linux with Python 3.2:

call stack in handle_connect_event:
<module>->main->loop->poll->write->handle_write_event->handle_connect_event
self.addr after connection: None


The attached patch fixes the problem. The patch includes a test case.
The following comment in the patch:

    # EWOULDBLOCK may also be returned by winsock when calling connect
    # while the connection attempt is in progress

refers to the following statement in
http://msdn.microsoft.com/en-us/library/aa923167.aspx

"""
As a result, it is not recommended that applications use multiple
calls to connect to detect connection completion. If they do, they
must be prepared to handle WSAEINVAL and WSAEWOULDBLOCK error codes
the same way that they handle WSAEALREADY to ensure robust execution.
"""


Note that two consecutive calls to
socket.getsockopt(socket.SOL_SOCKET, socket.SO_ERROR) are made when
handle_write_event() is called and self.connected is False: one in
handle_write_event and the following right away in
handle_connect_event. This seems useless.

----------
components: Library (Lib)
messages: 146849
nosy: xdegaye
priority: normal
severity: normal
status: open
title: no address in the representation of asyncore dispatcher after connection established
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Wed Nov  2 17:55:39 2011
From: report at bugs.python.org (Xavier de Gaye)
Date: Wed, 02 Nov 2011 16:55:39 +0000
Subject: [issue13325] no address in the representation of asyncore dispatcher
	after connection established
In-Reply-To: <1320252902.0.0.0833758767698.issue13325@psf.upfronthosting.co.za>
Message-ID: <1320252939.57.0.457833576723.issue13325@psf.upfronthosting.co.za>


Changes by Xavier de Gaye <xdegaye at gmail.com>:


Added file: http://bugs.python.org/file23593/dispatcher_addr.py

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

From report at bugs.python.org  Wed Nov  2 17:56:16 2011
From: report at bugs.python.org (Xavier de Gaye)
Date: Wed, 02 Nov 2011 16:56:16 +0000
Subject: [issue13325] no address in the representation of asyncore dispatcher
	after connection established
In-Reply-To: <1320252902.0.0.0833758767698.issue13325@psf.upfronthosting.co.za>
Message-ID: <1320252976.16.0.735751165343.issue13325@psf.upfronthosting.co.za>


Changes by Xavier de Gaye <xdegaye at gmail.com>:


----------
keywords: +patch
Added file: http://bugs.python.org/file23594/dispatcher_addr.diff

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

From report at bugs.python.org  Wed Nov  2 17:58:45 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 02 Nov 2011 16:58:45 +0000
Subject: [issue13295] Fix HTML produced by http.server
In-Reply-To: <1319987245.42.0.28884085529.issue13295@psf.upfronthosting.co.za>
Message-ID: <1320253125.64.0.0846246415073.issue13295@psf.upfronthosting.co.za>


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

Thanks.  +0.

----------

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

From report at bugs.python.org  Wed Nov  2 18:06:13 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 02 Nov 2011 17:06:13 +0000
Subject: [issue13226] Expose RTLD_* constants in the posix module
In-Reply-To: <1319061944.29.0.561087845829.issue13226@psf.upfronthosting.co.za>
Message-ID: <1320253573.19.0.590988959843.issue13226@psf.upfronthosting.co.za>


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

sys.getdlopenflags() doc and docstring still contain references to ctypes and DLFCN module.

----------

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

From report at bugs.python.org  Wed Nov  2 18:08:43 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 02 Nov 2011 17:08:43 +0000
Subject: [issue12629] HTMLParser silently stops parsing with malformed
	attributes
In-Reply-To: <1311532507.83.0.00235537878353.issue12629@psf.upfronthosting.co.za>
Message-ID: <1320253723.96.0.647669475293.issue12629@psf.upfronthosting.co.za>


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

I haven't found anything in the HTML5 spec but I haven't looked closely.
I'll do some more research when I'll start working on an actual patch.

----------

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

From report at bugs.python.org  Wed Nov  2 18:11:25 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 02 Nov 2011 17:11:25 +0000
Subject: [issue3173] external strftime for Python?
In-Reply-To: <1214189093.82.0.548435251403.issue3173@psf.upfronthosting.co.za>
Message-ID: <1320253885.07.0.597809546868.issue3173@psf.upfronthosting.co.za>


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

> Maybe rather than spending the effort maintaining a legacy API such as strftime, someone could
> look into implementing localized date formatting as defined by recent Unicode standards:
> http://unicode.org/reports/tr35/#Date_Format_Patterns

This scheme is very elegant.  I?d love to have built-in/stdlib support for it.  Would it need to be implemented in C?

> Apparently there is a free implementation for Python out there:
> http://babel.edgewall.org/wiki/Documentation/dates.html#pattern-syntax

Babel just rocks :)

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

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

From report at bugs.python.org  Wed Nov  2 18:16:56 2011
From: report at bugs.python.org (dmitry be)
Date: Wed, 02 Nov 2011 17:16:56 +0000
Subject: [issue13323] urllib2 does not correctly handle multiple
	www-authenticate headers in an HTTP response
In-Reply-To: <1320249966.17.0.892468926199.issue13323@psf.upfronthosting.co.za>
Message-ID: <1320254216.37.0.774380527127.issue13323@psf.upfronthosting.co.za>


Changes by dmitry be <db01 at dembel.org>:


----------
nosy: +Dmitry.Beransky

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

From report at bugs.python.org  Wed Nov  2 18:20:00 2011
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 02 Nov 2011 17:20:00 +0000
Subject: [issue13224] Change str(class) to return only the class name
In-Reply-To: <1320251472.15.0.803496603612.issue13224@psf.upfronthosting.co.za>
Message-ID: <CAP7+vJLD+TV5C4MS5uCtg5ngVUAcCc8HzaTDR8Oc9Q+0A=C_Gw@mail.gmail.com>


Guido van Rossum <guido at python.org> added the comment:

On Wed, Nov 2, 2011 at 9:31 AM, ?ric Araujo <report at bugs.python.org> wrote:
>
> ?ric Araujo <merwok at netwok.org> added the comment:
>
> I?ve updated my patch to handle modules and functions too, but there is a decision to make. ?The functions of built-in modules are implemented by methodobject.c, not functionobject.c (that?s for Python functions), so if we want str(sys.exc_info) to be equal to 'exc_info', then we?ll have str(dict.update) == 'update'. ?Is this okay?

Hm, that doesn't seem right. Currently, str(sys.exc_info) says
<built-in function exc_info> but str(dict.update) is <built-in
function exc_info>. So the latter definitely knows that it is an
unbound method! And {}.update is <built-in method update of dict
object at 0x10040c050> so that knows it is a bound method.

I'd be okay if str(sys.exc_info) and str({}.update) were unchanged
from today and if str(dict.update) returned 'dict.update', but if
that's too complicated I'd also be okay with all three being
unchanged, thus limiting this to Python functions (and classes and
modules).

----------

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

From report at bugs.python.org  Wed Nov  2 18:33:56 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 02 Nov 2011 17:33:56 +0000
Subject: [issue13295] Fix HTML produced by http.server
In-Reply-To: <1319987245.42.0.28884085529.issue13295@psf.upfronthosting.co.za>
Message-ID: <E1RLehA-0005na-Bm@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 10823e7be085 by Ezio Melotti in branch 'default':
#13295: http.server now produces valid HTML 4.01 strict.
http://hg.python.org/cpython/rev/10823e7be085

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

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

From report at bugs.python.org  Wed Nov  2 18:35:26 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 02 Nov 2011 17:35:26 +0000
Subject: [issue13295] Fix HTML produced by http.server
In-Reply-To: <1319987245.42.0.28884085529.issue13295@psf.upfronthosting.co.za>
Message-ID: <1320255326.89.0.546779585748.issue13295@psf.upfronthosting.co.za>


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

Fixed, thanks for the report and the reviews!

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

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

From report at bugs.python.org  Wed Nov  2 18:45:35 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Wed, 02 Nov 2011 17:45:35 +0000
Subject: [issue12498] asyncore.dispatcher_with_send,
	disconnection problem + miss-conception
In-Reply-To: <1309830930.03.0.793190602228.issue12498@psf.upfronthosting.co.za>
Message-ID: <1320255935.51.0.284842248525.issue12498@psf.upfronthosting.co.za>


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

I've done a review of your patch (looks like Rietveld doesn't send emails).

----------
stage: needs patch -> patch review

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

From report at bugs.python.org  Wed Nov  2 18:47:32 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Wed, 02 Nov 2011 17:47:32 +0000
Subject: [issue13303] Sporadic importlib failures: FileNotFoundError on
	os.rename()
In-Reply-To: <1320058871.09.0.581986884521.issue13303@psf.upfronthosting.co.za>
Message-ID: <1320256052.21.0.836223610771.issue13303@psf.upfronthosting.co.za>


Changes by Vinay Sajip <vinay_sajip at yahoo.co.uk>:


----------
resolution: fixed -> 

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

From report at bugs.python.org  Wed Nov  2 18:49:37 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 02 Nov 2011 17:49:37 +0000
Subject: [issue13224] Change str(class) to return only the class name
In-Reply-To: <1319053532.35.0.636674659737.issue13224@psf.upfronthosting.co.za>
Message-ID: <1320256177.01.0.0880794269936.issue13224@psf.upfronthosting.co.za>


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

Please also see the proposed PEP 3155 - http://mail.python.org/pipermail/python-ideas/2011-October/012609.html

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

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

From report at bugs.python.org  Wed Nov  2 18:51:22 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Wed, 02 Nov 2011 17:51:22 +0000
Subject: [issue13303] Sporadic importlib failures: FileNotFoundError on
	os.rename()
In-Reply-To: <1320058871.09.0.581986884521.issue13303@psf.upfronthosting.co.za>
Message-ID: <1320256282.81.0.53620509281.issue13303@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

What's the downside of option 2) ?

----------
nosy: +vinay.sajip

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

From report at bugs.python.org  Wed Nov  2 18:54:58 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 02 Nov 2011 17:54:58 +0000
Subject: [issue13303] Sporadic importlib failures: FileNotFoundError on
	os.rename()
In-Reply-To: <1320251340.89.0.927849038846.issue13303@psf.upfronthosting.co.za>
Message-ID: <1320256234.3356.0.camel@localhost.localdomain>


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

> Thoughts?

I would say go for the simpler (that's probably option 3).

----------

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

From report at bugs.python.org  Wed Nov  2 18:59:30 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 02 Nov 2011 17:59:30 +0000
Subject: [issue13324] fcntl module doesn't support F_NOCACHE (OS X specific)
	results in high 'inactive' memory performance issues
In-Reply-To: <1320252674.88.0.834289126042.issue13324@psf.upfronthosting.co.za>
Message-ID: <E1RLf5q-0008NT-Q5@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset cee6fdd6436d by Charles-Fran?ois Natali in branch 'default':
Issue #13324: fcntlmodule: Add the F_NOCACHE flag. Patch by Alex Stewart.
http://hg.python.org/cpython/rev/cee6fdd6436d

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

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

From report at bugs.python.org  Wed Nov  2 19:03:45 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 02 Nov 2011 18:03:45 +0000
Subject: [issue13147] Multiprocessing Pool.map_async() does not have an
	error_callback parameter
In-Reply-To: <1318289870.89.0.681252830912.issue13147@psf.upfronthosting.co.za>
Message-ID: <E1RLfA0-0000cE-VN@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 37e34a983d6d by Senthil Kumaran in branch '2.7':
Fix Issue13147 - Correct the Multiprocessing Pool.map_async method signature.
http://hg.python.org/cpython/rev/37e34a983d6d

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

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

From report at bugs.python.org  Wed Nov  2 19:04:54 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Wed, 02 Nov 2011 18:04:54 +0000
Subject: [issue13147] Multiprocessing Pool.map_async() does not have an
	error_callback parameter
In-Reply-To: <1318289870.89.0.681252830912.issue13147@psf.upfronthosting.co.za>
Message-ID: <1320257094.79.0.620882923831.issue13147@psf.upfronthosting.co.za>


Senthil Kumaran <senthil at uthcode.com> added the comment:

Thanks for the report, Jakub and for the patch, Jyrki

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

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

From report at bugs.python.org  Wed Nov  2 19:05:16 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Wed, 02 Nov 2011 18:05:16 +0000
Subject: [issue13324] fcntl module doesn't support F_NOCACHE (OS X specific)
	results in high 'inactive' memory performance issues
In-Reply-To: <1320252674.88.0.834289126042.issue13324@psf.upfronthosting.co.za>
Message-ID: <1320257116.81.0.791620612731.issue13324@psf.upfronthosting.co.za>


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

> With this patch in place the inactive memory on my system stays (low)
> and flat, without it it rises until it maxes out all available memory
> and then starts paging.

It's often a desired behaviour: paging out unused memory makes room for a bigger page cache, which yields better performance. Also, it's a simple heuristic to know which pages are actually in use.
Linux has a systcl that can be used to tune the swap tendency (vm.swappiness).
Anyway, since it seems to improve performance under some workloads and it's just a constant, I've applied your patch.
Thanks!

----------
nosy: +neologix
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
type: resource usage -> behavior
versions: +Python 3.3 -Python 2.6, Python 2.7

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

From report at bugs.python.org  Wed Nov  2 19:30:54 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Wed, 02 Nov 2011 18:30:54 +0000
Subject: [issue13324] fcntl module doesn't support F_NOCACHE (OS X specific)
	results in high 'inactive' memory performance issues
In-Reply-To: <1320252674.88.0.834289126042.issue13324@psf.upfronthosting.co.za>
Message-ID: <1320258654.61.0.24068788491.issue13324@psf.upfronthosting.co.za>


Changes by Charles-Fran?ois Natali <neologix at free.fr>:


----------
type: behavior -> feature request

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

From report at bugs.python.org  Wed Nov  2 19:36:44 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 02 Nov 2011 18:36:44 +0000
Subject: [issue13308] fix test_httpservers failures when run as root
In-Reply-To: <1320137754.01.0.106611498358.issue13308@psf.upfronthosting.co.za>
Message-ID: <E1RLffw-0003wP-7r@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset d1cde7081bf5 by Charles-Fran?ois Natali in branch '2.7':
Issue #13308: Fix test_httpservers failures when run as root.
http://hg.python.org/cpython/rev/d1cde7081bf5

New changeset 4dc5590dbd0b by Charles-Fran?ois Natali in branch '3.2':
Issue #13308: Fix test_httpservers failures when run as root.
http://hg.python.org/cpython/rev/4dc5590dbd0b

New changeset f2d3927a1165 by Charles-Fran?ois Natali in branch 'default':
Issue #13308: Fix test_httpservers failures when run as root.
http://hg.python.org/cpython/rev/f2d3927a1165

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

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

From report at bugs.python.org  Wed Nov  2 19:43:09 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Wed, 02 Nov 2011 18:43:09 +0000
Subject: [issue13323] urllib2 does not correctly handle
	multiple	www-authenticate headers in an HTTP response
In-Reply-To: <1320249966.17.0.892468926199.issue13323@psf.upfronthosting.co.za>
Message-ID: <4EB18F34.3020009@v.loewis.de>


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

> I ran into an application that responded with two www-authenticate
> challenges  to an HTTP request. First, it sends a standard Basic
> authentication challenge and then it also returns a www-authenticate
> header referencing another scheme. 

What exactly do you mean by "then"? In HTTP, there is only a single
response to a single request, so in what way does the server send
two responses to a single request?

----------
nosy: +loewis
title: urllib2 does not correctly handle multiple www-authenticate headers in an HTTP response -> urllib2 does not correctly handle multiple	www-authenticate headers in an HTTP response

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

From report at bugs.python.org  Wed Nov  2 19:45:28 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Wed, 02 Nov 2011 18:45:28 +0000
Subject: [issue13324] fcntl module doesn't support F_NOCACHE (OS X specific)
	results in high 'inactive' memory performance issues
In-Reply-To: <1320252674.88.0.834289126042.issue13324@psf.upfronthosting.co.za>
Message-ID: <1320259528.4.0.499876670091.issue13324@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/issue13324>
_______________________________________

From report at bugs.python.org  Wed Nov  2 19:47:50 2011
From: report at bugs.python.org (David Fischer)
Date: Wed, 02 Nov 2011 18:47:50 +0000
Subject: [issue13323] urllib2 does not correctly handle
	multiple	www-authenticate headers in an HTTP response
In-Reply-To: <1320249966.17.0.892468926199.issue13323@psf.upfronthosting.co.za>
Message-ID: <1320259670.84.0.222367825067.issue13323@psf.upfronthosting.co.za>


David Fischer <djfische at gmail.com> added the comment:

Perhaps I should have chosen my words more carefully. There are two www-authenticate headers the single HTTP response.

----------

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

From report at bugs.python.org  Wed Nov  2 20:00:23 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Wed, 02 Nov 2011 19:00:23 +0000
Subject: [issue13285] signal module ignores external signal changes
In-Reply-To: <1319801278.56.0.946220269602.issue13285@psf.upfronthosting.co.za>
Message-ID: <1320260423.37.0.651169011883.issue13285@psf.upfronthosting.co.za>


Petri Lehtinen <petri at digip.org> added the comment:

> Could it return an opaque wrapper object, rather than just the raw address? Something like:

Are you suggesting that it would return either a Python function object or a wrapper object?

----------

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

From report at bugs.python.org  Wed Nov  2 20:01:57 2011
From: report at bugs.python.org (Eric V. Smith)
Date: Wed, 02 Nov 2011 19:01:57 +0000
Subject: [issue13321] fstat doesn't accept an object with "fileno" method
In-Reply-To: <1320206652.2.0.972235455602.issue13321@psf.upfronthosting.co.za>
Message-ID: <1320260517.99.0.430400574533.issue13321@psf.upfronthosting.co.za>


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

If I understand it correctly, this change request is to change os.fstat(obj) (and probably other functions) to call obj.fileno(), instead of the caller doing that?

If so, -1. Keep os.fstat() as a thin wrapper around fstat.

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

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

From report at bugs.python.org  Wed Nov  2 20:15:40 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Wed, 02 Nov 2011 19:15:40 +0000
Subject: [issue13323] urllib2 does not correctly handle
	multiple	www-authenticate headers in an HTTP response
In-Reply-To: <1320249966.17.0.892468926199.issue13323@psf.upfronthosting.co.za>
Message-ID: <1320261340.96.0.968476063906.issue13323@psf.upfronthosting.co.za>


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

So what do you propose to do? RFC 2617 specifies

   The user agent MUST choose to use one of the challenges with the 
   strongest auth-scheme it understands and request credentials from the 
   user based upon that challenge.

----------

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

From report at bugs.python.org  Wed Nov  2 20:20:11 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Wed, 02 Nov 2011 19:20:11 +0000
Subject: [issue13281] Make robotparser.RobotFileParser ignore blank lines
In-Reply-To: <1319747444.2.0.491041533825.issue13281@psf.upfronthosting.co.za>
Message-ID: <1320261611.99.0.16083398318.issue13281@psf.upfronthosting.co.za>


Petri Lehtinen <petri at digip.org> added the comment:

> My current suggested doc change is to replace the sentence quoted at the top with

Sounds good to me.

----------

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

From report at bugs.python.org  Wed Nov  2 20:23:24 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Wed, 02 Nov 2011 19:23:24 +0000
Subject: [issue13322] buffered read() and write() does not raise
	BlockingIOError
In-Reply-To: <1320246535.71.0.465783773129.issue13322@psf.upfronthosting.co.za>
Message-ID: <1320261804.84.0.532701228323.issue13322@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/issue13322>
_______________________________________

From report at bugs.python.org  Wed Nov  2 20:26:35 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Wed, 02 Nov 2011 19:26:35 +0000
Subject: [issue13323] urllib2 does not correctly handle
	multiple	www-authenticate headers in an HTTP response
In-Reply-To: <1320249966.17.0.892468926199.issue13323@psf.upfronthosting.co.za>
Message-ID: <1320261995.2.0.963799232256.issue13323@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/issue13323>
_______________________________________

From report at bugs.python.org  Wed Nov  2 20:30:49 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Wed, 02 Nov 2011 19:30:49 +0000
Subject: [issue13285] signal module ignores external signal changes
In-Reply-To: <1320260423.37.0.651169011883.issue13285@psf.upfronthosting.co.za>
Message-ID: <CAH_1eM1aGyhWdK58n+LsfOJbTQ7S0A0HyZ6zGh1Jr5ww8LDFWw@mail.gmail.com>


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

>> Could it return an opaque wrapper object, rather than just the raw
>> address? Something like:
>
> Are you suggesting that it would return either a Python function object or a
> wrapper object?

I think it would be an ugly kludge. I don't like the idea of passing
around an opaque "blob" just for that purpose (I mean, it's really a
corner case).
So I'm -1.

----------

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

From report at bugs.python.org  Wed Nov  2 20:41:06 2011
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Wed, 02 Nov 2011 19:41:06 +0000
Subject: [issue13303] Sporadic importlib failures: FileNotFoundError on
	os.rename()
In-Reply-To: <1320058871.09.0.581986884521.issue13303@psf.upfronthosting.co.za>
Message-ID: <1320262866.06.0.865599031792.issue13303@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/issue13303>
_______________________________________

From report at bugs.python.org  Wed Nov  2 21:10:07 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Wed, 02 Nov 2011 20:10:07 +0000
Subject: [issue10570] curses.tigetstr() returns bytes,
	but curses.tparm() expects a string
In-Reply-To: <1290987535.2.0.130889699839.issue10570@psf.upfronthosting.co.za>
Message-ID: <1320264607.48.0.537644361265.issue10570@psf.upfronthosting.co.za>


Petri Lehtinen <petri at digip.org> added the comment:

I'm not a curses expert, but after digging a while, I believe that I now understand what these functions are doing. tigetstr() returns a "format string" (bytes) and tparm() does substitutions and returns a command string (bytes) for the terminal.

I don't believe that the first parameter to tparm() (the format string) is ever constructed by hand, because it's terminal specific. The value is obtained from the terminfo database by calling tigetstr() instead. Furthermore, tigetstr() returns binary data, for which bytes is the only sane representation, and therefore tparm() should expect bytes instead of str.

Attached a patch that fixes this.

----------
keywords: +needs review, patch
stage: test needed -> patch review
Added file: http://bugs.python.org/file23595/issue10570.patch

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

From report at bugs.python.org  Wed Nov  2 21:10:57 2011
From: report at bugs.python.org (Xavier de Gaye)
Date: Wed, 02 Nov 2011 20:10:57 +0000
Subject: [issue12498] asyncore.dispatcher_with_send,
	disconnection problem + miss-conception
In-Reply-To: <1309830930.03.0.793190602228.issue12498@psf.upfronthosting.co.za>
Message-ID: <1320264657.78.0.914229130431.issue12498@psf.upfronthosting.co.za>


Xavier de Gaye <xdegaye at gmail.com> added the comment:

Review done after Charles-Fran?ois review.

----------

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

From report at bugs.python.org  Wed Nov  2 21:11:59 2011
From: report at bugs.python.org (David Fischer)
Date: Wed, 02 Nov 2011 20:11:59 +0000
Subject: [issue13323] urllib2 does not correctly handle
	multiple	www-authenticate headers in an HTTP response
In-Reply-To: <1320249966.17.0.892468926199.issue13323@psf.upfronthosting.co.za>
Message-ID: <1320264719.35.0.152689980588.issue13323@psf.upfronthosting.co.za>


David Fischer <djfische at gmail.com> added the comment:

I think the key words in the RFC are "strongest auth-scheme it understands". I think in an ideal world, the urllib2 opener (given its handlers) would see that it doesn't understand the second auth-scheme and then see if it understands the first one. However, the term "strongest" implies an ordering among the auth schemes.

----------

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

From report at bugs.python.org  Wed Nov  2 22:05:17 2011
From: report at bugs.python.org (Mark Hammond)
Date: Wed, 02 Nov 2011 21:05:17 +0000
Subject: [issue13320] _remove_visual_c_ref in distutils.msvc9compiler causes
	DLL load fail with embedded Python and multiple CRT versions
In-Reply-To: <1320196634.59.0.302796026714.issue13320@psf.upfronthosting.co.za>
Message-ID: <1320267917.61.0.494842471695.issue13320@psf.upfronthosting.co.za>


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

I can't explain why this might be happening given the Python dll is still build against vc9 - I'm guessing this can't be reproduced without vs10 in the mix?

Re making the feature optional - distutils doesn't really lend itself to customizing the compiler best I can tell - the only answer I know of here is to provide your own compiler sub-class and override manifest_get_embed_info to return the manifest filename.

----------

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

From report at bugs.python.org  Wed Nov  2 22:41:05 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 02 Nov 2011 21:41:05 +0000
Subject: [issue13281] Make robotparser.RobotFileParser ignore blank lines
In-Reply-To: <1319747444.2.0.491041533825.issue13281@psf.upfronthosting.co.za>
Message-ID: <1320270065.65.0.959832715968.issue13281@psf.upfronthosting.co.za>


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


----------
nosy:  -osvenskan

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

From report at bugs.python.org  Wed Nov  2 23:10:01 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 02 Nov 2011 22:10:01 +0000
Subject: [issue13303] Sporadic importlib failures: FileNotFoundError on
	os.rename()
In-Reply-To: <1320058871.09.0.581986884521.issue13303@psf.upfronthosting.co.za>
Message-ID: <1320271801.5.0.20100041243.issue13303@psf.upfronthosting.co.za>


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

> 3) Fall back to the original ".tmp" suffix (with the risk
> of stale tmp file).

I missed something, what is the "stale tmp file" issue? Python/import.c uses:

    (void) unlink(filename);
    fd = open(filename, O_EXCL|O_CREAT|O_WRONLY|O_TRUNC ...);

So Python starts by removing the .tmp file, but it fails if another process is already writing into the .tmp file. In this case, we do nothing, which is not a problem: the other process will create the file.

Attached patch implements the same algorithm than import.c in importlib.

----------
Added file: http://bugs.python.org/file23597/importlib_write_atomic.patch

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

From report at bugs.python.org  Wed Nov  2 23:28:30 2011
From: report at bugs.python.org (sbt)
Date: Wed, 02 Nov 2011 22:28:30 +0000
Subject: [issue13322] buffered read() and write() does not raise
	BlockingIOError
In-Reply-To: <1320246535.71.0.465783773129.issue13322@psf.upfronthosting.co.za>
Message-ID: <1320272910.81.0.281974980124.issue13322@psf.upfronthosting.co.za>


sbt <shibturn at gmail.com> added the comment:

BufferedReader.readinto() should also raise BlockingIOError according to the docs.  Updated unittest checks for that also.

BTW, The documentation for BufferedIOBase.read() says that BlockingIOError should be raised if nothing can be read in non-blocking mode.  BufferedReader inherits from BufferedIOBase and overrides the read() method.  This is the documentation for BufferedReader.read():

    read([n])
        Read and return n bytes, or if n is not given or negative, 
        until EOF or if the read call would block in non-blocking mode.

This sentence is complete gobbledygook, and it makes no mention of what should happen if nothing can be read in non-blocking mode.   So I presume behaviour for BufferedReader.read() should match the documented behaviour for BufferedIOBase.read().

----------
Added file: http://bugs.python.org/file23598/blockingioerror.py

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

From report at bugs.python.org  Wed Nov  2 23:46:42 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 02 Nov 2011 22:46:42 +0000
Subject: [issue10570] curses.tigetstr() returns bytes,
	but curses.tparm() expects a string
In-Reply-To: <1290987535.2.0.130889699839.issue10570@psf.upfronthosting.co.za>
Message-ID: <E1RLjZo-0002hV-CC@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset e41663970ca5 by Victor Stinner in branch '3.2':
Issue #10570: curses.tigetstr() is now expecting a byte string, instead of a
http://hg.python.org/cpython/rev/e41663970ca5

New changeset ab11a6a73683 by Victor Stinner in branch 'default':
(Merge 3.2) Issue #10570: curses.tigetstr() is now expecting a byte string,
http://hg.python.org/cpython/rev/ab11a6a73683

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

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

From report at bugs.python.org  Wed Nov  2 23:48:09 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 02 Nov 2011 22:48:09 +0000
Subject: [issue10570] curses.tigetstr() returns bytes,
	but curses.tparm() expects a string
In-Reply-To: <1290987535.2.0.130889699839.issue10570@psf.upfronthosting.co.za>
Message-ID: <1320274089.6.0.756633015743.issue10570@psf.upfronthosting.co.za>


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

"I don't believe that the first parameter to tparm() (the format string) is ever constructed by hand, because it's terminal specific. The value is obtained from the terminfo database by calling tigetstr() instead. Furthermore, tigetstr() returns binary data, for which bytes is the only sane representation, and therefore tparm() should expect bytes instead of str."

Ok, it sounds to be fair. I wrote a patch based on yours (except that Python crashes with your patch :-)).

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

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

From report at bugs.python.org  Wed Nov  2 23:56:01 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Wed, 02 Nov 2011 22:56:01 +0000
Subject: [issue13303] Sporadic importlib failures: FileNotFoundError on
	os.rename()
In-Reply-To: <1320058871.09.0.581986884521.issue13303@psf.upfronthosting.co.za>
Message-ID: <1320274561.95.0.256421488834.issue13303@psf.upfronthosting.co.za>


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

> So Python starts by removing the .tmp file, but it fails if another 
> process is already writing into the .tmp file. In this case, we do 
> nothing, which is not a problem: the other process will create the 
> file.

unlink() does not fail, even if the file is open by another process with O_EXCL!
Therefore there's a race:
- process 1 opens file.tmp
- process 2 unlinks file.tmp
- process 2 opens file.tmp: this succeeds, since he just removed the file opened by proc 1
- process 1, which was working on its deleted file handle, is done, and renames file.tmp to file: except that it rename the file process 2 is in the middle of writing
- game over, file corrupted

> Attached patch implements the same algorithm than import.c in 
> importlib. 

Same race.


The current implementations are safe, both Python/import.c and Lib/importlib/_bootstrap.py
The only problem is that since import.c uses mkstemp, the file is created with mode 0600.

----------

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

From report at bugs.python.org  Thu Nov  3 00:15:47 2011
From: report at bugs.python.org (Remi Pointel)
Date: Wed, 02 Nov 2011 23:15:47 +0000
Subject: [issue13326] make clean failed on OpenBSD
Message-ID: <1320275747.65.0.48370892093.issue13326@psf.upfronthosting.co.za>


New submission from Remi Pointel <python at xiri.fr>:

Hi,

"make clean" failed on OpenBSD with this error:

find: -exec: no terminating ";"
*** Error code 1 (ignored)

It seems that "-exec" with "+" is a GNU extension.

Are you OK with this diff which does the same and is multi-platform?
Modifications can only be done for __pycache__, what do you prefer?

Cheers,

Remi.

----------
files: python3_3_Makefile_pre_in
messages: 146882
nosy: pitrou, rpointel
priority: normal
severity: normal
status: open
title: make clean failed on OpenBSD
Added file: http://bugs.python.org/file23599/python3_3_Makefile_pre_in

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

From report at bugs.python.org  Thu Nov  3 00:16:46 2011
From: report at bugs.python.org (Remi Pointel)
Date: Wed, 02 Nov 2011 23:16:46 +0000
Subject: [issue13326] make clean failed on OpenBSD
In-Reply-To: <1320275747.65.0.48370892093.issue13326@psf.upfronthosting.co.za>
Message-ID: <1320275806.78.0.269213639392.issue13326@psf.upfronthosting.co.za>


Remi Pointel <python at xiri.fr> added the comment:

FYI I tested with Python 3.3, but I didn't look for 2.7 and 3.2, I think modifications are also needed.

----------

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

From report at bugs.python.org  Thu Nov  3 00:22:16 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 02 Nov 2011 23:22:16 +0000
Subject: [issue13326] make clean failed on OpenBSD
In-Reply-To: <1320275747.65.0.48370892093.issue13326@psf.upfronthosting.co.za>
Message-ID: <1320276136.23.0.531531763151.issue13326@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/issue13326>
_______________________________________

From report at bugs.python.org  Thu Nov  3 00:46:32 2011
From: report at bugs.python.org (Brian Curtin)
Date: Wed, 02 Nov 2011 23:46:32 +0000
Subject: [issue13327] Update utime API to not require explicit None argument
Message-ID: <1320277592.58.0.341414975391.issue13327@psf.upfronthosting.co.za>


New submission from Brian Curtin <brian at python.org>:

os.utime currently requires an explicit `None` as the second argument in order to update to the current time. Other APIs would just have the second argument as optional in this case, operating with one argument.

Attached is a patch which changes the second argument to accept the time tuple, `None`, or literally nothing. Tested on Windows and Mac.

If this is acceptable, I'll make the same change for futimes, lutimes, and futimens.

----------
assignee: brian.curtin
components: Library (Lib)
files: utime.diff
keywords: needs review, patch
messages: 146884
nosy: brian.curtin
priority: normal
severity: normal
stage: patch review
status: open
title: Update utime API to not require explicit None argument
type: feature request
versions: Python 3.3
Added file: http://bugs.python.org/file23600/utime.diff

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

From report at bugs.python.org  Thu Nov  3 01:03:19 2011
From: report at bugs.python.org (Arkadiusz Wahlig)
Date: Thu, 03 Nov 2011 00:03:19 +0000
Subject: [issue13328] pdb shows code from wrong module
Message-ID: <1320278597.67.0.4589054929.issue13328@psf.upfronthosting.co.za>


New submission from Arkadiusz Wahlig <arkadiusz.wahlig at gmail.com>:

If pdb is used to debug code using zipimport, it may end up displaying source code from wrong module. Python will execute the correct code but the source code lines displayed by pdb (including the "list" command) will come from an unrelated module.

Reason:

The pdb obtains lines of code using the linecache module. When used with zipimported modules, linecache requires the module's globals dict to be passed in along with the filename. The filename is then used as a cache key for future lookups.

A bug in pdb causes it to pass filename and globals from different modules when calling linecache thus polluting the cache with bogus data.

A patch for 2.7.2 is attached that fixes the problem.

The patch also fixes another problem:

When Bdb (Pdb parent class from bdb.py) calls linecache, it calls Bdb.canonic(filename) before passing the filename to it. It doesn't pass the module's globals though. This isn't a problem because the call is always made after Pdb has queried source lines for the same module (and it does pass the globals). However, because Pdb doesn't call Bdb.canonic() on the filename, the cache key is different and Bdb's call fails.

To fix this, the patch adds calls to Bdb.canonic(filename) whenever Pdb passes a filename to linecache.

----------
files: pdb.diff
keywords: patch
messages: 146885
nosy: yak
priority: normal
severity: normal
status: open
title: pdb shows code from wrong module
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file23601/pdb.diff

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

From report at bugs.python.org  Thu Nov  3 01:13:26 2011
From: report at bugs.python.org (Arkadiusz Wahlig)
Date: Thu, 03 Nov 2011 00:13:26 +0000
Subject: [issue13328] pdb shows code from wrong module
In-Reply-To: <1320278597.67.0.4589054929.issue13328@psf.upfronthosting.co.za>
Message-ID: <1320279206.01.0.790300668238.issue13328@psf.upfronthosting.co.za>


Arkadiusz Wahlig <arkadiusz.wahlig at gmail.com> added the comment:

How to reproduce:

Given a module foo.py imported using zipimport with a function bar, if we try to set a breakpoint in bar using:

> break foo.bar

pdb would take filename and lineno from the function object but would use current frame to get module globals.

linecache would return a line from current module but also store it in cache under foo's filename.

----------

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

From report at bugs.python.org  Thu Nov  3 02:02:37 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 03 Nov 2011 01:02:37 +0000
Subject: [issue13328] pdb shows code from wrong module
In-Reply-To: <1320278597.67.0.4589054929.issue13328@psf.upfronthosting.co.za>
Message-ID: <1320282157.46.0.478459727844.issue13328@psf.upfronthosting.co.za>


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


----------
nosy: +brett.cannon, georg.brandl, ncoghlan

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

From report at bugs.python.org  Thu Nov  3 02:51:20 2011
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 03 Nov 2011 01:51:20 +0000
Subject: [issue13307] bdist_rpm: INSTALLED_FILES does not use __pycache__
In-Reply-To: <1320100717.66.0.765161985418.issue13307@psf.upfronthosting.co.za>
Message-ID: <E1RLmSV-0008JQ-Mt@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 2c0253d4d9ba by Antoine Pitrou in branch '3.2':
Issue #13307: fix bdist_rpm test failures
http://hg.python.org/cpython/rev/2c0253d4d9ba

New changeset eb2991f7cdc8 by Antoine Pitrou in branch 'default':
Issue #13307: fix bdist_rpm test failures
http://hg.python.org/cpython/rev/eb2991f7cdc8

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

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

From report at bugs.python.org  Thu Nov  3 02:52:08 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 03 Nov 2011 01:52:08 +0000
Subject: [issue13307] bdist_rpm: INSTALLED_FILES does not use __pycache__
In-Reply-To: <1320100717.66.0.765161985418.issue13307@psf.upfronthosting.co.za>
Message-ID: <1320285128.62.0.905212787097.issue13307@psf.upfronthosting.co.za>


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

Should be fixed now (verified here on Mageia).

----------
dependencies:  -distutils doesn't byte-compile .py files to __pycache__ during installation
nosy: +pitrou
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Thu Nov  3 02:58:41 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 03 Nov 2011 01:58:41 +0000
Subject: [issue13325] no address in the representation of asyncore dispatcher
	after connection established
In-Reply-To: <1320252902.0.0.0833758767698.issue13325@psf.upfronthosting.co.za>
Message-ID: <1320285521.41.0.564183721817.issue13325@psf.upfronthosting.co.za>


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


----------
nosy: +giampaolo.rodola, josiahcarlson, stutzbach
stage:  -> patch review
versions: +Python 3.3

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

From report at bugs.python.org  Thu Nov  3 03:00:36 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 03 Nov 2011 02:00:36 +0000
Subject: [issue13314] ImportError ImportError: Import by filename,
	should be deferred until sys.meta_path hooks are processed
In-Reply-To: <1320170547.3.0.447612016778.issue13314@psf.upfronthosting.co.za>
Message-ID: <1320285636.95.0.708527819166.issue13314@psf.upfronthosting.co.za>


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


----------
nosy: +brett.cannon, ncoghlan

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

From report at bugs.python.org  Thu Nov  3 03:01:32 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 03 Nov 2011 02:01:32 +0000
Subject: [issue13311] asyncore handle_read should call recv
In-Reply-To: <1320163710.5.0.667995234807.issue13311@psf.upfronthosting.co.za>
Message-ID: <1320285692.75.0.844578210519.issue13311@psf.upfronthosting.co.za>


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


----------
nosy: +giampaolo.rodola, josiahcarlson, neologix, stutzbach
stage:  -> patch review
versions: +Python 3.2

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

From report at bugs.python.org  Thu Nov  3 03:12:43 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 03 Nov 2011 02:12:43 +0000
Subject: [issue13327] Update utime API to not require explicit None argument
In-Reply-To: <1320277592.58.0.341414975391.issue13327@psf.upfronthosting.co.za>
Message-ID: <1320286363.12.0.257559148979.issue13327@psf.upfronthosting.co.za>


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

You have a possible failure here: 

+        # Set to the current time in the old explicit way.
+        os.utime(support.TESTFN, None)
+        st1 = os.stat(support.TESTFN)
+        # Set to the current time in the new way
+        os.utime(support.TESTFN)
+        st2 = os.stat(support.TESTFN)
+        self.assertEqual(st1.st_mtime, st2.st_mtime)

I managed to trigger it after a run of tests:

======================================================================
FAIL: test_utime_noargs (test.test_os.StatAttributeTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/antoine/cpython/default/Lib/test/test_os.py", line 286, in test_utime_noargs
    self.assertEqual(st1.st_mtime, st2.st_mtime)
AssertionError: 1320285959.712339 != 1320285959.7133389


Otherwise, +1.

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

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

From report at bugs.python.org  Thu Nov  3 03:25:52 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 03 Nov 2011 02:25:52 +0000
Subject: [issue13298] Result type depends on order of operands for bytes and
	bytearray
In-Reply-To: <1320020077.78.0.866789839878.issue13298@psf.upfronthosting.co.za>
Message-ID: <1320287152.14.0.86027448534.issue13298@psf.upfronthosting.co.za>


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

I think the current behaviour is fine, in that the alternatives are not better at all. In the absence of a type inherently "superior" to the others (as float can be to int, except for very large integers :-)), it makes sense to keep the type of the left-hand argument.

Note that .join() has a slightly different behaviour:

>>> b"".join([bytearray(), b""])
b''
>>> bytearray().join([bytearray(), b""])
bytearray(b'')
>>> b"".join([bytearray(), memoryview(b"")])
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: sequence item 1: expected bytes, memoryview found

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

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

From report at bugs.python.org  Thu Nov  3 03:27:23 2011
From: report at bugs.python.org (Brian Curtin)
Date: Thu, 03 Nov 2011 02:27:23 +0000
Subject: [issue13327] Update utime API to not require explicit None argument
In-Reply-To: <1320277592.58.0.341414975391.issue13327@psf.upfronthosting.co.za>
Message-ID: <1320287243.37.0.412295850142.issue13327@psf.upfronthosting.co.za>


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

Ah, yes. Would the following work better for the last line?

self.assertAlmostEqual(st1.st_mtime, st2.st_mtime, places=2)

----------

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

From report at bugs.python.org  Thu Nov  3 03:32:49 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 03 Nov 2011 02:32:49 +0000
Subject: [issue13327] Update utime API to not require explicit None argument
In-Reply-To: <1320277592.58.0.341414975391.issue13327@psf.upfronthosting.co.za>
Message-ID: <1320287569.16.0.00558700695194.issue13327@psf.upfronthosting.co.za>


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

I would specify an even smaller "places". We have very slow buildbots.
You could first call utime() with a date far away in the past if you want.

----------

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

From report at bugs.python.org  Thu Nov  3 04:22:14 2011
From: report at bugs.python.org (Nick Rowan)
Date: Thu, 03 Nov 2011 03:22:14 +0000
Subject: [issue13329] Runs normal as console script but falls as CGI
Message-ID: <1320290534.75.0.190110850785.issue13329@psf.upfronthosting.co.za>


New submission from Nick Rowan <nnrowan at gmail.com>:

There is a Python script that tries to print a message in Russian language. It's okay when script runs in console, but it causes DecodeUnicodeError if it invokes as CGI.

----------
components: Interpreter Core, Library (Lib), Unicode
files: Test.py
messages: 146893
nosy: Nick.Rowan, ezio.melotti
priority: normal
severity: normal
status: open
title: Runs normal as console script but falls as CGI
type: behavior
versions: 3rd party, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file23602/Test.py

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

From report at bugs.python.org  Thu Nov  3 04:28:37 2011
From: report at bugs.python.org (Brian Curtin)
Date: Thu, 03 Nov 2011 03:28:37 +0000
Subject: [issue13327] Update utime API to not require explicit None argument
In-Reply-To: <1320277592.58.0.341414975391.issue13327@psf.upfronthosting.co.za>
Message-ID: <1320290917.92.0.756641085515.issue13327@psf.upfronthosting.co.za>


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

The `delta` keyword would actually be better than `places`, especially on the slower buildbots. delta=10 would allow up to 10 seconds between those utime calls. Is that being too permissive?

----------

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

From report at bugs.python.org  Thu Nov  3 07:14:10 2011
From: report at bugs.python.org (Sean Fleming)
Date: Thu, 03 Nov 2011 06:14:10 +0000
Subject: [issue13330] Attempt full test coverage of
	LocaleTextCalendar.formatweekday
Message-ID: <1320300850.58.0.556745870791.issue13330@psf.upfronthosting.co.za>


New submission from Sean Fleming <seanmtfleming at gmail.com>:

Patch includes new statements in test_localecalendars of CalendarTestCase such that coverage of LocaleTextCalendar.formatweekday should improve significantly. 

Feedback is appreciated.

----------
components: Tests
files: test_calendar.patch
keywords: patch
messages: 146895
nosy: Sean.Fleming
priority: normal
severity: normal
status: open
title: Attempt full test coverage of LocaleTextCalendar.formatweekday
versions: Python 3.4
Added file: http://bugs.python.org/file23603/test_calendar.patch

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

From report at bugs.python.org  Thu Nov  3 07:59:25 2011
From: report at bugs.python.org (Ronald Oussoren)
Date: Thu, 03 Nov 2011 06:59:25 +0000
Subject: [issue13315] tarfile extract fails on OS X system python due to chown
	of gid=-1
In-Reply-To: <1320171441.51.0.618008041157.issue13315@psf.upfronthosting.co.za>
Message-ID: <1320303565.53.0.38326772444.issue13315@psf.upfronthosting.co.za>


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

There's little chance that Apple will fix this issue in their build (at least not until Lion+1 gets released) because this is not a security bug. Their breaking of 2.7 in Lion is probably due to lack of review for their collection of patches, and is not something we can fix.

I'd close this as invalid as the issue is already fixed in our codebase.

I won't file a bug at Apple for this, although that shouldn't stop anyone else from doing so (and remember: bugreport.apple.com is a popularity contest, the more people file an report about a bug the more likely it is that it will get fixed)

----------
status: pending -> open

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

From report at bugs.python.org  Thu Nov  3 08:47:37 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Thu, 03 Nov 2011 07:47:37 +0000
Subject: [issue13298] Result type depends on order of operands for bytes and
	bytearray
In-Reply-To: <1320287152.14.0.86027448534.issue13298@psf.upfronthosting.co.za>
Message-ID: <20111103074725.GE4458@p16>


Petri Lehtinen <petri at digip.org> added the comment:

> Note that .join() has a slightly different behaviour:
> 
> >>> b"".join([bytearray(), b""])
> b''
> >>> bytearray().join([bytearray(), b""])
> bytearray(b'')
> >>> b"".join([bytearray(), memoryview(b"")])
> Traceback (most recent call last):
>   File "<stdin>", line 1, in <module>
> TypeError: sequence item 1: expected bytes, memoryview found

I thinks this is worth fixing. Is there an issue already?

----------

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

From report at bugs.python.org  Thu Nov  3 08:53:24 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Thu, 03 Nov 2011 07:53:24 +0000
Subject: [issue13308] fix test_httpservers failures when run as root
In-Reply-To: <1320137754.01.0.106611498358.issue13308@psf.upfronthosting.co.za>
Message-ID: <1320306804.35.0.438959379048.issue13308@psf.upfronthosting.co.za>


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

> You should change "issue #XXXX" with the real issue number now that 
> there's an issue for this :)

Done :-)

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

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

From report at bugs.python.org  Thu Nov  3 09:00:44 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Thu, 03 Nov 2011 08:00:44 +0000
Subject: [issue13326] make clean failed on OpenBSD
In-Reply-To: <1320275747.65.0.48370892093.issue13326@psf.upfronthosting.co.za>
Message-ID: <1320307244.34.0.350203171567.issue13326@psf.upfronthosting.co.za>


Petri Lehtinen <petri at digip.org> added the comment:

According to the man page, find -print0 and xargs -r are also GNU extensions. Even though they work on OpenBSD (do they?), they could still break on some platforms.

As find -exec cmd {} ';' is already used for everything but __pycache__, I'd rather only change the removal of __pycache__. I believe there are more files that match '*.py[co]' than '__pycache__', and people are already waiting for a separate rm process to be invoked on each *.py[co], so invoking a separate rmdir for each __pycache__ shouldn't make it much slower.

----------
nosy: +petri.lehtinen

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

From report at bugs.python.org  Thu Nov  3 09:06:02 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Thu, 03 Nov 2011 08:06:02 +0000
Subject: [issue13327] Update utime API to not require explicit None argument
In-Reply-To: <1320277592.58.0.341414975391.issue13327@psf.upfronthosting.co.za>
Message-ID: <1320307562.03.0.997734159452.issue13327@psf.upfronthosting.co.za>


Petri Lehtinen <petri at digip.org> added the comment:

+1 on making the second arg optional.

----------
nosy: +petri.lehtinen

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

From report at bugs.python.org  Thu Nov  3 09:06:58 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Thu, 03 Nov 2011 08:06:58 +0000
Subject: [issue13328] pdb shows code from wrong module
In-Reply-To: <1320278597.67.0.4589054929.issue13328@psf.upfronthosting.co.za>
Message-ID: <1320307618.12.0.887783793936.issue13328@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/issue13328>
_______________________________________

From report at bugs.python.org  Thu Nov  3 09:10:37 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 03 Nov 2011 08:10:37 +0000
Subject: [issue13298] Result type depends on order of operands for bytes and
	bytearray
In-Reply-To: <1320020077.78.0.866789839878.issue13298@psf.upfronthosting.co.za>
Message-ID: <1320307837.49.0.408915794639.issue13298@psf.upfronthosting.co.za>


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

We can just use this one - it was more in the nature of a question "is there anything we want to change about the status quo?" than a request for any specific change.

I'm actually OK with buffer API based interoperability, but if we're going to offer that, we should be consistent:

1. bytes and bytearray should interoperate with anything supporting the buffer interface (which they already mostly do)
2. When they encounter each other, LHS wins (as with set() and frozenset())
3. We should fix the operand coercion bug for C level concatenation slot implementations (already covered by issue #11477) 
4. Update the documentation as needed

Since we're tinkering with builtin behaviour, 1 & 2 should probably be brought up on python-dev once someone checks if there is anything other than .join() that needs updating.

----------

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

From report at bugs.python.org  Thu Nov  3 09:19:51 2011
From: report at bugs.python.org (Remi Pointel)
Date: Thu, 03 Nov 2011 08:19:51 +0000
Subject: [issue13326] make clean failed on OpenBSD
In-Reply-To: <1320275747.65.0.48370892093.issue13326@psf.upfronthosting.co.za>
Message-ID: <1320308391.67.0.880039141725.issue13326@psf.upfronthosting.co.za>


Remi Pointel <python at xiri.fr> added the comment:

> According to the man page, find -print0 and xargs -r are also GNU extensions. Even though they work on OpenBSD (do they?), they could still break on some platforms.

Yes, it works fine, but you're allright.

> As find -exec cmd {} ';' is already used for everything but __pycache__, I'd rather only change the removal of __pycache__. I believe there are more files that match '*.py[co]' than '__pycache__', and people are already waiting for a separate rm process to be invoked on each *.py[co], so invoking a separate rmdir for each __pycache__ shouldn't make it much slower.

You mean to just exec rmdir instead of rm only for __pycache__?

Cheers,

Remi.

----------

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

From report at bugs.python.org  Thu Nov  3 09:36:23 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Thu, 03 Nov 2011 08:36:23 +0000
Subject: [issue13308] fix test_httpservers failures when run as root
In-Reply-To: <1320137754.01.0.106611498358.issue13308@psf.upfronthosting.co.za>
Message-ID: <1320309383.87.0.384201788766.issue13308@psf.upfronthosting.co.za>


Petri Lehtinen <petri at digip.org> added the comment:

I mean that this should be enough to close this issue:

-	-find $(srcdir) -name '__pycache__' -exec rmdir {} '+'
+	-find $(srcdir) -name '__pycache__' -exec rmdir {} ';'

That is, use ';' instead of the unportable '+' instead of changing all cleaning to use find ... | xargs ...

----------

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

From report at bugs.python.org  Thu Nov  3 09:37:38 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Thu, 03 Nov 2011 08:37:38 +0000
Subject: [issue13308] fix test_httpservers failures when run as root
In-Reply-To: <1320137754.01.0.106611498358.issue13308@psf.upfronthosting.co.za>
Message-ID: <1320309458.91.0.624215965964.issue13308@psf.upfronthosting.co.za>


Petri Lehtinen <petri at digip.org> added the comment:

Whoops, posted the previous message to a totally wrong issue. Who was it thag introduced tabbed browsing?

----------

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

From report at bugs.python.org  Thu Nov  3 09:37:53 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Thu, 03 Nov 2011 08:37:53 +0000
Subject: [issue13326] make clean failed on OpenBSD
In-Reply-To: <1320275747.65.0.48370892093.issue13326@psf.upfronthosting.co.za>
Message-ID: <1320309473.14.0.0153371620881.issue13326@psf.upfronthosting.co.za>


Petri Lehtinen <petri at digip.org> added the comment:

I mean that this should be enough to close this issue:

-	-find $(srcdir) -name '__pycache__' -exec rmdir {} '+'
+	-find $(srcdir) -name '__pycache__' -exec rmdir {} ';'

That is, use ';' instead of the unportable '+' instead of changing all cleaning to use find ... | xargs ...

----------

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

From report at bugs.python.org  Thu Nov  3 09:41:01 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Thu, 03 Nov 2011 08:41:01 +0000
Subject: [issue13329] Runs normal as console script but falls as CGI
In-Reply-To: <1320290534.75.0.190110850785.issue13329@psf.upfronthosting.co.za>
Message-ID: <1320309661.02.0.0124315817978.issue13329@psf.upfronthosting.co.za>


Petri Lehtinen <petri at digip.org> added the comment:

How are you running the CGI script? Are you sure that the PYTHONIOENCODING environment variable isn't set by the HTTP server?

----------
nosy: +petri.lehtinen

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

From report at bugs.python.org  Thu Nov  3 09:48:10 2011
From: report at bugs.python.org (Remi Pointel)
Date: Thu, 03 Nov 2011 08:48:10 +0000
Subject: [issue13326] make clean failed on OpenBSD
In-Reply-To: <1320275747.65.0.48370892093.issue13326@psf.upfronthosting.co.za>
Message-ID: <1320310090.36.0.790551463937.issue13326@psf.upfronthosting.co.za>


Remi Pointel <python at xiri.fr> added the comment:

Please see this:

http://bugs.python.org/issue8665
http://hg.python.org/cpython/rev/5468f3aee4ae/

----------

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

From report at bugs.python.org  Thu Nov  3 09:55:03 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Thu, 03 Nov 2011 08:55:03 +0000
Subject: [issue13326] make clean failed on OpenBSD
In-Reply-To: <1320275747.65.0.48370892093.issue13326@psf.upfronthosting.co.za>
Message-ID: <1320310503.29.0.87427523621.issue13326@psf.upfronthosting.co.za>


Petri Lehtinen <petri at digip.org> added the comment:

Ah, I didn't think about that.

How about using the -depth option then? It's in POSIX but does OpenBSD have it? The man page of GNU find says it has a -d option (that does the same as -depth) for compatibility with BSD.

----------

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

From report at bugs.python.org  Thu Nov  3 09:58:03 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Thu, 03 Nov 2011 08:58:03 +0000
Subject: [issue13330] Attempt full test coverage of
	LocaleTextCalendar.formatweekday
In-Reply-To: <1320300850.58.0.556745870791.issue13330@psf.upfronthosting.co.za>
Message-ID: <1320310683.34.0.48311099168.issue13330@psf.upfronthosting.co.za>


Changes by Petri Lehtinen <petri at digip.org>:


----------
components: +Library (Lib)
keywords: +needs review
stage:  -> patch review
type:  -> feature request
versions: +Python 3.3 -Python 3.4

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

From report at bugs.python.org  Thu Nov  3 10:07:08 2011
From: report at bugs.python.org (Remi Pointel)
Date: Thu, 03 Nov 2011 09:07:08 +0000
Subject: [issue13326] make clean failed on OpenBSD
In-Reply-To: <1320275747.65.0.48370892093.issue13326@psf.upfronthosting.co.za>
Message-ID: <1320311228.96.0.899193057846.issue13326@psf.upfronthosting.co.za>


Remi Pointel <python at xiri.fr> added the comment:

> How about using the -depth option then? It's in POSIX but does OpenBSD have it? The man page of GNU find says it has a -d option (that does the same as -depth) for compatibility with BSD.

Yes, we have this option:
-depth  This primary always evaluates to true.  The same as specifying the -d option.

Source: http://www.openbsd.org/cgi-bin/man.cgi?query=find

----------

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

From report at bugs.python.org  Thu Nov  3 10:24:49 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 03 Nov 2011 09:24:49 +0000
Subject: [issue13326] make clean failed on OpenBSD
In-Reply-To: <1320275747.65.0.48370892093.issue13326@psf.upfronthosting.co.za>
Message-ID: <1320312289.07.0.811525535106.issue13326@psf.upfronthosting.co.za>


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

By the way, removing *.pyc and *.pyo is useless: Python 3.3 only generates such files in __pycache__:

+	-find $(srcdir) -name '*.py[co]' -print0 | xargs -0r rm -f
+	-find $(srcdir) -name '__pycache__' -print0 | xargs -0r rmdir

can be simplified to

+	-find $(srcdir) -name '__pycache__' -print0 | xargs -0r rm -rf

----------

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

From report at bugs.python.org  Thu Nov  3 10:26:37 2011
From: report at bugs.python.org (=?utf-8?q?Miguel_Hern=C3=A1ndez_Martos?=)
Date: Thu, 03 Nov 2011 09:26:37 +0000
Subject: [issue6434] buffer overflow in Zipfile when wrinting more than 2gig
	file
In-Reply-To: <1246986659.26.0.972556799924.issue6434@psf.upfronthosting.co.za>
Message-ID: <1320312397.56.0.276188461871.issue6434@psf.upfronthosting.co.za>


Miguel Hern?ndez Martos <enlavin at gmail.com> added the comment:

I think it's a dup of http://bugs.python.org/issue9720 

That issue has a patch that allows the generation of zip files with >2GB files.

----------
nosy: +enlavin

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

From report at bugs.python.org  Thu Nov  3 10:27:42 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Thu, 03 Nov 2011 09:27:42 +0000
Subject: [issue13326] make clean failed on OpenBSD
In-Reply-To: <1320312289.07.0.811525535106.issue13326@psf.upfronthosting.co.za>
Message-ID: <20111103092731.GI4458@p16>


Petri Lehtinen <petri at digip.org> added the comment:

> +	-find $(srcdir) -name '__pycache__' -print0 | xargs -0r rm -rf

I'd still do it like this for portability's sake:

+	-find $(srcdir) -depth -name '__pycache__' -exec rm -rf {} ';'

----------

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

From report at bugs.python.org  Thu Nov  3 10:53:50 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Thu, 03 Nov 2011 09:53:50 +0000
Subject: [issue10570] curses.tigetstr() returns bytes,
	but curses.tparm() expects a string
In-Reply-To: <1290987535.2.0.130889699839.issue10570@psf.upfronthosting.co.za>
Message-ID: <1320314030.99.0.0442655879501.issue10570@psf.upfronthosting.co.za>


Petri Lehtinen <petri at digip.org> added the comment:

It seems that putp() should also accept only bytes, because it's used to output terminal commands. It's currently expecting a str.

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

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

From report at bugs.python.org  Thu Nov  3 10:59:00 2011
From: report at bugs.python.org (Boris FELD)
Date: Thu, 03 Nov 2011 09:59:00 +0000
Subject: [issue1469629] __dict__ = self in subclass of dict causes a memory
	leak?
Message-ID: <1320314340.22.0.812485247714.issue1469629@psf.upfronthosting.co.za>


Changes by Boris FELD <lothiraldan at gmail.com>:


----------
nosy: +Boris.FELD

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

From report at bugs.python.org  Thu Nov  3 11:44:57 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Thu, 03 Nov 2011 10:44:57 +0000
Subject: [issue3067] setlocale error message is confusing
In-Reply-To: <1213013354.87.0.861327880823.issue3067@psf.upfronthosting.co.za>
Message-ID: <1320317097.8.0.211443694098.issue3067@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/issue3067>
_______________________________________

From report at bugs.python.org  Thu Nov  3 12:25:15 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 03 Nov 2011 11:25:15 +0000
Subject: [issue13327] Update utime API to not require explicit None argument
In-Reply-To: <1320290917.92.0.756641085515.issue13327@psf.upfronthosting.co.za>
Message-ID: <1320319251.3374.0.camel@localhost.localdomain>


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

> The `delta` keyword would actually be better than `places`, especially
> on the slower buildbots. delta=10 would allow up to 10 seconds between
> those utime calls. Is that being too permissive?

I think it's ok. We don't have to test the system's utime
implementation, just that the second parameter does what it should.

----------

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

From report at bugs.python.org  Thu Nov  3 12:28:57 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 03 Nov 2011 11:28:57 +0000
Subject: [issue13326] make clean failed on OpenBSD
In-Reply-To: <20111103092731.GI4458@p16>
Message-ID: <1320319473.3374.1.camel@localhost.localdomain>


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

> I'd still do it like this for portability's sake:
> 
> +	-find $(srcdir) -depth -name '__pycache__' -exec rm -rf {} ';'

Then you'd probably reintroduce issue8665.

----------

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

From report at bugs.python.org  Thu Nov  3 12:42:24 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Thu, 03 Nov 2011 11:42:24 +0000
Subject: [issue13326] make clean failed on OpenBSD
In-Reply-To: <1320319473.3374.1.camel@localhost.localdomain>
Message-ID: <20111103112956.GN4458@p16>


Petri Lehtinen <petri at digip.org> added the comment:

> Then you'd probably reintroduce issue8665.

No, the -depth argument avoids that.

----------

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

From report at bugs.python.org  Thu Nov  3 12:50:56 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Thu, 03 Nov 2011 11:50:56 +0000
Subject: [issue13331] Packaging cannot install resource directory trees
	specified in setup.cfg
Message-ID: <1320321056.38.0.167356334613.issue13331@psf.upfronthosting.co.za>


New submission from Vinay Sajip <vinay_sajip at yahoo.co.uk>:

If setup.cfg contains a line such as

[files]
resources =
    mydata/** = {purelib}

and the project contains a directory tree more than one level deep under mydata, e.g.

mydata
 |
 +-mydata1
 |   |
 |   +-data1.dat
 |
 +-mydata2
     |
     +-data2.dat

then the parsing correctly identifies all the things to copy, but the install_data step fails because it does not try to create intermediate directories for mydata1, mydata2 but tries to copy them as files using copy_file.

----------
assignee: tarek
components: Distutils2, Library (Lib)
messages: 146917
nosy: alexis, eric.araujo, tarek, vinay.sajip
priority: high
severity: normal
status: open
title: Packaging cannot install resource directory trees specified in setup.cfg
versions: Python 3.3

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

From report at bugs.python.org  Thu Nov  3 13:11:32 2011
From: report at bugs.python.org (Sven Marnach)
Date: Thu, 03 Nov 2011 12:11:32 +0000
Subject: [issue13332] execfile fixer produces code that does not close the file
Message-ID: <1320322292.48.0.851588051991.issue13332@psf.upfronthosting.co.za>


New submission from Sven Marnach <sven at marnach.net>:

The execfile fixer of the 2to3 script replaces the 2.x code

    execfile("a.py")

by

    exec(compile(open("a.py").read(), "a.py", 'exec'))

The new code does not explicitly close the file.  This is not usually a problem in CPython, but

 1. the code will throw a RessourceWarnings if enabled and

 2. other Python implementation don't close the file immediately.

(I think the 2to3 script should be as implementation-independent as possible.)

The obvious fix would be to use a with-statement:

    with open("a.py") as new_name:
        exec(compile(new_name.read(), "a.py", 'exec'))

If this is to be changed, I'd be happy to prepare a patch.

----------
components: 2to3 (2.x to 3.x conversion tool)
messages: 146918
nosy: smarnach
priority: normal
severity: normal
status: open
title: execfile fixer produces code that does not close the file
type: behavior
versions: Python 3.2, Python 3.3

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

From report at bugs.python.org  Thu Nov  3 13:13:47 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 03 Nov 2011 12:13:47 +0000
Subject: [issue13333] utf-7 inconsistent with surrogates
Message-ID: <1320322427.22.0.464090396955.issue13333@psf.upfronthosting.co.za>


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

The utf-7 codec happily encodes lone surrogates, but it won't decode them:

>>> "\ud801".encode("utf-7")
b'+2AE-'
>>> "\ud801\ud801".encode("utf-7")
b'+2AHYAQ-'
>>> "\ud801".encode("utf-7").decode("utf-7")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/antoine/cpython/default/Lib/encodings/utf_7.py", line 12, in decode
    return codecs.utf_7_decode(input, errors, True)
UnicodeDecodeError: 'utf7' codec can't decode bytes in position 0-4: second surrogate missing at end of shift sequence
>>> "\ud801\ud801".encode("utf-7").decode("utf-7")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/antoine/cpython/default/Lib/encodings/utf_7.py", line 12, in decode
    return codecs.utf_7_decode(input, errors, True)
UnicodeDecodeError: 'utf7' codec can't decode bytes in position 0-6: second surrogate missing


I don't know which behaviour is better but round-tripping is certainly a desirable property of any codec.

----------
components: Interpreter Core, Unicode
messages: 146919
nosy: ezio.melotti, loewis, pitrou
priority: normal
severity: normal
status: open
title: utf-7 inconsistent with surrogates
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3

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

From report at bugs.python.org  Thu Nov  3 13:15:00 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Thu, 03 Nov 2011 12:15:00 +0000
Subject: [issue13327] Update utime API to not require explicit None argument
In-Reply-To: <1320277592.58.0.341414975391.issue13327@psf.upfronthosting.co.za>
Message-ID: <1320322500.55.0.0335072377091.issue13327@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

+1 to the optional parameter.

----------
nosy: +jcea

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

From report at bugs.python.org  Thu Nov  3 13:16:54 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 03 Nov 2011 12:16:54 +0000
Subject: [issue13326] make clean failed on OpenBSD
In-Reply-To: <1320275747.65.0.48370892093.issue13326@psf.upfronthosting.co.za>
Message-ID: <1320322614.17.0.386735699373.issue13326@psf.upfronthosting.co.za>


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

> No, the -depth argument avoids that.

Ah, you are right, my bad.

----------

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

From report at bugs.python.org  Thu Nov  3 13:17:18 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Thu, 03 Nov 2011 12:17:18 +0000
Subject: [issue6434] buffer overflow in Zipfile when wrinting more than 2gig
	file
In-Reply-To: <1246986659.26.0.972556799924.issue6434@psf.upfronthosting.co.za>
Message-ID: <1320322638.35.0.618513024885.issue6434@psf.upfronthosting.co.za>


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

Marking as duplicate.

----------
resolution:  -> duplicate
stage: needs patch -> committed/rejected
status: open -> closed
superseder:  -> zipfile writes incorrect local file header for large files in zip64
type: crash -> behavior

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

From report at bugs.python.org  Thu Nov  3 13:17:55 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Thu, 03 Nov 2011 12:17:55 +0000
Subject: [issue9720] zipfile writes incorrect local file header for large
	files in zip64
In-Reply-To: <1283216540.17.0.624049939978.issue9720@psf.upfronthosting.co.za>
Message-ID: <1320322675.68.0.913130802886.issue9720@psf.upfronthosting.co.za>


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

Issue 6434 was marked as a duplicate of this issue.

----------
nosy: +Paul, amaury.forgeotdarc, enlavin, lambacck, nadeem.vawda, segfault42
stage:  -> needs patch
versions: +Python 3.3 -Python 3.1

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

From report at bugs.python.org  Thu Nov  3 13:24:00 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Thu, 03 Nov 2011 12:24:00 +0000
Subject: [issue13333] utf-7 inconsistent with surrogates
In-Reply-To: <1320322427.22.0.464090396955.issue13333@psf.upfronthosting.co.za>
Message-ID: <1320323040.56.0.677136005141.issue13333@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/issue13333>
_______________________________________

From report at bugs.python.org  Thu Nov  3 13:25:20 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Thu, 03 Nov 2011 12:25:20 +0000
Subject: [issue13332] execfile fixer produces code that does not close the file
In-Reply-To: <1320322292.48.0.851588051991.issue13332@psf.upfronthosting.co.za>
Message-ID: <1320323120.34.0.124756542053.issue13332@psf.upfronthosting.co.za>


Petri Lehtinen <petri at digip.org> added the comment:

Sounds reasonable to me. Is it easy to generate unique identifier names in 2to3 fixers?

----------
nosy: +petri.lehtinen

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

From report at bugs.python.org  Thu Nov  3 13:29:20 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 03 Nov 2011 12:29:20 +0000
Subject: [issue13332] execfile fixer produces code that does not close the file
In-Reply-To: <1320322292.48.0.851588051991.issue13332@psf.upfronthosting.co.za>
Message-ID: <1320323360.21.0.626347166259.issue13332@psf.upfronthosting.co.za>


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

Be aware that execfile() is a simple function call and can be used in any expression.

----------
nosy: +benjamin.peterson, pitrou

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

From report at bugs.python.org  Thu Nov  3 13:39:41 2011
From: report at bugs.python.org (Dave Flogeras)
Date: Thu, 03 Nov 2011 12:39:41 +0000
Subject: [issue13315] tarfile extract fails on OS X system python due to chown
	of gid=-1
In-Reply-To: <1320171441.51.0.618008041157.issue13315@psf.upfronthosting.co.za>
Message-ID: <1320323981.52.0.000723240841237.issue13315@psf.upfronthosting.co.za>


Dave Flogeras <dflogeras2 at gmail.com> added the comment:

Thank you sirs.  I've already got a workaround for this situation, and personally don't care to waste my time with apple.  I'm satisfied that Python is handling bugs seriously and it will hopefully get into an apple release in the future.

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

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

From report at bugs.python.org  Thu Nov  3 13:50:02 2011
From: report at bugs.python.org (david)
Date: Thu, 03 Nov 2011 12:50:02 +0000
Subject: [issue13334] Erroneous Size check in
Message-ID: <1320324602.51.0.635021711304.issue13334@psf.upfronthosting.co.za>


New submission from david <db.pub.mail at gmail.com>:

The _PyString_Resize function in stringobject.c[0] takes in a PyObject ** and a Py_ssize_t newsize. Where Py_ssize_t is often a typedef for ssize_t(a signed version of size_t). As such the newsize parameter could be negative. 
The code checks for when the newsize is negative like so:

 int
_PyString_Resize(PyObject **pv, Py_ssize_t newsize)
{
...
    if (!PyString_Check(v) || Py_REFCNT(v) != 1 || newsize < 0 ||
        PyString_CHECK_INTERNED(v)) {
        *pv = 0;
        Py_DECREF(v);
        PyErr_BadInternalCall();
        return -1;
    }

Unfortunately, a few lines below it does the following:
 *pv = (PyObject *)
        PyObject_REALLOC((char *)v, PyStringObject_SIZE + newsize);

so now if PyStringObject_SIZE + newsize is enough to wrap around then realloc through python will end up allocating insufficient space for the 'new' string. The python interpreter is likely to crash on this line --> 

    sv->ob_sval[newsize] = '\0';

 
I haven't tried to reproduce this in the python interpreter. 
IMHO the code should be checking that newline + PyStringObject_SIZE is non-negative. 


[0] - http://svn.python.org/projects/python/trunk/Objects/stringobject.c

----------
messages: 146927
nosy: db
priority: normal
severity: normal
status: open
title: Erroneous Size check in

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

From report at bugs.python.org  Thu Nov  3 13:53:49 2011
From: report at bugs.python.org (Chandra Sekhar Reddy)
Date: Thu, 03 Nov 2011 12:53:49 +0000
Subject: [issue13335] Service application hang in python25.dll
Message-ID: <1320324829.1.0.613797933132.issue13335@psf.upfronthosting.co.za>


New submission from Chandra Sekhar Reddy <sanch09 at ca.com>:

Service application hanged in python25.dll, below are the environment details.

Operating System : Windows server 2008 R2 (Virtual Machine) Application Type : Service Application

We have got the process dump from the customer environment and after analyzing the dump using the Windbg tool.

Below is the status of the 4 running threads.
 
 Last error for thread 0:
 LastErrorValue: (Win32) 0 (0) - The operation completed successfully.
 LastStatusValue: (NTSTATUS) 0 - STATUS_WAIT_0
 
 Last error for thread 1:
 LastErrorValue: (Win32) 0 (0) - The operation completed successfully.
 LastStatusValue: (NTSTATUS) 0 - STATUS_WAIT_0
 
 Last error for thread 2:
 LastErrorValue: (Win32) 0 (0) - The operation completed successfully.
 LastStatusValue: (NTSTATUS) 0 - STATUS_WAIT_0

Last error for thread 3:
 LastErrorValue: (Win32) 0 (0) - The operation completed successfully.
 LastStatusValue: (NTSTATUS) 0 - STATUS_WAIT_0
 
 But as part of the hang analysis the command "!analyze -hang" shows
 some problem with thread 1
 
 Probably caused by : python25.dll ( python25!PyList_New+62 )
 
 03dff250 1e072c5b python25!PyFuture_FromAST+0x873
 03dff25c 1e073307 python25!PyFuture_FromAST+0xbcb
 03dff264 1e07332e python25!PyObject_GC_Malloc+0x67
 03dff270 1e081502 python25!PyObject_GC_New+0xe
 00000000 00000000 python25!PyList_New+0x62

Thanks,
-Chandra

----------
components: Windows
messages: 146928
nosy: chandra
priority: normal
severity: normal
status: open
title: Service application hang in python25.dll
type: performance
versions: Python 2.6

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

From report at bugs.python.org  Thu Nov  3 13:59:28 2011
From: report at bugs.python.org (david)
Date: Thu, 03 Nov 2011 12:59:28 +0000
Subject: [issue13334] Erroneous Size check in
In-Reply-To: <1320324602.51.0.635021711304.issue13334@psf.upfronthosting.co.za>
Message-ID: <1320325168.62.0.877683223518.issue13334@psf.upfronthosting.co.za>


Changes by david <db.pub.mail at gmail.com>:


----------
components: +None
versions: +Python 2.7

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

From report at bugs.python.org  Thu Nov  3 13:59:45 2011
From: report at bugs.python.org (david)
Date: Thu, 03 Nov 2011 12:59:45 +0000
Subject: [issue13334] Erroneous Size check in _PyString_Resize
In-Reply-To: <1320324602.51.0.635021711304.issue13334@psf.upfronthosting.co.za>
Message-ID: <1320325185.06.0.870268553961.issue13334@psf.upfronthosting.co.za>


Changes by david <db.pub.mail at gmail.com>:


----------
title: Erroneous Size check in -> Erroneous Size check in _PyString_Resize

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

From report at bugs.python.org  Thu Nov  3 14:02:37 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 03 Nov 2011 13:02:37 +0000
Subject: [issue13334] Erroneous Size check in _PyString_Resize
In-Reply-To: <1320324602.51.0.635021711304.issue13334@psf.upfronthosting.co.za>
Message-ID: <1320325357.93.0.0614294169255.issue13334@psf.upfronthosting.co.za>


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

Let's take an example: on a 32bit system, call
   _PyString_Resize(&s, 0x7ffffff8)
Then PyStringObject_SIZE + newsize is something like -0x7ffffff8 (yes, it wraps around and is a negative number)
But when cast to an unsigned size_t (because that's what PyObject_REALLOC declares as parameter), it becomes 0x80000008, which is correct even if it is very likely to fail.
Did you experience something different?

----------
nosy: +amaury.forgeotdarc
resolution:  -> invalid
status: open -> pending

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

From report at bugs.python.org  Thu Nov  3 14:10:14 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 03 Nov 2011 13:10:14 +0000
Subject: [issue13335] Service application hang in python25.dll
In-Reply-To: <1320324829.1.0.613797933132.issue13335@psf.upfronthosting.co.za>
Message-ID: <1320325814.34.0.0922773163483.issue13335@psf.upfronthosting.co.za>


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

This information is far too incomplete, but as a first step, did you check the memory usage of the process? Is the computer constantly swapping memory to disk?

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

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

From report at bugs.python.org  Thu Nov  3 14:11:18 2011
From: report at bugs.python.org (Sven Marnach)
Date: Thu, 03 Nov 2011 13:11:18 +0000
Subject: [issue13332] execfile fixer produces code that does not close the file
In-Reply-To: <1320322292.48.0.851588051991.issue13332@psf.upfronthosting.co.za>
Message-ID: <1320325878.91.0.0232436018742.issue13332@psf.upfronthosting.co.za>


Sven Marnach <sven at marnach.net> added the comment:

@Petri: Yes, that's what the BaseFix.new_name() method is for.

@Antoine: I thought about this, though I don't think it is very common to call execfile() as part of an expression. The whole statement containing the function call would need to be wrapped.

----------

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

From report at bugs.python.org  Thu Nov  3 14:12:59 2011
From: report at bugs.python.org (david)
Date: Thu, 03 Nov 2011 13:12:59 +0000
Subject: [issue13334] Erroneous Size check in _PyString_Resize
In-Reply-To: <1320324602.51.0.635021711304.issue13334@psf.upfronthosting.co.za>
Message-ID: <1320325979.5.0.938047405411.issue13334@psf.upfronthosting.co.za>


david <db.pub.mail at gmail.com> added the comment:

Yes my bad :-) I got my C test case wrong.

----------
status: pending -> open

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

From report at bugs.python.org  Thu Nov  3 14:14:56 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 03 Nov 2011 13:14:56 +0000
Subject: [issue13334] Erroneous Size check in _PyString_Resize
In-Reply-To: <1320324602.51.0.635021711304.issue13334@psf.upfronthosting.co.za>
Message-ID: <1320326096.47.0.708633439355.issue13334@psf.upfronthosting.co.za>


Changes by Amaury Forgeot d'Arc <amauryfa at gmail.com>:


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

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

From report at bugs.python.org  Thu Nov  3 14:15:37 2011
From: report at bugs.python.org (Giampaolo Rodola')
Date: Thu, 03 Nov 2011 13:15:37 +0000
Subject: [issue13311] asyncore handle_read should call recv
In-Reply-To: <1320163710.5.0.667995234807.issue13311@psf.upfronthosting.co.za>
Message-ID: <1320326137.63.0.404914098922.issue13311@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

> When the remote end disconnects, handle_close is only called if recv
> is called (from handle_read).

Actually this isn't true; handle_close() is also called in send():
http://hg.python.org/cpython/file/eb2991f7cdc8/Lib/asyncore.py#l364

I'd say your patch can be useful only in case the dispatcher subclass doesn't send() neither recv() any data, in which case the connection is supposed to remain open forever.
On one hand this might be a good thing, on the other hand I'm not sure what the repercussions might be in the existing code base out there. Probably none, but...

Perhaps you could provide more info about why you needed to do this in the first place.
Did you encounter a specific use case requiring this patch in order to work?
If so, please paste the code where you subclassed asyncore.dispatcher.

----------

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

From report at bugs.python.org  Thu Nov  3 15:10:13 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Thu, 03 Nov 2011 14:10:13 +0000
Subject: [issue13326] make clean failed on OpenBSD
In-Reply-To: <1320275747.65.0.48370892093.issue13326@psf.upfronthosting.co.za>
Message-ID: <1320329413.44.0.223673214439.issue13326@psf.upfronthosting.co.za>


Petri Lehtinen <petri at digip.org> added the comment:

The issue exists only in 3.2 and 3.3, as 2.7 doesn't have __pycache__ (PEP 3147). In 3.2 and 3.3, all *.py[co] files are in __pycache__ directories, so the pycremoval make target can only remove the __pycache__ directories, using the -depth option of find to remove child directories before the parent.

----------
keywords: +easy
stage:  -> needs patch
versions: +Python 3.2, Python 3.3

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

From report at bugs.python.org  Thu Nov  3 15:12:15 2011
From: report at bugs.python.org (Vilya Harvey)
Date: Thu, 03 Nov 2011 14:12:15 +0000
Subject: [issue13285] signal module ignores external signal changes
In-Reply-To: <1319801278.56.0.946220269602.issue13285@psf.upfronthosting.co.za>
Message-ID: <1320329535.16.0.044014019649.issue13285@psf.upfronthosting.co.za>


Vilya Harvey <vilya.harvey at gmail.com> added the comment:

Petri: yes, that what I was suggesting.

Charles-Fran?ois: I'm certainly open to alternatives. Unless I've overlooked something though, the problem is that no workaround is possible at the moment. BTW this came up in the context of a customer script for the software I work on, so it's not just a theoretical problem - at least, not for me. :-)

I guess another solution would be methods to save and restore the native signal handers, e.g. savesignal(signum) & restoresignal(signum). That wouldn't entirely solve the problem - if someone called setsignal() before calling savesignal(), they'd end up in the same situation - but it would at least permit a workaround.

----------

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

From report at bugs.python.org  Thu Nov  3 15:27:51 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 03 Nov 2011 14:27:51 +0000
Subject: [issue13309] test_time fails: time data 'LMT' does not match format
	'%Z'
In-Reply-To: <1320156304.27.0.1872899991.issue13309@psf.upfronthosting.co.za>
Message-ID: <1320330471.22.0.265138157568.issue13309@psf.upfronthosting.co.za>


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


----------
priority: normal -> deferred blocker

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

From report at bugs.python.org  Thu Nov  3 16:14:19 2011
From: report at bugs.python.org (sbt)
Date: Thu, 03 Nov 2011 15:14:19 +0000
Subject: [issue13322] buffered read() and write() does not raise
	BlockingIOError
In-Reply-To: <1320246535.71.0.465783773129.issue13322@psf.upfronthosting.co.za>
Message-ID: <1320333259.15.0.891356833463.issue13322@psf.upfronthosting.co.za>


sbt <shibturn at gmail.com> added the comment:

Wierdly, it looks like BlockingIO is not raised anywhere in the code for the C implementation of io.

Even more wierdly, in the Python implementation of io, BlockingIOError is only ever raised by except clauses which have already caught BlockingIOError.  So, of course, these clauses are dead code.

The only code in CPython which can ever succesfully raise BlockingIOError is MockNonBlockWriterIO.write() in test/test_io.py.

I don't know what the correct behaviour is for flush() and close() if you get EAGAIN.  I think flush() should raise an error rather than blocking, and that close() should delegate to self.raw.close() before raising the error.

The docs say that read(), readinto() and write() can raise BlockingIOError.  But what should readall() and readline() do?  Should we just try to emulate whatever Python's old libc IO system did (with BlockingIOError replacing IOError(EAGAIN))?

----------

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

From report at bugs.python.org  Thu Nov  3 16:24:57 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 03 Nov 2011 15:24:57 +0000
Subject: [issue13307] bdist_rpm: INSTALLED_FILES does not use __pycache__
In-Reply-To: <1320100717.66.0.765161985418.issue13307@psf.upfronthosting.co.za>
Message-ID: <1320333897.8.0.952011034947.issue13307@psf.upfronthosting.co.za>


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

I wrote the same fix this night :)

----------

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

From report at bugs.python.org  Thu Nov  3 16:27:04 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 03 Nov 2011 15:27:04 +0000
Subject: [issue13224] Change str(class) to return only the class name
In-Reply-To: <1319053532.35.0.636674659737.issue13224@psf.upfronthosting.co.za>
Message-ID: <1320334024.35.0.184787087355.issue13224@psf.upfronthosting.co.za>


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

> Please also see the proposed PEP 3155
I?ve seen it and like it.  I assume you?re telling that we should consider str(cls/mod/func) to return the qname instead of the name?  I think it could be good.  My patch can wait for your PEP, or go in first and be updated later if your PEP is accepted.

----------

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

From report at bugs.python.org  Thu Nov  3 16:45:54 2011
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 03 Nov 2011 15:45:54 +0000
Subject: [issue11254] distutils doesn't byte-compile .py files to __pycache__
	during installation
In-Reply-To: <1298195698.48.0.330644441328.issue11254@psf.upfronthosting.co.za>
Message-ID: <E1RLzU8-00030q-ID@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset ea926dff958f by ?ric Araujo in branch '3.2':
More fixes for PEP 3147 compliance in distutils (#11254)
http://hg.python.org/cpython/rev/ea926dff958f

New changeset 60ede940089f by ?ric Araujo in branch 'default':
Merge follow-up for #11254 and other changes from 3.2
http://hg.python.org/cpython/rev/60ede940089f

----------

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

From report at bugs.python.org  Thu Nov  3 16:49:22 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 03 Nov 2011 15:49:22 +0000
Subject: [issue13322] buffered read() and write() does not raise
	BlockingIOError
In-Reply-To: <1320246535.71.0.465783773129.issue13322@psf.upfronthosting.co.za>
Message-ID: <1320335362.46.0.12725742226.issue13322@psf.upfronthosting.co.za>


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

> Wierdly, it looks like BlockingIO is not raised anywhere in the code
> for the C implementation of io.

That would explain why it isn't raised :)

This is a hairy issue: read(n) is documented as returning either n bytes or nothing. But what if less than n bytes are available non-blocking? Currently we return a partial read. readline() behaviour is especially problematic:

>>> fcntl.fcntl(r, fcntl.F_SETFL, os.O_NDELAY)
0
>>> rf = open(r, mode='rb')
>>> os.write(w, b'xy')
2
>>> rf.read(3)
b'xy'
>>> os.write(w, b'xy')
2
>>> rf.readline()
b'xy'

We should probably raise BlockingIOError in these cases, but that complicates the implementation quite a bit: where do we buffer the partial data? The internal (fixed size) buffer might not be large enough.

write() is a bit simpler, since BlockingIOError has a "characters_written" attribute which is meant to inform you of the partial success: we can just reuse that. That said, BlockingIOError could grow a "partial_read" attribute containing the read result...

Of course, we may also question whether it's useful to use buffered I/O objects around non-blocking file descriptors; if you do non-blocking I/O, you generally want to be in control, which means not having any implicit buffer between you and the OS.

(this may be a topic for python-dev)

----------
nosy: +benjamin.peterson, neologix, stutzbach
stage:  -> needs patch

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

From report at bugs.python.org  Thu Nov  3 17:02:07 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 03 Nov 2011 16:02:07 +0000
Subject: [issue13331] Packaging cannot install resource directory trees
	specified in setup.cfg
In-Reply-To: <1320321056.38.0.167356334613.issue13331@psf.upfronthosting.co.za>
Message-ID: <1320336127.47.0.194206333727.issue13331@psf.upfronthosting.co.za>


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

Should be easy to add a test to reproduce this.

----------
assignee: tarek -> eric.araujo
keywords: +easy
priority: high -> normal
stage:  -> needs patch
type:  -> behavior
versions: +3rd party

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

From report at bugs.python.org  Thu Nov  3 17:07:04 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 03 Nov 2011 16:07:04 +0000
Subject: [issue11254] distutils doesn't byte-compile .py files to __pycache__
	during installation
In-Reply-To: <1298195698.48.0.330644441328.issue11254@psf.upfronthosting.co.za>
Message-ID: <1320336424.36.0.25541152445.issue11254@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Thu Nov  3 17:24:48 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 03 Nov 2011 16:24:48 +0000
Subject: [issue12120] test_packaging failure
In-Reply-To: <1305822128.84.0.738916530306.issue12120@psf.upfronthosting.co.za>
Message-ID: <1320337488.61.0.963923102362.issue12120@psf.upfronthosting.co.za>


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

I have improved packaging to be independent of -B/-O in http://hg.python.org/cpython/rev/dad02a080bbc.  See commit message for rationale.

----------
assignee: tarek -> eric.araujo
stage:  -> committed/rejected
versions: +3rd party

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

From report at bugs.python.org  Thu Nov  3 17:31:35 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 03 Nov 2011 16:31:35 +0000
Subject: [issue12119] test_distutils failure
In-Reply-To: <1305822053.61.0.184404379566.issue12119@psf.upfronthosting.co.za>
Message-ID: <1320337895.48.0.570688676695.issue12119@psf.upfronthosting.co.za>


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

I have changed packaging in dad02a080bbc to work even under -O or -B.

packaging gives control over the creation of pyc and/or pyo files to the user with its own explicit options (--compile/--no-compile and --optimize 0/1/2), and the behavior should not change if the calling Python happens to run with -B or -O for whatever reason.

Other libraries make different choices: For example, compileall gives no option to generate pyo instead of pyc, you have to call it with python -O.  I argue that distutils and packaging are different.  Calling ?python -B setup.py build? means that you don?t want pyc files to be created for the modules that are imported for this invocation, but it should not mean that distutils needs to behave as if --no-compile was given.

Fixing this is a small change, and in my opinion a bug fix.  Of course, I would not remove the DistutilsByteCompileError to preserve compatibility, but I would remove the warnings/exceptions when running under -B.  Can I do it?

----------
assignee: tarek -> eric.araujo
resolution: duplicate -> 
stage:  -> commit review
status: closed -> open

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

From report at bugs.python.org  Thu Nov  3 17:33:51 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 03 Nov 2011 16:33:51 +0000
Subject: [issue13317] building with 2to3 generates wrong import paths because
	build_ext is run after build_py
In-Reply-To: <1320183133.27.0.209500697705.issue13317@psf.upfronthosting.co.za>
Message-ID: <1320338031.4.0.218583878435.issue13317@psf.upfronthosting.co.za>


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

Hello and thanks for the report.

> We need build_ext before build_py. Otherwise, when 2to3 is called (in build_py),
> it will not find ext modules,
Why is 2to3 interested in extension modules?  2to3 converts Python code, extension modules are written in C or C++.

> thinking that those modules are global
I don?t understand what you mean.

Can you give me a Python or shell script to reproduce the error or a full description of what you did, what you expected and what went wrong?

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

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

From report at bugs.python.org  Thu Nov  3 17:36:51 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 03 Nov 2011 16:36:51 +0000
Subject: [issue13316] build_py_2to3 does not convert when there was an error
	in the last run
In-Reply-To: <1320182540.3.0.985799836702.issue13316@psf.upfronthosting.co.za>
Message-ID: <1320338211.49.0.293263320096.issue13316@psf.upfronthosting.co.za>


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

> When I use build_py_2to3 and there is an error while converting a
> file with 2to3, convert is skipped on the next run.

I think build should stop with an error message if 2to3 fails.  Do you agree?

----------
assignee:  -> tarek
components: +Distutils, Distutils2 -2to3 (2.x to 3.x conversion tool), Build
nosy: +alexis, eric.araujo, tarek
stage:  -> test needed
versions: +3rd party, Python 3.2, Python 3.3 -Python 3.1

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

From report at bugs.python.org  Thu Nov  3 17:39:04 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 03 Nov 2011 16:39:04 +0000
Subject: [issue13314] ImportError ImportError: Import by filename,
	should be deferred until sys.meta_path hooks are processed
In-Reply-To: <1320170547.3.0.447612016778.issue13314@psf.upfronthosting.co.za>
Message-ID: <1320338344.08.0.534340177984.issue13314@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/issue13314>
_______________________________________

From report at bugs.python.org  Thu Nov  3 17:43:44 2011
From: report at bugs.python.org (Xavier de Gaye)
Date: Thu, 03 Nov 2011 16:43:44 +0000
Subject: [issue12498] asyncore.dispatcher_with_send,
	disconnection problem + miss-conception
In-Reply-To: <1309830930.03.0.793190602228.issue12498@psf.upfronthosting.co.za>
Message-ID: <1320338624.8.0.572127607844.issue12498@psf.upfronthosting.co.za>


Xavier de Gaye <xdegaye at gmail.com> added the comment:

Attached is a new patch following the code review.

After rewriting the asyncore test to check that the data has been
successfully received by the client, the test fails when
using poll() and a data size of 4096 bytes. The reason is that when
TestHandler closes the connection after writing the output buffer, the
client receives a POLLHUP which prevents it to receive the data since
POLLHUP is triggering a call to handle_close.

POSIX states:
"""
POLLHUP
    A device has been disconnected, or a pipe or FIFO has been closed
    by the last process that had it open for writing. Once set, the
    hangup state of a FIFO shall persist until some process opens the
    FIFO for writing or until all read-only file descriptors for the
    FIFO are closed. This event and POLLOUT are mutually-exclusive; a
    stream can never be writable if a hangup has occurred. However,
    this event and POLLIN, POLLRDNORM, POLLRDBAND, or POLLPRI are not
    mutually-exclusive. This flag is only valid in the revents
    bitmask; it shall be ignored in the events member.
"""

The attached patch changes the handling of POLLHUP to fix this: it
calls a new method named handle_hangup_evt() on a POLLHUP event, and
uses a new _hangup attribute to have writable() return False after a
POLLHUP. Note that we do get a close event (on linux) when all data
has been received, allowing the client to close the socket.

Please review this new patch.

----------
Added file: http://bugs.python.org/file23604/half_duplex_close.diff

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

From report at bugs.python.org  Thu Nov  3 18:12:09 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 03 Nov 2011 17:12:09 +0000
Subject: [issue11805] package_data only allows one glob per-package
In-Reply-To: <1302301429.27.0.797210396018.issue11805@psf.upfronthosting.co.za>
Message-ID: <1320340329.07.0.364561023281.issue11805@psf.upfronthosting.co.za>


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

> As far as I've been able to tell there is no proposed syntax in the docs specifically for
> package_data.
Right.  I?ve only found an example in d2?s own setup.cfg:

package_data =
    distutils2._backport = sysconfig.cfg
    distutils2.command = wininst*.exe
    distutils2.tests = xxmodule.c

(Note that there?s a bug in build_py or config so you can?t test this right now.)

> The docs for the resources option seems to suggest separating globs with spaces, which would
> be fine by me (wouldn't allow paths that contain spaces, but that's a bad idea anyways).
Agreed.

> I think that allowing one glob string on each line is more readable
Definitely.

> Another possibility would be to allow line breaks in the value [...]
> But that's getting a little more complex syntax-wise.
Truly!

> Agreed on getting rid of data_files--it's dangerous.
Actually the resources system redefines data_files (it was even called datafiles.py and DATAFILES at one time, and it?s still handled by install_data; I think that was a better naming scheme).  distutils-style data_files were practically unusable: System packagers were unhappy because they wanted to control the location of installed files, Python authors were unhappy because they could not access the files from their code.  I think that?s why package_data took off.

> But package_data I find very useful sometimes, and I don't think it's always wrong.
OS maintainers like the Debian project strongly disagree :)

> At the very least, it's not clear to me how the above use case is intended to be replaced.
The point of resources is that it redefines data_files and is as easy to use as package_data.  If you have for example a project named Spam with a Python package spamlib and a file in templates/log.txt, your code just needs to do this:

   from packaging.database import get_file
   with get_file('Spam', 'templates/log.txt') as fp:
      ...

When run from an uninstalled checkout, for example when developing, the file will be found in the checkout.  When run after being installed on a Debian system, the file will be found in /usr/local/share/spam/templates/log.txt.  Each Python installation can decide (through sysconfig.cfg) where to install things.

----------

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

From report at bugs.python.org  Thu Nov  3 18:13:21 2011
From: report at bugs.python.org (Xavier de Gaye)
Date: Thu, 03 Nov 2011 17:13:21 +0000
Subject: [issue13311] asyncore handle_read should call recv
In-Reply-To: <1320163710.5.0.667995234807.issue13311@psf.upfronthosting.co.za>
Message-ID: <1320340401.79.0.591416195559.issue13311@psf.upfronthosting.co.za>


Xavier de Gaye <xdegaye at gmail.com> added the comment:

> I'd say your patch can be useful only in case the dispatcher subclass
> doesn't send() neither recv() any data, in which case the connection
> is supposed to remain open forever.

There are some cases where it is important to detect that the remote
end is disconnected even if there is no data to send. Say a logger
connected to a data collector that sends data every few minutes. The
data collector dies, the logger may have to take actions on this
event: connect to a backup collector, raise an alarm, whatever... It
should not have to depend on the fact that data needs to be sent to
learn of the disconnection.

> Perhaps you could provide more info about why you needed to do this
> in the first place.

See also issue 12498 and the message 146653. When the remote end
performs a half-duplex disconnection, you may send data without
detecting the close event in send(), so you must rely on recv() to
detect it.

----------

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

From report at bugs.python.org  Thu Nov  3 18:21:52 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 03 Nov 2011 17:21:52 +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: <1320340912.43.0.873582943509.issue6087@psf.upfronthosting.co.za>


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

> I?m not sure yet whether this is a bug or a new feature, but when python runs from an
> uninstalled build, I would like paths to refer to the source directory, not the default
> configure prefix.

I need this fixed for packaging and it may affect venv too, so I will consider it a bug, fix it and wait for the python-dev response :)

----------
versions:  -Python 3.1

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

From report at bugs.python.org  Thu Nov  3 18:24:44 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 03 Nov 2011 17:24:44 +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: <1320341084.31.0.458760615293.issue5875@psf.upfronthosting.co.za>


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

Buildbot passes, certainly thanks to the fix for #13307.

----------
assignee: tarek -> eric.araujo
resolution:  -> out of date
stage:  -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Thu Nov  3 18:28:59 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 03 Nov 2011 17:28:59 +0000
Subject: [issue13333] utf-7 inconsistent with surrogates
In-Reply-To: <1320322427.22.0.464090396955.issue13333@psf.upfronthosting.co.za>
Message-ID: <1320341339.76.0.186711693523.issue13333@psf.upfronthosting.co.za>


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

RFC 2152 talks about encoding 16-bit unicode, and clarifies

 Surrogate pairs (UTF-16) are converted by treating each half 
 of the pair as a separate 16 bit quantity (i.e., no special
 treatment).

So lone surrogates clearly should be supported.

This text could be interpreted as saying that decoding surrogate pairs should also keep them (rather than combining them). However, the RFC also assumes that the decoded form will use 16-bit code units; for Python, I think we should continue combining surrogate pairs on decoding UTF-7 when we find them.

----------

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

From report at bugs.python.org  Thu Nov  3 18:29:52 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 03 Nov 2011 17:29:52 +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: <1320341392.74.0.918863519617.issue5875@psf.upfronthosting.co.za>


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

Hm, did I close this too hastily?  The original report was not about the buildbot; does the buildbot run as a non-root user with the same version that was reported in the first message?  If no, can someone try to reproduce the issue in the same conditions as the OP?

----------

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

From report at bugs.python.org  Thu Nov  3 18:34:48 2011
From: report at bugs.python.org (Sven Marnach)
Date: Thu, 03 Nov 2011 17:34:48 +0000
Subject: [issue13332] execfile fixer produces code that does not close the file
In-Reply-To: <1320322292.48.0.851588051991.issue13332@psf.upfronthosting.co.za>
Message-ID: <1320341688.19.0.908675994058.issue13332@psf.upfronthosting.co.za>


Sven Marnach <sven at marnach.net> added the comment:

Getting the general case right seems a bit too difficult.  Examples like

    [execfile(n) for n in names if condition(n)]

    execfile(execfile(n1) or n2)

    try: 1 / 0
    except execfile(n) or ZeroDivisionError: pass

would require rather complex transformations to get exactly matching behaviour, and obviously we don't want to explode the fixer code to support such nonsense.

I think it is enough to cover the case of an execfile() call that forms a statement of its own.  Browsing through the first ten pages of a Google code search for "execfile" didn't reveal any other uses, except for a few that aren't covered by the current version of the fixer either. [1]

I'd suggest to simply throw a "could not convert" warning for any other uses of execfile().  Opinions?

[1]: http://www.google.com/codesearch#yqvQ9RM69FY/mercurial/lsprof.py&q=execfile&sq=&l=111&ct=rc&cd=49

----------

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

From report at bugs.python.org  Thu Nov  3 18:43:44 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Thu, 03 Nov 2011 17:43:44 +0000
Subject: [issue13311] asyncore handle_read should call recv
In-Reply-To: <1320163710.5.0.667995234807.issue13311@psf.upfronthosting.co.za>
Message-ID: <1320342224.5.0.292555355299.issue13311@psf.upfronthosting.co.za>


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

> The attached patch adds a call to recv in handle_read, updates the
> documentation and adds a test case.

In this kind of situation, it is perfectly legitimate for the client to perform a half-duplex close (shutdown(SHUT_WR)), since it does not intend to send data (which is implied by the fact that the sever doesn't implement an handle_read() method).

With the current code, the server will keep sending data until the remote end close()s its socket.
With this patch, this would break: the server's handle_close() method will be called right away.

> There are some cases where it is important to detect that the remote
> end is disconnected even if there is no data to send.

Indeed, but if you must detect in a timely maner that the remote end close()d its connection, you should provide an handle_read() method.

I don't think that breaking perfectly valid code to help hypothetical sloppy applications is a good idea.

Here's what the doc says:
"""
handle_close()   | Implied by a read event with no data available
[...]
handle_close()   | Called when the socket is closed.
"""

Note that "Called when the socket is closed" is confusing: it should probably be rephrased as "Called when the remote endpoint has performed a shutdown", or something along those lines.

----------

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

From report at bugs.python.org  Thu Nov  3 18:45:10 2011
From: report at bugs.python.org (Stefan Krah)
Date: Thu, 03 Nov 2011 17:45:10 +0000
Subject: [issue5875] test_distutils failing on OpenSUSE 10.3, Py3k
In-Reply-To: <1320341392.74.0.918863519617.issue5875@psf.upfronthosting.co.za>
Message-ID: <20111103174501.GA18059@sleipnir.bytereef.org>


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

The buildbot runs as non-root, so it should reproduce this
issue (but it's green).

The original report was for 2.6/3.1, so I think closing this as
out-of-date is reasonable.

----------

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

From report at bugs.python.org  Thu Nov  3 18:56:12 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Thu, 03 Nov 2011 17:56:12 +0000
Subject: [issue12498] asyncore.dispatcher_with_send,
	disconnection problem + miss-conception
In-Reply-To: <1309830930.03.0.793190602228.issue12498@psf.upfronthosting.co.za>
Message-ID: <1320342972.89.0.343789711544.issue12498@psf.upfronthosting.co.za>


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

> The reason is that when TestHandler closes the connection after 
> writing the output buffer, the client receives a POLLHUP which 
> prevents it to receive the data since POLLHUP is triggering a call to 
> handle_close.

Yes, that's the problem it noticed in http://bugs.python.org/issue12498#msg146645 :
"""
(Note that the current code is probably broken: when POLLHUP is
received, this likely means that the remote end has shutdown the
connection, but there might still be some data in the input socket
buffer. I'll try to dig a little...).
"""

I think the best would be to not handle POLLHUP events while POLLIN is set, so that the handlers can have a chance to drain the input socket buffer.
But it's a separate issue, could you create a new one?
You may also add a patch (in the same issue) to remove the useless setting of input flags to poll():
"""
        if flags:
            # Only check for exceptions if object was either readable
            # or writable.
            flags |= select.POLLERR | select.POLLHUP | select.POLLNVAL
            pollster.register(fd, flags)
"""

POLLERR, POLLHUP and POLLNVAL don't make sense when passed as input to poll() (they're set automatically in the output revents).

----------

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

From report at bugs.python.org  Thu Nov  3 18:59:46 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 03 Nov 2011 17:59:46 +0000
Subject: [issue12498] asyncore.dispatcher_with_send,
	disconnection problem + miss-conception
In-Reply-To: <1309830930.03.0.793190602228.issue12498@psf.upfronthosting.co.za>
Message-ID: <1320343186.9.0.29886713706.issue12498@psf.upfronthosting.co.za>


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


----------
nosy: +giampaolo.rodola, josiahcarlson, stutzbach

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

From report at bugs.python.org  Thu Nov  3 19:06:37 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Thu, 03 Nov 2011 18:06:37 +0000
Subject: [issue13336] packaging.command.Command.copy_file doesn't implement
	preserve_mode and preserve_times
Message-ID: <1320343597.32.0.412564968356.issue13336@psf.upfronthosting.co.za>


New submission from Vinay Sajip <vinay_sajip at yahoo.co.uk>:

The packaging.command.Command.copy_file method does not honour the preserve_mode and preserve_times keyword arguments.

Likewise, packaging.command.Command.copy_tree does not honour the preserve_mode, preserve_times and preserve_symlinks keyword arguments.

----------
assignee: tarek
components: Distutils2, Library (Lib)
messages: 146957
nosy: alexis, eric.araujo, tarek, vinay.sajip
priority: normal
severity: normal
status: open
title: packaging.command.Command.copy_file doesn't implement preserve_mode and preserve_times
versions: Python 3.3

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

From report at bugs.python.org  Thu Nov  3 19:09:57 2011
From: report at bugs.python.org (Stefan Krah)
Date: Thu, 03 Nov 2011 18:09:57 +0000
Subject: [issue12998] Memory leak with CTypes Structure
In-Reply-To: <1316240966.68.0.395492985431.issue12998@psf.upfronthosting.co.za>
Message-ID: <1320343797.58.0.469652062432.issue12998@psf.upfronthosting.co.za>


Changes by Stefan Krah <stefan-usenet at bytereef.org>:


----------
status: pending -> closed

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

From report at bugs.python.org  Thu Nov  3 19:19:12 2011
From: report at bugs.python.org (Giampaolo Rodola')
Date: Thu, 03 Nov 2011 18:19:12 +0000
Subject: [issue12498] asyncore.dispatcher_with_send,
	disconnection problem + miss-conception
In-Reply-To: <1309830930.03.0.793190602228.issue12498@psf.upfronthosting.co.za>
Message-ID: <1320344352.9.0.0158976273756.issue12498@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

Follow my comments about half_duplex_close.diff (current latest patch).

+    def handle_close(self):
+        if not self._closing:
+            self._closing = True
+            # try to drain the output buffer
+            while self.writable() and self.initiate_send() > 0:
+                pass
+        self.close()

*Any* while loop should be avoided in the dispatcher. 
The risk is you keep the poller busy for more than a single loop or, at worst, forever.

Also, you expect initiate_send() to return a meaningful value which breaks compatibility with existing asynchat code overriding it.

----------

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

From report at bugs.python.org  Thu Nov  3 19:38:47 2011
From: report at bugs.python.org (Vitja Makarov)
Date: Thu, 03 Nov 2011 18:38:47 +0000
Subject: [issue13284] email.utils.formatdate function does not handle
	timezones correctly.
In-Reply-To: <1319797564.66.0.629117270841.issue13284@psf.upfronthosting.co.za>
Message-ID: <1320345527.78.0.917094021914.issue13284@psf.upfronthosting.co.za>


Vitja Makarov <vitja.makarov at gmail.com> added the comment:

We have the same issue in Russia (MSK timezone). It seems to be related to recent changes in timezone info.

It looks like time.timezone is calculated incorrectly.

You can test that with attached script:

$ TZ=Europe/Moscow python /tmp/test_tz.py
-10800 -14400

Both values should be the same.

----------
nosy: +Vitja.Makarov
Added file: http://bugs.python.org/file23605/test_tz.py

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

From report at bugs.python.org  Thu Nov  3 19:49:07 2011
From: report at bugs.python.org (Erik Bray)
Date: Thu, 03 Nov 2011 18:49:07 +0000
Subject: [issue11805] package_data only allows one glob per-package
In-Reply-To: <1302301429.27.0.797210396018.issue11805@psf.upfronthosting.co.za>
Message-ID: <1320346147.83.0.477244090654.issue11805@psf.upfronthosting.co.za>


Erik Bray <erik.m.bray at gmail.com> added the comment:

> When run from an uninstalled checkout, for example when developing, the 
> file will be found in the checkout.  When run after being installed on 
> a Debian system, the file will be found in /usr/local/share
> /spam/templates/log.txt.  Each Python installation can decide (through 
> sysconfig.cfg) where to install things.

Got it!  I think when I first submitted this issue my primary concern was where the resource files live in different development/deployment contexts.  Looking at sysconfig.cfg makes it all pretty clear, though it was hard to find this information a while ago.

So what exactly is the verdict then?  Keep package_data for now, but encourage resources, and dump data_files all together?  Or...?

----------

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

From report at bugs.python.org  Thu Nov  3 20:03:20 2011
From: report at bugs.python.org (Gerald Dalley)
Date: Thu, 03 Nov 2011 19:03:20 +0000
Subject: [issue13337] IGNORE_CASE doctest option flag
Message-ID: <1320347000.37.0.62477718357.issue13337@psf.upfronthosting.co.za>


New submission from Gerald Dalley <dalleyg at alum.mit.edu>:

It would be helpful to have a doctest flag that makes the test case insensitive.

Use case: nan values are printed as "nan" with typical Linux implementations, but as "NaN" on other operating systems like Solaris.

In a naive implementation, the core change to doctest.OutputChecker.check_output is:

+        if optionflags & IGNORE_CASE:
+            got        = got.lower()
+            want       = want.lower()
+            true_line  = "true\n"
+            false_line = "false\n"
+        else:
+            true_line  = "True\n"
+            false_line = "False\n"
+
         # Handle the common case first, for efficiency:
         # if they're string-identical, always return true.
         if got == want:
             return True

         # The values True and False replaced 1 and 0 as the return
         # value for boolean comparisons in Python 2.3.
         if not (optionflags & DONT_ACCEPT_TRUE_FOR_1):
-            if (got,want) == ("True\n", "1\n"):
+            if (got,want) == (true_line, "1\n"):
                 return True
-            if (got,want) == ("False\n", "0\n"):
+            if (got,want) == (false_line, "0\n"):
                 return True

----------
components: Library (Lib)
messages: 146961
nosy: Gerald.Dalley
priority: normal
severity: normal
status: open
title: IGNORE_CASE doctest option flag
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/issue13337>
_______________________________________

From report at bugs.python.org  Thu Nov  3 20:03:28 2011
From: report at bugs.python.org (Gerald Dalley)
Date: Thu, 03 Nov 2011 19:03:28 +0000
Subject: [issue13337] IGNORE_CASE doctest option flag
In-Reply-To: <1320347000.37.0.62477718357.issue13337@psf.upfronthosting.co.za>
Message-ID: <1320347008.72.0.0724308730807.issue13337@psf.upfronthosting.co.za>


Changes by Gerald Dalley <dalleyg at alum.mit.edu>:


----------
type:  -> feature request

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

From report at bugs.python.org  Thu Nov  3 20:06:13 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Thu, 03 Nov 2011 19:06:13 +0000
Subject: [issue13303] Sporadic importlib failures: FileNotFoundError on
	os.rename()
In-Reply-To: <1320058871.09.0.581986884521.issue13303@psf.upfronthosting.co.za>
Message-ID: <1320347173.55.0.656255701663.issue13303@psf.upfronthosting.co.za>


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

Here's a patch using the '.tmp' suffix.
I also updated test_import.
Note that the current test_import.test_execute_bit_not_copied is a no-op:
"""
                fname = TESTFN + os.extsep + "py"
                create_empty_file(fname)
                os.chmod(fname, (stat.S_IRUSR | stat.S_IRGRP | stat.S_IROTH |
                                 stat.S_IXUSR | stat.S_IXGRP | stat.S_IXOTH))
                __import__(TESTFN)
                fn = imp.cache_from_source(fname)
                if not os.path.exists(fn):
                    self.fail("__import__ did not result in creation of "
                              "either a .pyc or .pyo file")
                    s = os.stat(fn)
                    self.assertEqual(
                        stat.S_IMODE(s.st_mode),
                        stat.S_IRUSR | stat.S_IRGRP | stat.S_IROTH)

"""

The indentation is wrong: the stat() is never performed...
I'll fix that in 3.2 and 2.7.

----------
Added file: http://bugs.python.org/file23606/import_perm.diff

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

From report at bugs.python.org  Thu Nov  3 20:35:38 2011
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 03 Nov 2011 19:35:38 +0000
Subject: [issue10570] curses.tigetstr() returns bytes,
	but curses.tparm() expects a string
In-Reply-To: <1290987535.2.0.130889699839.issue10570@psf.upfronthosting.co.za>
Message-ID: <E1RM34U-0001Va-B9@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 38f4a251608f by Victor Stinner in branch '3.2':
Issue #10570: curses.putp() is now expecting a byte string, instead of a
http://hg.python.org/cpython/rev/38f4a251608f

New changeset 08f44eb760a6 by Victor Stinner in branch 'default':
(Merge 3.2) Issue #10570: curses.putp() is now expecting a byte string, instead
http://hg.python.org/cpython/rev/08f44eb760a6

----------

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

From report at bugs.python.org  Thu Nov  3 20:36:19 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 03 Nov 2011 19:36:19 +0000
Subject: [issue10570] curses.tigetstr() returns bytes,
	but curses.tparm() expects a string
In-Reply-To: <1290987535.2.0.130889699839.issue10570@psf.upfronthosting.co.za>
Message-ID: <1320348979.45.0.590091288144.issue10570@psf.upfronthosting.co.za>


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

> It seems that putp() should also accept only bytes,
> because it's used to output terminal commands.

Ok, here is another fix for Python 3.2 and 3.3. I'm closing the issue again.

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

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

From report at bugs.python.org  Thu Nov  3 20:54:37 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 03 Nov 2011 19:54:37 +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: <1320350077.66.0.631143808366.issue12342@psf.upfronthosting.co.za>


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

Here is the patch as a .patch file.

----------
keywords: +patch
Added file: http://bugs.python.org/file23607/tcl_unicode_range.patch

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

From report at bugs.python.org  Thu Nov  3 20:54:40 2011
From: report at bugs.python.org (Xavier de Gaye)
Date: Thu, 03 Nov 2011 19:54:40 +0000
Subject: [issue13311] asyncore handle_read should call recv
In-Reply-To: <1320163710.5.0.667995234807.issue13311@psf.upfronthosting.co.za>
Message-ID: <1320350080.89.0.878923744396.issue13311@psf.upfronthosting.co.za>


Xavier de Gaye <xdegaye at gmail.com> added the comment:

> In this kind of situation, it is perfectly legitimate for the client
> to perform a half-duplex close (shutdown(SHUT_WR)), since it does
> not intend to send data (which is implied by the fact that the sever
> doesn't implement an handle_read() method).

> With the current code, the server will keep sending data until the
> remote end close()s its socket.
> With this patch, this would break: the server's handle_close()
> method will be called right away.

Since this patch may break existing valid code, I think it should be
closed as invalid.

----------

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

From report at bugs.python.org  Thu Nov  3 20:57:05 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 03 Nov 2011 19:57:05 +0000
Subject: [issue13305] datetime.strftime("%Y") not consistent for years < 1000
In-Reply-To: <1320091957.61.0.759691422668.issue13305@psf.upfronthosting.co.za>
Message-ID: <1320350225.68.0.632574414335.issue13305@psf.upfronthosting.co.za>


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

Did your commit fix the issue or not?

----------

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

From report at bugs.python.org  Thu Nov  3 21:02:37 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 03 Nov 2011 20:02:37 +0000
Subject: [issue11812] transient socket failure to connect to 'localhost'
In-Reply-To: <1302386214.84.0.811032327589.issue11812@psf.upfronthosting.co.za>
Message-ID: <1320350557.62.0.611252023046.issue11812@psf.upfronthosting.co.za>


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

> Sure, if you have access to a machine on which you can
> reliably reproduce the problem, it'll be much easier.

I explain a reliable method to reproduce this issue on Linux (it may work on other OSes) in msg138882.

----------

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

From report at bugs.python.org  Thu Nov  3 21:07:09 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 03 Nov 2011 20:07:09 +0000
Subject: [issue8256] input() doesn't catch _PyUnicode_AsString() exception;
	io.StringIO().encoding is None
In-Reply-To: <1269807316.51.0.487538621224.issue8256@psf.upfronthosting.co.za>
Message-ID: <1320350829.11.0.180572710517.issue8256@psf.upfronthosting.co.za>


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

A patch similar to input_stdout_encoding.patch has been applied to 3.2 and 3.3 for the issue #6697: see changeset 846866aa0eb6.

----------

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

From report at bugs.python.org  Thu Nov  3 21:08:45 2011
From: report at bugs.python.org (Xavier de Gaye)
Date: Thu, 03 Nov 2011 20:08:45 +0000
Subject: [issue12498] asyncore.dispatcher_with_send,
	disconnection problem + miss-conception
In-Reply-To: <1309830930.03.0.793190602228.issue12498@psf.upfronthosting.co.za>
Message-ID: <1320350925.26.0.646290297907.issue12498@psf.upfronthosting.co.za>


Xavier de Gaye <xdegaye at gmail.com> added the comment:

> I think the best would be to not handle POLLHUP events while POLLIN
> is set, so that the handlers can have a chance to drain the input
> socket buffer.

Ok.


> But it's a separate issue, could you create a new one?

The test case fails if the data has not been fully received by the
client. Do you mean that this new issue must be fixed first. Why a new
issue, after all this is the handling of a half-duplex disconnection
on the remote side ?

----------

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

From report at bugs.python.org  Thu Nov  3 21:12:39 2011
From: report at bugs.python.org (Xavier de Gaye)
Date: Thu, 03 Nov 2011 20:12:39 +0000
Subject: [issue12498] asyncore.dispatcher_with_send,
	disconnection problem + miss-conception
In-Reply-To: <1309830930.03.0.793190602228.issue12498@psf.upfronthosting.co.za>
Message-ID: <1320351159.06.0.66571955508.issue12498@psf.upfronthosting.co.za>


Xavier de Gaye <xdegaye at gmail.com> added the comment:

Follow my comments about half_duplex_close.diff (current latest patch).

+    def handle_close(self):
+        if not self._closing:
+            self._closing = True
+            # try to drain the output buffer
+            while self.writable() and self.initiate_send() > 0:
+                pass
+        self.close()

> *Any* while loop should be avoided in the dispatcher. 
> The risk is you keep the poller busy for more than a single loop or,
> at worst, forever.

Right. I will try to change that.


> Also, you expect initiate_send() to return a meaningful value which
> breaks compatibility with existing asynchat code overriding it.

The patch changes also initiate_send() accordingly in asynchat.

----------

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

From report at bugs.python.org  Thu Nov  3 21:20:49 2011
From: report at bugs.python.org (Florent Xicluna)
Date: Thu, 03 Nov 2011 20:20:49 +0000
Subject: [issue13305] datetime.strftime("%Y") not consistent for years < 1000
In-Reply-To: <1320091957.61.0.759691422668.issue13305@psf.upfronthosting.co.za>
Message-ID: <1320351649.51.0.916134076248.issue13305@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

I understand that the issue is because the C standard does not specify the length of the string returned by '%Y'.

The changeset 230f0956aaa3 adds a test to verify that either '%Y' or '%4Y' returns a 4-digits value usable to produce ISO-8601 representations.

Now it is a documentation issue: add a comment to the "%Y" specifier saying that the padding is not applicable to all platforms and in such case the "%4Y" specifier should return the 4-digit value.

----------
assignee:  -> docs at python
components: +Documentation
dependencies:  -external strftime for Python?
nosy: +docs at python
superseder:  -> external strftime for Python?

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

From report at bugs.python.org  Thu Nov  3 21:25:56 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 03 Nov 2011 20:25:56 +0000
Subject: [issue8256] input() doesn't catch _PyUnicode_AsString() exception;
	io.StringIO().encoding is None
In-Reply-To: <1269807316.51.0.487538621224.issue8256@psf.upfronthosting.co.za>
Message-ID: <1320351956.97.0.304547750094.issue8256@psf.upfronthosting.co.za>


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

input_stdout_none_encoding.patch uses UTF-8 if sys.stdout.encoding is None.

----------
Added file: http://bugs.python.org/file23608/input_stdout_none_encoding.patch

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

From report at bugs.python.org  Thu Nov  3 21:27:43 2011
From: report at bugs.python.org (Xavier de Gaye)
Date: Thu, 03 Nov 2011 20:27:43 +0000
Subject: [issue12498] asyncore.dispatcher_with_send,
	disconnection problem + miss-conception
In-Reply-To: <1309830930.03.0.793190602228.issue12498@psf.upfronthosting.co.za>
Message-ID: <1320352063.14.0.0768697158658.issue12498@psf.upfronthosting.co.za>


Xavier de Gaye <xdegaye at gmail.com> added the comment:

> this is the handling of a half-duplex disconnection on the remote
> side ?

Actually this is not the handling of a half-duplex disconnection on the
remote side, but we need a half-duplex disconnection to test it.

----------

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

From report at bugs.python.org  Thu Nov  3 21:28:02 2011
From: report at bugs.python.org (simohe)
Date: Thu, 03 Nov 2011 20:28:02 +0000
Subject: [issue13316] build_py_2to3 does not convert when there was an error
	in the last run
In-Reply-To: <1320182540.3.0.985799836702.issue13316@psf.upfronthosting.co.za>
Message-ID: <1320352082.92.0.711894736306.issue13316@psf.upfronthosting.co.za>


simohe <simohe at besonet.ch> added the comment:

It does stop with an error message.
But when I reinvoke the command, converting is skipped (because the file is already copied). No error message is raised and the build continues with the remaining jobs (build_*).
It should reexecute at least the failing conversion and those after them. (And when the error still is there, it should reraise it.)

----------

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

From report at bugs.python.org  Thu Nov  3 21:30:17 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 03 Nov 2011 20:30:17 +0000
Subject: [issue13305] datetime.strftime("%Y") not consistent for years < 1000
In-Reply-To: <1320091957.61.0.759691422668.issue13305@psf.upfronthosting.co.za>
Message-ID: <1320352217.17.0.0694751160331.issue13305@psf.upfronthosting.co.za>


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

Since the changeset 55a3b563f0dbed04af317f632f7f3c0f6abe175b, test_strptime is failing on "AMD64 Gentoo Wide 3.x" buildbot:

======================================================================
FAIL: test_strptime (test.test_time.TimeTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/buildbot/buildarea/3.x.ochtman-gentoo-amd64/build/Lib/test/test_time.py", line 159, in test_strptime
    time.strptime(strf_output, format)
ValueError: time data 'LMT' does not match format '%Z'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/home/buildbot/buildarea/3.x.ochtman-gentoo-amd64/build/Lib/test/test_time.py", line 162, in test_strptime
    (format, strf_output))
AssertionError: conversion specifier '%Z' failed with 'LMT' input.

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

http://www.python.org/dev/buildbot/all/builders/AMD64%20Gentoo%20Wide%203.x/builds/2661

----------

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

From report at bugs.python.org  Thu Nov  3 21:30:55 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 03 Nov 2011 20:30:55 +0000
Subject: [issue13332] execfile fixer produces code that does not close the file
In-Reply-To: <1320322292.48.0.851588051991.issue13332@psf.upfronthosting.co.za>
Message-ID: <1320352255.67.0.0721553929684.issue13332@psf.upfronthosting.co.za>


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

Or you could just explicitly write out the exec(compile()) in your 2.x code.

----------

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

From report at bugs.python.org  Thu Nov  3 21:39:43 2011
From: report at bugs.python.org (Florent Xicluna)
Date: Thu, 03 Nov 2011 20:39:43 +0000
Subject: [issue13305] datetime.strftime("%Y") not consistent for years < 1000
In-Reply-To: <1320091957.61.0.759691422668.issue13305@psf.upfronthosting.co.za>
Message-ID: <1320352783.86.0.848819243964.issue13305@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

other test_time related errors are followed with issue 13309, issue 13312 and issue 13313

----------

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

From report at bugs.python.org  Thu Nov  3 21:51:35 2011
From: report at bugs.python.org (simohe)
Date: Thu, 03 Nov 2011 20:51:35 +0000
Subject: [issue13317] building with 2to3 generates wrong import paths because
	build_ext is run after build_py
In-Reply-To: <1320183133.27.0.209500697705.issue13317@psf.upfronthosting.co.za>
Message-ID: <1320353495.15.0.419965770813.issue13317@psf.upfronthosting.co.za>


simohe <simohe at besonet.ch> added the comment:

fix_imports rewrites the import statements to local or global. When a python module loads a local extension module, this import statement should be converted to a local import (from . import extensionmodule). But when the extension module is not built yet, fix_imports does not find them (no file named extenstionmodule.[so|sl]). So it suggests a global import (import extensionmodule).


The original comment is a slightly modified version of this here:
http://selenic.com/hg/file/afc02adf4ded/contrib/setup3k.py#l223


short summary:

build.sub_commands in distutils.command.build should list "build_ext" before "build_py".
lib2to3.fixes.fix_import will write global instead of local import statements else.

----------
assignee:  -> tarek
components: +Distutils -Build
nosy: +tarek

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

From report at bugs.python.org  Thu Nov  3 22:20:40 2011
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 03 Nov 2011 21:20:40 +0000
Subject: [issue13314] ImportError ImportError: Import by filename,
	should be deferred until sys.meta_path hooks are processed
In-Reply-To: <1320170547.3.0.447612016778.issue13314@psf.upfronthosting.co.za>
Message-ID: <1320355240.42.0.789576413269.issue13314@psf.upfronthosting.co.za>


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

This is working as intended. Importers on sys.meta_path should be able to rely on the assumption that the names they are given are syntactically proper module names and not just any random string. You could perform a transform from module name to random string name in an importer or whatever to support some funky naming scheme under the hood. You could also walk sys.meta_path yourself to get around this sanity check, but I see no value in changing import itself to support this use case.

----------
resolution:  -> rejected
status: open -> closed

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

From report at bugs.python.org  Thu Nov  3 22:25:11 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 03 Nov 2011 21:25:11 +0000
Subject: [issue13323] urllib2 does not correctly handle
	multiple	www-authenticate headers in an HTTP response
In-Reply-To: <1320249966.17.0.892468926199.issue13323@psf.upfronthosting.co.za>
Message-ID: <1320355511.49.0.118718364957.issue13323@psf.upfronthosting.co.za>


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

Would you like to provide a patch?

----------

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

From report at bugs.python.org  Thu Nov  3 22:36:32 2011
From: report at bugs.python.org (Rob Bairos)
Date: Thu, 03 Nov 2011 21:36:32 +0000
Subject: [issue13314] ImportError ImportError: Import by filename,
	should be deferred until sys.meta_path hooks are processed
In-Reply-To: <1320170547.3.0.447612016778.issue13314@psf.upfronthosting.co.za>
Message-ID: <1320356192.97.0.43889339662.issue13314@psf.upfronthosting.co.za>


Rob Bairos <rbairos at gmail.com> added the comment:

Why is a module name syntactically improper simply because it contains a slash?  That seems an arbitrary definition, that serves no purpose, except to discourage accidentally specifying a filename.

Module with unusual characters all reach the meta_path stage,
eg:  my,mo*d1?2my##m;o#d13

But as soon as a slash is introduced, a warning that filenames not being supported is thrown.

1) If the issue is that its not syntactically correct, it should state so.
2) If the issue is that its not syntactically correct, the syntax of a module name should be documented to include *,?#  or throw the same exception.
3) Whats the purpose of the 'Import my filename' exception anyhow? Will it not fail soon thereafter at any rate?

This behaviour is definitely inconsistent and arbitrary.

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

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

From report at bugs.python.org  Thu Nov  3 22:39:34 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 03 Nov 2011 21:39:34 +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: <1320356374.25.0.482906898366.issue12342@psf.upfronthosting.co.za>


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

I'm not sure whether the wording is good English, but apart from that, the patch looks fine.

----------

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

From report at bugs.python.org  Thu Nov  3 22:49:02 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 03 Nov 2011 21:49:02 +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: <1320356942.66.0.551941620668.issue12342@psf.upfronthosting.co.za>


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

The patch implements my suggestion. Looking again, I think the English is fine ;-).

----------
stage:  -> commit review

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

From report at bugs.python.org  Thu Nov  3 22:55:46 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Thu, 03 Nov 2011 21:55: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: <1320357346.12.0.743887381911.issue11812@psf.upfronthosting.co.za>


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

> I explain a reliable method to reproduce this issue on Linux

It's a way to reproduce the symptom (i.e. connection refused because you're trying to connect to 127.0.0.2 while the server is listening on 127.0.0.1), but not the cause: if the server binds to 'localhost' and the client connects to 'localhost', it should work.
But like you, I think it could be a good idea to change support.HOST to 127.0.0.1, to rule out name resolution delay (especially since Windows 7 doens't use its host file to resolve 'localhost' anymore, but calls the DNS solver).

----------

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

From report at bugs.python.org  Thu Nov  3 22:58:51 2011
From: report at bugs.python.org (Vlada Peric)
Date: Thu, 03 Nov 2011 21:58:51 +0000
Subject: [issue13332] execfile fixer produces code that does not close the file
In-Reply-To: <1320322292.48.0.851588051991.issue13332@psf.upfronthosting.co.za>
Message-ID: <1320357531.13.0.433519823815.issue13332@psf.upfronthosting.co.za>


Changes by Vlada Peric <vlada.peric at gmail.com>:


----------
nosy: +VPeric

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

From report at bugs.python.org  Thu Nov  3 22:59:31 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 03 Nov 2011 21:59:31 +0000
Subject: [issue13337] IGNORE_CASE doctest option flag
In-Reply-To: <1320347000.37.0.62477718357.issue13337@psf.upfronthosting.co.za>
Message-ID: <1320357571.58.0.181563641878.issue13337@psf.upfronthosting.co.za>


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

> Use case: nan values are printed as "nan" with typical Linux
> implementations, but as "NaN" on other operating systems like Solaris.

Did you test with Python 2.7 or above? ITSM that 
   repr(float("nan")) == "nan"
consistently on all platforms.

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

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

From report at bugs.python.org  Thu Nov  3 23:14:50 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 03 Nov 2011 22:14:50 +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: <1320358490.95.0.69790248577.issue12342@psf.upfronthosting.co.za>


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

You could say "Unicode character ..." in the error to make clear what kind of range is U+0000-U+FFFF (people that are not familiar with Unicode and BMP chars might wonder if that's some tcl/tk thing).

----------

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

From report at bugs.python.org  Thu Nov  3 23:26:31 2011
From: report at bugs.python.org (Florent Xicluna)
Date: Thu, 03 Nov 2011 22:26:31 +0000
Subject: [issue13140] ThreadingMixIn.daemon_threads is not honored when parent
	is daemon
In-Reply-To: <1318191525.3.0.322601594247.issue13140@psf.upfronthosting.co.za>
Message-ID: <1320359191.25.0.39674771657.issue13140@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

I agree it is a bug. It does not make sense to preserve this behaviour.
I plan to apply the initial patch by Charles-Fran?ois to 2.7 and 3.x.

----------

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

From report at bugs.python.org  Thu Nov  3 23:26:46 2011
From: report at bugs.python.org (Florent Xicluna)
Date: Thu, 03 Nov 2011 22:26:46 +0000
Subject: [issue13140] ThreadingMixIn.daemon_threads is not honored when parent
	is daemon
In-Reply-To: <1318191525.3.0.322601594247.issue13140@psf.upfronthosting.co.za>
Message-ID: <1320359206.14.0.0250714000094.issue13140@psf.upfronthosting.co.za>


Changes by Florent Xicluna <florent.xicluna at gmail.com>:


----------
assignee:  -> flox

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

From report at bugs.python.org  Thu Nov  3 23:42:44 2011
From: report at bugs.python.org (Gerald Dalley)
Date: Thu, 03 Nov 2011 22:42:44 +0000
Subject: [issue13337] IGNORE_CASE doctest option flag
In-Reply-To: <1320347000.37.0.62477718357.issue13337@psf.upfronthosting.co.za>
Message-ID: <1320360164.79.0.423292397411.issue13337@psf.upfronthosting.co.za>


Gerald Dalley <dalleyg at alum.mit.edu> added the comment:

ITSM?

The motivating use case here comes from "nan" strings produced by libc in extension modules (even though python itself and some major libraries like numpy are consistent).  At least some versions Solaris and Linux differ in this particular case.

----------

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

From report at bugs.python.org  Fri Nov  4 00:17:39 2011
From: report at bugs.python.org (Paul Moore)
Date: Thu, 03 Nov 2011 23:17:39 +0000
Subject: [issue11805] package_data only allows one glob per-package
In-Reply-To: <1302301429.27.0.797210396018.issue11805@psf.upfronthosting.co.za>
Message-ID: <1320362259.89.0.0292222533873.issue11805@psf.upfronthosting.co.za>


Paul Moore <p.f.moore at gmail.com> added the comment:

I see what you're saying - and looking through sysconfig.cfg, I can see how things are expected to be laid out (and how I'd configure it if I didn't like it :-))

But as far as I can see, there's no way in packaging to describe a module that works like sysconfig itself! (A module with a resource which is expected to live alongside the .py file). Installing the cfg file to {purelib} would work in practice, but if the distribution containing sysconfig was later changed to include a C extension, then the code would get silently switched to install into platlib, and the .cfg file would no longer be alongside the .py file.

(This is only actually the case when purebase and base differ - which never happens on Windows, and I don't really understand when it would happen on Unix. So I can't really say how likely and/or important this possibility is. But it's certainly there.)

I'd like to see an extra category that was guaranteed to point to where the code files were going to be installed (i.e., the same as whichever one of platlib or purelib the packaging installer chooses). With that, it would be possible (but still clumsy) to implement package data reliably.

OK, having said all that, I do think that saying "package_data was wrong, let?s move away from that" is a bit user-unfriendly. Whether it causes issues for OS distributors, or is "wrong" as a matter of principle, people do use it, a lot. It's the basis of the whole egg concept (a package and its data as a single self-contained object), it's used by distutils itself as you mention, as well as in a number of other places in the stdlib. If you don't support it, I predict that people are simply going to invent more and more elaborate hacks to emulate it.

Actually, given that packaging should allow a hook to find out where a given file is going to be installed (if it isn't, expect a feature request :-)), it should be reasonably easy to write a hook to add a custom category for this purpose. But I'd argue that it's better to put the feature in packaging directly, rather than see the same workaround implemented over and over again.

----------
nosy: +pmoore

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

From report at bugs.python.org  Fri Nov  4 00:42:26 2011
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 03 Nov 2011 23:42:26 +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: <E1RM6vJ-0007G0-O4@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 9a07b73abdb1 by Victor Stinner in branch '3.2':
Issue #12342: Improve _tkinter error message on unencodable character
http://hg.python.org/cpython/rev/9a07b73abdb1

New changeset 5aea95d41ad2 by Victor Stinner in branch 'default':
(Merge 3.2) Issue #12342: Improve _tkinter error message on unencodable character
http://hg.python.org/cpython/rev/5aea95d41ad2

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

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

From report at bugs.python.org  Fri Nov  4 00:49:36 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 03 Nov 2011 23:49:36 +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: <1320364176.23.0.457733990477.issue12342@psf.upfronthosting.co.za>


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

_tkinter now raises ValueError("character U+10ffff is above the range (U+0000-U+FFFF) allowed by Tcl").

> You could say "Unicode character ..." in the error to make clear
> what kind of range is U+0000-U+FFFF (people that are not familiar
> with Unicode and BMP chars might wonder if that's some tcl/tk thing).

I consider that U+10ffff in "character U+10ffff" is enough to specify that it is a Unicode character. Even if you don't understand Unicode, you can at least computer numbers (0x10ffff is not in range [0x0000; 0xFFFF]) ;-)

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

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

From report at bugs.python.org  Fri Nov  4 01:11:06 2011
From: report at bugs.python.org (Aaron Meurer)
Date: Fri, 04 Nov 2011 00:11:06 +0000
Subject: [issue13332] execfile fixer produces code that does not close the file
In-Reply-To: <1320322292.48.0.851588051991.issue13332@psf.upfronthosting.co.za>
Message-ID: <1320365466.3.0.813102368934.issue13332@psf.upfronthosting.co.za>


Changes by Aaron Meurer <asmeurer at gmail.com>:


----------
nosy: +Aaron.Meurer

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

From report at bugs.python.org  Fri Nov  4 01:24:44 2011
From: report at bugs.python.org (Floris Bruynooghe)
Date: Fri, 04 Nov 2011 00:24:44 +0000
Subject: [issue13338] Not all enumerations used in _Py_ANNOTATE_MEMORY_ORDER
Message-ID: <1320366284.3.0.0625863072508.issue13338@psf.upfronthosting.co.za>


New submission from Floris Bruynooghe <floris.bruynooghe at gmail.com>:

Hi,

When compiling using gcc and -Werror=switch-enum the compilation fails, e.g. while compiling an extension module:

In file included from /usr/include/python3.2mu/Python.h:52:0,
                 from src/util.c:27:
/usr/include/python3.2mu/pyatomic.h: In function ?_Py_ANNOTATE_MEMORY_ORDER?:
/usr/include/python3.2mu/pyatomic.h:61:5: error: enumeration value ?_Py_memory_order_relaxed? not handled in switch [-Werror=switch-enum]
/usr/include/python3.2mu/pyatomic.h:61:5: error: enumeration value ?_Py_memory_order_acquire? not handled in switch [-Werror=switch-enum]
/usr/include/python3.2mu/pyatomic.h:70:5: error: enumeration value ?_Py_memory_order_relaxed? not handled in switch [-Werror=switch-enum]
/usr/include/python3.2mu/pyatomic.h:70:5: error: enumeration value ?_Py_memory_order_release? not handled in switch [-Werror=switch-enum]

This could be easily resolved without any drawbacks by simply listing the missing enumeration items together with the default.  And that would enable extensions to be built using -Werror=switch-enum again.

Regards,
Floris

----------
components: Interpreter Core
messages: 146993
nosy: flub
priority: normal
severity: normal
status: open
title: Not all enumerations used in _Py_ANNOTATE_MEMORY_ORDER
type: compile error
versions: Python 3.2, Python 3.3

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

From report at bugs.python.org  Fri Nov  4 01:27:38 2011
From: report at bugs.python.org (Florent Xicluna)
Date: Fri, 04 Nov 2011 00:27:38 +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: <1320366458.96.0.520000010389.issue12342@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

Failed to build these modules: (3.3 on Snow Leopard)
_tkinter


./cpython/Modules/_tkinter.c: In function ?AsObj?:
./cpython/Modules/_tkinter.c:996: warning: dereferencing ?void *? pointer
./cpython/Modules/_tkinter.c:996: error: invalid use of void expression

----------
nosy: +flox
status: closed -> open

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

From report at bugs.python.org  Fri Nov  4 05:34:24 2011
From: report at bugs.python.org (Robert Xiao)
Date: Fri, 04 Nov 2011 04:34:24 +0000
Subject: [issue13339] Missing semicolon at Modules/posixsubprocess.c:4511
Message-ID: <1320381264.57.0.354485296745.issue13339@psf.upfronthosting.co.za>


New submission from Robert Xiao <nneonneo at gmail.com>:

Line 4511 of Modules/posixsubprocess.c is missing a semicolon, so it would not compile successfully if the relevant build flags were enabled (PYOS_OS2).

Trivial patch:
@@ -4508,7 +4508,7 @@
 static PyObject *
 posix_spawnvpe(PyObject *self, PyObject *args)
 {
-    PyObject *opath
+    PyObject *opath;
     char *path;
     PyObject *argv, *env;
     char **argvlist;

No tests needed since it's a compile error.

----------
components: Extension Modules
messages: 146995
nosy: nneonneo
priority: normal
severity: normal
status: open
title: Missing semicolon at Modules/posixsubprocess.c:4511
type: compile error
versions: Python 3.1, Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Fri Nov  4 06:15:40 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 04 Nov 2011 05:15:40 +0000
Subject: [issue13339] Missing semicolon at Modules/posixsubprocess.c:4511
In-Reply-To: <1320381264.57.0.354485296745.issue13339@psf.upfronthosting.co.za>
Message-ID: <E1RMC7h-0006fu-Qn@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset fa9c69dcf31b by Ross Lagerwall in branch '3.2':
Issue #13339: Fix compile error in posixmodule.c due to missing semicolon.
http://hg.python.org/cpython/rev/fa9c69dcf31b

New changeset 9e5d14aadca4 by Ross Lagerwall in branch 'default':
(Merge 3.2) Issue #13339.
http://hg.python.org/cpython/rev/9e5d14aadca4

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

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

From report at bugs.python.org  Fri Nov  4 07:41:20 2011
From: report at bugs.python.org (Ross Lagerwall)
Date: Fri, 04 Nov 2011 06:41:20 +0000
Subject: [issue13339] Missing semicolon at Modules/posixsubprocess.c:4511
In-Reply-To: <1320381264.57.0.354485296745.issue13339@psf.upfronthosting.co.za>
Message-ID: <1320388880.67.0.961338055951.issue13339@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

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

From report at bugs.python.org  Fri Nov  4 09:24:30 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Fri, 04 Nov 2011 08:24:30 +0000
Subject: [issue13322] buffered read() and write() does not raise
	BlockingIOError
In-Reply-To: <1320246535.71.0.465783773129.issue13322@psf.upfronthosting.co.za>
Message-ID: <1320395070.26.0.825412055288.issue13322@psf.upfronthosting.co.za>


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

> This is a hairy issue

Indeed.

Performing partial read/write may sound imperfect, but using buffered I/O around non-blockind FD is definitely not a good idea.
Also, the advantage of the current approach is that at least, no data is ever lost (and changing the behavior to raise a BlockingIOError might break some code out there in the wild).

Note that Java's BufferedInputStream and ReadableByteChannel also return partial reads.

So I'm somewhat inclined to keep the current behavior (it would however probably be a good idea to update the documentation to warn about this limitation, though).

----------

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

From report at bugs.python.org  Fri Nov  4 09:49:13 2011
From: report at bugs.python.org (Florent Xicluna)
Date: Fri, 04 Nov 2011 08:49:13 +0000
Subject: [issue13254] maildir.items() broken
In-Reply-To: <1319447699.1.0.36723918452.issue13254@psf.upfronthosting.co.za>
Message-ID: <1320396553.14.0.083445624302.issue13254@psf.upfronthosting.co.za>


Changes by Florent Xicluna <florent.xicluna at gmail.com>:


Removed file: http://bugs.python.org/file23586/issue13254_v2.diff

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

From report at bugs.python.org  Fri Nov  4 09:49:31 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 04 Nov 2011 08:49:31 +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: <E1RMFSk-0005Zm-Ek@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 5f49b496d161 by Victor Stinner in branch 'default':
Issue #12342: Fix compilation on Mac OS X
http://hg.python.org/cpython/rev/5f49b496d161

----------

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

From report at bugs.python.org  Fri Nov  4 09:49:40 2011
From: report at bugs.python.org (Florent Xicluna)
Date: Fri, 04 Nov 2011 08:49:40 +0000
Subject: [issue13254] maildir.items() broken
In-Reply-To: <1319447699.1.0.36723918452.issue13254@psf.upfronthosting.co.za>
Message-ID: <1320396580.06.0.580448395711.issue13254@psf.upfronthosting.co.za>


Changes by Florent Xicluna <florent.xicluna at gmail.com>:


----------
keywords:  -needs review

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

From report at bugs.python.org  Fri Nov  4 10:23:04 2011
From: report at bugs.python.org (Carl Friedrich Bolz)
Date: Fri, 04 Nov 2011 09:23:04 +0000
Subject: [issue13340] list.index does not accept None as start or stop
Message-ID: <1320398584.03.0.145013152611.issue13340@psf.upfronthosting.co.za>


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

The list.index method does not accept None as start and stop, which makes the error message quite confusing:

>>> [1, 2, 3].index(2, None, 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

I checked this in 3.2.2 and 2.7.2. Seems similar to #12163.

----------
messages: 147000
nosy: Carl.Friedrich.Bolz
priority: normal
severity: normal
status: open
title: list.index does not accept None as start or stop
type: behavior
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Fri Nov  4 10:23:37 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 04 Nov 2011 09:23:37 +0000
Subject: [issue13140] ThreadingMixIn.daemon_threads is not honored when parent
	is daemon
In-Reply-To: <1318191525.3.0.322601594247.issue13140@psf.upfronthosting.co.za>
Message-ID: <E1RMFzk-0000G0-Ni@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset f09e3b1603ee by Florent Xicluna in branch '2.7':
Issue #13140: Fix the daemon_threads attribute of ThreadingMixIn.
http://hg.python.org/cpython/rev/f09e3b1603ee

New changeset 94017ce9304d by Florent Xicluna in branch '3.2':
Closes #13140: Fix the daemon_threads attribute of ThreadingMixIn.
http://hg.python.org/cpython/rev/94017ce9304d

New changeset 6fe6769e54a5 by Florent Xicluna in branch 'default':
Merge 3.2: issue #13140
http://hg.python.org/cpython/rev/6fe6769e54a5

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

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

From report at bugs.python.org  Fri Nov  4 14:20:14 2011
From: report at bugs.python.org (Ilya Novoselov)
Date: Fri, 04 Nov 2011 13:20:14 +0000
Subject: [issue13341] Incorrect documentation for "u" PyArg_Parse format unit
Message-ID: <1320412814.48.0.657162308895.issue13341@psf.upfronthosting.co.za>


New submission from Ilya Novoselov <ilya.novoselov at gmail.com>:

Documentation states that u format unit returns "buffer of 16-bit Unicode (UTF-16) data" while it returns pointer to internal buffer of unicode data, which is either UCS-16 or UCS-32

http://docs.python.org/c-api/arg.html

----------
assignee: docs at python
components: Documentation, Unicode
messages: 147002
nosy: Ilya.Novoselov, docs at python, ezio.melotti
priority: normal
severity: normal
status: open
title: Incorrect documentation for "u" PyArg_Parse format unit
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Fri Nov  4 15:03:42 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 04 Nov 2011 14:03:42 +0000
Subject: [issue13322] buffered read() and write() does not raise
	BlockingIOError
In-Reply-To: <1320246535.71.0.465783773129.issue13322@psf.upfronthosting.co.za>
Message-ID: <1320415422.08.0.767868880133.issue13322@psf.upfronthosting.co.za>


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

> Also, the advantage of the current approach is that at least, no data
> is ever lost

But what about the buggy readline() behaviour?

----------

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

From report at bugs.python.org  Fri Nov  4 15:33:40 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 04 Nov 2011 14:33:40 +0000
Subject: [issue13322] buffered read() and write() does not raise
	BlockingIOError
In-Reply-To: <1320246535.71.0.465783773129.issue13322@psf.upfronthosting.co.za>
Message-ID: <1320417220.33.0.515899292418.issue13322@psf.upfronthosting.co.za>


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

> Note that Java's BufferedInputStream and ReadableByteChannel also 
> return partial reads.

Apparently, they are specified to, even for blocking streams (which I find a bit weird, and the language in the docs seems deliberately vague). Python's buffered read(), though, is specified to return the requested number of bytes (unless EOF happens).

----------

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

From report at bugs.python.org  Fri Nov  4 15:37:14 2011
From: report at bugs.python.org (stefanholek)
Date: Fri, 04 Nov 2011 14:37:14 +0000
Subject: [issue13342] input() builtin always uses "strict" error handler
Message-ID: <1320417434.92.0.472252310596.issue13342@psf.upfronthosting.co.za>


New submission from stefanholek <stefan at epy.co.at>:

The input builtin always uses "strict" error handling for Unicode conversions. This means that when I enter a latin-1 string in a utf-8 environment, input breaks with a UnicodeDecodeError. Now don't tell me not to do that, I have a valid use-case. ;-)

While "strict" may be a good default choice, it is clearly not sufficient. I would like to propose an optional 'errors' argument to input, similar to the 'errors' argument the decode and encode methods have.

I have in fact implemented such an input method for my own use:
https://github.com/stefanholek/rl/blob/surrogate-input/rl/input.c

While this solves my immediate needs, the fact that my implementation is basically just a copy of bltinmode.input with one additional argument, makes me think that this could be fixed in Python proper.

There cannot be a reason input() should be confined to "strict", or can there? ;-)

----------
components: Unicode
messages: 147005
nosy: ezio.melotti, stefanholek
priority: normal
severity: normal
status: open
title: input() builtin always uses "strict" error handler
type: behavior
versions: Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Fri Nov  4 15:42:46 2011
From: report at bugs.python.org (Lucas Sinclair)
Date: Fri, 04 Nov 2011 14:42:46 +0000
Subject: [issue13241] llvm-gcc-4.2 miscompiles Python (XCode 4.1 on Mac OS
	10.7)
In-Reply-To: <1319226560.18.0.474501275115.issue13241@psf.upfronthosting.co.za>
Message-ID: <1320417766.59.0.170394526119.issue13241@psf.upfronthosting.co.za>


Lucas Sinclair <blastocyst at mac.com> added the comment:

I'm on 10.7.2, with XCode is 4.2 and the problem is still present. The command "ggc -v" produces the following output:

gcc version 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.1.00)

The command "./configure --with-pydebug && make -j2" fails with the following output:

Assertion failed: (compact->utf8_length == 0), function _PyUnicode_CheckConsistency, file Objects/unicodeobject.c, line 381.
make: *** [sysconfig] Abort trap: 6

The only solution seems to be to install macports and use it to get a more recent gcc like Oleg Plakhotnyuk suggested.

----------
nosy: +xapple

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

From report at bugs.python.org  Fri Nov  4 15:49:18 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 04 Nov 2011 14:49:18 +0000
Subject: [issue13342] input() builtin always uses "strict" error handler
In-Reply-To: <1320417434.92.0.472252310596.issue13342@psf.upfronthosting.co.za>
Message-ID: <1320418158.36.0.711766205995.issue13342@psf.upfronthosting.co.za>


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

There's no reason you couldn't write your own input() function in Python to do this.

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

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

From report at bugs.python.org  Fri Nov  4 16:00:57 2011
From: report at bugs.python.org (stefanholek)
Date: Fri, 04 Nov 2011 15:00:57 +0000
Subject: [issue13342] input() builtin always uses "strict" error handler
In-Reply-To: <1320417434.92.0.472252310596.issue13342@psf.upfronthosting.co.za>
Message-ID: <1320418857.59.0.508152607278.issue13342@psf.upfronthosting.co.za>


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

I am not quite sure how I would write a custom, readline-using input function in Python (access to PyOS_Readline seems required), that's why I did it in C. Have an example?

----------

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

From report at bugs.python.org  Fri Nov  4 16:04:07 2011
From: report at bugs.python.org (sbt)
Date: Fri, 04 Nov 2011 15:04:07 +0000
Subject: [issue13322] buffered read() and write() does not raise
	BlockingIOError
In-Reply-To: <1320246535.71.0.465783773129.issue13322@psf.upfronthosting.co.za>
Message-ID: <1320419047.25.0.854178737094.issue13322@psf.upfronthosting.co.za>


sbt <shibturn at gmail.com> added the comment:

No one has suggested raising BlockingIOError and DISCARDING the data when a partial read has occurred.  The docs seem to imply that the partially read data should be returned since they only say that BlockingIOError should be raised if there is NOTHING to read.  Clearly this should all be spelt out properly.

That leaves the question of whether, when there is NOTHING to read, BlockingIOError should be raised (as the docs say) or None should be returned (as is done now).  I don't mind either way as long as the docs match reality.

The part which really needs addressing is partial writes.  Currently, if a write fails with EAGAIN then IOError is raised and there is no way to work out how much data was written/buffered.  The docs say that BlockingIOError should be raised with the e.args[2] set to indicate the number of bytes written/buffered.  This at least should be fixed.

I will work on a patch.

----------

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

From report at bugs.python.org  Fri Nov  4 16:06:20 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 04 Nov 2011 15:06:20 +0000
Subject: [issue13342] input() builtin always uses "strict" error handler
In-Reply-To: <1320417434.92.0.472252310596.issue13342@psf.upfronthosting.co.za>
Message-ID: <1320419180.24.0.212801305164.issue13342@psf.upfronthosting.co.za>


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

> There cannot be a reason input() should be confined to "strict", or can 
> there? ;-)

Actually, there's a good reason: in the non-interactive case, input() simply calls sys.stdin.read(), which doesn't have encoding or errors attributes. You want to override sys.stdin so that it has the right error handler.

However, there is a bug in input() in that it ignores sys.stdin's error handler in interactive mode (where it delegates to the readline library, if present):

>>> import sys, io
>>> sys.stdin = io.TextIOWrapper(sys.stdin.detach(), "ascii", "replace")
>>> sys.stdin.read()
h?h?
'h??h??\n'
>>> input()
h?h?
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 1: ordinal not in range(128)


If you don't mind losing GNU readline functionality, the immediate workaround for you is to use sys.stdin.read() directly.

----------
components: +Interpreter Core -Unicode
nosy: +pitrou
stage:  -> needs patch
versions:  -Python 3.4

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

From report at bugs.python.org  Fri Nov  4 16:08:06 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 04 Nov 2011 15:08:06 +0000
Subject: [issue13342] input() builtin always uses "strict" error handler
In-Reply-To: <1320417434.92.0.472252310596.issue13342@psf.upfronthosting.co.za>
Message-ID: <1320419286.33.0.982477408453.issue13342@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/issue13342>
_______________________________________

From report at bugs.python.org  Fri Nov  4 16:31:12 2011
From: report at bugs.python.org (sbt)
Date: Fri, 04 Nov 2011 15:31:12 +0000
Subject: [issue13322] buffered read() and write() does not raise
	BlockingIOError
In-Reply-To: <1320246535.71.0.465783773129.issue13322@psf.upfronthosting.co.za>
Message-ID: <1320420672.84.0.0950224951725.issue13322@psf.upfronthosting.co.za>


sbt <shibturn at gmail.com> added the comment:

> But what about the buggy readline() behaviour?

Just tell people that if the return value is a string which does not end in '\n' then it might caused by EOF or EAGAIN.  They can just call readline() again to check which.

----------

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

From report at bugs.python.org  Fri Nov  4 16:48:20 2011
From: report at bugs.python.org (sbt)
Date: Fri, 04 Nov 2011 15:48:20 +0000
Subject: [issue13322] buffered read() and write() does not raise
	BlockingIOError
In-Reply-To: <1320246535.71.0.465783773129.issue13322@psf.upfronthosting.co.za>
Message-ID: <1320421700.71.0.122839828675.issue13322@psf.upfronthosting.co.za>


sbt <shibturn at gmail.com> added the comment:

The third arg of BlockingIOError is used in two quite different ways.

In write(s) it indicates the number of bytes of s which have been "consumed" (ie written to the raw file or buffered).

But in flush() and flush_unlocked() (in _pyio) it indicates the number of bytes from the internal buffer which have been written to the raw file.

I think this explains the following comment in write():

                # We're full, so let's pre-flush the buffer
                try:
                    self._flush_unlocked()
                except BlockingIOError as e:
                    # We can't accept anything else.
                    # XXX Why not just let the exception pass through?
                    raise BlockingIOError(e.errno, e.strerror, 0)

I don't think flush() should try to tell us how many bytes were flushed: we only need to know whether we need to try again.

----------

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

From report at bugs.python.org  Fri Nov  4 17:25:04 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Fri, 04 Nov 2011 16:25:04 +0000
Subject: [issue13322] buffered read() and write() does not raise
	BlockingIOError
In-Reply-To: <1320246535.71.0.465783773129.issue13322@psf.upfronthosting.co.za>
Message-ID: <1320423904.17.0.23870186698.issue13322@psf.upfronthosting.co.za>


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

> Apparently, they are specified to, even for blocking streams (which 
> I find a bit weird, and the language in the docs seems deliberately
> vague). 

"""
As an additional convenience, it attempts to read as many bytes as possible by repeatedly invoking the read method of the underlying stream. This iterated read continues until one of the following conditions becomes true:

The specified number of bytes have been read,
The read method of the underlying stream returns -1, indicating end-of-file, or
The available method of the underlying stream returns zero, indicating that further input requests would block.
"""

As I understand it, it will return the number of bytes asked, unless EOF or EAGAIN/EWOULDBLOCK. It would seem reasonable to me to add the same note for non-blocking FDs to Python's read().

>> But what about the buggy readline() behaviour?
> Just tell people that if the return value is a string which does not 
> end in '\n' then it might caused by EOF or EAGAIN.  They can just call 
> readline() again to check which.

Sounds reasonable.

> No one has suggested raising BlockingIOError and DISCARDING the data 
> when a partial read has occurred.

The problem is that if we raise BlockingIOError, we can only buffer a limited amount of data.

> The docs seem to imply that the partially read data should be returned 
> since they only say that BlockingIOError should be raised if there is 
> NOTHING to read.  Clearly this should all be spelt out properly.

Agreed.

> That leaves the question of whether, when there is NOTHING to 
> read, BlockingIOError should be raised (as the docs say) or None
> should be returned (as is done now).

I don't have a string feeling: if we don't raise BlockingIOError on partial reads, then it probably makes sense to keep None.

----------

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

From report at bugs.python.org  Fri Nov  4 17:37:38 2011
From: report at bugs.python.org (Ned Deily)
Date: Fri, 04 Nov 2011 16:37:38 +0000
Subject: [issue13241] llvm-gcc-4.2 miscompiles Python (XCode 4.1 on Mac OS
	10.7)
In-Reply-To: <1319226560.18.0.474501275115.issue13241@psf.upfronthosting.co.za>
Message-ID: <1320424658.76.0.116806877544.issue13241@psf.upfronthosting.co.za>


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

Lucas, exactly what source version of Python are you trying to build (i.e what does "hg summary" say)?

----------

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

From report at bugs.python.org  Fri Nov  4 18:00:56 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 04 Nov 2011 17:00:56 +0000
Subject: [issue13283] removal of two unused variable in locale.py
In-Reply-To: <1319796863.15.0.791142726242.issue13283@psf.upfronthosting.co.za>
Message-ID: <1320426056.57.0.877189155823.issue13283@psf.upfronthosting.co.za>


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

Our policy is to not commit code cleanup patches that are not strict bug fixes; see thread at http://mail.python.org/pipermail/python-dev/2011-October/114281.html and http://mail.python.org/pipermail/python-dev/2011-November/114301.html

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

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

From report at bugs.python.org  Fri Nov  4 18:12:54 2011
From: report at bugs.python.org (Xavier de Gaye)
Date: Fri, 04 Nov 2011 17:12:54 +0000
Subject: [issue12498] asyncore.dispatcher_with_send,
	disconnection problem + miss-conception
In-Reply-To: <1309830930.03.0.793190602228.issue12498@psf.upfronthosting.co.za>
Message-ID: <1320426774.61.0.116033536512.issue12498@psf.upfronthosting.co.za>


Xavier de Gaye <xdegaye at gmail.com> added the comment:

Attached yet another patch.
This patch does not use a while loop in handle_close() and handles
POLLHUP as suggested by Charles-Fran?ois. No changes have been made to
both tests (test_half_duplex_close).

----------
Added file: http://bugs.python.org/file23609/half_duplex_close_2.diff

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

From report at bugs.python.org  Fri Nov  4 18:16:08 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 04 Nov 2011 17:16:08 +0000
Subject: [issue5301] add mimetype for image/vnd.microsoft.icon (patch)
In-Reply-To: <1234907792.31.0.00254559526039.issue5301@psf.upfronthosting.co.za>
Message-ID: <E1RMNMw-0003WH-GP@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 33680de042e7 by ?ric Araujo in branch '2.7':
Revert commit that was not a bugfix (#5301).
http://hg.python.org/cpython/rev/33680de042e7

----------

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

From report at bugs.python.org  Fri Nov  4 18:17:49 2011
From: report at bugs.python.org (Lucas Sinclair)
Date: Fri, 04 Nov 2011 17:17:49 +0000
Subject: [issue13241] llvm-gcc-4.2 miscompiles Python (XCode 4.1 on Mac OS
	10.7)
In-Reply-To: <1319226560.18.0.474501275115.issue13241@psf.upfronthosting.co.za>
Message-ID: <1320427069.66.0.348487478432.issue13241@psf.upfronthosting.co.za>


Lucas Sinclair <blastocyst at mac.com> added the comment:

I just cloned cpython today. The output of "hg summary" is:

parent: 73351:2bec7c452b39 tip
 Fix C89 incompatibility.
branch: default
commit: (clean)
update: (current)

----------

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

From report at bugs.python.org  Fri Nov  4 18:22:24 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 04 Nov 2011 17:22:24 +0000
Subject: [issue12260] Make install default to user site-packages
In-Reply-To: <1307121861.82.0.570588263731.issue12260@psf.upfronthosting.co.za>
Message-ID: <1320427344.13.0.88140060722.issue12260@psf.upfronthosting.co.za>


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

With the raise of virtualenv and its inclusion in CPython for 3.3, this is even less a concern, even for UNIX.  I?m withdrawing the idea and will continue to advertise --user and warn against sudo in documentation and other venues.

----------
assignee: tarek -> eric.araujo
resolution:  -> rejected
stage:  -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Fri Nov  4 18:25:46 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 04 Nov 2011 17:25:46 +0000
Subject: [issue13342] input() builtin always uses "strict" error handler
In-Reply-To: <1320417434.92.0.472252310596.issue13342@psf.upfronthosting.co.za>
Message-ID: <1320427546.56.0.979459694714.issue13342@psf.upfronthosting.co.za>


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

Here is a patch. The bugfix itself is quite pedestrian, but the test is more interesting. I did what I could to fork a subprocess into a pseudoterminal so as to trigger the GNU readline code path. The only limitation I've found is that I'm unable to read further on the child's stdout after input() has been called. The test therefore uses a pipe to do the return checking.

----------
keywords: +patch
nosy: +neologix
stage: needs patch -> patch review
Added file: http://bugs.python.org/file23610/input_readline.patch

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

From report at bugs.python.org  Fri Nov  4 18:47:12 2011
From: report at bugs.python.org (Rob Bairos)
Date: Fri, 04 Nov 2011 17:47:12 +0000
Subject: [issue13314] ImportError ImportError: Import by filename,
	should be deferred until sys.meta_path hooks are processed
In-Reply-To: <1320170547.3.0.447612016778.issue13314@psf.upfronthosting.co.za>
Message-ID: <1320428832.69.0.969943769201.issue13314@psf.upfronthosting.co.za>


Rob Bairos <rbairos at gmail.com> added the comment:

Yah, thinking about this further, the real error is that sys.meta_path allows processing of names with #,?*  etc.
I can see why this would cause problems, as python names must only be _ and alphanumeric characters.
I'll re-implement this. 
Thanks.

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

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

From report at bugs.python.org  Fri Nov  4 19:18:33 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Fri, 04 Nov 2011 18:18:33 +0000
Subject: [issue13311] asyncore handle_read should call recv
In-Reply-To: <1320163710.5.0.667995234807.issue13311@psf.upfronthosting.co.za>
Message-ID: <1320430713.06.0.708715543121.issue13311@psf.upfronthosting.co.za>


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

> Since this patch may break existing valid code, I think it should be
> closed as invalid.

Yes. Since the benefit is not clear and it may break existing code, it's probably wiser.

----------
resolution:  -> rejected
stage: patch review -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Fri Nov  4 19:32:17 2011
From: report at bugs.python.org (sbt)
Date: Fri, 04 Nov 2011 18:32:17 +0000
Subject: [issue13322] buffered read() and write() does not raise
	BlockingIOError
In-Reply-To: <1320246535.71.0.465783773129.issue13322@psf.upfronthosting.co.za>
Message-ID: <1320431537.86.0.425143296084.issue13322@psf.upfronthosting.co.za>


sbt <shibturn at gmail.com> added the comment:

Currently a BlockingIOError exception raised by flush() sets
characters_written to the number of bytes fushed from the internal
buffer.  This is undocument (although there is a unit test which tests
for it) and causes confusion because characters_written has conflicting
meanings depending on whether the exception was raised by flush() or
write().  I would propose setting characters_written to zero on
BlockingIOError exceptions raised by flush().  Are there any reasons not
to make this change?

Also, the docs say that the raw file wrapped by
BufferedReader/BufferedWriter should implement RawIOBase.  This means
that self.raw.write() should return None instead of raising
BlockingIOError.  But the implementation tries to cope with
BlockingIOError coming from a raw write.  In fact, the
MockNonBlockWriterIO class in unit tests is used as a raw file, but its
write() method raises BlockingIOError.

It would simplify matters a lot to insist that raw files implement
RawIOBase properly.

BTW, when I try to change characters_written of an existing
BlockingIOError exception using the pointer returned by
_buffered_check_blocking_error(), it appears not to work: the exception
continues to have characters_written == 0 -- not sure why...

----------

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

From report at bugs.python.org  Fri Nov  4 20:11:10 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 04 Nov 2011 19:11:10 +0000
Subject: [issue13341] Incorrect documentation for "u" PyArg_Parse format unit
In-Reply-To: <1320412814.48.0.657162308895.issue13341@psf.upfronthosting.co.za>
Message-ID: <1320433870.44.0.68058791537.issue13341@psf.upfronthosting.co.za>


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

Can you write a patch?

----------
nosy: +haypo

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

From report at bugs.python.org  Fri Nov  4 20:15:51 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 04 Nov 2011 19:15:51 +0000
Subject: [issue13287] urllib.request exposes too many names
In-Reply-To: <1319814075.5.0.569025067527.issue13287@psf.upfronthosting.co.za>
Message-ID: <1320434151.26.0.16659208164.issue13287@psf.upfronthosting.co.za>


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

test_urllib2.test___all__() is failing on Windows. Example:

http://www.python.org/dev/buildbot/all/builders/x86%20XP-4%203.x/builds/5498/steps/test/logs/stdio

======================================================================
FAIL: test___all__ (test.test_urllib2.TrivialTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\test\test_urllib2.py", line 32, in test___all__
    (k, module, v.__module__))
AssertionError: 'nturl2path' != 'urllib.request'
- nturl2path
+ urllib.request
 : 'pathname2url' is exposed in 'urllib.request' but defined in 'nturl2path'

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

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

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

From report at bugs.python.org  Fri Nov  4 20:37:32 2011
From: report at bugs.python.org (Joshua Landau)
Date: Fri, 04 Nov 2011 19:37:32 +0000
Subject: [issue13343] Lambda keyword-only argument not updating co_freevars
Message-ID: <1320435452.65.0.656040815575.issue13343@psf.upfronthosting.co.za>


New submission from Joshua Landau <joshua.landau.ws at gmail.com>:

When setting defaults to keyword-only arguments in lambdas which are inside non-global scopes, cPython doesn't push the name to it's closure's co_freevars.

EXAMPLE:
global_variable = None
(lambda: (lambda *, keyword_only=global_variable: None))()

Because the inner lambda hasn't told the outer lambda to put global_variable in co_freevars, it fails to create the default to keyword_only. This only happens if the inner function is a lambda and you are setting a keyword_only variable.

It does not cause a crash if global_variable is local to the outer lambda, as the opcode LOAD_FAST is still created properly (as opposed to LOAD_NAME).

It does not crash if global_variable is used elsewhere in the outer function as co_freevars will be updated with it, allowing LOAD_NAME to retrieve it.



I've never done a bug here before and I'm unsure what to say, so please be nice and correct me if I'm doing it wrong.

----------
components: Interpreter Core
messages: 147026
nosy: Joshua.Landau
priority: normal
severity: normal
status: open
title: Lambda keyword-only argument not updating co_freevars
type: crash
versions: Python 3.2

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

From report at bugs.python.org  Fri Nov  4 20:38:38 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 04 Nov 2011 19:38:38 +0000
Subject: [issue13322] buffered read() and write() does not raise
	BlockingIOError
In-Reply-To: <1320423904.17.0.23870186698.issue13322@psf.upfronthosting.co.za>
Message-ID: <1320435249.3379.3.camel@localhost.localdomain>


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

> >> But what about the buggy readline() behaviour?
> > Just tell people that if the return value is a string which does not 
> > end in '\n' then it might caused by EOF or EAGAIN.  They can just call 
> > readline() again to check which.
> 
> Sounds reasonable.

But then what's the point of using buffered I/O at all? If it can't
offer anything more than raw I/O, I'd rather do something like raise a
RuntimeError("buffered I/O doesn't work with non-blocking streams") when
the raw stream returns None. Returning partial results on a buffered's
readline() is not something we should ever do.

(actually, raw I/O readline() is probably buggy as well)

----------

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

From report at bugs.python.org  Fri Nov  4 21:19:26 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Fri, 04 Nov 2011 20:19:26 +0000
Subject: [issue13322] buffered read() and write() does not raise
	BlockingIOError
In-Reply-To: <1320246535.71.0.465783773129.issue13322@psf.upfronthosting.co.za>
Message-ID: <1320437966.62.0.720070740495.issue13322@psf.upfronthosting.co.za>


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

> But then what's the point of using buffered I/O at all? If it can't
> offer anything more than raw I/O, I'd rather do something like raise
> a RuntimeError("buffered I/O doesn't work with non-blocking streams")
> when the raw stream returns None.

Well, ideally it should be an UnsupportedOperation, but that's an option. The only think I didn't like about this is that we should ideally raise this error upon the first method call, not when - and if - we receive EAGAIN.
Another possibility would be that, since lines are usually reasonably sized, they should fit in the buffer (which is 8KB by default). So we could do the extra effort of buffering the data and return it once the line is complete: if the buffer fills up before we got the whole line, then we could raise a RuntimeError("Partial line read"). Note that I didn't check if it's easily feasible (i.e. we should avoid introducing kludges in the I/O layer just to handle thi corner case).

> Returning partial results on a buffered's readline() is not something
> we should ever do.

Yeah, I know.
Java made the choice of making readline() block, which is IMHO even worse (I mean, it defeats the whole point of non-blocking I/O...).

----------

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

From report at bugs.python.org  Fri Nov  4 21:20:46 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Fri, 04 Nov 2011 20:20:46 +0000
Subject: [issue13342] input() builtin always uses "strict" error handler
In-Reply-To: <1320417434.92.0.472252310596.issue13342@psf.upfronthosting.co.za>
Message-ID: <1320438046.14.0.601956147917.issue13342@psf.upfronthosting.co.za>


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

> The bugfix itself is quite pedestrian, but the test is more interesting.

Indeed. Looks good to me.

----------

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

From report at bugs.python.org  Fri Nov  4 21:29:08 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 04 Nov 2011 20:29:08 +0000
Subject: [issue13343] Lambda keyword-only argument not updating co_freevars
In-Reply-To: <1320435452.65.0.656040815575.issue13343@psf.upfronthosting.co.za>
Message-ID: <1320438548.55.0.0606095894159.issue13343@psf.upfronthosting.co.za>


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


----------
priority: normal -> critical
stage:  -> needs patch
versions: +Python 3.3

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

From report at bugs.python.org  Fri Nov  4 21:41:57 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 04 Nov 2011 20:41:57 +0000
Subject: [issue3067] setlocale error message is confusing
In-Reply-To: <1213013354.87.0.861327880823.issue3067@psf.upfronthosting.co.za>
Message-ID: <E1RMQaB-0007HA-LN@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 931ae170e51c by Petri Lehtinen in branch '3.2':
Issue #3067: Fix the error raised by locale.setlocale()
http://hg.python.org/cpython/rev/931ae170e51c

New changeset d90d88380aca by Petri Lehtinen in branch 'default':
Issue #3067: Fix the error raised by locale.setlocale()
http://hg.python.org/cpython/rev/d90d88380aca

----------

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

From report at bugs.python.org  Fri Nov  4 21:42:41 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 04 Nov 2011 20:42:41 +0000
Subject: [issue13343] Lambda keyword-only argument not updating co_freevars
In-Reply-To: <1320435452.65.0.656040815575.issue13343@psf.upfronthosting.co.za>
Message-ID: <1320439361.95.0.445544856764.issue13343@psf.upfronthosting.co.za>


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

Here is a patch, with a minimal test.

----------
keywords: +patch
nosy: +amaury.forgeotdarc
Added file: http://bugs.python.org/file23611/issue13343.patch

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

From report at bugs.python.org  Fri Nov  4 21:43:42 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Fri, 04 Nov 2011 20:43:42 +0000
Subject: [issue3067] setlocale error message is confusing
In-Reply-To: <1213013354.87.0.861327880823.issue3067@psf.upfronthosting.co.za>
Message-ID: <1320439422.41.0.895082586251.issue3067@psf.upfronthosting.co.za>


Petri Lehtinen <petri at digip.org> added the comment:

Terry: Do you still think there's need for a doc update?

----------
resolution:  -> fixed
status: open -> pending

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

From report at bugs.python.org  Fri Nov  4 21:45:06 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 04 Nov 2011 20:45:06 +0000
Subject: [issue13343] Lambda keyword-only argument not updating co_freevars
In-Reply-To: <1320435452.65.0.656040815575.issue13343@psf.upfronthosting.co.za>
Message-ID: <1320439506.99.0.93294526858.issue13343@psf.upfronthosting.co.za>


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

same patch, without tabs.

----------
Added file: http://bugs.python.org/file23612/issue13343.patch

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

From report at bugs.python.org  Fri Nov  4 21:45:19 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 04 Nov 2011 20:45:19 +0000
Subject: [issue13343] Lambda keyword-only argument not updating co_freevars
In-Reply-To: <1320435452.65.0.656040815575.issue13343@psf.upfronthosting.co.za>
Message-ID: <1320439519.61.0.978409525171.issue13343@psf.upfronthosting.co.za>


Changes by Amaury Forgeot d'Arc <amauryfa at gmail.com>:


Removed file: http://bugs.python.org/file23611/issue13343.patch

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

From report at bugs.python.org  Fri Nov  4 21:48:03 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Fri, 04 Nov 2011 20:48:03 +0000
Subject: [issue13321] fstat doesn't accept an object with "fileno" method
In-Reply-To: <1320206652.2.0.972235455602.issue13321@psf.upfronthosting.co.za>
Message-ID: <1320439683.01.0.571896458758.issue13321@psf.upfronthosting.co.za>


Changes by Petri Lehtinen <petri at digip.org>:


----------
resolution:  -> wont fix
stage:  -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Fri Nov  4 21:48:27 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Fri, 04 Nov 2011 20:48:27 +0000
Subject: [issue13321] fstat doesn't accept an object with "fileno" method
In-Reply-To: <1320206652.2.0.972235455602.issue13321@psf.upfronthosting.co.za>
Message-ID: <1320439707.27.0.400722059132.issue13321@psf.upfronthosting.co.za>


Petri Lehtinen <petri at digip.org> added the comment:

Closing as wontfix.

----------

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

From report at bugs.python.org  Fri Nov  4 21:51:05 2011
From: report at bugs.python.org (stefanholek)
Date: Fri, 04 Nov 2011 20:51:05 +0000
Subject: [issue13342] input() builtin always uses "strict" error handler
In-Reply-To: <1320417434.92.0.472252310596.issue13342@psf.upfronthosting.co.za>
Message-ID: <1320439865.29.0.167773709217.issue13342@psf.upfronthosting.co.za>


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

Thank you Antoine, this looks good.

However when I try your example I get

sys.stdin = io.TextIOWrapper(
    sys.stdin.detach(), 'ascii', 'replace')
ValueError: underlying buffer has been detached

</helpforum>

----------

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

From report at bugs.python.org  Fri Nov  4 21:52:35 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 04 Nov 2011 20:52:35 +0000
Subject: [issue13342] input() builtin always uses "strict" error handler
In-Reply-To: <1320439865.29.0.167773709217.issue13342@psf.upfronthosting.co.za>
Message-ID: <1320439687.3379.4.camel@localhost.localdomain>


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

> However when I try your example I get
> 
> sys.stdin = io.TextIOWrapper(
>     sys.stdin.detach(), 'ascii', 'replace')
> ValueError: underlying buffer has been detached

Which version of Python (and which OS?). It works fine here on latest
3.2 and 3.3 branches.

----------

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

From report at bugs.python.org  Fri Nov  4 21:59:40 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 04 Nov 2011 20:59:40 +0000
Subject: [issue13343] Lambda keyword-only argument not updating co_freevars
In-Reply-To: <1320435452.65.0.656040815575.issue13343@psf.upfronthosting.co.za>
Message-ID: <1320440380.86.0.557331192479.issue13343@psf.upfronthosting.co.za>


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

Patch looks good to me.

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

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

From report at bugs.python.org  Fri Nov  4 21:59:59 2011
From: report at bugs.python.org (Stefan Holek)
Date: Fri, 04 Nov 2011 20:59:59 +0000
Subject: [issue13342] input() builtin always uses "strict" error handler
In-Reply-To: <1320417434.92.0.472252310596.issue13342@psf.upfronthosting.co.za>
Message-ID: <1320440399.43.0.620654099744.issue13342@psf.upfronthosting.co.za>


Stefan Holek <stefan at epy.co.at> added the comment:

This is with Python 3.2.2 on Mac OS X 10.6 (SL). I have built Python from source with: ./configure; make; make install.

----------

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

From report at bugs.python.org  Fri Nov  4 22:14:46 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 04 Nov 2011 21:14:46 +0000
Subject: [issue13344] closed sockets don't raise EBADF anymore
Message-ID: <1320441286.92.0.465148592312.issue13344@psf.upfronthosting.co.za>


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

This decrepancy between 2.x and 3.x is witnessed under Windows:

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.
>>> import socket
>>> sock = socket.create_connection(("www.python.org", 80))
>>> sock.close()
>>> sock.send(b"x")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "c:\python27\lib\socket.py", line 170, in _dummy
    raise error(EBADF, 'Bad file descriptor')
socket.error: [Errno 9] Bad file descriptor

Python 3.2.1 (default, Jul 10 2011, 20:02:51) [MSC v.1500 64 bit (AMD64)] on win
32
Type "help", "copyright", "credits" or "license" for more information.
>>> import socket
>>> sock = socket.socket(); sock.connect(("www.python.org", 80))
>>> sock.close()
>>> sock.send(b"x")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
socket.error: [Errno 10038] An operation was attempted on something that is not
a socket


I'm not sure this is worth fixing, though.

----------
components: Library (Lib)
messages: 147039
nosy: exarkun, pitrou
priority: low
severity: normal
status: open
title: closed sockets don't raise EBADF anymore
type: behavior
versions: Python 3.2, Python 3.3

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

From report at bugs.python.org  Fri Nov  4 22:15:58 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 04 Nov 2011 21:15:58 +0000
Subject: [issue13287] urllib.request exposes too many names
In-Reply-To: <1319814075.5.0.569025067527.issue13287@psf.upfronthosting.co.za>
Message-ID: <E1RMR75-00025F-9P@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset ca78ed7393bf by Florent Xicluna in branch 'default':
Fix test_urllib2 error on Windows in relation with issue #13287.
http://hg.python.org/cpython/rev/ca78ed7393bf

----------

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

From report at bugs.python.org  Fri Nov  4 22:17:12 2011
From: report at bugs.python.org (Florent Xicluna)
Date: Fri, 04 Nov 2011 21:17:12 +0000
Subject: [issue13287] urllib.request exposes too many names
In-Reply-To: <1319814075.5.0.569025067527.issue13287@psf.upfronthosting.co.za>
Message-ID: <1320441432.28.0.305005312032.issue13287@psf.upfronthosting.co.za>


Changes by Florent Xicluna <florent.xicluna at gmail.com>:


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

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

From report at bugs.python.org  Fri Nov  4 22:21:26 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 04 Nov 2011 21:21:26 +0000
Subject: [issue13344] closed sockets don't raise EBADF anymore
In-Reply-To: <1320441286.92.0.465148592312.issue13344@psf.upfronthosting.co.za>
Message-ID: <1320441686.37.0.150340310069.issue13344@psf.upfronthosting.co.za>


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

discrepancy, not decrepancy :S

(10038 is WSAENOTSOCK, by the way)

----------

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

From report at bugs.python.org  Fri Nov  4 22:27:10 2011
From: report at bugs.python.org (Giampaolo Rodola')
Date: Fri, 04 Nov 2011 21:27:10 +0000
Subject: [issue12498] asyncore.dispatcher_with_send,
	disconnection problem + miss-conception
In-Reply-To: <1309830930.03.0.793190602228.issue12498@psf.upfronthosting.co.za>
Message-ID: <1320442030.6.0.385641318285.issue12498@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

I think this thread is becoming a little messy and since asyncore/asynchat are in a situation where even the slightest change can break existent code I recommend to be really careful.

I see 3 different issues here:

1 - dispatcher_with_send closing the socket without sending pending data (this was the initial issue)
2 - dispatcher_with_send default buffer is too small (512 bytes)
3 - add support for correct POLLHUP/socket.shutdown() handling (msg146946)

All of them should be treated and discussed separately in their own ticket to figure out:

- what's wrong
- whether it's a bugfix or a new feature (POLLHUP handling appears to be so)
- for what python version(s) the patch should be applied

As a final note we should consider mandatory for any patch not to alter the existent API.
initiate_send() method suddenly returning a meaningful value might be the case and as such it should be weighed up first.

----------

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

From report at bugs.python.org  Fri Nov  4 22:29:20 2011
From: report at bugs.python.org (Giampaolo Rodola')
Date: Fri, 04 Nov 2011 21:29:20 +0000
Subject: [issue13344] closed sockets don't raise EBADF anymore
In-Reply-To: <1320441286.92.0.465148592312.issue13344@psf.upfronthosting.co.za>
Message-ID: <1320442160.86.0.95103526958.issue13344@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/issue13344>
_______________________________________

From report at bugs.python.org  Fri Nov  4 22:29:56 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 04 Nov 2011 21:29:56 +0000
Subject: [issue13343] Lambda keyword-only argument not updating co_freevars
In-Reply-To: <1320435452.65.0.656040815575.issue13343@psf.upfronthosting.co.za>
Message-ID: <E1RMRKe-0003Qy-6L@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 1e0e821d2626 by Amaury Forgeot d'Arc in branch '3.2':
Issue #13343: Fix a SystemError when a lambda expression uses a global
http://hg.python.org/cpython/rev/1e0e821d2626

New changeset bddb455439d0 by Amaury Forgeot d'Arc in branch 'default':
Issue #13343: Fix a SystemError when a lambda expression uses a global
http://hg.python.org/cpython/rev/bddb455439d0

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

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

From report at bugs.python.org  Fri Nov  4 22:32:08 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 04 Nov 2011 21:32:08 +0000
Subject: [issue13343] Lambda keyword-only argument not updating co_freevars
In-Reply-To: <1320435452.65.0.656040815575.issue13343@psf.upfronthosting.co.za>
Message-ID: <1320442328.4.0.374388209928.issue13343@psf.upfronthosting.co.za>


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

It was a bug in Python compiler, thanks for the report!

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

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

From report at bugs.python.org  Fri Nov  4 22:35:08 2011
From: report at bugs.python.org (Stefan Holek)
Date: Fri, 04 Nov 2011 21:35:08 +0000
Subject: [issue13342] input() builtin always uses "strict" error handler
In-Reply-To: <1320417434.92.0.472252310596.issue13342@psf.upfronthosting.co.za>
Message-ID: <1320442508.81.0.0471115251419.issue13342@psf.upfronthosting.co.za>


Stefan Holek <stefan at epy.co.at> added the comment:

Python 3.2.2 (default, Nov  4 2011, 22:28:55) 
[GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys, io
>>> w = io.TextIOWrapper(sys.stdin.detach(), 'ascii', 'replace')
>>> input
<built-in function input>
>>> input()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: underlying buffer has been detached

----------

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

From report at bugs.python.org  Fri Nov  4 22:36:13 2011
From: report at bugs.python.org (Joshua Landau)
Date: Fri, 04 Nov 2011 21:36:13 +0000
Subject: [issue13343] Lambda keyword-only argument not updating co_freevars
In-Reply-To: <1320435452.65.0.656040815575.issue13343@psf.upfronthosting.co.za>
Message-ID: <1320442573.92.0.768404297261.issue13343@psf.upfronthosting.co.za>


Joshua Landau <joshua.landau.ws at gmail.com> added the comment:

Glad to help :)
It's made my day. I get to boast at school now!

----------

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

From report at bugs.python.org  Fri Nov  4 22:37:09 2011
From: report at bugs.python.org (Stefan Holek)
Date: Fri, 04 Nov 2011 21:37:09 +0000
Subject: [issue13342] input() builtin always uses "strict" error handler
In-Reply-To: <1320417434.92.0.472252310596.issue13342@psf.upfronthosting.co.za>
Message-ID: <1320442629.1.0.376711066094.issue13342@psf.upfronthosting.co.za>


Stefan Holek <stefan at epy.co.at> added the comment:

Oops, the last one wasn't meant for the bug tracker. <blush>

----------

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

From report at bugs.python.org  Fri Nov  4 22:46:28 2011
From: report at bugs.python.org (sbt)
Date: Fri, 04 Nov 2011 21:46:28 +0000
Subject: [issue13322] buffered read() and write() does not raise
	BlockingIOError
In-Reply-To: <1320246535.71.0.465783773129.issue13322@psf.upfronthosting.co.za>
Message-ID: <1320443188.87.0.668726977346.issue13322@psf.upfronthosting.co.za>


sbt <shibturn at gmail.com> added the comment:

> Another possibility would be that, since lines are usually reasonably
> sized, they should fit in the buffer (which is 8KB by default). So we 
> could do the extra effort of buffering the data and return it once the 
> line is complete: if the buffer fills up before we got the whole line, 
> then we could raise a RuntimeError("Partial line read"). Note that I 
> didn't check if it's easily feasible (i.e. we should avoid introducing 
> kludges in the I/O layer just to handle thi corner case).

Discarding data rarely is worse than always throwing an exception.

----------

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

From report at bugs.python.org  Fri Nov  4 22:47:02 2011
From: report at bugs.python.org (Stefan Holek)
Date: Fri, 04 Nov 2011 21:47:02 +0000
Subject: [issue13342] input() builtin always uses "strict" error handler
In-Reply-To: <1320417434.92.0.472252310596.issue13342@psf.upfronthosting.co.za>
Message-ID: <1320443222.34.0.39589559336.issue13342@psf.upfronthosting.co.za>


Stefan Holek <stefan at epy.co.at> added the comment:

I can make it work at the interpreter prompt with your patch applied. Sorry for cluttering up the ticket. ;-)

----------

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

From report at bugs.python.org  Fri Nov  4 22:56:21 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 04 Nov 2011 21:56:21 +0000
Subject: [issue13342] input() builtin always uses "strict" error handler
In-Reply-To: <1320443222.34.0.39589559336.issue13342@psf.upfronthosting.co.za>
Message-ID: <1320443513.3379.5.camel@localhost.localdomain>


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

> I can make it work at the interpreter prompt with your patch applied.
> Sorry for cluttering up the ticket. ;-)

That's ok, thanks a lot for testing.

----------

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

From report at bugs.python.org  Fri Nov  4 22:57:57 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 04 Nov 2011 21:57:57 +0000
Subject: [issue13290] get vars for object with __slots__
In-Reply-To: <1319871850.77.0.869546838833.issue13290@psf.upfronthosting.co.za>
Message-ID: <1320443877.29.0.0551686735814.issue13290@psf.upfronthosting.co.za>


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

New features only go in future versions: Given the doc: "With a module, class or class instance object as argument (or anything else that has a __dict__ attribute), return that attribute." So you are proposing a change in the definition of vars() input.

I agree that the proposal is a good idea as far as it goes. Vars() predates __slots__ (introduced in 2.2). In particular, adding or deleting a __slots__ binding to a user-defined class should not change the behavior of vars().

I am thinking that the doc should also be tweaked a bit. It implies that all class instances have a __dict__ attribute. Before 2.2, when 'class' meant a user-defined old style class, that was true. But with 'types' becoming new-style classes, it is not.

Perhaps the domain of vars() should be extended to all objects, returning {} if nothing more. I may bring that idea to python-ideas list.

You should attach diffs (context diffs, I believe) rather than files so we can see what you changed. The diff module can create such. I believe your changes come after the following:

        d = PyObject_GetAttrString(v, "__dict__");
        if (d == NULL) {

The statement '''slots = PyObject_GetAttrString(v, "__slots__")''' gets the attribute from the object itself. Like most special attributes other than __dict__, it should be gotten from the object's class (or superclasses). [I don't know the C version of doing this.] For example, suppose v is a class with a custom metaclass and type(v).__slots__ == ('__slots__', '__init__') whereas v.__slots__ == ('a', 'b') (and v.__init__ is not assigned). Then vars(v) should return {'__slots__': ('__slots__', '__init__')}.

The comment /* Find attributes out of __slots__ */ seems misleading. I believe it should be /* Convert string to iterable of 1 string */

New code for 3.3 should use the new unicode api from pep 393. Though I could be wrong, I believe PyUnicode_Check() has been replaced.

Your example "__slots__ = {'some': 'mapping'} is somewhat strange. It works, but only because iterating dicts iterates the keys, and the key is a string. As far as I know, the value is ignored and useless, so I hope no one does this. Perhaps your only point was to test a non-sequence iterable of strings.

A patch should include a patch to the appropriate Lib/test/testxxx.py file.

----------
nosy: +terry.reedy
stage:  -> needs patch
versions:  -Python 3.2

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

From report at bugs.python.org  Fri Nov  4 23:15:26 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 04 Nov 2011 22:15:26 +0000
Subject: [issue13298] Result type depends on order of operands for bytes and
	bytearray
In-Reply-To: <1320020077.78.0.866789839878.issue13298@psf.upfronthosting.co.za>
Message-ID: <1320444926.99.0.496893956678.issue13298@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Fri Nov  4 23:15:48 2011
From: report at bugs.python.org (Jon Bryan)
Date: Fri, 04 Nov 2011 22:15:48 +0000
Subject: [issue13345] Invisible Files in Windows 7
Message-ID: <1320444948.85.0.183506060307.issue13345@psf.upfronthosting.co.za>


New submission from Jon Bryan <jrbryan at sandia.gov>:

Running 32-bit Python in 64-bit Windows 7 Enterprise.  I am very much a Python noob.

A .dll in c:\Windows\System32 that I need to access can't be found by ctypes.WinDLL().  Upon further investigation I have found that the file, along with many others, doesn't show up in an os.listdir() either.  Within IDLE the files don't appear in the drop-down autocomplete list.

I don't have this problem on either of the Windows XP machines I've tried it on, but in Win7 I see the same behavior in both 2.7 and 3.2.

----------
components: IDLE, Windows, ctypes
messages: 147052
nosy: jrbryan
priority: normal
severity: normal
status: open
title: Invisible Files in Windows 7
type: behavior
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Fri Nov  4 23:17:46 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 04 Nov 2011 22:17:46 +0000
Subject: [issue13300] IDLE 3.3 Restart Shell command fails
In-Reply-To: <1320026799.26.0.540984948832.issue13300@psf.upfronthosting.co.za>
Message-ID: <1320445066.04.0.414380282863.issue13300@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Fri Nov  4 23:21:33 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 04 Nov 2011 22:21:33 +0000
Subject: [issue13306] Add diagnostic tools to importlib?
In-Reply-To: <1320098820.25.0.925823454462.issue13306@psf.upfronthosting.co.za>
Message-ID: <1320445293.04.0.0454149425394.issue13306@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Fri Nov  4 23:27:04 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 04 Nov 2011 22:27:04 +0000
Subject: [issue13345] Invisible Files in Windows 7
In-Reply-To: <1320444948.85.0.183506060307.issue13345@psf.upfronthosting.co.za>
Message-ID: <1320445624.47.0.182310481602.issue13345@psf.upfronthosting.co.za>


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

Does the file exist at all? Does it have some specific properties? a "Hidden" flag?

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

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

From report at bugs.python.org  Fri Nov  4 23:34:46 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 04 Nov 2011 22:34:46 +0000
Subject: [issue13319] IDLE: Menu accelerator conflict between Format and
	Options
In-Reply-To: <1320195837.58.0.031082649983.issue13319@psf.upfronthosting.co.za>
Message-ID: <1320446086.72.0.824892450857.issue13319@psf.upfronthosting.co.za>


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

The conflict is not fatal for keyboard users because repeating alt-o switches between Format and Options. To resolve the conflict, I would prefer to keep alt-o for Options, both because it is the first letter of Options and because Options appears on Shell windows. The only non-conflicting character in Format is 'a'.

----------
nosy: +terry.reedy
stage:  -> needs patch
versions:  -Python 2.6, Python 3.1, Python 3.4

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

From report at bugs.python.org  Fri Nov  4 23:40:54 2011
From: report at bugs.python.org (Ilya Novoselov)
Date: Fri, 04 Nov 2011 22:40:54 +0000
Subject: [issue13341] Incorrect documentation for "u" PyArg_Parse format unit
In-Reply-To: <1320412814.48.0.657162308895.issue13341@psf.upfronthosting.co.za>
Message-ID: <1320446454.25.0.884640941198.issue13341@psf.upfronthosting.co.za>


Ilya Novoselov <ilya.novoselov at gmail.com> added the comment:

No, I don't feel like I'm up to standard yet.

----------

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

From report at bugs.python.org  Fri Nov  4 23:42:18 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 04 Nov 2011 22:42:18 +0000
Subject: [issue13330] Attempt full test coverage of
	LocaleTextCalendar.formatweekday
In-Reply-To: <1320300850.58.0.556745870791.issue13330@psf.upfronthosting.co.za>
Message-ID: <1320446538.04.0.0527708145692.issue13330@psf.upfronthosting.co.za>


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


----------
nosy: +rhettinger, terry.reedy

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

From report at bugs.python.org  Fri Nov  4 23:48:01 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 04 Nov 2011 22:48:01 +0000
Subject: [issue13335] Service application hang in python25.dll
In-Reply-To: <1320324829.1.0.613797933132.issue13335@psf.upfronthosting.co.za>
Message-ID: <1320446881.42.0.551013097581.issue13335@psf.upfronthosting.co.za>


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

2.5 in no longer maintained. 2.6 only gets security patches.
So please test with the latest 2.7 (currently 2.7.2).
If you cannot do that, please close.

----------
nosy: +terry.reedy
versions:  -Python 2.6

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

From report at bugs.python.org  Fri Nov  4 23:50:36 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 04 Nov 2011 22:50:36 +0000
Subject: [issue13337] IGNORE_CASE doctest option flag
In-Reply-To: <1320347000.37.0.62477718357.issue13337@psf.upfronthosting.co.za>
Message-ID: <1320447036.13.0.504818732059.issue13337@psf.upfronthosting.co.za>


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


----------
versions:  -Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.4

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

From report at bugs.python.org  Sat Nov  5 00:11:17 2011
From: report at bugs.python.org (=?utf-8?q?Jo=C3=A3o_Bernardo?=)
Date: Fri, 04 Nov 2011 23:11:17 +0000
Subject: [issue13290] get vars for object with __slots__
In-Reply-To: <1319871850.77.0.869546838833.issue13290@psf.upfronthosting.co.za>
Message-ID: <1320448277.91.0.0573239532372.issue13290@psf.upfronthosting.co.za>


Jo?o Bernardo <jbvsmo at gmail.com> added the comment:

Oh, sorry for the full file. Yes, I only changed after 

        d = PyObject_GetAttrString(v, "__dict__");
        if (d == NULL) {

I was searching for uses of slots other than __slots__ = (a, b) and I saw a guy saying that dicts may have special meaning the future. So, something like

      __slots__ = {'my_var': int}

could be an annotation (or hint for IDE's). In the present implementation, the value of each key is just ignored.

If slots is just "a_single_string" it should not be treated as an iterable, so I used PyUnicode_Check because I didn't knew a better method.

----------

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

From report at bugs.python.org  Sat Nov  5 00:58:30 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Fri, 04 Nov 2011 23:58:30 +0000
Subject: [issue4489] shutil.rmtree is vulnerable to a symlink attack
In-Reply-To: <1228232522.58.0.0992151848245.issue4489@psf.upfronthosting.co.za>
Message-ID: <1320451110.41.0.475815409869.issue4489@psf.upfronthosting.co.za>


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

There's a race:
"""
--- Lib/shutil.py       2011-11-05 00:11:05.745221315 +0100
+++ Lib/shutil.py.new   2011-11-05 00:11:01.445220324 +0100
@@ -307,6 +307,7 @@
        try:
            mode = os.fstatat(dirfd, name, os.AT_SYMLINK_NOFOLLOW).st_mode
         except os.error:
             mode = 0
         if stat.S_ISDIR(mode):
+            input("press enter")
             newfd = os.openat(dirfd, name, os.O_RDONLY)
             _rmtree_safe(newfd, ignore_errors, onerror)
             try:
"""

$ rm -rf /tmp/target
$ mkdir -p /tmp/target/etc
$ ./python -c "import shutil; shutil.rmtree('/tmp/target')"
press enter^Z
[1]+  Stopped                 ./python -c "import shutil; shutil.rmtree('/tmp/target')"
$ rm -r /tmp/target/etc; ln -s /etc /tmp/target/
$ fg
./python -c "import shutil; shutil.rmtree('/tmp/target')"

Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/home/cf/python/cpython/Lib/shutil.py", line 290, in rmtree
    _rmtree_safe(fd, ignore_errors, onerror)
  File "/home/cf/python/cpython/Lib/shutil.py", line 314, in _rmtree_safe
    _rmtree_safe(newfd, ignore_errors, onerror)
  File "/home/cf/python/cpython/Lib/shutil.py", line 323, in _rmtree_safe
    onerror(os.unlinkat, (dirfd, name), sys.exc_info())
  File "/home/cf/python/cpython/Lib/shutil.py", line 321, in _rmtree_safe
    os.unlinkat(dirfd, name)
PermissionError: [Errno 13] Permission denied
[52334 refs]

"""
openat(3, "etc", O_RDONLY|O_LARGEFILE)  = 4
dup(4)                                  = 5
fstat64(5, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
fcntl64(5, F_GETFL)                     = 0x8000 (flags O_RDONLY|O_LARGEFILE)
fcntl64(5, F_SETFD, FD_CLOEXEC)         = 0
getdents64(5, /* 162 entries */, 32768) = 5176
getdents64(5, /* 0 entries */, 32768)   = 0
close(5)                                = 0
fstatat64(4, "passwd", {st_mode=S_IFREG|0644, st_size=980, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(4, "passwd", 0)                = -1 EACCES (Permission denied)
"""

You should use the lstat/open/fstat idiom.
Also, here:
"""
            mode1 = os.lstat(path).st_mode
            if stat.S_ISLNK(mode1):
                raise OSError("Cannot call rmtree on a symbolic link")
        except OSError:
            onerror(os.lstat, path, sys.exc_info())
            # can't continue even if onerror hook returns
            return
        fd = os.open(path, os.O_RDONLY)
        try:
            mode2 = os.fstat(fd).st_mode
            if mode1 != mode2:
                raise OSError("Target changed")
"""

You check that path is not a symlink, then you open it, perform fstat on it, and check that the mode is the same.
But if someone replaces path by a symlink to a directory with the same mode, then rmtree won't catch this. You should also compare st_dev and st_ino to make sure we're dealing with the same file.

One more thing :-)
"""
        fd = os.open(path, os.O_RDONLY)
        try:
            mode2 = os.fstat(fd).st_mode
            if mode1 != mode2:
                raise OSError("Target changed")
        except OSError:
            onerror(os.fstat, fd, sys.exc_info())
            # can't continue if target has changed
            return
"""

Here `fd` is not closed (there might be other places leaking FD).

Finally, since writting a such code is tricky, what do you - all - think of making this a generic walker method that would take as argument the methods to call on a directory and on a file (or link), so that we could reuse it to write chmodtree(), chowntree() and friends?

----------
nosy: +neologix

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

From report at bugs.python.org  Sat Nov  5 01:11:27 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 05 Nov 2011 00:11:27 +0000
Subject: [issue4489] shutil.rmtree is vulnerable to a symlink attack
In-Reply-To: <1320451110.41.0.475815409869.issue4489@psf.upfronthosting.co.za>
Message-ID: <1320451618.3379.7.camel@localhost.localdomain>


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

> Finally, since writting a such code is tricky, what do you - all -
> think of making this a generic walker method that would take as
> argument the methods to call on a directory and on a file (or link),
> so that we could reuse it to write chmodtree(), chowntree() and
> friends?

Sounds good.
FYI, I have a pathlib experiment in
http://hg.python.org/features/pathlib/, with an optional openat-based
accessor.

----------

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

From report at bugs.python.org  Sat Nov  5 01:19:21 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 05 Nov 2011 00:19:21 +0000
Subject: [issue3067] setlocale error message is confusing
In-Reply-To: <1213013354.87.0.861327880823.issue3067@psf.upfronthosting.co.za>
Message-ID: <1320452361.93.0.974665406954.issue3067@psf.upfronthosting.co.za>


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

Yes. I think in locale.rst (assuming that is the name)
'''
exception locale.Error 
Exception raised when setlocale() fails.

locale.setlocale(category, locale=None) 
If *locale* is specified, it may be a string, a tuple of the form (language code, encoding), or None. If it is a tuple, it is converted to a string using the locale aliasing engine.
'''
should be changed to
'''
exception locale.Error 
Exception raised when the locale passed to setlocale() is not recognized.

locale.setlocale(category, locale=None) 
If *locale* is specified, it may be a None, a string, or an iterable of two strings, language code and encoding. String pairs are converted to a single string using the locale aliasing engine.
'''
where language code and encoding are gray shaded as they are now.

----------
assignee:  -> docs at python
components: +Documentation -Library (Lib), Unicode
nosy: +docs at python
status: pending -> open

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

From report at bugs.python.org  Sat Nov  5 01:20:56 2011
From: report at bugs.python.org (sbt)
Date: Sat, 05 Nov 2011 00:20:56 +0000
Subject: [issue13322] buffered read() and write() does not raise
	BlockingIOError
In-Reply-To: <1320246535.71.0.465783773129.issue13322@psf.upfronthosting.co.za>
Message-ID: <1320452456.67.0.0391983293521.issue13322@psf.upfronthosting.co.za>


sbt <shibturn at gmail.com> added the comment:

The attached patch makes BufferedWrite.write() raise BlockingIOError when the raw file is non-blocking and the write would block.

----------
keywords: +patch
Added file: http://bugs.python.org/file23613/write_blockingioerror.patch

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

From report at bugs.python.org  Sat Nov  5 01:20:57 2011
From: report at bugs.python.org (Roger Serwy)
Date: Sat, 05 Nov 2011 00:20:57 +0000
Subject: [issue13319] IDLE: Menu accelerator conflict between Format and
	Options
In-Reply-To: <1320195837.58.0.031082649983.issue13319@psf.upfronthosting.co.za>
Message-ID: <1320452457.69.0.727583111584.issue13319@psf.upfronthosting.co.za>


Roger Serwy <roger.serwy at gmail.com> added the comment:

Which platform are you running? 

On Linux (Ubuntu 11.10, Python 3.2, Tk 8.5), Alt-o does not toggle between Format and Options. The first Alt-o selects "Format" and the second Alt-o selects "Comment Out Region". 

Changing Format's accelerator to "a" would be inconsistent with other applications that use "o", such as LibreOffice and Abiword. Consistency aside, changing Format to "a" would be the simplest fix.

----------

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

From report at bugs.python.org  Sat Nov  5 01:22:01 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 05 Nov 2011 00:22:01 +0000
Subject: [issue13290] get vars for object with __slots__
In-Reply-To: <1319871850.77.0.869546838833.issue13290@psf.upfronthosting.co.za>
Message-ID: <1320452521.89.0.0399958617173.issue13290@psf.upfronthosting.co.za>


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

PyUnicode_Check may still be correct. I have not examined PEP393 in detail.

----------

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

From report at bugs.python.org  Sat Nov  5 01:29:00 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 05 Nov 2011 00:29:00 +0000
Subject: [issue13319] IDLE: Menu accelerator conflict between Format and
	Options
In-Reply-To: <1320195837.58.0.031082649983.issue13319@psf.upfronthosting.co.za>
Message-ID: <1320452940.45.0.7708296759.issue13319@psf.upfronthosting.co.za>


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

Py 3.2 on Win 7. 'Comment out region' is Alt-3 here.

----------

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

From report at bugs.python.org  Sat Nov  5 01:51:16 2011
From: report at bugs.python.org (Roger Serwy)
Date: Sat, 05 Nov 2011 00:51:16 +0000
Subject: [issue13319] IDLE: Menu accelerator conflict between Format and
	Options
In-Reply-To: <1320195837.58.0.031082649983.issue13319@psf.upfronthosting.co.za>
Message-ID: <1320454276.38.0.681834604695.issue13319@psf.upfronthosting.co.za>


Roger Serwy <roger.serwy at gmail.com> added the comment:

Alt-3 is comment-out region on Linux as well. The problem is that "o" is an accelerator for "Comment Out Region" under the Format menu. Pressing "Alt-o and o" under Linux is equivalent to "Alt-o and Alt-o".

This toggling between Format and Options may be a Tk bug under Linux since it works on Win7.

----------

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

From report at bugs.python.org  Sat Nov  5 03:46:36 2011
From: report at bugs.python.org (Alan Grow)
Date: Sat, 05 Nov 2011 02:46:36 +0000
Subject: [issue13346] re.split() should behave like string.split() for
	maxsplit=0 and maxsplit=-1
Message-ID: <1320461196.01.0.560612390683.issue13346@psf.upfronthosting.co.za>


New submission from Alan Grow <alangrow+pythonbugs at gmail.com>:

If you split a string in a maximum of zero places, you should get the original string back. "".split(s,0) behaves this way. But re.split(r,s,0) performs an unlimited number of splits in this case.

To get an unlimited number of splits, "".split(s,-1) is a sensible choice. But in this case re.split(r,s,-1) performs zero splits.

Where's the sense in this?

>>> import string, re
>>> string.split("foo bar baz"," ",0)
['foo bar baz']
>>> re.split("\s+","foo bar baz",0)
['foo', 'bar', 'baz']
>>> string.split("foo bar baz"," ",-1)
['foo', 'bar', 'baz']
>>> re.split("\s+","foo bar baz",-1)
['foo bar baz']

----------
components: Library (Lib)
messages: 147066
nosy: acg
priority: normal
severity: normal
status: open
title: re.split() should behave like string.split() for maxsplit=0 and maxsplit=-1
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Sat Nov  5 04:03:22 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 05 Nov 2011 03:03:22 +0000
Subject: [issue13346] re.split() should behave like string.split() for
	maxsplit=0 and maxsplit=-1
In-Reply-To: <1320461196.01.0.560612390683.issue13346@psf.upfronthosting.co.za>
Message-ID: <1320462202.93.0.711145343086.issue13346@psf.upfronthosting.co.za>


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

This is a known issue, but I don't think it can be fixed without breaking backward compatibility.  The behavior with negative values is not explicitly documented, so I would consider it an implementation detail. The behavior with positive values is documented for both the functions.  Also even if it's inconsistent, I would expect people to request at least 1 split, otherwise they are basically asking for a no-op.
I suggest to close this as wontfix

----------
nosy: +ezio.melotti, rhettinger
resolution:  -> wont fix
versions: +Python 2.7, Python 3.2, Python 3.3 -Python 2.6

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

From report at bugs.python.org  Sat Nov  5 05:11:59 2011
From: report at bugs.python.org (Mike Hoy)
Date: Sat, 05 Nov 2011 04:11:59 +0000
Subject: [issue13341] Incorrect documentation for "u" PyArg_Parse format unit
In-Reply-To: <1320412814.48.0.657162308895.issue13341@psf.upfronthosting.co.za>
Message-ID: <1320466319.47.0.24193901258.issue13341@psf.upfronthosting.co.za>


Changes by Mike Hoy <mhoy09 at gmail.com>:


----------
nosy: +mikehoy

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

From report at bugs.python.org  Sat Nov  5 05:40:46 2011
From: report at bugs.python.org (Steve Holden)
Date: Sat, 05 Nov 2011 04:40:46 +0000
Subject: [issue2801] Py30a5 float.is_integer() raises ValueError
In-Reply-To: <1210332530.82.0.122312238822.issue2801@psf.upfronthosting.co.za>
Message-ID: <1320468046.07.0.0780488260395.issue2801@psf.upfronthosting.co.za>


Steve Holden <steve at holdenweb.com> added the comment:

ValueError: (11, 'Resource temporarily unavailable') looks to me like a Cygwin error relating to Windows' DLLs and the difficulty of mapping them to unique memory locations. I very much doubt it's a real issue with Python, so closing the issue appears to be the correct decision in the absence of further contradictory information from the OP.

----------
nosy: +holdenweb

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

From report at bugs.python.org  Sat Nov  5 08:24:03 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Sat, 05 Nov 2011 07:24:03 +0000
Subject: [issue3067] setlocale error message is confusing
In-Reply-To: <1320452361.93.0.974665406954.issue3067@psf.upfronthosting.co.za>
Message-ID: <20111105072351.GA1970@ihaa>


Petri Lehtinen <petri at digip.org> added the comment:

> If *locale* is specified, it may be a None, a string, or an iterable of two strings, language code and encoding. String pairs are converted to a single string using the locale aliasing engine.

What about the possible None value then? Do you think that mentions to
it be dropped?

I don't think so, because setlocale(locale.LC_ALL, None) is an
explicit way of saying "Return me the current value", especially
because the function's name is SETlocale, which doesn't make it
explicit.

If None is not dropped, the ", language code and encoding" should
maybe be in parentheses insteead: "to strings (language code and
encoding), or None..."

----------

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

From report at bugs.python.org  Sat Nov  5 08:30:08 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 05 Nov 2011 07:30:08 +0000
Subject: [issue3067] setlocale error message is confusing
In-Reply-To: <1213013354.87.0.861327880823.issue3067@psf.upfronthosting.co.za>
Message-ID: <1320478208.37.0.782501025752.issue3067@psf.upfronthosting.co.za>


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

Yes, parentheses would be better.

----------

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

From report at bugs.python.org  Sat Nov  5 08:30:23 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sat, 05 Nov 2011 07:30:23 +0000
Subject: [issue13322] buffered read() and write() does not raise
	BlockingIOError
In-Reply-To: <1320246535.71.0.465783773129.issue13322@psf.upfronthosting.co.za>
Message-ID: <1320478223.38.0.31964698024.issue13322@psf.upfronthosting.co.za>


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

> write() is a bit simpler, since BlockingIOError has 
> a "characters_written" attribute which is meant to inform you of the 
> partial success: we can just reuse that. That said, BlockingIOError 
> could grow a "partial_read" attribute containing the read result...

Now that I think about it, it's probably the best solution:
always raise a BlockingIOError in case of partial write, with characters_written set correctly (sbt's patch).
And do the same thing on partial read/readline, and return the partially read data as an attribute of BlockingIOError (we could also return a characters_read that would indicate the exact number of bytes read: then the user could call read()/read_into() with exactly characters_read).
That could certainly break existing - sloppy - code, but this would be more much consistent than the current behavior.

----------

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

From report at bugs.python.org  Sat Nov  5 08:51:58 2011
From: report at bugs.python.org (Kaleb702)
Date: Sat, 05 Nov 2011 07:51:58 +0000
Subject: [issue13347] .py extension not auto added
Message-ID: <1320479518.35.0.248470834603.issue13347@psf.upfronthosting.co.za>


New submission from Kaleb702 <ronneymichelle at gmail.com>:

Python IDLE does not auto add the .py extension when saving a file.

----------
components: IDLE
messages: 147072
nosy: Kaleb702
priority: normal
severity: normal
status: open
title: .py extension not auto added

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

From report at bugs.python.org  Sat Nov  5 08:53:46 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 05 Nov 2011 07:53:46 +0000
Subject: [issue13254] maildir.items() broken
In-Reply-To: <1319447699.1.0.36723918452.issue13254@psf.upfronthosting.co.za>
Message-ID: <E1RMb4K-0002xC-Ss@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 5f27a9f67a34 by Petri Lehtinen in branch '3.2':
Fix Maildir initialization so that maildir contents are read correctly.
http://hg.python.org/cpython/rev/5f27a9f67a34

New changeset 91a0f6879173 by Petri Lehtinen in branch 'default':
Fix Maildir initialization so that maildir contents are read correctly.
http://hg.python.org/cpython/rev/91a0f6879173

New changeset 0b754ee12dbd by Petri Lehtinen in branch '2.7':
Fix Maildir initialization so that maildir contents  are read correctly.
http://hg.python.org/cpython/rev/0b754ee12dbd

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

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

From report at bugs.python.org  Sat Nov  5 08:55:14 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Sat, 05 Nov 2011 07:55:14 +0000
Subject: [issue13254] maildir.items() broken
In-Reply-To: <1319447699.1.0.36723918452.issue13254@psf.upfronthosting.co.za>
Message-ID: <1320479714.51.0.169088294107.issue13254@psf.upfronthosting.co.za>


Petri Lehtinen <petri at digip.org> added the comment:

In the absence of any complaints, I went on and committed the fix. Thanks for reporting the issue!

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

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

From report at bugs.python.org  Sat Nov  5 09:25:15 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 05 Nov 2011 08:25:15 +0000
Subject: [issue3067] setlocale error message is confusing
In-Reply-To: <1213013354.87.0.861327880823.issue3067@psf.upfronthosting.co.za>
Message-ID: <E1RMbYo-0004xR-Cz@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 34c9465f5023 by Petri Lehtinen in branch '2.7':
Issue #3067: Enhance the documentation and docstring of locale.setlocale()
http://hg.python.org/cpython/rev/34c9465f5023

New changeset 98806dd03506 by Petri Lehtinen in branch '3.2':
Issue #3067: Enhance the documentation and docstring of locale.setlocale()
http://hg.python.org/cpython/rev/98806dd03506

New changeset 8a27920efffe by Petri Lehtinen in branch 'default':
Issue #3067: Enhance the documentation and docstring of locale.setlocale()
http://hg.python.org/cpython/rev/8a27920efffe

----------

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

From report at bugs.python.org  Sat Nov  5 09:28:26 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Sat, 05 Nov 2011 08:28:26 +0000
Subject: [issue3067] setlocale error message is confusing
In-Reply-To: <1213013354.87.0.861327880823.issue3067@psf.upfronthosting.co.za>
Message-ID: <1320481706.37.0.737239387835.issue3067@psf.upfronthosting.co.za>


Petri Lehtinen <petri at digip.org> added the comment:

I decided to restructure the documentation of setlocale() a bit and I think it's better now overall. It includes Terry's suggestions.

I think this issue can now be closed. Thanks for the report and patches!

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

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

From report at bugs.python.org  Sat Nov  5 11:36:43 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sat, 05 Nov 2011 10:36:43 +0000
Subject: [issue7777] Support needed for AF_RDS family
In-Reply-To: <1264404460.15.0.913920533968.issue7777@psf.upfronthosting.co.za>
Message-ID: <1320489403.81.0.979918620693.issue7777@psf.upfronthosting.co.za>


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

So, what do you think of the new patch?

----------

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

From report at bugs.python.org  Sat Nov  5 11:45:46 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sat, 05 Nov 2011 10:45:46 +0000
Subject: [issue12856] tempfile PRNG reuse between parent and child process
In-Reply-To: <1314664313.38.0.204964767206.issue12856@psf.upfronthosting.co.za>
Message-ID: <1320489946.77.0.212394256939.issue12856@psf.upfronthosting.co.za>


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

The patch looks good to me.
Note that the whole kill(pid, SIGKILL) looks overkill to me...

----------
nosy: +neologix

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

From report at bugs.python.org  Sat Nov  5 11:58:02 2011
From: report at bugs.python.org (Florent Xicluna)
Date: Sat, 05 Nov 2011 10:58:02 +0000
Subject: [issue13348] test_unicode_file fails: shutil.copy2 says "same file"
Message-ID: <1320490682.69.0.905628343655.issue13348@psf.upfronthosting.co.za>


New submission from Florent Xicluna <florent.xicluna at gmail.com>:

I stopped on this error on buildbot x86 Tiger 3.2.
It looks strange.

test_single_files (test.test_unicode_file.TestUnicodeFiles) ... ERROR

======================================================================
ERROR: test_single_files (test.test_unicode_file.TestUnicodeFiles)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/db3l/buildarea/3.2.bolen-tiger/build/Lib/test/test_unicode_file.py", line 120, in test_single_files
    self._test_single(TESTFN_UNICODE)
  File "/Users/db3l/buildarea/3.2.bolen-tiger/build/Lib/test/test_unicode_file.py", line 113, in _test_single
    self._do_single(filename)
  File "/Users/db3l/buildarea/3.2.bolen-tiger/build/Lib/test/test_unicode_file.py", line 40, in _do_single
    self._do_copyish(filename, filename)
  File "/Users/db3l/buildarea/3.2.bolen-tiger/build/Lib/test/test_unicode_file.py", line 75, in _do_copyish
    shutil.copy2(filename1, filename2 + ".new")
  File "/Users/db3l/buildarea/3.2.bolen-tiger/build/Lib/shutil.py", line 144, in copy2
    copyfile(src, dst)
  File "/Users/db3l/buildarea/3.2.bolen-tiger/build/Lib/shutil.py", line 85, in copyfile
    raise Error("`%s` and `%s` are the same file" % (src, dst))
shutil.Error: `@test_19432_tmp-?????` and `@test_19432_tmp-?????.new` are the same file

----------------------------------------------------------------------
Ran 2 tests in 0.013s

FAILED (errors=1)


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

----------
keywords: buildbot
messages: 147079
nosy: flox
priority: normal
severity: normal
stage: test needed
status: open
title: test_unicode_file fails: shutil.copy2 says "same file"
type: behavior
versions: Python 3.2, Python 3.3

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

From report at bugs.python.org  Sat Nov  5 12:56:50 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sat, 05 Nov 2011 11:56:50 +0000
Subject: [issue4489] shutil.rmtree is vulnerable to a symlink attack
In-Reply-To: <1228232522.58.0.0992151848245.issue4489@psf.upfronthosting.co.za>
Message-ID: <1320494210.0.0.130351658855.issue4489@psf.upfronthosting.co.za>


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

> FYI, I have a pathlib experiment in
> http://hg.python.org/features/pathlib/, with an optional openat-based
> accessor.

Interesting: I used to think that the current API for dealing with paths was a little too basic and terse.

Concerning this issue, one (last) thing: rmtree performs a depth-first traversal of the directory tree, keeping an open FD at each directory level: in case of deeply-nested directory hierarchy, or if there are many open FDs, there's the risk of running out of FDs.
I think the best thing would be to let rmtree fail (provided it closes all the FDs it opened): falling back to the "unsafe" version would be stupid (an attacker would just have to create a deeply-nested hierarchy, and then use the same old symlink race).

----------

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

From report at bugs.python.org  Sat Nov  5 13:07:54 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Sat, 05 Nov 2011 12:07:54 +0000
Subject: [issue13309] test_time fails: time data 'LMT' does not match format
	'%Z'
In-Reply-To: <1320156304.27.0.1872899991.issue13309@psf.upfronthosting.co.za>
Message-ID: <1320494874.87.0.483285892256.issue13309@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

It's not just Gentoo. I get this error repeatably on Ubuntu Oneiric 64- bit and Linux Mint Katya 64-bit, though not on the 32-bit variants.

----------
nosy: +vinay.sajip

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

From report at bugs.python.org  Sat Nov  5 13:35:02 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 05 Nov 2011 12:35:02 +0000
Subject: [issue13348] test_unicode_file fails: shutil.copy2 says "same file"
In-Reply-To: <1320490682.69.0.905628343655.issue13348@psf.upfronthosting.co.za>
Message-ID: <1320496502.49.0.141189985439.issue13348@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/issue13348>
_______________________________________

From report at bugs.python.org  Sat Nov  5 13:39:55 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Sat, 05 Nov 2011 12:39:55 +0000
Subject: [issue13193] test_packaging and test_distutils failures
In-Reply-To: <1318800293.23.0.0737706148876.issue13193@psf.upfronthosting.co.za>
Message-ID: <1320496795.02.0.196100740814.issue13193@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

I get the opposite failure to Nadeem as far as InstallDataTestCase.test_resources: it works on Ubuntu 64-bit, but fails on 32-bit. Digging into it a bit further, I find that _generate_cache in Lib/packaging/database.py returns prematurely in the failing case, because _cache_generated_egg is True in the failing case but not in the test run which succeeds. My guess is that this could be due to a missing call to clear_cache() in the same module, as _cache_generated_egg is set to True only in the last part of _generate_cache, and my guess is that the value is a holdover from an earlier test.

If I add the line "packaging.database.clear_cache()" just above "with packaging.database.get_file('Spamlib', 'spamd') as fp:" then the test succeeds.

----------
nosy: +vinay.sajip

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

From report at bugs.python.org  Sat Nov  5 13:47:38 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Sat, 05 Nov 2011 12:47:38 +0000
Subject: [issue13193] test_packaging and test_distutils failures
In-Reply-To: <1318800293.23.0.0737706148876.issue13193@psf.upfronthosting.co.za>
Message-ID: <1320497258.71.0.429179998688.issue13193@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

I added the packaging.database.clear_cache() at the end of setUp(); that works, too.

Gotta love global variables - not! ;-)

----------

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

From report at bugs.python.org  Sat Nov  5 13:53:06 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 05 Nov 2011 12:53:06 +0000
Subject: [issue7777] Support needed for AF_RDS family
In-Reply-To: <1264404460.15.0.913920533968.issue7777@psf.upfronthosting.co.za>
Message-ID: <1320497586.91.0.14501599665.issue7777@psf.upfronthosting.co.za>


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

Oops, sorry. I wonder if it would be possible to test the address returned by recvfrom(). Same for the flags and ancillary data in recvmsg().

----------

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

From report at bugs.python.org  Sat Nov  5 14:53:09 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Sat, 05 Nov 2011 13:53:09 +0000
Subject: [issue13193] test_packaging and test_distutils failures
In-Reply-To: <1318800293.23.0.0737706148876.issue13193@psf.upfronthosting.co.za>
Message-ID: <1320501189.59.0.626826375279.issue13193@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

I looked in packaging/test, and noticed that database.get_distribution is called from test_depgraph, test_xmlrpc and test_database. These may also need looking over to see if cache invalidation needs to happen.

----------

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

From report at bugs.python.org  Sat Nov  5 15:07:52 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Sat, 05 Nov 2011 14:07:52 +0000
Subject: [issue13193] test_packaging and test_distutils failures
In-Reply-To: <1318800293.23.0.0737706148876.issue13193@psf.upfronthosting.co.za>
Message-ID: <1320502072.62.0.624058674116.issue13193@psf.upfronthosting.co.za>


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

> I added the packaging.database.clear_cache() at the end of setUp(); that works, too.

That fixes the InstallDataTestCase failure for me as well
(on both Ubuntu 11.10 64-bit and Windows 7 64-bit).

> I get the opposite failure to Nadeem as far as InstallDataTestCase.test_resources: it works on Ubuntu 64-bit, but fails on 32-bit.

FTR, I haven't checked this on Ubuntu 32-bit. It's rather odd for the
failure to be architecture-dependent. Are these two machines running
different versions of Ubuntu, perhaps?

----------

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

From report at bugs.python.org  Sat Nov  5 16:11:26 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sat, 05 Nov 2011 15:11:26 +0000
Subject: [issue13345] Invisible Files in Windows 7
In-Reply-To: <1320444948.85.0.183506060307.issue13345@psf.upfronthosting.co.za>
Message-ID: <1320505886.08.0.490350674026.issue13345@psf.upfronthosting.co.za>


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

Most likely, you are using a 32-bit Python on a 64-bit Windows. 32-bit programs can't access c:\windows\system32, as that will contain the 64-bit DLLs. Instead, access is redirected to c:\windows\syswow64.

Please confirm whether or not this is the case here also.

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

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

From report at bugs.python.org  Sat Nov  5 16:13:19 2011
From: report at bugs.python.org (Roumen Petrov)
Date: Sat, 05 Nov 2011 15:13:19 +0000
Subject: [issue13193] test_packaging and test_distutils failures
In-Reply-To: <1318800293.23.0.0737706148876.issue13193@psf.upfronthosting.co.za>
Message-ID: <1320505999.43.0.3250395722.issue13193@psf.upfronthosting.co.za>


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

Test test_install and test_command_install_data interference cache . Adding clear_cache as clean up routine  will resolve reported issue with Spamlib. The patch is trivial. Also one of the test set clear_cache as cleanup.

Most important is why packaging use global variables . To me good solution will not use globals , but this  require authors to rewrite packaging itself.

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

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

From report at bugs.python.org  Sat Nov  5 16:59:03 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 05 Nov 2011 15:59:03 +0000
Subject: [issue13204] sys.flags.__new__ crashes
In-Reply-To: <1318889665.83.0.350090316357.issue13204@psf.upfronthosting.co.za>
Message-ID: <1320508743.1.0.0464543585992.issue13204@psf.upfronthosting.co.za>


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

I?m not sure it is useful to fix this bug.

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

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

From report at bugs.python.org  Sat Nov  5 17:01:16 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 05 Nov 2011 16:01:16 +0000
Subject: [issue13033] Add shutil.chowntree
In-Reply-To: <1316769849.87.0.0298236424523.issue13033@psf.upfronthosting.co.za>
Message-ID: <1320508876.26.0.969757032724.issue13033@psf.upfronthosting.co.za>


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

See also #13229.

----------

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

From report at bugs.python.org  Sat Nov  5 17:01:41 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 05 Nov 2011 16:01:41 +0000
Subject: [issue13033] Add shutil.chowntree
In-Reply-To: <1316769849.87.0.0298236424523.issue13033@psf.upfronthosting.co.za>
Message-ID: <1320508901.06.0.340386288538.issue13033@psf.upfronthosting.co.za>


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

Tigger: Could you provide a patch for Python 3.3? (more info at http://docs.python.org/devguide/)

----------

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

From report at bugs.python.org  Sat Nov  5 17:02:23 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 05 Nov 2011 16:02:23 +0000
Subject: [issue13204] sys.flags.__new__ crashes
In-Reply-To: <1318889665.83.0.350090316357.issue13204@psf.upfronthosting.co.za>
Message-ID: <1320508943.12.0.456492712542.issue13204@psf.upfronthosting.co.za>


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

Why not?

----------
nosy: +ezio.melotti

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

From report at bugs.python.org  Sat Nov  5 17:07:59 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 05 Nov 2011 16:07:59 +0000
Subject: [issue13229] Add shutil.filter_walk
In-Reply-To: <1319076330.7.0.757546324527.issue13229@psf.upfronthosting.co.za>
Message-ID: <1320509279.03.0.0802549032559.issue13229@psf.upfronthosting.co.za>


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

During the discussion about adding a chowntree function to shutil (http://mail.python.org/pipermail/python-dev/2011-May/111661.html and ), Victor suggested this:

> I don't like the idea of a recursive flag. I would prefer a "map-like" function to "apply" a
> function on all files of a directory. Something like shutil.apply_recursive(shutil.chown)...
> ... maybe with options to choose between deep-first search and breadth-first search, filter
> (filenames, file size, files only, directories only, other attributes?), directory before
> files (may be need for chmod(0o000)), etc.

Such a function removes the need for copytee, rmtree, dosomethingelsetree, etc.  When I first read this feature request I thought it was the same idea, but after reading it again I see that you propose a function that walks and returns, not a function that walks and applies a callback.  Both use cases are important, so an apply_tree function could be implemented on top of your filter_walk (I?ll open another report if we reach agreement on the idea of these two functions working together).

----------
nosy: +haypo

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

From report at bugs.python.org  Sat Nov  5 17:08:22 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 05 Nov 2011 16:08:22 +0000
Subject: [issue13229] Add shutil.filter_walk
In-Reply-To: <1319076330.7.0.757546324527.issue13229@psf.upfronthosting.co.za>
Message-ID: <1320509302.87.0.232779752721.issue13229@psf.upfronthosting.co.za>


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

s/and /and #13033/

----------

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

From report at bugs.python.org  Sat Nov  5 17:10:54 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 05 Nov 2011 16:10:54 +0000
Subject: [issue13200] Add start, stop and step attributes to range objects
In-Reply-To: <1318861740.84.0.628710969686.issue13200@psf.upfronthosting.co.za>
Message-ID: <1320509454.76.0.85662440465.issue13200@psf.upfronthosting.co.za>


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

The other bug is older and has more discussion, I?m closing this one as duplicate.

----------

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

From report at bugs.python.org  Sat Nov  5 17:11:15 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 05 Nov 2011 16:11:15 +0000
Subject: [issue13200] Add start, stop and step attributes to range objects
In-Reply-To: <1318861740.84.0.628710969686.issue13200@psf.upfronthosting.co.za>
Message-ID: <1320509475.15.0.234503755752.issue13200@psf.upfronthosting.co.za>


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


----------
resolution:  -> duplicate
stage: patch review -> committed/rejected
status: open -> closed
superseder:  -> Introspectable range objects

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

From report at bugs.python.org  Sat Nov  5 17:15:56 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 05 Nov 2011 16:15:56 +0000
Subject: [issue9896] Introspectable range objects
In-Reply-To: <1284835167.56.0.979385376089.issue9896@psf.upfronthosting.co.za>
Message-ID: <1320509756.27.0.854271810999.issue9896@psf.upfronthosting.co.za>


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

I think this is ready for commit.

----------
nosy: +smarnach

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

From report at bugs.python.org  Sat Nov  5 17:20:05 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 05 Nov 2011 16:20:05 +0000
Subject: [issue13290] get vars for object with __slots__
In-Reply-To: <1319871850.77.0.869546838833.issue13290@psf.upfronthosting.co.za>
Message-ID: <1320510005.42.0.867982238791.issue13290@psf.upfronthosting.co.za>


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

> You should attach diffs (context diffs, I believe)
Nope, these are hard to read :)  The universal diff format is the unified one.  That?s also what Mercurial uses (see the devguide for more info on contributing).

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

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

From report at bugs.python.org  Sat Nov  5 17:20:14 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 05 Nov 2011 16:20:14 +0000
Subject: [issue13290] get vars for object with __slots__
In-Reply-To: <1319871850.77.0.869546838833.issue13290@psf.upfronthosting.co.za>
Message-ID: <1320510014.22.0.502632095519.issue13290@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Sat Nov  5 17:21:26 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 05 Nov 2011 16:21:26 +0000
Subject: [issue13292] missing versionadded for bytearray
In-Reply-To: <1319975533.88.0.431386848219.issue13292@psf.upfronthosting.co.za>
Message-ID: <1320510086.22.0.29352149977.issue13292@psf.upfronthosting.co.za>


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


----------
assignee: docs at python -> eric.araujo
nosy: +eric.araujo

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

From report at bugs.python.org  Sat Nov  5 17:37:23 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 05 Nov 2011 16:37:23 +0000
Subject: [issue13193] test_packaging and test_distutils failures
In-Reply-To: <1318800293.23.0.0737706148876.issue13193@psf.upfronthosting.co.za>
Message-ID: <1320511043.34.0.310881249648.issue13193@psf.upfronthosting.co.za>


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

Thanks, I?ll add the disable_cache call.

Westley: I?ve installed Arch.  Is there a command I can run to get zlib, openssl, gcc, make and all that, similar to ?aptitude build-dep python3.2??

----------

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

From report at bugs.python.org  Sat Nov  5 17:48:02 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 05 Nov 2011 16:48:02 +0000
Subject: [issue13193] test_packaging and test_distutils failures
In-Reply-To: <1318800293.23.0.0737706148876.issue13193@psf.upfronthosting.co.za>
Message-ID: <1320511682.91.0.217976628659.issue13193@psf.upfronthosting.co.za>


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

I?ll open another reports for the possible bug in _generate_cache and for review of the other tests calling get_distribution.

> Test test_install and test_command_install_data interference cache
I?ve added checks in regrtest to make sure that each tests clears the caches some time ago.

> Most important is why packaging use global variables.
[citation needed].  First, mutable objects with a global name (let?s not use ?variable? for Python) are not unconditionally evil; see sys.path and sys.modules for example.  Second, how concretely would you change that implementation?  We need shared caches for functions in packaging.database.  They should be built on demand, and should be cleared by higher-level libraries or applications when the filesystem has changed (after an installation or removal for example).  With these constraints, do you have implementation ideas?

----------

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

From report at bugs.python.org  Sat Nov  5 17:48:56 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 05 Nov 2011 16:48:56 +0000
Subject: [issue13204] sys.flags.__new__ crashes
In-Reply-To: <1318889665.83.0.350090316357.issue13204@psf.upfronthosting.co.za>
Message-ID: <1320511736.13.0.307932073471.issue13204@psf.upfronthosting.co.za>


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

Because the class of sys.flags is an implementation detail.  Most people won?t try to instantiate it, IMO.

----------

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

From report at bugs.python.org  Sat Nov  5 17:52:12 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 05 Nov 2011 16:52:12 +0000
Subject: [issue13193] test_packaging and test_distutils failures
In-Reply-To: <1318800293.23.0.0737706148876.issue13193@psf.upfronthosting.co.za>
Message-ID: <E1RMjTP-0004hQ-7j@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 4eee9dd61147 by ?ric Araujo in branch 'default':
Try to fix buildbot failures from #13193
http://hg.python.org/cpython/rev/4eee9dd61147

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

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

From report at bugs.python.org  Sat Nov  5 17:55:20 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 05 Nov 2011 16:55:20 +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: <E1RMjWR-0004xW-M0@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 8ea34a74f118 by ?ric Araujo in branch '2.7':
Add missing versionadded (fixes #12392)
http://hg.python.org/cpython/rev/8ea34a74f118

----------

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

From report at bugs.python.org  Sat Nov  5 18:08:33 2011
From: report at bugs.python.org (Kaleb702)
Date: Sat, 05 Nov 2011 17:08:33 +0000
Subject: [issue13347] .py extension not auto added
In-Reply-To: <1320479518.35.0.248470834603.issue13347@psf.upfronthosting.co.za>
Message-ID: <1320512913.64.0.983278495446.issue13347@psf.upfronthosting.co.za>


Changes by Kaleb702 <ronneymichelle at gmail.com>:


----------
versions: +Python 3.2

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

From report at bugs.python.org  Sat Nov  5 18:10:27 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 05 Nov 2011 17:10:27 +0000
Subject: [issue13204] sys.flags.__new__ crashes
In-Reply-To: <1318889665.83.0.350090316357.issue13204@psf.upfronthosting.co.za>
Message-ID: <1320513027.45.0.456555832888.issue13204@psf.upfronthosting.co.za>


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

That's probably true, but IMHO it's not a valid reason to keep the buggy behavior.

----------

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

From report at bugs.python.org  Sat Nov  5 20:19:11 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 05 Nov 2011 19:19:11 +0000
Subject: [issue9896] Introspectable range objects
In-Reply-To: <1284835167.56.0.979385376089.issue9896@psf.upfronthosting.co.za>
Message-ID: <E1RMlld-0003Ri-6z@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 4643be424293 by Benjamin Peterson in branch 'default':
add introspection to range objects (closes #9896)
http://hg.python.org/cpython/rev/4643be424293

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

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

From report at bugs.python.org  Sat Nov  5 20:48:24 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Sat, 05 Nov 2011 19:48:24 +0000
Subject: [issue13338] Not all enumerations used in _Py_ANNOTATE_MEMORY_ORDER
In-Reply-To: <1320366284.3.0.0625863072508.issue13338@psf.upfronthosting.co.za>
Message-ID: <1320522504.43.0.661092131271.issue13338@psf.upfronthosting.co.za>


Changes by Petri Lehtinen <petri at digip.org>:


----------
stage:  -> needs patch

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

From report at bugs.python.org  Sat Nov  5 20:48:34 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Sat, 05 Nov 2011 19:48:34 +0000
Subject: [issue13338] Not all enumerations used in _Py_ANNOTATE_MEMORY_ORDER
In-Reply-To: <1320366284.3.0.0625863072508.issue13338@psf.upfronthosting.co.za>
Message-ID: <1320522514.75.0.320709704914.issue13338@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/issue13338>
_______________________________________

From report at bugs.python.org  Sat Nov  5 21:02:43 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 05 Nov 2011 20:02:43 +0000
Subject: [issue13326] make clean failed on OpenBSD
In-Reply-To: <1320275747.65.0.48370892093.issue13326@psf.upfronthosting.co.za>
Message-ID: <E1RMmRj-0006nF-MI@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 41ab1dfaf1d4 by Petri Lehtinen in branch '3.2':
Remove __pycache__ directories correctly on OpenBSD
http://hg.python.org/cpython/rev/41ab1dfaf1d4

New changeset f853a2cbd68b by Petri Lehtinen in branch 'default':
Remove __pycache__ directories correctly on OpenBSD
http://hg.python.org/cpython/rev/f853a2cbd68b

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

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

From report at bugs.python.org  Sat Nov  5 21:05:01 2011
From: report at bugs.python.org (Eric Snow)
Date: Sat, 05 Nov 2011 20:05:01 +0000
Subject: [issue10977] Concrete object C API considered harmful to subclasses
	of builtin types
In-Reply-To: <1295653779.62.0.836506069174.issue10977@psf.upfronthosting.co.za>
Message-ID: <1320523501.53.0.1426859523.issue10977@psf.upfronthosting.co.za>


Changes by Eric Snow <ericsnowcurrently at gmail.com>:


----------
nosy: +eric.snow

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

From report at bugs.python.org  Sat Nov  5 21:14:29 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sat, 05 Nov 2011 20:14:29 +0000
Subject: [issue13204] sys.flags.__new__ crashes
In-Reply-To: <1318889665.83.0.350090316357.issue13204@psf.upfronthosting.co.za>
Message-ID: <1320524069.23.0.275679939715.issue13204@psf.upfronthosting.co.za>


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

Why would we want to prevent users from creating new instances of FlagsType?

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

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

From report at bugs.python.org  Sat Nov  5 21:17:49 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Sat, 05 Nov 2011 20:17:49 +0000
Subject: [issue12163] str.count
In-Reply-To: <1306203026.57.0.880785470377.issue12163@psf.upfronthosting.co.za>
Message-ID: <1320524269.93.0.0938520656468.issue12163@psf.upfronthosting.co.za>


Petri Lehtinen <petri at digip.org> added the comment:

This already seems fixed on 2.7, 3.2 and 3.3:

>>> ''.find('', None)
0

----------
nosy: +petri.lehtinen
resolution:  -> out of date
status: open -> closed
versions:  -Python 3.1

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

From report at bugs.python.org  Sat Nov  5 21:23:11 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Sat, 05 Nov 2011 20:23:11 +0000
Subject: [issue13340] list.index does not accept None as start or stop
In-Reply-To: <1320398584.03.0.145013152611.issue13340@psf.upfronthosting.co.za>
Message-ID: <1320524591.34.0.91814488061.issue13340@psf.upfronthosting.co.za>


Petri Lehtinen <petri at digip.org> added the comment:

The same issue exists for tuples:

>>> (1, 2, 3).index(2, 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
nosy: +petri.lehtinen
stage:  -> needs patch
versions: +Python 3.3

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

From report at bugs.python.org  Sat Nov  5 21:27:23 2011
From: report at bugs.python.org (Alex Gaynor)
Date: Sat, 05 Nov 2011 20:27:23 +0000
Subject: [issue13340] list.index does not accept None as start or stop
In-Reply-To: <1320398584.03.0.145013152611.issue13340@psf.upfronthosting.co.za>
Message-ID: <1320524843.14.0.296489789232.issue13340@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/issue13340>
_______________________________________

From report at bugs.python.org  Sat Nov  5 21:49:38 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Sat, 05 Nov 2011 20:49:38 +0000
Subject: [issue13349] Uninformal error message in index() and remove()
	functions
Message-ID: <1320526177.89.0.678573577515.issue13349@psf.upfronthosting.co.za>


New submission from Petri Lehtinen <petri at digip.org>:

For example:

>>> (1, 2, 3).index(4)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: tuple.index(x): x not in tuple

The "x not in tuple" error message should be replaced with "4 is not in tuple". list.index() already does this (see #7252):

>>> [1, 2, 3].index(4)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: 4 is not in list

Although in #7252 it was claimed that no other place in stdlib has this error message, I found many occurences:

Modules/_collectionsmodule.c:    PyErr_SetString(PyExc_ValueError, "deque.remove(x): x not in deque"
Modules/_elementtree.c:            "list.remove(x): x not in list"
Modules/_elementtree.c:            "list.remove(x): x not in list"
Modules/arraymodule.c:    PyErr_SetString(PyExc_ValueError, "array.index(x): x not in list");
Modules/arraymodule.c:    PyErr_SetString(PyExc_ValueError, "array.remove(x): x not in list");
Objects/abstract.c:                    "sequence.index(x): x not in sequence");
Objects/listobject.c:    PyErr_SetString(PyExc_ValueError, "list.remove(x): x not in list");
Objects/tupleobject.c:    PyErr_SetString(PyExc_ValueError, "tuple.index(x): x not in tuple");

There's also documentation and tests that depend on this actual error message:

Doc/library/doctest.rst:   ValueError: list.remove(x): x not in list
Lib/test/test_xml_etree.py:    ValueError: list.remove(x): x not in list

#7252 was fixed in r76058, and it's quite a lot of code. I think it could be done more easily using PyUnicode_FromFormat() and the %R format.

----------
messages: 147109
nosy: petri.lehtinen
priority: normal
severity: normal
status: open
title: Uninformal error message in index() and remove() functions

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

From report at bugs.python.org  Sat Nov  5 21:50:45 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Sat, 05 Nov 2011 20:50:45 +0000
Subject: [issue13349] Uninformal error message in index() and remove()
	functions
In-Reply-To: <1320526177.89.0.678573577515.issue13349@psf.upfronthosting.co.za>
Message-ID: <1320526245.2.0.276526730458.issue13349@psf.upfronthosting.co.za>


Changes by Petri Lehtinen <petri at digip.org>:


----------
components: +Extension Modules, Interpreter Core
type:  -> behavior
versions: +Python 3.3

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

From report at bugs.python.org  Sat Nov  5 21:59:30 2011
From: report at bugs.python.org (Zsolt Kendi)
Date: Sat, 05 Nov 2011 20:59:30 +0000
Subject: [issue7980] time.strptime not thread safe
In-Reply-To: <1266835598.13.0.361031999331.issue7980@psf.upfronthosting.co.za>
Message-ID: <1320526770.03.0.677393078654.issue7980@psf.upfronthosting.co.za>


Zsolt Kendi <kzsoltkzsolt at freemail.hu> added the comment:

I recognize the same problem problem at linux with 4 core 64 processor. The python version is 2.6.5 . Looks like occured randomly but maybe this is depend from thread sequence.

----------
nosy: +kzsolt

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

From report at bugs.python.org  Sat Nov  5 22:30:20 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 05 Nov 2011 21:30:20 +0000
Subject: [issue13340] list.index does not accept None as start or stop
In-Reply-To: <1320398584.03.0.145013152611.issue13340@psf.upfronthosting.co.za>
Message-ID: <E1RMnoZ-0004u2-IX@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 0f0eda4daac7 by Petri Lehtinen in branch '2.7':
Accept None as start and stop parameters for list.index() and tuple.index()
http://hg.python.org/cpython/rev/0f0eda4daac7

New changeset 5c1fcaf3cf1c by Petri Lehtinen in branch '3.2':
Accept None as start and stop parameters for list.index() and tuple.index()
http://hg.python.org/cpython/rev/5c1fcaf3cf1c

New changeset c33aa14f4edb by Petri Lehtinen in branch 'default':
Accept None as start and stop parameters for list.index() and tuple.index().
http://hg.python.org/cpython/rev/c33aa14f4edb

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

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

From report at bugs.python.org  Sat Nov  5 22:30:35 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sat, 05 Nov 2011 21:30:35 +0000
Subject: [issue13350] Use PyUnicode_FromFomat instead of PyUnicode_Format for
	fixed formats
Message-ID: <1320528635.6.0.850267932355.issue13350@psf.upfronthosting.co.za>


New submission from Amaury Forgeot d'Arc <amauryfa at gmail.com>:

A code simplification suggested by a comment in issue13349:
Replace most usages of PyUnicode_Format (a.k.a. str.__mod__) by PyUnicode_FromFormat, which is easier to use from C:
no need to build a tuple, and the format accept both C strings (%s) and Python strings (%S or %R)

----------
files: FromFormat.diff
keywords: patch
messages: 147112
nosy: amaury.forgeotdarc, petri.lehtinen
priority: normal
severity: normal
status: open
title: Use PyUnicode_FromFomat instead of PyUnicode_Format for fixed formats
versions: Python 3.3
Added file: http://bugs.python.org/file23614/FromFormat.diff

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

From report at bugs.python.org  Sat Nov  5 22:32:09 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Sat, 05 Nov 2011 21:32:09 +0000
Subject: [issue13340] list.index does not accept None as start or stop
In-Reply-To: <1320398584.03.0.145013152611.issue13340@psf.upfronthosting.co.za>
Message-ID: <1320528729.55.0.227736412849.issue13340@psf.upfronthosting.co.za>


Petri Lehtinen <petri at digip.org> added the comment:

Committed a fix for both list and tuple. I considered this a bug fix rather than a new feature based on discussion in #11828, especially msg133532, and applied the fix to 2.7 and 3.2, too.

----------

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

From report at bugs.python.org  Sat Nov  5 22:35:22 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 05 Nov 2011 21:35:22 +0000
Subject: [issue13340] list.index does not accept None as start or stop
In-Reply-To: <1320398584.03.0.145013152611.issue13340@psf.upfronthosting.co.za>
Message-ID: <1320528922.1.0.393266345743.issue13340@psf.upfronthosting.co.za>


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

The relevant code is in _PyEval_SliceIndex() in Python/ceval.c.

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

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

From report at bugs.python.org  Sat Nov  5 22:35:37 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Sat, 05 Nov 2011 21:35:37 +0000
Subject: [issue13193] test_packaging and test_distutils failures
In-Reply-To: <1320511682.91.0.217976628659.issue13193@psf.upfronthosting.co.za>
Message-ID: <1320528928.78537.YahooMailNeo@web25801.mail.ukl.yahoo.com>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

>[citation needed].? First, mutable objects with a global name (let?s not use
> "variable" for Python) are not unconditionally evil; see sys.path and
> sys.modules for example.? Second, how concretely would you change that
> implementation?? We need shared caches for functions in packaging.database.
> They should be built on demand, and should be cleared by higher-level
> libraries or applications when the filesystem has changed (after an
> installation or removal for example).? With these constraints, do you have
> implementation ideas?

I agree, we shouldn't have a knee-jerk reaction to global bindings - they definitely
have their uses, and I'm sometimes driven to defend their use in logging. Since
you ask, though - one possible approach might be: Have those bindings be
instance variables in a Database class in database.py, and have a module-level
binding to an instance of it. Then, tests can have their own instance which is
thrown away aftereach test.

This problem was not trivial to find, because it appears that test execution order
may not be entirely deterministic: I couldn't see any other reason why the flag
would have different values on different machines. I believe that you (?ric) had
difficulty reproducing it. Perhaps we don't need to re-implement, but instead
add more tests around cache invalidation and cache contents.

----------

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

From report at bugs.python.org  Sat Nov  5 22:37:34 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 05 Nov 2011 21:37:34 +0000
Subject: [issue13340] list.index does not accept None as start or stop
In-Reply-To: <1320398584.03.0.145013152611.issue13340@psf.upfronthosting.co.za>
Message-ID: <1320529054.66.0.861138111684.issue13340@psf.upfronthosting.co.za>


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

I think this "fix" was too hastily committed. 

1) It was an API change.
2) It probably should have been done in _PyEval_SliceIndex().

Be careful.  Don't rush to commit.  Especially for backports.

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

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

From report at bugs.python.org  Sat Nov  5 22:46:25 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Sat, 05 Nov 2011 21:46:25 +0000
Subject: [issue13340] list.index does not accept None as start or stop
In-Reply-To: <1320529054.66.0.861138111684.issue13340@psf.upfronthosting.co.za>
Message-ID: <20111105214614.GB2203@ihaa>


Petri Lehtinen <petri at digip.org> added the comment:

> 2) It probably should have been done in _PyEval_SliceIndex().

I saw that other code used the same approach as I used in the fix.

The comment above _PyEval_SliceIndex() suggests it's used in other
contexts too. It seems that 2.7 uses it to implement the SLICE opcode,
while in 3.x it's only used to convert slice-like arguments.

What do you suggest? Doing it in _PyEval_SliceIndex() in 2.7 is
problematic, as we don't want x[None:2], right? :)

----------

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

From report at bugs.python.org  Sat Nov  5 22:47:29 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Sat, 05 Nov 2011 21:47:29 +0000
Subject: [issue13193] test_packaging and test_distutils failures
In-Reply-To: <1320502072.62.0.624058674116.issue13193@psf.upfronthosting.co.za>
Message-ID: <1320529639.81705.YahooMailNeo@web25803.mail.ukl.yahoo.com>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

> FTR, I haven't checked this on Ubuntu 32-bit. It's rather odd for the

> failure to be architecture-dependent. Are these two machines running
> different versions of Ubuntu, perhaps?

They are (Ubuntu Natty 32-bit failing, Ubuntu Oneiric 64-bit passing).
However, I don't believe the failure is directly architecture-related, but
indirectly so. For example, test execution order might not be identical
on all machines, depending for example on hash values and dict bucket
sizes, which I would expect to be different on different machines for any
number of reasons. In my limited testing, I found the following:

Ubuntu Natty 32-bit - failed.
Windows 7 32-bit - failed.
Ubuntu Oneiric 64-bit - passed.
Linux Mint "Katya" 11 64-bit (based on Ubuntu Natty) - passed.

With non-deterministic test execution order combined with module-level
data updated by tests, it can be hard to reproduce these failures - a bit
like uninitialised data errors in C :-(

----------

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

From report at bugs.python.org  Sat Nov  5 22:59:35 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Sat, 05 Nov 2011 21:59:35 +0000
Subject: [issue13193] test_packaging and test_distutils failures
In-Reply-To: <1318800293.23.0.0737706148876.issue13193@psf.upfronthosting.co.za>
Message-ID: <1320530375.97.0.751420681468.issue13193@psf.upfronthosting.co.za>


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

How strange. I've had no problem reproducing the failures; they've
occurred every time I've run test_packaging since the bug was opened
(on both Ubuntu and Windows). And the Windows buildbots seem to be
failing consistently as well...

----------

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

From report at bugs.python.org  Sat Nov  5 23:17:33 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 05 Nov 2011 22:17:33 +0000
Subject: [issue13340] list.index does not accept None as start or stop
In-Reply-To: <1320398584.03.0.145013152611.issue13340@psf.upfronthosting.co.za>
Message-ID: <1320531453.65.0.293354267774.issue13340@psf.upfronthosting.co.za>


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

The API in 2.7 shouldn't be changed.
The error message can be fixed though.

Also, it is not clear that the API should change even in 3.3.  The list.index() method is not required to accept None.  It is not different than other APIs that use PyArg_ParseTuple() with an "i" field for a start, stop, or step argument.

----------

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

From report at bugs.python.org  Sat Nov  5 23:29:05 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sat, 05 Nov 2011 22:29:05 +0000
Subject: [issue13340] list.index does not accept None as start or stop
In-Reply-To: <1320398584.03.0.145013152611.issue13340@psf.upfronthosting.co.za>
Message-ID: <1320532145.44.0.0335240264191.issue13340@psf.upfronthosting.co.za>


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

str.index does accept None, though

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

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

From report at bugs.python.org  Sat Nov  5 23:42:41 2011
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sat, 05 Nov 2011 22:42:41 +0000
Subject: [issue13316] build_py_2to3 does not convert when there was an error
	in the last run
In-Reply-To: <1320182540.3.0.985799836702.issue13316@psf.upfronthosting.co.za>
Message-ID: <1320532961.63.0.200829603116.issue13316@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/issue13316>
_______________________________________

From report at bugs.python.org  Sat Nov  5 23:42:51 2011
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sat, 05 Nov 2011 22:42:51 +0000
Subject: [issue13317] building with 2to3 generates wrong import paths because
	build_ext is run after build_py
In-Reply-To: <1320183133.27.0.209500697705.issue13317@psf.upfronthosting.co.za>
Message-ID: <1320532971.19.0.430723557937.issue13317@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/issue13317>
_______________________________________

From report at bugs.python.org  Sun Nov  6 00:46:44 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 05 Nov 2011 23:46:44 +0000
Subject: [issue13309] test_time fails: time data 'LMT' does not match format
	'%Z'
In-Reply-To: <1320156304.27.0.1872899991.issue13309@psf.upfronthosting.co.za>
Message-ID: <1320536804.23.0.712946580774.issue13309@psf.upfronthosting.co.za>


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

I also get this error on Mageia. If this can't be fixed, the test should be skipped or removed.

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

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

From report at bugs.python.org  Sun Nov  6 00:46:59 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 05 Nov 2011 23:46:59 +0000
Subject: [issue13342] input() builtin always uses "strict" error handler
In-Reply-To: <1320417434.92.0.472252310596.issue13342@psf.upfronthosting.co.za>
Message-ID: <E1RMpwo-0008Uf-03@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 421c8e291221 by Antoine Pitrou in branch '3.2':
Issue #13342: input() used to ignore sys.stdin's and sys.stdout's unicode
http://hg.python.org/cpython/rev/421c8e291221

New changeset 992ba03d60a8 by Antoine Pitrou in branch 'default':
Issue #13342: input() used to ignore sys.stdin's and sys.stdout's unicode
http://hg.python.org/cpython/rev/992ba03d60a8

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

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

From report at bugs.python.org  Sun Nov  6 00:47:22 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 05 Nov 2011 23:47:22 +0000
Subject: [issue13342] input() builtin always uses "strict" error handler
In-Reply-To: <1320417434.92.0.472252310596.issue13342@psf.upfronthosting.co.za>
Message-ID: <1320536842.28.0.628582105736.issue13342@psf.upfronthosting.co.za>


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

Committed. I hope the test won't disturb the buildbots.

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

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

From report at bugs.python.org  Sun Nov  6 00:49:25 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Sat, 05 Nov 2011 23:49:25 +0000
Subject: [issue13193] test_packaging and test_distutils failures
In-Reply-To: <1320530375.97.0.751420681468.issue13193@psf.upfronthosting.co.za>
Message-ID: <1320536954.36669.YahooMailNeo@web25804.mail.ukl.yahoo.com>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

> How strange. I've had no problem reproducing the failures; they've

> occurred every time I've run test_packaging since the bug was opened
> (on both Ubuntu and Windows). And the Windows buildbots seem to be
> failing consistently as well...

On a given machine, if the failure occurs, it fails every time. I got failures on
Ubuntu 32-bit and Windows 32-bit every time, too. One more data
point: on OS X Leopard (32-bit), there were no failures at all in my testing.

I only saw the tests pass when I tested on 64-bit Ubuntu variants (and OS X
32-bit).

N.B. All my testing was on the pythonv branch - though I don't believe that
had any bearing on the tests, as they also failed on the default branch (on
Ubuntu Jaunty 32-bit, where I do maintenance for logging etc.)

----------

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

From report at bugs.python.org  Sun Nov  6 00:56:42 2011
From: report at bugs.python.org (Jonas LM)
Date: Sat, 05 Nov 2011 23:56:42 +0000
Subject: [issue13351] Strange time complexity when creating nested lists
Message-ID: <1320537402.3.0.127960683982.issue13351@psf.upfronthosting.co.za>


New submission from Jonas LM <quakes0 at gmail.com>:

Consider the following snippets:

def lists(n):
    start_time = time.time()
    lists = [None]*n
    for i in xrange(n):
            lists[i] = [None]*n
            for j in xrange(n):
                    lists[i][j] = []
    print time.time() - start_time

def simple_lists(n):
    start_time = time.time()
    lists = [None]*n
    for i in xrange(n):
            lists[i] = [None]*n
            for j in xrange(n):
                    lists[i][j] = False
    print time.time() - start_time

Both of these snippets seem like they should run in O(n^2), right?

Observe the following test runs:

>>> for i in [4000, 8000, 16000]: simple_lists(i)
2.11170578003
8.67467808723
34.0958559513
>>> for i in [1000, 2000, 4000]: lists(i)
1.13742399216
7.39806008339
78.0808939934

While simple_lists() seem to run roughly in O(n^2), it seems like lists() runs in upwards of O(n^3) or worse! Something funky is going on, and I have no idea what.

----------
components: None
messages: 147126
nosy: quakes
priority: normal
severity: normal
status: open
title: Strange time complexity when creating nested lists
type: performance
versions: Python 2.6

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

From report at bugs.python.org  Sun Nov  6 01:12:11 2011
From: report at bugs.python.org (R. David Murray)
Date: Sun, 06 Nov 2011 00:12:11 +0000
Subject: [issue13351] Strange time complexity when creating nested lists
In-Reply-To: <1320537402.3.0.127960683982.issue13351@psf.upfronthosting.co.za>
Message-ID: <1320538331.52.0.503861677764.issue13351@psf.upfronthosting.co.za>


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

In the case of 'lists' an object is being allocated each time through the inner loop.  In the case of simple_lists, no such allocation is being done.  Your timing issues are probably related to the memory allocation behavior of your system.

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

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

From report at bugs.python.org  Sun Nov  6 01:34:25 2011
From: report at bugs.python.org (Florent Xicluna)
Date: Sun, 06 Nov 2011 00:34: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: <1320539665.47.0.82101553234.issue9516@psf.upfronthosting.co.za>


Changes by Florent Xicluna <florent.xicluna at gmail.com>:


----------
nosy: +flox

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

From report at bugs.python.org  Sun Nov  6 01:43:33 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 06 Nov 2011 00:43:33 +0000
Subject: [issue13229] Add shutil.filter_walk
In-Reply-To: <1319076330.7.0.757546324527.issue13229@psf.upfronthosting.co.za>
Message-ID: <1320540213.89.0.365463113335.issue13229@psf.upfronthosting.co.za>


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

I should probably update that posted recipe to my latest version (which adds "excluded_files" and "excluded_dirs" parameters).

However, since I've been dealing with remote filesystems where os.listdir() and os.stat() calls from the local machine aren't possible lately, I also think we may need to reconsider how this is structured and look at the idea of building a more effective pipeline model that permits more efficient modes of interaction.

Let's take 'os.walk' as the base primitive - the basis of the pipeline will always be an iterator that produces 3-tuples of a base name, a list of subdirectories and a list of files. The filtering pipeline elements will require that the underlying walk include "topdown=True" and pay attention to changes in the subdirectory list.


Then consider the following possible pipeline elements:

def filter_dirs(walk_iter, *include_filters, exclude_filters=()):
    def should_include(dirname):
       return any(fnmatch(dirname, include) for include in include_filters)
    def should_exclude(dirname):
       return any(fnmatch(dirname, include) for exclude in exclude_filters)
    for dirpath, subdirs, files in walk_iter:
        subdirs[:] = [subdir for subdir in subdirs
                         if should_include(subdir) and not should_exclude(subdir)]
        yield dirpath, subdirs, files

def filter_files(walk_iter, *include_filters, exclude_filters=()):
    def should_include(dirname):
       return any(fnmatch(dirname, include) for include in include_filters)
    def should_exclude(dirname):
       return any(fnmatch(dirname, include) for exclude in exclude_filters)
    for dirpath, subdirs, files in walk_iter:
        files[:] = [fname for fname in files
                         if should_include(fname) and not should_exclude(fname)]
        yield dirpath, subdirs, files

def limit_depth(walk_iter, depth):
    if depth < 0:
        msg = "Depth limit greater than 0 ({!r} provided)"
        raise ValueError(msg.format(depth))
    sep = os.sep
    for top, subdirs, files in walk_iter:
        yield top, subdirs, files
        initial_depth = top.count(sep)
        if depth == 0:
            subdirs[:] = []
        break
    for dirpath, subdirs, files in walk_iter:
        yield dirpath, subdirs, files
        current_depth = dirpath.count(sep) - initial_depth
        if current_depth >= depth:
            subdirs[:] = []

def detect_symlink_loops(walk_iter, onloop=None):
    if onloop is None:
        def onloop(path):
            msg = "Symlink {!r} refers to a parent directory, skipping\n"
            sys.stderr.write(msg.format(path))
            sys.stderr.flush()
    for top, subdirs, files in walk_iter:
        yield top, subdirs, files
        real_top = os.path.abspath(os.path.realpath(top))
        break
    for dirpath, subdirs, files in walk_iter:
        if os.path.islink(dirpath):
            # We just descended into a directory via a symbolic link
            # Check if we're referring to a directory that is
            # a parent of our nominal directory
            relative = os.path.relpath(dirpath, top)
            nominal_path = os.path.join(real_top, relative)
            real_path = os.path.abspath(os.path.realpath(dirpath))
            path_fragments = zip(nominal_path.split(sep), real_path.split(sep))
            for nominal, real in path_fragments:
                if nominal != real:
                    break
            else:
                if not onloop(dirpath):
                    subdirs[:] = []
                    continue
        yield dirpath, subdirs, files

And pipeline terminators:

def walk_dirs(walk_iter):
    for dirpath, subdirs, files in walk_iter:
        yield dirpath

def walk_files(walk_iter):
    for dirpath, subdirs, files in walk_iter:
        for fname in files:
            yield os.path.join(dirpath, fname)

def walk_all(walk_iter):
    for dirpath, subdirs, files in walk_iter:
        yield dirpath
        for fname in files:
            yield os.path.join(dirpath, fname)

The pipeline terminators could then be combined with ordinary iterable consumers like comprehensions:

    base_walk = detect_symlink_loops(os.walk(os.path.abspath(base_dir, followlinks=True)))
    depth_limited_walk = limit_depth(base_walk, 2)
    filtered_walk = filter_dirs(filter_files(depth_limited_walk, "*.py"), "*.pyp")
    tree_info = {path, os.stat(path) for path in walk_all(filtered_walk)}

----------

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

From report at bugs.python.org  Sun Nov  6 01:46:21 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 06 Nov 2011 00:46:21 +0000
Subject: [issue13229] Add shutil.filter_walk
In-Reply-To: <1319076330.7.0.757546324527.issue13229@psf.upfronthosting.co.za>
Message-ID: <1320540381.87.0.104167611044.issue13229@psf.upfronthosting.co.za>


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

This needs more thought - pypi package coming soon :)

----------

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

From report at bugs.python.org  Sun Nov  6 02:09:54 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 06 Nov 2011 01:09:54 +0000
Subject: [issue13351] Strange time complexity when creating nested lists
In-Reply-To: <1320537402.3.0.127960683982.issue13351@psf.upfronthosting.co.za>
Message-ID: <1320541794.91.0.335943678184.issue13351@psf.upfronthosting.co.za>


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

It's because of the cyclic garbage collector. If you call gc.disable() at the beginning of your benchmark, you'll see that runtimes get more similar in both cases.
You can also use tuples instead of lists as much as possible, it will reduce pressure on the GC.

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

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

From report at bugs.python.org  Sun Nov  6 02:12:00 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 06 Nov 2011 01:12:00 +0000
Subject: [issue13229] Add shutil.filter_walk
In-Reply-To: <1319076330.7.0.757546324527.issue13229@psf.upfronthosting.co.za>
Message-ID: <1320541920.34.0.411186756353.issue13229@psf.upfronthosting.co.za>


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

Nick, perhaps you want to have a look at http://hg.python.org/features/pathlib/
(it doesn't have a filter_walk equivalent but it could grow one :-))

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

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

From report at bugs.python.org  Sun Nov  6 02:25:03 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 06 Nov 2011 01:25:03 +0000
Subject: [issue13229] Add shutil.filter_walk
In-Reply-To: <1319076330.7.0.757546324527.issue13229@psf.upfronthosting.co.za>
Message-ID: <1320542703.43.0.0844579264037.issue13229@psf.upfronthosting.co.za>


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

That's one of the nicer attempts I've seen at an object-oriented path library, but I have a core problem with OOP path APIs, and it relates to the Unicode encoding/decoding problem: the ultimate purpose of path objects is almost always to either pass them to the OS, or else to another application. That exchange will almost *always* happen as a plain string.

So when your approach is based on a more sophisticated type internally, you end up having to be very careful about all of your system boundaries, making sure that "paths" are correctly being turned into "Paths".

However, one of my hopes for iterwalk will be that it *won't* care if the underlying walk iterator produces Path objects instead of ordinary strings, so long as those objects can be passed to fnmatch, os, etc and work correctly.

----------

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

From report at bugs.python.org  Sun Nov  6 03:05:40 2011
From: report at bugs.python.org (Jonas LM)
Date: Sun, 06 Nov 2011 02:05:40 +0000
Subject: [issue13351] Strange time complexity when creating nested lists
In-Reply-To: <1320537402.3.0.127960683982.issue13351@psf.upfronthosting.co.za>
Message-ID: <1320545140.26.0.531653062258.issue13351@psf.upfronthosting.co.za>


Jonas LM <quakes0 at gmail.com> added the comment:

Confirmed that this was caused by the garbage collector, as pitrou suspected. Thanks!

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

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

From report at bugs.python.org  Sun Nov  6 03:45:27 2011
From: report at bugs.python.org (Ned Deily)
Date: Sun, 06 Nov 2011 02:45:27 +0000
Subject: [issue13347] .py extension not auto added
In-Reply-To: <1320479518.35.0.248470834603.issue13347@psf.upfronthosting.co.za>
Message-ID: <1320547527.99.0.297506760887.issue13347@psf.upfronthosting.co.za>


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

A request for this change in behavior is already being tracked by Issue10364.

----------
nosy: +ned.deily
resolution:  -> duplicate
stage:  -> committed/rejected
status: open -> closed
superseder:  -> IDLE: make .py default added extension on save

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

From report at bugs.python.org  Sun Nov  6 03:45:43 2011
From: report at bugs.python.org (Ned Deily)
Date: Sun, 06 Nov 2011 02:45:43 +0000
Subject: [issue10364] IDLE: make .py default added extension on save
In-Reply-To: <1289239102.42.0.620564801896.issue10364@psf.upfronthosting.co.za>
Message-ID: <1320547543.04.0.118357919595.issue10364@psf.upfronthosting.co.za>


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


----------
nosy: +Kaleb702

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

From report at bugs.python.org  Sun Nov  6 04:01:11 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 06 Nov 2011 03:01:11 +0000
Subject: [issue13229] Add shutil.filter_walk
In-Reply-To: <1319076330.7.0.757546324527.issue13229@psf.upfronthosting.co.za>
Message-ID: <1320548471.69.0.767732013782.issue13229@psf.upfronthosting.co.za>


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

Initial version available at: https://bitbucket.org/ncoghlan/iterwalk/src

I'll get it published to PyPI once the test suite is in a slightly better state (no filesystem based tests as yet).

----------

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

From report at bugs.python.org  Sun Nov  6 04:05:55 2011
From: report at bugs.python.org (Meador Inge)
Date: Sun, 06 Nov 2011 03:05:55 +0000
Subject: [issue10977] Concrete object C API considered harmful to subclasses
	of builtin types
In-Reply-To: <1295653779.62.0.836506069174.issue10977@psf.upfronthosting.co.za>
Message-ID: <1320548755.24.0.630877343027.issue10977@psf.upfronthosting.co.za>


Changes by Meador Inge <meadori at gmail.com>:


----------
nosy: +meador.inge

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

From report at bugs.python.org  Sun Nov  6 04:17:11 2011
From: report at bugs.python.org (Meador Inge)
Date: Sun, 06 Nov 2011 03:17:11 +0000
Subject: [issue13328] pdb shows code from wrong module
In-Reply-To: <1320278597.67.0.4589054929.issue13328@psf.upfronthosting.co.za>
Message-ID: <1320549431.8.0.867428289158.issue13328@psf.upfronthosting.co.za>


Changes by Meador Inge <meadori at gmail.com>:


----------
nosy: +meador.inge

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

From report at bugs.python.org  Sun Nov  6 04:18:32 2011
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sun, 06 Nov 2011 03:18:32 +0000
Subject: [issue10570] curses.tigetstr() returns bytes,
	but curses.tparm() expects a string
In-Reply-To: <1290987535.2.0.130889699839.issue10570@psf.upfronthosting.co.za>
Message-ID: <1320549512.74.0.299526274471.issue10570@psf.upfronthosting.co.za>


Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com> added the comment:

The entry in Misc/NEWS mentions the change in curses.tigetstr(), but actually curses.tparm() has been changed. Please fix that entry to avoid confusion.
(curses.tigetstr() still expects a unicode string and returns a bytes string.)

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

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

From report at bugs.python.org  Sun Nov  6 04:21:24 2011
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sun, 06 Nov 2011 03:21:24 +0000
Subject: [issue13309] test_time fails: time data 'LMT' does not match format
	'%Z'
In-Reply-To: <1320156304.27.0.1872899991.issue13309@psf.upfronthosting.co.za>
Message-ID: <1320549684.9.0.765970854218.issue13309@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/issue13309>
_______________________________________

From report at bugs.python.org  Sun Nov  6 04:21:38 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Sun, 06 Nov 2011 03:21:38 +0000
Subject: [issue13352] tutorial section 9.3.3 documentation problem
Message-ID: <1320549698.37.0.353874550901.issue13352@psf.upfronthosting.co.za>


New submission from Eli Bendersky <eliben at gmail.com>:

User report on the docs@ list:

-----

http://docs.python.org/tutorial/classes.html#instance-objects

I think the "counter" attribute is mentioned for the first time in the
example code, not "in Instance of MyClass created above", i.e. class
MyClass does not contain "counter" attribute.

"x.counter = 1
while x.counter < 10:
   x.counter = x.counter * 2
print x.counter
del x.counter"

Best Regards,
Jussi Peltonen

----------
assignee: docs at python
components: Documentation
keywords: easy
messages: 147137
nosy: docs at python, eli.bendersky
priority: normal
severity: normal
status: open
title: tutorial section 9.3.3 documentation problem
versions: Python 2.7

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

From report at bugs.python.org  Sun Nov  6 04:24:02 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Sun, 06 Nov 2011 03:24:02 +0000
Subject: [issue13353] documentation problem in
	logging.handlers.TimedRotatingFileHandler for 2.7
Message-ID: <1320549842.11.0.772766831495.issue13353@psf.upfronthosting.co.za>


New submission from Eli Bendersky <eliben at gmail.com>:

User (Yoann Roman) report on docs@ maillist:

----

The docs for logging.handlers.TimedRotatingFileHandler in Python 2.7 say that the "utc" keyword argument was added in 2.7:
http://docs.python.org/library/logging.handlers.html#timedrotatingfilehandler

This isn't correct, however, since it was available as of 2.6 (I verified the source as well):
http://docs.python.org/release/2.6/library/logging.html#timedrotatingfilehandler

It did appear to change to True/False in 2.7 instead of 0/1 in 2.6. I'd recommend changing it to indicate this or removing the fact that this was added in 2.7 altogether.

----------
assignee: docs at python
components: Documentation
keywords: easy
messages: 147138
nosy: docs at python, eli.bendersky
priority: low
severity: normal
status: open
title: documentation problem in logging.handlers.TimedRotatingFileHandler for 2.7
versions: Python 2.7

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

From report at bugs.python.org  Sun Nov  6 05:01:35 2011
From: report at bugs.python.org (Ori Livneh)
Date: Sun, 06 Nov 2011 04:01:35 +0000
Subject: [issue13352] tutorial section 9.3.3 documentation problem
In-Reply-To: <1320549698.37.0.353874550901.issue13352@psf.upfronthosting.co.za>
Message-ID: <1320552095.25.0.87455308939.issue13352@psf.upfronthosting.co.za>


Ori Livneh <ori.livneh at gmail.com> added the comment:

That's exactly the point: in Python, data attributes don't need to be declared in the class definition.

----------
nosy: +ori.livneh

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

From report at bugs.python.org  Sun Nov  6 05:06:47 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Sun, 06 Nov 2011 04:06:47 +0000
Subject: [issue13352] tutorial section 9.3.3 documentation problem
In-Reply-To: <1320549698.37.0.353874550901.issue13352@psf.upfronthosting.co.za>
Message-ID: <1320552407.66.0.684409267019.issue13352@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

Yep, I agree, Ori.

The paragraph immediately preceding the code sample says:

    "Data attributes need not be declared; like local variables, they spring into existence when they are first assigned to [...] the following piece of code will print the value 16, without leaving a trace"

Which is what the code sample demonstrates.

----------

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

From report at bugs.python.org  Sun Nov  6 05:07:24 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Sun, 06 Nov 2011 04:07:24 +0000
Subject: [issue13352] tutorial section 9.3.3 documentation problem
In-Reply-To: <1320549698.37.0.353874550901.issue13352@psf.upfronthosting.co.za>
Message-ID: <1320552444.64.0.995542397869.issue13352@psf.upfronthosting.co.za>


Changes by Eli Bendersky <eliben at gmail.com>:


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

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

From report at bugs.python.org  Sun Nov  6 05:18:55 2011
From: report at bugs.python.org (Nathan Clayton)
Date: Sun, 06 Nov 2011 04:18:55 +0000
Subject: [issue10287] NNTP authentication should check capabilities
In-Reply-To: <1288648592.72.0.261739190945.issue10287@psf.upfronthosting.co.za>
Message-ID: <1320553135.92.0.0118057457392.issue10287@psf.upfronthosting.co.za>


Nathan Clayton <nathanclayton at gmail.com> added the comment:

By always sending capabilities at connection, some servers immediately throw an error. I've modified the class initialization to include an optional parameter to indicate if this should be disabled.

----------
keywords: +patch
nosy: +Nathan.Clayton
Added file: http://bugs.python.org/file23615/nntplib_optcapabilities.patch

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

From report at bugs.python.org  Sun Nov  6 05:52:02 2011
From: report at bugs.python.org (Oleg Oshmyan)
Date: Sun, 06 Nov 2011 04:52:02 +0000
Subject: [issue8087] Unupdated source file in traceback
In-Reply-To: <1267990809.73.0.116039880896.issue8087@psf.upfronthosting.co.za>
Message-ID: <1320555122.7.0.0525484138286.issue8087@psf.upfronthosting.co.za>


Oleg Oshmyan <chortos at inbox.lv> added the comment:

I just want to note that the code might be edited not only while it is running it in the interactive interpreter but also while it is running as a standalone script. In this case the script naturally would not know to reload its own code nor allow the user to do it manually, and even if it would, some objects created from the old code would probably remain alive.

Here is a simple shell script that causes Python to show a stack traceback with '# This is just a comment' as the offending line by launching it in the background and then overwriting the Python code. What happened in reality is that I launched a front-end tool for video transcoding I had written in Python and after a while tweaked the code while it was still running. When the actual encode finished, my (buggy) clean-up code raised an exception and I got a traceback saying it had been raised in a line that only had a comment in it.

cat <<EOF >proof.py
import time
time.sleep(5)
raise Exception
EOF
python proof.py &
sleep 1
cat <<EOF >proof.py


# This is just a comment
EOF
sleep 5

----------
nosy: +chortos

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

From report at bugs.python.org  Sun Nov  6 06:38:12 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 06 Nov 2011 05:38:12 +0000
Subject: [issue13300] IDLE 3.3 Restart Shell command fails
In-Reply-To: <1320026799.26.0.540984948832.issue13300@psf.upfronthosting.co.za>
Message-ID: <E1RMvQa-0006HP-Nf@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset ce483d696c06 by Ned Deily in branch 'default':
Issue #13300: Fix IDLE Restart Shell command failure introduced by
http://hg.python.org/cpython/rev/ce483d696c06

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

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

From report at bugs.python.org  Sun Nov  6 06:39:04 2011
From: report at bugs.python.org (Ned Deily)
Date: Sun, 06 Nov 2011 05:39:04 +0000
Subject: [issue13300] IDLE 3.3 Restart Shell command fails
In-Reply-To: <1320026799.26.0.540984948832.issue13300@psf.upfronthosting.co.za>
Message-ID: <1320557944.33.0.338398580183.issue13300@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Sun Nov  6 08:13:30 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 06 Nov 2011 07:13:30 +0000
Subject: [issue13350] Use PyUnicode_FromFomat instead of PyUnicode_Format for
	fixed formats
In-Reply-To: <1320528635.6.0.850267932355.issue13350@psf.upfronthosting.co.za>
Message-ID: <1320563610.23.0.0403851264142.issue13350@psf.upfronthosting.co.za>


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

+1

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

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

From report at bugs.python.org  Sun Nov  6 08:31:09 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 06 Nov 2011 07:31:09 +0000
Subject: [issue10570] curses.tigetstr() returns bytes,
	but curses.tparm() expects a string
In-Reply-To: <1290987535.2.0.130889699839.issue10570@psf.upfronthosting.co.za>
Message-ID: <E1RMxC0-0004E5-AN@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 3a0a94797ac5 by Petri Lehtinen in branch '3.2':
curses.tparm() is expecting a byte string, not curses.tigetstr()
http://hg.python.org/cpython/rev/3a0a94797ac5

New changeset 626c6c7f3af6 by Petri Lehtinen in branch 'default':
curses.tparm() is expecting a byte string, not curses.tigetstr()
http://hg.python.org/cpython/rev/626c6c7f3af6

----------

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

From report at bugs.python.org  Sun Nov  6 08:40:16 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 06 Nov 2011 07:40:16 +0000
Subject: [issue7777] Support needed for AF_RDS family
In-Reply-To: <1264404460.15.0.913920533968.issue7777@psf.upfronthosting.co.za>
Message-ID: <1320565216.54.0.871326545891.issue7777@psf.upfronthosting.co.za>


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

I think the patch currently lacks a lot of symbolic constants; see my review.

----------

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

From report at bugs.python.org  Sun Nov  6 08:40:28 2011
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sun, 06 Nov 2011 07:40:28 +0000
Subject: [issue10570] curses.tigetstr() returns bytes,
	but curses.tparm() expects a string
In-Reply-To: <1290987535.2.0.130889699839.issue10570@psf.upfronthosting.co.za>
Message-ID: <1320565228.64.0.439095564167.issue10570@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Sun Nov  6 10:10:11 2011
From: report at bugs.python.org (Bas Wijnen)
Date: Sun, 06 Nov 2011 09:10:11 +0000
Subject: [issue13354] tcpserver should document non-threaded long-living
	connections
Message-ID: <1320570611.72.0.286817751979.issue13354@psf.upfronthosting.co.za>


New submission from Bas Wijnen <wijnen at debian.org>:

http://docs.python.org/py3k/library/socketserver.html says:

The solution is to create a separate process or thread to handle each request; the ForkingMixIn and ThreadingMixIn mix-in classes can be used to support asynchronous behaviour.

There is another way, which doesn't bring multi-threading hell over you: keep a copy of the file descriptor and use it when events occur. I recall that this suggestion used to be in the documentation as well, but I can't find it anymore. It would be good to add this suggestion to the documentation.

However, there is a thing you must know before you can use this approach: tcpserver calls shutdown() on the socket when handle() returns. This means that the network connection is closed. Even dup2() doesn't keep it open (it lets you keep a file descriptor, but it returns EOF). The solution for this is to override shutdown_request of your handler to only call close_request (or not call anything at all) for sockets which must remain open. That way, as long as there is a reference to the socket, the network connection will not be shut down. Optionally the socket can be shutdown() explicitly when you're done with the connection.

Something like the paragraph above would be useful in the documentation IMO.

----------
assignee: docs at python
components: Documentation
messages: 147147
nosy: docs at python, shevek
priority: normal
severity: normal
status: open
title: tcpserver should document non-threaded long-living connections
type: feature request
versions: Python 3.2

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

From report at bugs.python.org  Sun Nov  6 11:56:56 2011
From: report at bugs.python.org (Mark)
Date: Sun, 06 Nov 2011 10:56:56 +0000
Subject: [issue13355] random.triangular error when low = mode
Message-ID: <1320577016.77.0.989776485745.issue13355@psf.upfronthosting.co.za>


New submission from Mark <mhughes108 at gmail.com>:

When low and mode are the same in random.triangular it gives the following error:


<type 'exceptions.ZeroDivisionError'>: float division
      args = ('float division',)
      message = 'float division' 


When high and mode are the same there is no problem.

----------
components: Extension Modules
messages: 147148
nosy: mark108
priority: normal
severity: normal
status: open
title: random.triangular error when low = mode
versions: Python 2.6

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

From report at bugs.python.org  Sun Nov  6 12:09:21 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 06 Nov 2011 11:09:21 +0000
Subject: [issue13355] random.triangular error when low = mode
In-Reply-To: <1320577016.77.0.989776485745.issue13355@psf.upfronthosting.co.za>
Message-ID: <1320577761.98.0.022543639088.issue13355@psf.upfronthosting.co.za>


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

I can't reproduce this:

Python 2.7.2 |EPD 7.1-2 (32-bit)| (default, Jul  3 2011, 15:40:35) 
[GCC 4.0.1 (Apple Inc. build 5493)] on darwin
Type "packages", "demo" or "enthought" for more information.
>>> from random import triangular
>>> triangular(low=1, high=2, mode=1)  # low == mode
1.185344240827765

Note that the order of the parameters to random.triangular is (low, high, mode).  I suspect that you're actually passing identical values for `low` and `high`, and that's what's causing the error.

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

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

From report at bugs.python.org  Sun Nov  6 12:27:40 2011
From: report at bugs.python.org (Mark)
Date: Sun, 06 Nov 2011 11:27:40 +0000
Subject: [issue13355] random.triangular error when low = mode
In-Reply-To: <1320577016.77.0.989776485745.issue13355@psf.upfronthosting.co.za>
Message-ID: <1320578860.49.0.0817365015276.issue13355@psf.upfronthosting.co.za>


Mark <mhughes108 at gmail.com> added the comment:

Many thanks, Mark. I'm very new to python so apologies for my obvious mistake (you were absolutely right, I was feeding the high and mode in back to front). 

As a separate aside, it would be convenient if low=high=mode returned low (or mode or high) rather than error but it's a minor point really and easy to work around as is.

Many thanks for your help.

----------

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

From report at bugs.python.org  Sun Nov  6 12:28:00 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 06 Nov 2011 11:28:00 +0000
Subject: [issue13340] list.index does not accept None as start or stop
In-Reply-To: <1320398584.03.0.145013152611.issue13340@psf.upfronthosting.co.za>
Message-ID: <1320578880.8.0.683568485654.issue13340@psf.upfronthosting.co.za>


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

> What do you suggest? Doing it in _PyEval_SliceIndex() in 2.7 is
> problematic, as we don't want x[None:2], right? :)

Eh? Don't we already have this?

Python 2.7.2 (default, Aug 22 2011, 13:53:27) 
[GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> range(5)[None:2]
[0, 1]

Or am I misunderstanding?

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

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

From report at bugs.python.org  Sun Nov  6 12:33:23 2011
From: report at bugs.python.org (Floris Bruynooghe)
Date: Sun, 06 Nov 2011 11:33:23 +0000
Subject: [issue13338] Not all enumerations used in _Py_ANNOTATE_MEMORY_ORDER
In-Reply-To: <1320366284.3.0.0625863072508.issue13338@psf.upfronthosting.co.za>
Message-ID: <1320579203.77.0.238575449047.issue13338@psf.upfronthosting.co.za>


Floris Bruynooghe <floris.bruynooghe at gmail.com> added the comment:

Apologies for not attaching a patch, I thought it was pretty trivial.  Attached it now.

----------
keywords: +patch
Added file: http://bugs.python.org/file23616/pyatomic.diff

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

From report at bugs.python.org  Sun Nov  6 12:46:59 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Sun, 06 Nov 2011 11:46:59 +0000
Subject: [issue13340] list.index does not accept None as start or stop
In-Reply-To: <1320398584.03.0.145013152611.issue13340@psf.upfronthosting.co.za>
Message-ID: <1320580019.2.0.614660575638.issue13340@psf.upfronthosting.co.za>


Petri Lehtinen <petri at digip.org> added the comment:

> Or am I misunderstanding?

Ah, no, sorry. I wasn't aware of this.

Now the error message set by _PyEval_SliceIndex() makes sense. It doesn't itself accept None, but apply_slice() and assign_slice() handle the None case.

There's still the question whether {list,tuple}.index() should accept None or not.

----------

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

From report at bugs.python.org  Sun Nov  6 12:50:36 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Sun, 06 Nov 2011 11:50:36 +0000
Subject: [issue13338] Not all enumerations used in _Py_ANNOTATE_MEMORY_ORDER
In-Reply-To: <1320366284.3.0.0625863072508.issue13338@psf.upfronthosting.co.za>
Message-ID: <1320580236.61.0.551554957097.issue13338@psf.upfronthosting.co.za>


Changes by Petri Lehtinen <petri at digip.org>:


----------
keywords: +needs review
stage: needs patch -> patch review

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

From report at bugs.python.org  Sun Nov  6 12:52:59 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Sun, 06 Nov 2011 11:52:59 +0000
Subject: [issue13350] Use PyUnicode_FromFomat instead of PyUnicode_Format for
	fixed formats
In-Reply-To: <1320528635.6.0.850267932355.issue13350@psf.upfronthosting.co.za>
Message-ID: <1320580379.9.0.295696829192.issue13350@psf.upfronthosting.co.za>


Petri Lehtinen <petri at digip.org> added the comment:

This would chop unnecessary lines of code very nicely. +1

----------

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

From report at bugs.python.org  Sun Nov  6 13:22:22 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 06 Nov 2011 12:22:22 +0000
Subject: [issue13355] random.triangular error when low = mode
In-Reply-To: <1320577016.77.0.989776485745.issue13355@psf.upfronthosting.co.za>
Message-ID: <1320582142.88.0.0281216637263.issue13355@psf.upfronthosting.co.za>


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

> it would be convenient if low=high=mode returned low (or mode or high)

Yes, I agree that random.triangular should degrade gracefully, in the same way that random.uniform does.

----------

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

From report at bugs.python.org  Sun Nov  6 14:03:02 2011
From: report at bugs.python.org (=?utf-8?q?Julien_=C3=89LIE?=)
Date: Sun, 06 Nov 2011 13:03:02 +0000
Subject: [issue10287] NNTP authentication should check capabilities
In-Reply-To: <1288648592.72.0.261739190945.issue10287@psf.upfronthosting.co.za>
Message-ID: <1320584582.98.0.880884963124.issue10287@psf.upfronthosting.co.za>


Julien ?LIE <julien at trigofacile.com> added the comment:

A drawback is that CAPABILITIES will still being unsent after an upgrade of the news server to a more up-to-date version supporting the command.

If CAPABILITIES is not understood by the news server, it is not an issue.  A 500 response code is usually answered by the news server, which is RFC-compliant.  nntplib should then behave properly.  (getcapabilities() returns an empty dictionary when CAPABILITIES is not implemented.)

----------

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

From report at bugs.python.org  Sun Nov  6 14:33:36 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 06 Nov 2011 13:33:36 +0000
Subject: [issue10287] NNTP authentication should check capabilities
In-Reply-To: <1320553135.92.0.0118057457392.issue10287@psf.upfronthosting.co.za>
Message-ID: <1320586143.4044.2.camel@localhost.localdomain>


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

> By always sending capabilities at connection, some servers immediately
> throw an error. I've modified the class initialization to include an
> optional parameter to indicate if this should be disabled.

Which kind of error? As Julien says, we could simply catch it and
proceed.
By the way, when sending a patch, please send a unified diff if possible
("diff -u"; if you are using Mercurial, this should be the default).

----------

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

From report at bugs.python.org  Sun Nov  6 14:55:43 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 06 Nov 2011 13:55:43 +0000
Subject: [issue10570] curses.tigetstr() returns bytes,
	but curses.tparm() expects a string
In-Reply-To: <1290987535.2.0.130889699839.issue10570@psf.upfronthosting.co.za>
Message-ID: <1320587743.2.0.635832801527.issue10570@psf.upfronthosting.co.za>


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

> The entry in Misc/NEWS mentions the change in curses.tigetstr(),
> but actually curses.tparm() has been changed

Woops, thanks for fixing the NEWS file :-)

----------

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

From report at bugs.python.org  Sun Nov  6 15:15:34 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 06 Nov 2011 14:15:34 +0000
Subject: [issue13350] Use PyUnicode_FromFomat instead of PyUnicode_Format for
	fixed formats
In-Reply-To: <1320528635.6.0.850267932355.issue13350@psf.upfronthosting.co.za>
Message-ID: <E1RN3VN-0003ux-GK@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 386a319b1825 by Amaury Forgeot d'Arc in branch 'default':
Issue #13350: Replace most usages of PyUnicode_Format by PyUnicode_FromFormat.
http://hg.python.org/cpython/rev/386a319b1825

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

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

From report at bugs.python.org  Sun Nov  6 15:18:10 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sun, 06 Nov 2011 14:18:10 +0000
Subject: [issue13350] Use PyUnicode_FromFomat instead of PyUnicode_Format for
	fixed formats
In-Reply-To: <1320528635.6.0.850267932355.issue13350@psf.upfronthosting.co.za>
Message-ID: <1320589090.12.0.0596161847837.issue13350@psf.upfronthosting.co.za>


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

Now PyUnicode_Format is only called by unicode_mod...

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

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

From report at bugs.python.org  Sun Nov  6 16:31:32 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 06 Nov 2011 15:31:32 +0000
Subject: [issue13353] documentation problem in
	logging.handlers.TimedRotatingFileHandler for 2.7
In-Reply-To: <1320549842.11.0.772766831495.issue13353@psf.upfronthosting.co.za>
Message-ID: <1320593492.21.0.367199565001.issue13353@psf.upfronthosting.co.za>


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


----------
nosy: +vinay.sajip
stage:  -> needs patch

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

From report at bugs.python.org  Sun Nov  6 17:29:57 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sun, 06 Nov 2011 16:29:57 +0000
Subject: [issue7777] Support needed for AF_RDS family
In-Reply-To: <1264404460.15.0.913920533968.issue7777@psf.upfronthosting.co.za>
Message-ID: <1320596997.25.0.923538272064.issue7777@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

Here's an updated patch:
- address returned by recvfrom()
- recv flags (MSG_PEEK)
- congestion behavior

I've also added a bunch of constants:
- all the typical SO_ constants
- CMSG flags
- RDMA-related options (RDMA is probably one of the most useful features of RDS)
- I chose to let aside INFO flags, since they don't appear in the man pages  (and neither here: https://github.com/agrover/python-rds/blob/master/rdma.py, a ctypes-based RDS implementation I stumbled upon)
- I didn't add control messages tests: they all pertain to RDMA, which is rather tricky to test to test from Python (and my header files don't define them)

----------
Added file: http://bugs.python.org/file23617/socket_rds-2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7777>
_______________________________________

From report at bugs.python.org  Sun Nov  6 18:08:31 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 06 Nov 2011 17:08:31 +0000
Subject: [issue13355] random.triangular error when low = mode
In-Reply-To: <1320577016.77.0.989776485745.issue13355@psf.upfronthosting.co.za>
Message-ID: <1320599311.8.0.218085263839.issue13355@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
assignee:  -> rhettinger
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13355>
_______________________________________

From report at bugs.python.org  Sun Nov  6 18:13:59 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 06 Nov 2011 17:13:59 +0000
Subject: [issue13340] list.index does not accept None as start or stop
In-Reply-To: <1320398584.03.0.145013152611.issue13340@psf.upfronthosting.co.za>
Message-ID: <1320599639.45.0.751184916023.issue13340@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

> There's still the question whether {list,tuple}.index() should accept None or not.

The API should not be changed for Py2.7 and Py3.2.  Those changesets should be reverted.

For Py3.3, it is open to discussion, but we probably don't need the change (making every other implementation also change for nearly zero benefit).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13340>
_______________________________________

From report at bugs.python.org  Sun Nov  6 18:18:06 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 06 Nov 2011 17:18:06 +0000
Subject: [issue13340] list.index does not accept None as start or stop
In-Reply-To: <1320398584.03.0.145013152611.issue13340@psf.upfronthosting.co.za>
Message-ID: <1320599886.16.0.0757025316117.issue13340@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

One other thought:  the API for list.index() doesn't exist in isolation.  There is also str.index, the sequence abstract base class, and tons of code that has been written to emulate lists.  This is an ancient API (approx 20 years) and should only be changed with care.

IOW, I don't think this change should have been made at all, at least not without a discussion on python-dev and motivating use cases.

----------
priority: normal -> high
resolution: fixed -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13340>
_______________________________________

From report at bugs.python.org  Sun Nov  6 18:19:53 2011
From: report at bugs.python.org (Vetoshkin Nikita)
Date: Sun, 06 Nov 2011 17:19:53 +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: <1320599993.35.0.331132519468.issue10115@psf.upfronthosting.co.za>


Vetoshkin Nikita <nikita.vetoshkin at gmail.com> added the comment:

up?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10115>
_______________________________________

From report at bugs.python.org  Sun Nov  6 18:53:01 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 06 Nov 2011 17:53:01 +0000
Subject: [issue13356] test_logging warning on 2.7
Message-ID: <1320601981.59.0.630588677402.issue13356@psf.upfronthosting.co.za>


New submission from Ezio Melotti <ezio.melotti at gmail.com>:

$ ./python -Wd -3 -m test.regrtest -v test_logging
== CPython 2.7.2+ (2.7:39573be48b4a, Nov 6 2011, 17:13:44) [GCC 4.6.1]
==   Linux-3.0.0-12-generic-i686-with-debian-wheezy-sid little-endian
==   /home/wolf/dev/py/wide-2.7/build/test_python_6508
Testing with flags: sys.flags(debug=0, py3k_warning=1, division_warning=1, division_new=0, inspect=0, interactive=0, optimize=0, dont_write_bytecode=0, no_user_site=0, no_site=0, ignore_environment=0, tabcheck=1, verbose=0, unicode=0, bytes_warning=0)
test_logging
[...]
test_listen_config_10_ok (test.test_logging.ConfigDictTest) ... /home/wolf/dev/py/wide-2.7/Lib/logging/config.py:599: UnicodeWarning: Unicode equal comparison failed to convert both arguments to Unicode - interpreting them as being unequal
  if name in existing:
ok
[...]

----------------------------------------------------------------------
Ran 43 tests in 2.328s

OK
1 test OK.

----------
assignee: vinay.sajip
components: Library (Lib)
messages: 147165
nosy: ezio.melotti, vinay.sajip
priority: normal
severity: normal
stage: needs patch
status: open
title: test_logging warning on 2.7
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13356>
_______________________________________

From report at bugs.python.org  Sun Nov  6 18:54:05 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 06 Nov 2011 17:54:05 +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: <1320602045.92.0.575267475925.issue10115@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> What value should we assign to sock->sock_timeout if SOCK_NONBLOCK was 
> specified in accept4() call?

The same value as for other non-blocking sockets, IMO.

> And in socket.py should we check as in original accept:
> if getdefaulttimeout() is None and self.gettimeout():
>    sock.setblocking(True)

I don't think so, since the whole point of accept4() is to override normal flags creation.

----------
versions: +Python 3.3 -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10115>
_______________________________________

From report at bugs.python.org  Sun Nov  6 19:12:13 2011
From: report at bugs.python.org (Vetoshkin Nikita)
Date: Sun, 06 Nov 2011 18:12:13 +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: <1320603133.23.0.139710140638.issue10115@psf.upfronthosting.co.za>


Vetoshkin Nikita <nikita.vetoshkin at gmail.com> added the comment:

> The same value as for other non-blocking sockets, IMO.
There are three possible values I think:
1. parent's current sock_timeout
2. global default socket timeout
3. 0

Can you please tell which one? I assume it should be number 3.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10115>
_______________________________________

From report at bugs.python.org  Sun Nov  6 19:13:39 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 06 Nov 2011 18:13:39 +0000
Subject: [issue10115] Support accept4() for atomic setting of flags at socket
	creation
In-Reply-To: <1320603133.23.0.139710140638.issue10115@psf.upfronthosting.co.za>
Message-ID: <1320602947.23330.1.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> > The same value as for other non-blocking sockets, IMO.
> There are three possible values I think:
> 1. parent's current sock_timeout
> 2. global default socket timeout
> 3. 0
> 
> Can you please tell which one? I assume it should be number 3.

Yes (again, IMO).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10115>
_______________________________________

From report at bugs.python.org  Sun Nov  6 20:09:06 2011
From: report at bugs.python.org (Michael Brooks)
Date: Sun, 06 Nov 2011 19:09:06 +0000
Subject: [issue13357] HTMLParser parses attributes incorrectly.
Message-ID: <1320606546.64.0.752508532419.issue13357@psf.upfronthosting.co.za>


New submission from Michael Brooks <firealwaysworks at gmail.com>:

Open the attached file "red_test.html" in a browser.  The "bad" elements are blue because the style tag isn't parsed by any known browser.   However,  the HTMLParser library will incorrectly recognize them.

----------
components: Library (Lib)
files: red_test.html
messages: 147169
nosy: Michael.Brooks
priority: normal
severity: normal
status: open
title: HTMLParser parses attributes incorrectly.
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file23618/red_test.html

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13357>
_______________________________________

From report at bugs.python.org  Sun Nov  6 20:14:18 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 06 Nov 2011 19:14:18 +0000
Subject: [issue13357] HTMLParser parses attributes incorrectly.
In-Reply-To: <1320606546.64.0.752508532419.issue13357@psf.upfronthosting.co.za>
Message-ID: <1320606858.96.0.187831321626.issue13357@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Thanks for the report.
Could you try with the latest 2.7 and see if you can reproduce the problem? (see the devguide for instructions.)

If you can reproduce the issue even on the latest 2.7, it would be great if you could provide a patch with a test case like the ones in Lib/test/test_htmlparser.py.

----------
nosy: +ezio.melotti
stage:  -> test needed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13357>
_______________________________________

From report at bugs.python.org  Sun Nov  6 20:15:23 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 06 Nov 2011 19:15:23 +0000
Subject: [issue13340] list.index does not accept None as start or stop
In-Reply-To: <1320398584.03.0.145013152611.issue13340@psf.upfronthosting.co.za>
Message-ID: <E1RN8BV-0004kZ-Eb@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 19ffa12ffdd4 by Petri Lehtinen in branch '2.7':
Revert "Accept None as start and stop parameters for list.index() and tuple.index()"
http://hg.python.org/cpython/rev/19ffa12ffdd4

New changeset ed0e85efac47 by Petri Lehtinen in branch '3.2':
Revert "Accept None as start and stop parameters for list.index() and tuple.index()"
http://hg.python.org/cpython/rev/ed0e85efac47

New changeset 106f9e1ad7ab by Petri Lehtinen in branch 'default':
Revert "Accept None as start and stop parameters for list.index() and tuple.index()"
http://hg.python.org/cpython/rev/106f9e1ad7ab

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13340>
_______________________________________

From report at bugs.python.org  Sun Nov  6 20:20:00 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Sun, 06 Nov 2011 19:20:00 +0000
Subject: [issue13340] list.index does not accept None as start or stop
In-Reply-To: <1320398584.03.0.145013152611.issue13340@psf.upfronthosting.co.za>
Message-ID: <1320607200.72.0.377035207061.issue13340@psf.upfronthosting.co.za>


Petri Lehtinen <petri at digip.org> added the comment:

It's now reverted on all branches. I posted to python-dev alreay earlier.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13340>
_______________________________________

From report at bugs.python.org  Sun Nov  6 20:41:45 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 06 Nov 2011 19:41:45 +0000
Subject: [issue13327] Update utime API to not require explicit None argument
In-Reply-To: <1320277592.58.0.341414975391.issue13327@psf.upfronthosting.co.za>
Message-ID: <E1RN8b2-0006km-0a@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 99e118951a80 by Brian Curtin in branch 'default':
Fix #13327. Remove the need for an explicit None as the second argument to
http://hg.python.org/cpython/rev/99e118951a80

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13327>
_______________________________________

From report at bugs.python.org  Sun Nov  6 20:48:11 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Sun, 06 Nov 2011 19:48:11 +0000
Subject: [issue6203] 3.x locale does not default to C,
	contrary to the documentation and to 2.x behavior
In-Reply-To: <1244199398.44.0.399320307295.issue6203@psf.upfronthosting.co.za>
Message-ID: <1320608891.27.0.216425585232.issue6203@psf.upfronthosting.co.za>


Petri Lehtinen <petri at digip.org> added the comment:

If the thread safety of setlocale() is a problem, does anybody know how portable uselocale() is? It sets the locale of the current thread only, so it's safe to temporarily change the locale and then set it back.

----------
nosy: +petri.lehtinen

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6203>
_______________________________________

From report at bugs.python.org  Sun Nov  6 20:48:25 2011
From: report at bugs.python.org (Michael Brooks)
Date: Sun, 06 Nov 2011 19:48:25 +0000
Subject: [issue13358] HTMLParser incorrectly handles cdata elements.
Message-ID: <1320608905.33.0.994524216308.issue13358@psf.upfronthosting.co.za>


New submission from Michael Brooks <firealwaysworks at gmail.com>:

The HTML tag at the bottom of this page correctly identified has having cdata like properties and trigger set_cdata_mode().  Due to the cdata properties of this tag,  the only way to end the data segment is with a closing </script> tag, NO OTHER tag can close this data segment.  Currently in cdata mode the HTMLParser will use this regular expression to close this script tag: re.compile(r'<(/|\Z)'),  however this script tag is setting a variable with data that contains "</b>" which will terminate this script tag prematurely.

I have written and tested the following patch on my system:
#used to terminate cdata elements
endtagfind_script = re.compile('(?i)</\s*script\s*>')
endtagfind_style = re.compile('(?i)</\s*style\s*>')

class html_patch(HTMLParser.HTMLParser):
    # Internal -- sets the proper tag terminator based on cdata element type
    def set_cdata_mode(self, tag):
        #We check if the script is either a style or a script
        #based on self.CDATA_CONTENT_ELEMENTS
        if tag=="style":
            self.interesting = endtagfind_style
        elif tag=="script":
            self.interesting = endtagfind_script
        else:
            self.error("Unknown cdata type:"+tag) # should never happen
        self.cdata_tag = tag 


This cdata tag isn't parsed properly by HTMLParser,  but it works fine in a browser:
<script>
pwa.setup(
pwa.searchview,
'lhid_searchheader',
'lhid_content',
'lhid_trayhandle',
'lhid_tray',
{'query': 'test',
'tagQuery': '',
'searchScope': '',
'owner': '',
'doCrowding': false,
'isOwner': false,
'albumId': ''
,'experimentalsearchquality': true},
'firealwaysworks'
,
{feedUrl: 'https://picasaweb.google.com/data/feed/tiny/all?alt=jsonm&amp;kind=photo&amp;access=public&amp;filter=1&amp;q=test',
feedPreload: null},
{NEW_HOMEPAGE:1,NEW_ONE_BAR:1,fr:1,tags:1,search:1,globalsearch:1,globalsearchpromo:1,newfeatureslink:1,cart:1,contentcaching:1,developerlink:1,payments:1,newStrings:1,cccquota:1,signups:1,flashSlideshow:1,URL_SHORTENER_VISIBILITY:1,emailupload:1,photopickeralbumview:1,PWA_NEWUI:1,WILDCARD_QUERY_FEED:1,recentphotos:1,editinpicasa:1,imagesearch:1,froptin:1,FR_CONTINUOUS_CLUSTERING:1,asyncUploads:1,PERFORMANCE_EXPERIMENTS:1,BAKED_PRELOAD_FEEDS:1,albumviewlimit:1,HQ_VIDEOS:1,VIDEO_INFO_DISPLAY:1,CSI:1,EXPERIMENTAL_SEARCH_QUALITY:1,COMMENT_TRANSLATION:1,NEW_COMMENT_STYLE:1,ENABLE_NEW_FLAG_ABUSE_FORM:1,QRCODE:1,CHINA:1,GWS_URL_REDIRECTION:1,FEATURED_PHOTOS:1,COMMENT_SUBSCRIPTION:1,COMMENT_SUBSCRIPTION_SETTING:1,PICASA_MAC:1,AD_ON_SEARCHPAGE:1,API_AUTO_ACCOUNTS:1,FOCUS_GROUP_ACL:1,PHOTOSTREAM:1,BACKEND_ACL:1,ADVANCED_SEARCH:1,FACE_SEARCH:1,CAMERA_SEARCH:1,NOTIFICATION:1,PIXELATED_PREVIEW:1,TRANSPARENT_PIXELATED_PREVIEW:1,NEW_SETTINGS_PAGE:1,VIEW_STARRERS:1,FR_FOCUS_MERGE:1,AD_ON_SEARCH_ONEUP:1,GALLERY_COMMENTS:1,COMMENT_ABUSE_BLOCKING:1,FAVORITE_NOTIFICATION:1,IMAGE_ONLY_LINK:1,RECENT_PHOTOS_SLIDESHOW:1,HEART:1,SMALLER_IMAGE:1,FAST_SLIDESHOW:1,VIEW_CONTACTS:1,COLLABORATIVE_ALBUMS:1,PRINT_MARKETPLACE:1,PRINT_MARKETPLACE_REPLACEMENT:1,VIEW_COUNT:1,POST_TO:1,GAPLUS:1,PICASA_PROMO:1,DOUBLECLICK_PREMIUM_ADS:1,DOUBLECLICK_EXPLORE_MAIN:1,DOUBLECLICK_MYPHOTOS:1,DOUBLECLICK_PUBLIC_GALLERY:1,DOUBLECLICK_USER_ALBUM:1,DOUBLECLICK_USER_PHOTO:1,DOUBLECLICK_VISITOR_ADS:1,PRODUCTION:1,NOSCRIPT:1,UNLISTED_GALLERY:1,GA_TRACKING:1,UNLIMITED_GALLERY:1,PICNIK_EDIT:1,MICROSCOPE_ZOOM:1,FR_V2:1,FAVORITE_SUGGESTION:1,FAVORITE_UPDATE:1,MERGED_PROFILES_SOFTLAUNCH:1,MERGED_PROFILES:1,MERGED_PROFILES_ASYNC:1,NEW_FR_UI:1,GAPLUS_UNMERGED_SOCIALIZATION:1,OPTOUT_ACL_NOTIFICATION:1,HTTPS_VISIBILITY:1,DEFAULT_HTTPS:1,EXTENDED_EXIF:1,DOUBLECLICK_MULTISLOT:1,ONEPICK:1,PER_ALBUM_GEO_VISIBILITY:1,FOCUS_MERGE_LINK_DIALOG_VISIBILITY:1,SHAREBOX_VISIBILITY:1,AUTO_DOWNSIZE:1,BULK_ALBUM_EDITOR_VISIBILITY:1,PROFILE_NAME_CHECK:1,COLLABORATIVE_NAMETAGS:1,NOT_FOUND_404:1,REDIRECT_TO_PLUS:1},
{
'gdataVersion': '4.0',
'updateCartPath': '\x2Flh\x2FupdateCart?rtok=b8S9ibYqrTMF',
'editCaptionsPath': '',
'albumMapPath': '',
'albumKmlUrl': '',
'selectedPhotosPath': '\x2Flh\x2FselectedPhotos?tok=QUI1UGxRYk9fNmw1Q2tVeS1DWnY3UlFoTTY1RzRNNWphdzoxMzIwNjAyMzA3NDYx',
'setLicensePath': '',
'setStarPath': '\x2Flh\x2FsetStar?tok=QUI1UGxRWW4zY1ZKb3U0TzROZU5tUHhIV3hhRW9HcUYwQToxMzIwNjAyMzA3NDYx',
'peopleManagerPath': '',
'peopleSearchPath': '',
'clusterViewPath': '',
'frOptStatus': 'OptedIn',
'isNameTagsVisible': '','authUserIsPhotosUser': true,
'authUserNickname': 'Some Nickname',
'authUserPortraitUrl': 'https:\x2F\x2Flh4.googleusercontent.com\x2F-UI9ZfIFfyQI\x2FAAAAAAAAAAI\x2FAAAAAAAAAAA\x2Fm0enLvZXYbI\x2Fs32-c\x2Ffirealwaysworks.jpg',
'authUserProfileUrl':'https:\x2F\x2Fprofiles.google.com\x2F115162402406836485912', 'authUser':{name:'firealwaysworks',isProfileUser:1,isLoggedIn:1,user:1,isOwner:1
,'showGeo': 0
},
'foreignNickname': '',
'subjects': [
]
,
'owner': {name:'firealwaysworks',nickname:'Michael Brooks',portrait:'https:\x2F\x2Flh4.googleusercontent.com\x2F-UI9ZfIFfyQI\x2FAAAAAAAAAAI\x2FAAAAAAAAAAA\x2Fm0enLvZXYbI\x2Fs32-c\x2Ffirealwaysworks.jpg',link:'https:\x2F\x2Fpicasaweb.google.com\x2F115162402406836485912',defaultalbumnametagsvisibility:'2'
,isnewstorageuser:false},
'album': {id:'',link:'',name:'',title:'',titleshort:'',kmlLink:'',mapLink:'',showGeo:0},
'picnikHandlerUrl': 'https:\x2F\x2Fpicasaweb.google.com\x2Flh\x2FpicnikHandler?tok=QUI1UGxRYWJYZVVueTE2SjJJLTBjRUliWVlaaU42S0NRQToxMzIwNjAyMzA3NDYx',
'picnikCloseUrl': 'https:\x2F\x2Fpicasaweb.google.com\x2Flh\x2FpicnikClose',
'picnikLocale': 'en_US',
'authUserIsProfileUser': true,
'ownerIsEsUser': false,
'profileServerUrl': '',
'profileSignupUrl': 'https:\x2F\x2Fplus.google.com\x2Fup\x2F?type=st',
'profileName': 'Google+'
});
function google_afs_request_done(google_ads) {
var google_num_ads = google_ads.length;
if (google_num_ads <= 0)
      return;

    var wideAds = '<table width="100%" cellspacing="0" cellpadding="8"' +
        'border="0" class="lhcl_search_ad_tbl"><tbody><tr>';
for(var i = 0; i < google_num_ads; i++){
      if (google_ads[i].type=="text/wide"){
        wideAds += '<td>';
wideAds += '<table width="100%" cellspacing="0" ' +
          'cellpadding="0" border="0"><tbody><tr><td>';
wideAds+='<a href="' + google_ads[i].url + '" ' +
        'onmouseout="window.status=\'\';return true" ' +
        'onmouseover="window.status=\'go to ' +
        google_ads[i].visible_url + '\';return true" ' +
        'style="text-decoration:none">' +
'<span style="text-decoration:underline">' +
'<b>' + google_ads[i].line1 + '</b><br></span>' +
'<span style="color:#000000">' +
google_ads[i].line2 + '<br></span>' +
'<span style="color:#008000">' +
google_ads[i].visible_url + '</span></a><BR>';
wideAds += '</td>';
if (i == google_num_ads - 1) {
wideAds += '<td valign="top">' +
'<div id="lhid_search_ad_spl">Sponsored Links</div></td>';
}
wideAds += '</tr></tbody></table>';
wideAds += '</td>';
}
}
wideAds += '</tr></tbody></table>';
document.getElementById("lhid_search_ad_unit").innerHTML = wideAds;
}
google_afs_query = 'test';
google_afs_ad = 'w3'; // specify the number of ads you are requesting
google_afs_client = 'google-picasa_js'; // substitute your client ID
// google_afs_channel = ''; // enter your comma-separated channel IDs
google_afs_ie = 'utf8'; // select input encoding scheme
google_afs_oe = 'utf8'; // select output encoding scheme
google_afs_adsafe = 'high'; // specify level for filtering non-family-safe ads
google_afs_adtest = 'off'; // ** set parameter to off before launch to production
document.write('<' +
    'script src="https://www.google.com/afsonline/show_afs_ads.js"></' +
    'script>');
</script>

----------
components: Library (Lib)
messages: 147175
nosy: Michael.Brooks
priority: normal
severity: normal
status: open
title: HTMLParser incorrectly handles cdata elements.
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13358>
_______________________________________

From report at bugs.python.org  Sun Nov  6 20:48:45 2011
From: report at bugs.python.org (Michael Brooks)
Date: Sun, 06 Nov 2011 19:48:45 +0000
Subject: [issue13358] HTMLParser incorrectly handles cdata elements.
In-Reply-To: <1320608905.33.0.994524216308.issue13358@psf.upfronthosting.co.za>
Message-ID: <1320608925.05.0.825000958902.issue13358@psf.upfronthosting.co.za>


Changes by Michael Brooks <firealwaysworks at gmail.com>:


----------
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13358>
_______________________________________

From report at bugs.python.org  Sun Nov  6 20:52:01 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 06 Nov 2011 19:52:01 +0000
Subject: [issue13358] HTMLParser incorrectly handles cdata elements.
In-Reply-To: <1320608905.33.0.994524216308.issue13358@psf.upfronthosting.co.za>
Message-ID: <1320609121.31.0.864925797383.issue13358@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Have you tried with the latest 2.7? (see msg147170)

----------
nosy: +ezio.melotti
stage:  -> test needed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13358>
_______________________________________

From report at bugs.python.org  Sun Nov  6 20:54:07 2011
From: report at bugs.python.org (Michael Brooks)
Date: Sun, 06 Nov 2011 19:54:07 +0000
Subject: [issue13357] HTMLParser parses attributes incorrectly.
In-Reply-To: <1320606858.96.0.187831321626.issue13357@psf.upfronthosting.co.za>
Message-ID: <CACDSwDnOFPVb2gEu4Okf6DHgYsccRfn6L4JpaajUvh_NnJPZHw@mail.gmail.com>


Michael Brooks <firealwaysworks at gmail.com> added the comment:

Yes, I am running the latest version,  which is python 2.7.2.

On Sun, Nov 6, 2011 at 12:14 PM, Ezio Melotti <report at bugs.python.org>wrote:

>
> Ezio Melotti <ezio.melotti at gmail.com> added the comment:
>
> Thanks for the report.
> Could you try with the latest 2.7 and see if you can reproduce the
> problem? (see the devguide for instructions.)
>
> If you can reproduce the issue even on the latest 2.7, it would be great
> if you could provide a patch with a test case like the ones in
> Lib/test/test_htmlparser.py.
>
> ----------
> nosy: +ezio.melotti
> stage:  -> test needed
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue13357>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13357>
_______________________________________

From report at bugs.python.org  Sun Nov  6 20:54:37 2011
From: report at bugs.python.org (Michael Brooks)
Date: Sun, 06 Nov 2011 19:54:37 +0000
Subject: [issue13358] HTMLParser incorrectly handles cdata elements.
In-Reply-To: <1320609121.31.0.864925797383.issue13358@psf.upfronthosting.co.za>
Message-ID: <CACDSwDkqg9RHhdoB3grZTT5z6VxQ8MtX8LWD6SOXPCvMMr6g+w@mail.gmail.com>


Michael Brooks <firealwaysworks at gmail.com> added the comment:

Yes I am running python 2.7.2.

On Sun, Nov 6, 2011 at 12:52 PM, Ezio Melotti <report at bugs.python.org>wrote:

>
> Ezio Melotti <ezio.melotti at gmail.com> added the comment:
>
> Have you tried with the latest 2.7? (see msg147170)
>
> ----------
> nosy: +ezio.melotti
> stage:  -> test needed
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue13358>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13358>
_______________________________________

From report at bugs.python.org  Sun Nov  6 20:56:25 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 06 Nov 2011 19:56:25 +0000
Subject: [issue13357] HTMLParser parses attributes incorrectly.
In-Reply-To: <1320606546.64.0.752508532419.issue13357@psf.upfronthosting.co.za>
Message-ID: <1320609385.23.0.651998290333.issue13357@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

I mean 2.7.3 (i.e. the development version).
You need to get a clone of Python as explained here: http://docs.python.org/devguide/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13357>
_______________________________________

From report at bugs.python.org  Sun Nov  6 21:13:47 2011
From: report at bugs.python.org (Davide Rizzo)
Date: Sun, 06 Nov 2011 20:13:47 +0000
Subject: [issue13359] urllib2 doesn't escape spaces in http requests
Message-ID: <1320610427.07.0.982938376676.issue13359@psf.upfronthosting.co.za>


New submission from Davide Rizzo <sorcio at gmail.com>:

urllib2.urlopen('http://foo/url and spaces') will send a HTTP request line like this to the server:

GET /url and spaces HTTP/1.1

which the server obviously does not understand. This contrasts with urllib's behaviour which replaces the spaces (' ') in the url with '%20'.

Related: #918368 #1153027

----------
components: Library (Lib)
messages: 147180
nosy: davide.rizzo, orsenthil
priority: normal
severity: normal
status: open
title: urllib2 doesn't escape spaces in http requests
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13359>
_______________________________________

From report at bugs.python.org  Sun Nov  6 21:14:48 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 06 Nov 2011 20:14:48 +0000
Subject: [issue13359] urllib2 doesn't escape spaces in http requests
In-Reply-To: <1320610427.07.0.982938376676.issue13359@psf.upfronthosting.co.za>
Message-ID: <1320610488.98.0.06450221614.issue13359@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti
stage:  -> test needed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13359>
_______________________________________

From report at bugs.python.org  Sun Nov  6 21:22:12 2011
From: report at bugs.python.org (Florent Xicluna)
Date: Sun, 06 Nov 2011 20:22:12 +0000
Subject: [issue13360] UnicodeWarning raised on dict() and set()
Message-ID: <1320610932.39.0.0241525481536.issue13360@psf.upfronthosting.co.za>


New submission from Florent Xicluna <florent.xicluna at gmail.com>:

The UnicodeWarning is raised on some dict or set operations.
It is not very helpful, and sometimes annoying.
And it is somewhat inconsistent.


# ** warning not raised **

$ python2.7 -c "print u'd\xe9' in {'foo', 'bar'}"
False
$ python2.7 -c "print 'd\xe9' in {u'foo', u'bar'}"
False
$ python2.7 -c "print 'd\xc3\xa9' in {u'foo', u'd\xe9'}"
False


# ** warning raised **

$ python2.7 -c "print 'd\xe9' in {u'foo', u'd\xe9'}"
-c:1: UnicodeWarning: Unicode equal comparison failed to convert both arguments to Unicode - interpreting them as being unequal
False
$ python2.7 -c "print u'd\xe9' in {'foo', 'd\xe9'}"
-c:1: UnicodeWarning: Unicode equal comparison failed to convert both arguments to Unicode - interpreting them as being unequal
False

----------
components: Unicode
messages: 147181
nosy: ezio.melotti, flox
priority: normal
severity: normal
status: open
title: UnicodeWarning raised on dict() and set()
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13360>
_______________________________________

From report at bugs.python.org  Sun Nov  6 21:26:11 2011
From: report at bugs.python.org (Michael Brooks)
Date: Sun, 06 Nov 2011 20:26:11 +0000
Subject: [issue13357] HTMLParser parses attributes incorrectly.
In-Reply-To: <1320609385.23.0.651998290333.issue13357@psf.upfronthosting.co.za>
Message-ID: <CACDSwDkG4J4ZWXpQTt+tYSSYYFwAgqcrZOUj+FVLBygNahq8cw@mail.gmail.com>


Michael Brooks <firealwaysworks at gmail.com> added the comment:

Python 2.7.3 is still affected by both of these issues.

On Sun, Nov 6, 2011 at 12:56 PM, Ezio Melotti <report at bugs.python.org>wrote:

>
> Ezio Melotti <ezio.melotti at gmail.com> added the comment:
>
> I mean 2.7.3 (i.e. the development version).
> You need to get a clone of Python as explained here:
> http://docs.python.org/devguide/
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue13357>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13357>
_______________________________________

From report at bugs.python.org  Sun Nov  6 21:27:12 2011
From: report at bugs.python.org (Florent Xicluna)
Date: Sun, 06 Nov 2011 20:27:12 +0000
Subject: [issue13356] test_logging warning on 2.7
In-Reply-To: <1320601981.59.0.630588677402.issue13356@psf.upfronthosting.co.za>
Message-ID: <1320611232.77.0.218704018374.issue13356@psf.upfronthosting.co.za>


Changes by Florent Xicluna <florent.xicluna at gmail.com>:


----------
dependencies: +UnicodeWarning raised on dict() and set()
nosy: +flox

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13356>
_______________________________________

From report at bugs.python.org  Sun Nov  6 21:46:08 2011
From: report at bugs.python.org (Florent Xicluna)
Date: Sun, 06 Nov 2011 20:46:08 +0000
Subject: [issue13360] UnicodeWarning raised on dict() and set()
In-Reply-To: <1320610932.39.0.0241525481536.issue13360@psf.upfronthosting.co.za>
Message-ID: <1320612368.6.0.963659023462.issue13360@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

Similar expressions where the warning is raised or not (depending on "latin-1" comparison):


$ python2.7 -c "print u'd\xe9' in {'foo', 'd\xe9r'}"
False
$ python2.7 -c "print u'd\xe9' in {'foo', 'd\xe9'}"
-c:1: UnicodeWarning: Unicode equal comparison failed to convert both arguments to Unicode - interpreting them as being unequal
False


$ python2.7 -c "print 'd\xe9r' in {u'foo', u'd\xe9'}"
False
$ python2.7 -c "print 'd\xe9'  in {u'foo', u'd\xe9'}"
-c:1: UnicodeWarning: Unicode equal comparison failed to convert both arguments to Unicode - interpreting them as being unequal
False

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13360>
_______________________________________

From report at bugs.python.org  Sun Nov  6 21:57:00 2011
From: report at bugs.python.org (Nathan Clayton)
Date: Sun, 06 Nov 2011 20:57:00 +0000
Subject: [issue10287] NNTP authentication should check capabilities
In-Reply-To: <1288648592.72.0.261739190945.issue10287@psf.upfronthosting.co.za>
Message-ID: <1320613020.09.0.398080176196.issue10287@psf.upfronthosting.co.za>


Nathan Clayton <nathanclayton at gmail.com> added the comment:

When using Easynews, it sends a 480 error (e.g. "nntplib.NNTPTemporaryError: 480 You must log in.")

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10287>
_______________________________________

From report at bugs.python.org  Sun Nov  6 22:02:54 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 06 Nov 2011 21:02:54 +0000
Subject: [issue7777] Support needed for AF_RDS family
In-Reply-To: <1264404460.15.0.913920533968.issue7777@psf.upfronthosting.co.za>
Message-ID: <1320613374.68.0.60833875778.issue7777@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Not having tests for the control messages is fine with me - we don't need to test Linux, but Python.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7777>
_______________________________________

From report at bugs.python.org  Sun Nov  6 22:23:02 2011
From: report at bugs.python.org (Florent Xicluna)
Date: Sun, 06 Nov 2011 21:23:02 +0000
Subject: [issue13356] test_logging warning on 2.7
In-Reply-To: <1320601981.59.0.630588677402.issue13356@psf.upfronthosting.co.za>
Message-ID: <1320614582.88.0.638250285315.issue13356@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

This is the expression which raises the warning.

>>> u'compiler.parser' in ['\xab\xd7\xbb', u'\u013f\xd6G']
__main__:1: UnicodeWarning: Unicode equal comparison failed to convert both arguments to Unicode - interpreting them as being unequal
False


See also issue #13360

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13356>
_______________________________________

From report at bugs.python.org  Sun Nov  6 22:23:50 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 06 Nov 2011 21:23:50 +0000
Subject: [issue13360] UnicodeWarning raised on dict() and set()
In-Reply-To: <1320610932.39.0.0241525481536.issue13360@psf.upfronthosting.co.za>
Message-ID: <1320614630.96.0.111355011819.issue13360@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

I fail to see the issue. What exactly is the problem with the warning? It looks all consistent and helpful to me.

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13360>
_______________________________________

From report at bugs.python.org  Sun Nov  6 22:43:12 2011
From: report at bugs.python.org (Florent Xicluna)
Date: Sun, 06 Nov 2011 21:43:12 +0000
Subject: [issue13360] UnicodeWarning raised on sequence and set comparisons
In-Reply-To: <1320610932.39.0.0241525481536.issue13360@psf.upfronthosting.co.za>
Message-ID: <1320615792.75.0.341796553059.issue13360@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

Often sequences or sets have heterogeneous keys, mixing <str> and <unicode>, and in this case there's no easy way to work with them without raising this UnicodeWarning.
The "logging" module is such an example.

Of course it is only a warning, not a strong annoyance.

----------
title: UnicodeWarning raised on dict() and set() -> UnicodeWarning raised on sequence and set comparisons

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13360>
_______________________________________

From report at bugs.python.org  Sun Nov  6 23:06:56 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 06 Nov 2011 22:06:56 +0000
Subject: [issue3932] HTMLParser cannot handle '&' and non-ascii characters in
	attribute names
In-Reply-To: <1222086790.7.0.800001604957.issue3932@psf.upfronthosting.co.za>
Message-ID: <1320617216.39.0.465373636123.issue3932@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

I'm not sure what is the best solution here.

unescape uses a regex with replaceEntities as callback to replace the entities in attribute values.
The problem is that replaceEntities currently returns unicode, and if unescape receives a str, an automatic coercion to unicode happens and an error is raised whenever the str is non-ascii.

The possible solutions are:
 1) Document the status quo (i.e replaceEntities always returns unicode, and an error is raised whenever a string that contains non-ascii chars is passed);
 2) Change replaceEntities to return str only for ascii chars (as the patch proposed by Zbigniew does).  This works as long as the entity resolves to an ascii character, but keep failing for the other cases.

The first option is cleaner, and means that if you want to parse something you should always use unicode, otherwise it might fail (In case of ambiguity, refuse the temptation to guess).
The second option might allow you to parse a few more documents without converting them to unicode, but only if you are lucky (i.e. you don't get any unicode mixed with non-ascii str).  If most of the entities in attributes resolve to ascii (e.g. &quote; &amp; &apos; &gt; &lt;), it might be more practical to return str and avoid unnecessary errors, while still adding a note in documentation that passing unicode is better.

----------
nosy: +ezio.melotti, r.david.murray
type:  -> behavior
versions:  -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3932>
_______________________________________

From report at bugs.python.org  Sun Nov  6 23:42:11 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 06 Nov 2011 22:42:11 +0000
Subject: [issue13353] documentation problem in
	logging.handlers.TimedRotatingFileHandler for 2.7
In-Reply-To: <1320549842.11.0.772766831495.issue13353@psf.upfronthosting.co.za>
Message-ID: <E1RNBPd-0002jU-9W@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 0b779988e8b7 by Vinay Sajip in branch '2.7':
Closes issue #13353: version doumentation about utc parameter corrected.
http://hg.python.org/cpython/rev/0b779988e8b7

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13353>
_______________________________________

From report at bugs.python.org  Sun Nov  6 23:44:07 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Sun, 06 Nov 2011 22:44:07 +0000
Subject: [issue13353] documentation problem in
	logging.handlers.TimedRotatingFileHandler for 2.7
In-Reply-To: <1320549842.11.0.772766831495.issue13353@psf.upfronthosting.co.za>
Message-ID: <1320619447.5.0.545930028972.issue13353@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/issue13353>
_______________________________________

From report at bugs.python.org  Sun Nov  6 23:45:30 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 06 Nov 2011 22:45:30 +0000
Subject: [issue3932] HTMLParser cannot handle '&' and non-ascii characters in
	attribute names
In-Reply-To: <1222086790.7.0.800001604957.issue3932@psf.upfronthosting.co.za>
Message-ID: <1320619530.15.0.135428143549.issue3932@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3932>
_______________________________________

From report at bugs.python.org  Sun Nov  6 23:46:38 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 06 Nov 2011 22:46:38 +0000
Subject: [issue13360] UnicodeWarning raised on sequence and set comparisons
In-Reply-To: <1320615792.75.0.341796553059.issue13360@psf.upfronthosting.co.za>
Message-ID: <4EB70E40.2020902@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> Often sequences or sets have heterogeneous keys, mixing <str> and
> <unicode>, and in this case there's no easy way to work with them
> without raising this UnicodeWarning.

That's a bug in the application. You must not mix byte strings
and unicode strings as dictionary keys. Whether or not the warning
is produced: the behavior would still be fairly unpredictable, and
vary with Python versions.

> Of course it is only a warning, not a strong annoyance.

This warning is deliberate. It tells the developer that something
is broken about this application.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13360>
_______________________________________

From report at bugs.python.org  Sun Nov  6 23:51:52 2011
From: report at bugs.python.org (David Fischer)
Date: Sun, 06 Nov 2011 22:51:52 +0000
Subject: [issue13323] urllib2 does not correctly handle
	multiple	www-authenticate headers in an HTTP response
In-Reply-To: <1320249966.17.0.892468926199.issue13323@psf.upfronthosting.co.za>
Message-ID: <1320619912.6.0.519804909195.issue13323@psf.upfronthosting.co.za>


David Fischer <djfische at gmail.com> added the comment:

With this patch, the AbstractBasicAuthHandler (and its subclasses) performs a regex search on the amalgamated "www-authenticate" header for basic authentication. 

This fixes the case where you have an HTTP response of the form:

HTTP/1.1 401 Authorization Required
Server: HTTPd/1.0
WWW-Authenticate: Basic realm="Secure Area"
WWW-Authenticate: SomethingElse realm="Alternative"
...

In the above case, AbstractBasicAuthHandler will attempt basic auth against the "Secure Area" realm.

----------
keywords: +patch
Added file: http://bugs.python.org/file23619/urllib2_basicauth.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13323>
_______________________________________

From report at bugs.python.org  Mon Nov  7 00:12:22 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Sun, 06 Nov 2011 23:12:22 +0000
Subject: [issue13356] test_logging warning on 2.7
In-Reply-To: <1320601981.59.0.630588677402.issue13356@psf.upfronthosting.co.za>
Message-ID: <1320621142.9.0.571674757754.issue13356@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

Thanks, Florent. This patch was by you in response to issue #8201 - do you have any suggestion as to the best way to resolve this? I tried changing the non-ASCII logger to '\xc3\xb4\xc3\xbc', which decodes cleanly to u'\xf4\xfc' (o-circumflex u-umlaut), but it apparently still fails to convert to Unicode when doing the comparison, and so still raises the warning. Is there any byte-string sequence which won't give the error in this circumstance? Obviously I could convert it to Unicode, but then the test is checking correct operation when you have a non-ASCII (byte-)string name as well as a Unicode name for loggers.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13356>
_______________________________________

From report at bugs.python.org  Mon Nov  7 00:24:45 2011
From: report at bugs.python.org (Florent Xicluna)
Date: Sun, 06 Nov 2011 23:24:45 +0000
Subject: [issue13356] test_logging warning on 2.7
In-Reply-To: <1320601981.59.0.630588677402.issue13356@psf.upfronthosting.co.za>
Message-ID: <1320621885.96.0.0544453467349.issue13356@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

I suggest to use encoded string as keys in loggerDict.
It should solve both issue #8201 and this one.
Moreover, it seems in line with msg147191 from Martin on issue #13360.

Patch attached.

----------
components: +Unicode
dependencies:  -UnicodeWarning raised on sequence and set comparisons
keywords: +patch
stage: needs patch -> patch review
Added file: http://bugs.python.org/file23620/issue13356_logging.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13356>
_______________________________________

From report at bugs.python.org  Mon Nov  7 00:46:25 2011
From: report at bugs.python.org (Florent Xicluna)
Date: Sun, 06 Nov 2011 23:46:25 +0000
Subject: [issue13361] getLogger does not check its argument
Message-ID: <1320623185.48.0.617067061365.issue13361@psf.upfronthosting.co.za>


New submission from Florent Xicluna <florent.xicluna at gmail.com>:

>>> import logging
>>> log = logging.getLogger(any)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "./Lib/logging/__init__.py", line 1730, in getLogger
    return Logger.manager.getLogger(name)
  File "./Lib/logging/__init__.py", line 1114, in getLogger
    self._fixupParents(rv)
  File "./Lib/logging/__init__.py", line 1142, in _fixupParents
    i = name.rfind(".")
AttributeError: 'builtin_function_or_method' object has no attribute 'rfind'
>>> log = logging.getLogger(any)
>>> log.error("It should not create this logger")
It should not create this logger
>>>

----------
components: Library (Lib)
messages: 147196
nosy: flox
priority: normal
severity: normal
stage: needs patch
status: open
title: getLogger does not check its argument
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13361>
_______________________________________

From report at bugs.python.org  Mon Nov  7 00:47:02 2011
From: report at bugs.python.org (Florent Xicluna)
Date: Sun, 06 Nov 2011 23:47:02 +0000
Subject: [issue13361] getLogger does not check its argument
In-Reply-To: <1320623185.48.0.617067061365.issue13361@psf.upfronthosting.co.za>
Message-ID: <1320623222.52.0.437273208274.issue13361@psf.upfronthosting.co.za>


Changes by Florent Xicluna <florent.xicluna at gmail.com>:


----------
nosy: +vinay.sajip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13361>
_______________________________________

From report at bugs.python.org  Mon Nov  7 03:38:34 2011
From: report at bugs.python.org (Florent Xicluna)
Date: Mon, 07 Nov 2011 02:38:34 +0000
Subject: [issue583975] gethostbyaddr lag
Message-ID: <1320633514.69.0.982399178171.issue583975@psf.upfronthosting.co.za>


Changes by Florent Xicluna <florent.xicluna at gmail.com>:


----------
nosy: +flox

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue583975>
_______________________________________

From report at bugs.python.org  Mon Nov  7 04:03:50 2011
From: report at bugs.python.org (skreft)
Date: Mon, 07 Nov 2011 03:03:50 +0000
Subject: [issue13362] Many PEP 8 errors
Message-ID: <1320635030.75.0.479982438805.issue13362@psf.upfronthosting.co.za>


New submission from skreft <skreft at gmail.com>:

Hi all, I was reading Python's source code and was surprised to find many PEP 8 errors.

The file that I found specially non PEP8 compliant is Lib/encodings/punnycode.py, but there are many others that are not compliant.

I think that this issue should be addressed, since Python's source code should be the model for good Pythonic code.

I would love to contribute on this topic. But since many files would be modified I don't know how to proceed. I see two things that could help to reduce the non compliance of the code. One is to have a website showing the non compliances of each file. And the one I like the most is to have a special test that checks the compliance of the code. The only problem is that it would rely on the external tool pep8 (http://pypi.python.org/pypi/pep8).

Let me know what you think.

Sebastian

----------
messages: 147197
nosy: skreft
priority: normal
severity: normal
status: open
title: Many PEP 8 errors
versions: Python 2.7, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13362>
_______________________________________

From report at bugs.python.org  Mon Nov  7 04:08:26 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 07 Nov 2011 03:08:26 +0000
Subject: [issue13362] Many PEP 8 errors
In-Reply-To: <1320635030.75.0.479982438805.issue13362@psf.upfronthosting.co.za>
Message-ID: <1320635306.07.0.571774739134.issue13362@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Generally, we don't do style cleanups for the sake of style cleanups.

----------
nosy: +benjamin.peterson
resolution:  -> rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13362>
_______________________________________

From report at bugs.python.org  Mon Nov  7 04:11:56 2011
From: report at bugs.python.org (skreft)
Date: Mon, 07 Nov 2011 03:11:56 +0000
Subject: [issue13363] Many usages of dict.keys(), dict.values(),
	dict.items() when the iter version could be used
Message-ID: <1320635516.59.0.95929031171.issue13363@psf.upfronthosting.co.za>


New submission from skreft <skreft at gmail.com>:

In Python 2.7, there are many patterns of the form

for x in mapping.(keys()|values()|items()):
    #code
when the iterator version of those method could be used.
Is there any reason for using those methods?

I see that in some other parts of the code the iterator version is used. Here is the summary:

       Non iter version Iter version
Keys   160              21 
Values 35               23
Items  249              79

I sued the following command

$ egrep -R "for.*[.]iterkeys\(\)" . | wc -l 


What's the position about this? Does it worth it to fix this?

----------
messages: 147199
nosy: skreft
priority: normal
severity: normal
status: open
title: Many usages of dict.keys(), dict.values(), dict.items() when the iter version could be used
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13363>
_______________________________________

From report at bugs.python.org  Mon Nov  7 04:31:01 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Mon, 07 Nov 2011 03:31:01 +0000
Subject: [issue13283] removal of two unused variable in locale.py
In-Reply-To: <1319796863.15.0.791142726242.issue13283@psf.upfronthosting.co.za>
Message-ID: <1320636661.68.0.457501386914.issue13283@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

?ric, thanks for paying attention to this. In this particular case, I checked the code and verified that the variables were not used anywhere. But I will comply with the policy in the future.

Thanks again for pointing out.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13283>
_______________________________________

From report at bugs.python.org  Mon Nov  7 06:14:44 2011
From: report at bugs.python.org (skreft)
Date: Mon, 07 Nov 2011 05:14:44 +0000
Subject: [issue13364] Duplicated Code
Message-ID: <1320642884.85.0.545330791342.issue13364@psf.upfronthosting.co.za>


New submission from skreft <skreft at gmail.com>:

By using tools like clonedigger is possible to spot some repeated code.
One file that caught my attention is Lib/decimal.py. It has many portions of duplicated code. 

Here is an example:
def logical_or(self, other, context=None):
        """Applies an 'or' operation between self and other's digits."""
        if context is None:
            context = getcontext()

        other = _convert_other(other, raiseit=True)

        if not self._islogical() or not other._islogical():
            return context._raise_error(InvalidOperation)

        # fill to context.prec
        (opa, opb) = self._fill_logical(context, self._int, other._int)

        # make the operation, and clean starting zeroes
        result = "".join([str(int(a)|int(b)) for a,b in zip(opa,opb)])
        return _dec_from_triple(0, result.lstrip('0') or '0', 0)

    def logical_xor(self, other, context=None):
        """Applies an 'xor' operation between self and other's digits."""
        if context is None:
            context = getcontext()

        other = _convert_other(other, raiseit=True)

        if not self._islogical() or not other._islogical():
            return context._raise_error(InvalidOperation)

        # fill to context.prec
        (opa, opb) = self._fill_logical(context, self._int, other._int)

        # make the operation, and clean starting zeroes
        result = "".join([str(int(a)^int(b)) for a,b in zip(opa,opb)])
        return _dec_from_triple(0, result.lstrip('0') or '0', 0)


What's the posture about this? Should this be fixed?

ps: Even more duplicated code is found in python 2.7.

----------
messages: 147201
nosy: skreft
priority: normal
severity: normal
status: open
title: Duplicated Code
versions: Python 2.7, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13364>
_______________________________________

From report at bugs.python.org  Mon Nov  7 06:22:34 2011
From: report at bugs.python.org (skreft)
Date: Mon, 07 Nov 2011 05:22:34 +0000
Subject: [issue13362] Many PEP 8 errors
In-Reply-To: <1320635030.75.0.479982438805.issue13362@psf.upfronthosting.co.za>
Message-ID: <1320643354.54.0.319680461208.issue13362@psf.upfronthosting.co.za>


skreft <skreft at gmail.com> added the comment:

Hi all again:

in the original posting of this issue,  I asked what would be the best way to address this issue. Additionally I proposed to use existing tools to check the current code. These tools could be easily added to the tests in a non failing mode, so developers who modify the code, could know that the source code does not follow the coding style and probably she/he could improve the code. This tool would also help newcomers to contribute better code.

Unfortunately, by the decision of rejecting this issue without even answering the full issue, I conclude that the Python team is not willing to improve its own basecode.

I repeat my posture, python source code should be a model of a python project, hence if there are tools that can ensure or improve the quality of the project, they should be incorporated to the development process.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13362>
_______________________________________

From report at bugs.python.org  Mon Nov  7 06:45:58 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 07 Nov 2011 05:45:58 +0000
Subject: [issue13357] HTMLParser parses attributes incorrectly.
In-Reply-To: <1320606546.64.0.752508532419.issue13357@psf.upfronthosting.co.za>
Message-ID: <1320644758.21.0.529558298722.issue13357@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
priority: normal -> high

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13357>
_______________________________________

From report at bugs.python.org  Mon Nov  7 06:53:35 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 07 Nov 2011 05:53:35 +0000
Subject: [issue13362] Many PEP 8 errors
In-Reply-To: <1320635030.75.0.479982438805.issue13362@psf.upfronthosting.co.za>
Message-ID: <1320645215.73.0.586377539985.issue13362@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

I concur with Benjamin.

This is a waste of time and a potential source of new errors.

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13362>
_______________________________________

From report at bugs.python.org  Mon Nov  7 07:41:17 2011
From: report at bugs.python.org (Ned Deily)
Date: Mon, 07 Nov 2011 06:41:17 +0000
Subject: [issue13363] Many usages of dict.keys(), dict.values(),
	dict.items() when the iter version could be used
In-Reply-To: <1320635516.59.0.95929031171.issue13363@psf.upfronthosting.co.za>
Message-ID: <1320648077.92.0.0310298769275.issue13363@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Thanks for you interest in improving Python. As noted in the response to one of your other issues, we generally do not do style cleanups just for the sake of style cleanups.  In addition, our policy for current maintenance branches, like Python 2.7, is to apply bug fixes only.  As there will be no further feature releases for Python 2, anything other than a bug fix would only be a candidate for the next Python 3 release (Python 3.3).

See the Python Developer's Guide for more information:
http://docs.python.org/devguide/devcycle.html#maintenance-branches

----------
nosy: +ned.deily
resolution:  -> rejected
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13363>
_______________________________________

From report at bugs.python.org  Mon Nov  7 07:53:30 2011
From: report at bugs.python.org (David Townshend)
Date: Mon, 07 Nov 2011 06:53:30 +0000
Subject: [issue12760] Add create mode to open()
In-Reply-To: <1313502559.06.0.415498401391.issue12760@psf.upfronthosting.co.za>
Message-ID: <1320648810.3.0.643250137336.issue12760@psf.upfronthosting.co.za>


David Townshend <aquavitae69 at gmail.com> added the comment:

It is already possible to write a wrapper function that does it:

def create(file):
    fd = os.open(file, os.O_EXCL | os.O_CREAT | os.O_WRONLY)
    return os.fdopen(fd)

The point it not that it can't be done, but that it is not straight forward.  The docs say this about os.open(): "This function is intended for low-level I/O. For normal usage, use the built-in function open()" 

I wouldn't call creating a new file low-level I/O, but it is normal usage.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12760>
_______________________________________

From report at bugs.python.org  Mon Nov  7 08:04:13 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 07 Nov 2011 07:04:13 +0000
Subject: [issue13364] Duplicated Code
In-Reply-To: <1320642884.85.0.545330791342.issue13364@psf.upfronthosting.co.za>
Message-ID: <1320649453.89.0.444259784676.issue13364@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

How would you suggest refactoring this?

For that example, I'd prefer not to remove the repetition;  as it is, the code is clean and clear.  Eliminating the repetition would involve adding an extra layer of indirection, making the code in one of these functions harder to follow.

----------
nosy: +mark.dickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13364>
_______________________________________

From report at bugs.python.org  Mon Nov  7 08:19:05 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 07 Nov 2011 07:19:05 +0000
Subject: [issue13349] Uninformal error message in index() and remove()
	functions
In-Reply-To: <1320526177.89.0.678573577515.issue13349@psf.upfronthosting.co.za>
Message-ID: <1320650345.42.0.451347162796.issue13349@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13349>
_______________________________________

From report at bugs.python.org  Mon Nov  7 08:31:20 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 07 Nov 2011 07:31:20 +0000
Subject: [issue3932] HTMLParser cannot handle '&' and non-ascii characters in
	attribute names
In-Reply-To: <1222086790.7.0.800001604957.issue3932@psf.upfronthosting.co.za>
Message-ID: <1320651080.59.0.52544490592.issue3932@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
stage:  -> needs patch
Added file: http://bugs.python.org/file23621/issue3932-test.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3932>
_______________________________________

From report at bugs.python.org  Mon Nov  7 08:39:05 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 07 Nov 2011 07:39:05 +0000
Subject: [issue13362] Many PEP 8 errors
In-Reply-To: <1320635030.75.0.479982438805.issue13362@psf.upfronthosting.co.za>
Message-ID: <1320651545.84.0.00129980654175.issue13362@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

skreft: I can see nothing wrong by having a website that lists PEP 8 violations in the standard library - feel free to create one on wiki.python.org.

Your preferred solution of having automated tests is not feasible. Taking punycode.py (sic) as an example (of which I'm the author): I disagree with some of the warnings that the tool produces (and hence I probably disagree with parts of PEP 8 also). The warnings I agree with (about missing space characters), I also agree with Benjamin and Raymond: we shouldn't fix these in the code, since that would clutter the version history of the file (suggesting that it was modified when there wasn't any substantial change). The same reasoning probably applies to many other "violations".

When you said that punycode.py violates PEP 8, I was concerned. Then seeing the actual complaints of the tool make me laugh, since they are *really* micrological, when I was expecting substantial problems.

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13362>
_______________________________________

From report at bugs.python.org  Mon Nov  7 08:42:50 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 07 Nov 2011 07:42:50 +0000
Subject: [issue13363] Many usages of dict.keys(), dict.values(),
	dict.items() when the iter version could be used
In-Reply-To: <1320635516.59.0.95929031171.issue13363@psf.upfronthosting.co.za>
Message-ID: <1320651770.98.0.507443319783.issue13363@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

skreft: since you were asking for a reason why the code looks the way it looks - the code in many cases predates the introduction of iterkeys and friends.

I personally find the names iterkeys/itervalues/iteritems fairly ugly, and rather avoid them for prettiness reasons, unless there is a real problem that requires using iterators. Thankfully, the issue was resolved in Python 3, where .keys() does the right thing (i.e. returning a view).

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13363>
_______________________________________

From report at bugs.python.org  Mon Nov  7 09:12:47 2011
From: report at bugs.python.org (skreft)
Date: Mon, 07 Nov 2011 08:12:47 +0000
Subject: [issue13364] Duplicated Code
In-Reply-To: <1320642884.85.0.545330791342.issue13364@psf.upfronthosting.co.za>
Message-ID: <1320653567.52.0.825657851554.issue13364@psf.upfronthosting.co.za>


skreft <skreft at gmail.com> added the comment:

One possible refactor would be.

import operator

   def logical_or(self, other, context=None):
       return self._logical_op(other, operator.__or__, context)

   def logical_xor(self, other, context=None):
       return self._logical_op(other, operator.__xor__, context)

   def logical_and(self, other, context=None):
       return self._logical_op(other, operator.__and__, context)

   def _logical_op(self, other, operation, context=None):
        """Applies a logical operation between self and other's digits."""
        if context is None:
            context = getcontext()

        other = _convert_other(other, raiseit=True)

        if not self._islogical() or not other._islogical():
            return context._raise_error(InvalidOperation)

        # fill to context.prec
        (opa, opb) = self._fill_logical(context, self._int, other._int)

        # make the operation, and clean starting zeroes
        result = "".join([str(operation(int(a), int(b))) for a,b in zip(opa,opb)])
        return _dec_from_triple(0, result.lstrip('0') or '0', 0)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13364>
_______________________________________

From report at bugs.python.org  Mon Nov  7 09:53:37 2011
From: report at bugs.python.org (Florent Xicluna)
Date: Mon, 07 Nov 2011 08:53:37 +0000
Subject: [issue13361] getLogger does not check its argument
In-Reply-To: <1320623185.48.0.617067061365.issue13361@psf.upfronthosting.co.za>
Message-ID: <1320656017.72.0.97315041292.issue13361@psf.upfronthosting.co.za>


Changes by Florent Xicluna <florent.xicluna at gmail.com>:


----------
keywords: +patch
Added file: http://bugs.python.org/file23622/issue13361_check.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13361>
_______________________________________

From report at bugs.python.org  Mon Nov  7 09:55:14 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 07 Nov 2011 08:55:14 +0000
Subject: [issue13356] test_logging warning on 2.7
In-Reply-To: <1320601981.59.0.630588677402.issue13356@psf.upfronthosting.co.za>
Message-ID: <E1RNKys-0002nh-F6@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 8726ad774cf0 by Vinay Sajip in branch '2.7':
Closes #13356. Thanks to Florent Xicluna for the patch.
http://hg.python.org/cpython/rev/8726ad774cf0

----------
nosy: +python-dev
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13356>
_______________________________________

From report at bugs.python.org  Mon Nov  7 09:55:15 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 07 Nov 2011 08:55:15 +0000
Subject: [issue13361] getLogger does not check its argument
In-Reply-To: <1320623185.48.0.617067061365.issue13361@psf.upfronthosting.co.za>
Message-ID: <E1RNKys-0002nh-F1@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 8c719e106694 by Vinay Sajip in branch 'default':
Merged fix for #13361 from 3.2.
http://hg.python.org/cpython/rev/8c719e106694

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13361>
_______________________________________

From report at bugs.python.org  Mon Nov  7 09:56:38 2011
From: report at bugs.python.org (Florent Xicluna)
Date: Mon, 07 Nov 2011 08:56:38 +0000
Subject: [issue13361] getLogger does not check its argument
In-Reply-To: <1320623185.48.0.617067061365.issue13361@psf.upfronthosting.co.za>
Message-ID: <1320656198.69.0.217742929107.issue13361@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

I've uploaded two proposals:
 - first with isinstance(name, str)
 - second which is more duck-friendly

Personally, I like ducks.

----------
stage: needs patch -> patch review
Added file: http://bugs.python.org/file23623/issue13361_dont_check.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13361>
_______________________________________

From report at bugs.python.org  Mon Nov  7 10:00:33 2011
From: report at bugs.python.org (Florent Xicluna)
Date: Mon, 07 Nov 2011 09:00:33 +0000
Subject: [issue13361] getLogger does not check its argument
In-Reply-To: <1320623185.48.0.617067061365.issue13361@psf.upfronthosting.co.za>
Message-ID: <1320656433.65.0.46395052857.issue13361@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

btw, changeset a3ba905447ba does not fix the case for:

import logging
log = logging.Logger(any)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13361>
_______________________________________

From report at bugs.python.org  Mon Nov  7 10:12:08 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Mon, 07 Nov 2011 09:12:08 +0000
Subject: [issue13361] getLogger does not check its argument
In-Reply-To: <1320623185.48.0.617067061365.issue13361@psf.upfronthosting.co.za>
Message-ID: <1320657128.33.0.560379605435.issue13361@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

@Florent: Sorry, I didn't see your patch, for some reason. But I would say:

1. I agree that where I put the check (logging.getLogger) does not catch the case where someone instantiates the logger directly (using logging.Logger(any)), but users aren't supposed to instantiate loggers directly anyway - this would not result in a working logger. The check is in the same place where (in 2.7) we check for Unicode and encode to bytes.

2. I don't want to be too liberal in accepting logger names, since they are intended to mean "a place in the application". So, accepting anything other than text does not seem right to me - so str for 3.x, str or unicode for 2.x.

3. I thought a single test (passing in a invalid type) would be sufficient for the logging code, ISTM adding tests with lots of types is actually testing isinstance ;-)

4. I didn't notice your patch, and hence goofed in raising a ValueError instead of (correctly as you had it) a TypeError. I will rectify this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13361>
_______________________________________

From report at bugs.python.org  Mon Nov  7 11:08:52 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Mon, 07 Nov 2011 10:08:52 +0000
Subject: [issue13349] Uninformal error message in index() and remove()
	functions
In-Reply-To: <1320526177.89.0.678573577515.issue13349@psf.upfronthosting.co.za>
Message-ID: <1320660532.38.0.380013415211.issue13349@psf.upfronthosting.co.za>


Petri Lehtinen <petri at digip.org> added the comment:

The good thing about this is ease of debugging. You can see which is the offending value that was not found.

On the other hand, the repr of a value might be very long:

>>> [].index(list(range(1000)))
ValueError: [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, ...
(many lines of numbers)
997, 998, 999] is not in list

Also, all values don't have a very informal repr:

>>> class Foo: pass
...
>>> [].index(Foo())
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: <__main__.Foo object at 0xb736f92c> is not in list

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13349>
_______________________________________

From report at bugs.python.org  Mon Nov  7 11:16:21 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 07 Nov 2011 10:16:21 +0000
Subject: [issue13361] getLogger does not check its argument
In-Reply-To: <1320623185.48.0.617067061365.issue13361@psf.upfronthosting.co.za>
Message-ID: <E1RNMFP-0001B5-Va@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 60dd1568bbd1 by Vinay Sajip in branch '2.7':
Closes #13361: Raise correct exception type.
http://hg.python.org/cpython/rev/60dd1568bbd1

New changeset bc05c11b340e by Vinay Sajip in branch '3.2':
Closes #13361: Raise correct exception type.
http://hg.python.org/cpython/rev/bc05c11b340e

New changeset fb73fe5d0ab1 by Vinay Sajip in branch 'default':
Closes #13361: Merge fix from 3.2.
http://hg.python.org/cpython/rev/fb73fe5d0ab1

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13361>
_______________________________________

From report at bugs.python.org  Mon Nov  7 11:54:49 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 07 Nov 2011 10:54:49 +0000
Subject: [issue4489] shutil.rmtree is vulnerable to a symlink attack
In-Reply-To: <1228232522.58.0.0992151848245.issue4489@psf.upfronthosting.co.za>
Message-ID: <1320663289.42.0.660482677523.issue4489@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> I think the best thing would be to let rmtree fail (provided it closes 
> all the FDs it opened)

Agreed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4489>
_______________________________________

From report at bugs.python.org  Mon Nov  7 13:28:57 2011
From: report at bugs.python.org (Chandra Sekhar Reddy)
Date: Mon, 07 Nov 2011 12:28:57 +0000
Subject: [issue13335] Service application hang in python25.dll
In-Reply-To: <1320324829.1.0.613797933132.issue13335@psf.upfronthosting.co.za>
Message-ID: <1320668937.02.0.95025375656.issue13335@psf.upfronthosting.co.za>


Chandra Sekhar Reddy <sanch09 at ca.com> added the comment:

Hi Amaury and Terry,

Thanks for your feedback, actually the product that we have delivered to customer is now in support phase, so currently there is no development going on, so we cannot use the latest python. 

It would be of great help if you could provide your inputs by looking at the process call stack. So that I can proceed further.

>From the call stack the function appears to be like memory allocation related functions from python module. Is it possible for a process to hang if memory request to OS is not satisfied.

Awaiting for your valuable inputs,
-Chandra

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13335>
_______________________________________

From report at bugs.python.org  Mon Nov  7 13:44:46 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 07 Nov 2011 12:44:46 +0000
Subject: [issue13335] Service application hang in python25.dll
In-Reply-To: <1320324829.1.0.613797933132.issue13335@psf.upfronthosting.co.za>
Message-ID: <1320669886.24.0.629166743292.issue13335@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Unfortunately there is not much in the process call stack: the creation of a list (PyList_New) needs to allocate some memory (not much: sizeof(PyListObject) + gc overhead, probably 32 bytes).

If the system malloc() function fails and returns NULL, Python will raise a MemoryError.  But if malloc() blocks and freezes the process, there is not much Python can do.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13335>
_______________________________________

From report at bugs.python.org  Mon Nov  7 14:01:33 2011
From: report at bugs.python.org (John Feuerstein)
Date: Mon, 07 Nov 2011 13:01:33 +0000
Subject: [issue12567] curses implementation of Unicode is wrong in Python 3
In-Reply-To: <1310682817.11.0.980195084883.issue12567@psf.upfronthosting.co.za>
Message-ID: <1320670893.18.0.651640378195.issue12567@psf.upfronthosting.co.za>


Changes by John Feuerstein <john at feurix.com>:


----------
nosy: +john.feuerstein

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12567>
_______________________________________

From report at bugs.python.org  Mon Nov  7 14:54:59 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 07 Nov 2011 13:54:59 +0000
Subject: [issue13362] Many PEP 8 errors
In-Reply-To: <1320643354.54.0.319680461208.issue13362@psf.upfronthosting.co.za>
Message-ID: <CAPZV6o-7YgBu-4Morwy3bTUi3gbQwzshfYaddcEoC18h0QALrA@mail.gmail.com>


Benjamin Peterson <benjamin at python.org> added the comment:

2011/11/7 skreft <report at bugs.python.org>:
>
> skreft <skreft at gmail.com> added the comment:
>
> Hi all again:
>
> in the original posting of this issue, ?I asked what would be the best way to address this issue. Additionally I proposed to use existing tools to check the current code. These tools could be easily added to the tests in a non failing mode, so developers who modify the code, could know that the source code does not follow the coding style and probably she/he could improve the code. This tool would also help newcomers to contribute better code.
>
> Unfortunately, by the decision of rejecting this issue without even answering the full issue, I conclude that the Python team is not willing to improve its own basecode.
>
> I repeat my posture, python source code should be a model of a python project, hence if there are tools that can ensure or improve the quality of the project, they should be incorporated to the development process.

It can be cleaned up and modernized as it is changed for some other
purpose. Ultimately, it doesn't matter in the least bit how many lines
are between inline comments and other code, which seems to be
principally what pep8.py cares about in Lib/*.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13362>
_______________________________________

From report at bugs.python.org  Mon Nov  7 14:58:38 2011
From: report at bugs.python.org (John Feuerstein)
Date: Mon, 07 Nov 2011 13:58:38 +0000
Subject: [issue13152] textwrap: support custom tabsize
In-Reply-To: <1318338300.67.0.514985359705.issue13152@psf.upfronthosting.co.za>
Message-ID: <1320674318.55.0.0111554443242.issue13152@psf.upfronthosting.co.za>


John Feuerstein <john at feurix.com> added the comment:

textwrap_tabsize_v2.diff:

* Moved the tabsize parameter to the end of the parameter list
* Added documentation update
* Made the test case more obvious

----------
Added file: http://bugs.python.org/file23624/textwrap_tabsize_v2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13152>
_______________________________________

From report at bugs.python.org  Mon Nov  7 15:23:05 2011
From: report at bugs.python.org (John Feuerstein)
Date: Mon, 07 Nov 2011 14:23:05 +0000
Subject: [issue13365] str.expandtabs documentation is wrong
Message-ID: <1320675785.8.0.972158739581.issue13365@psf.upfronthosting.co.za>


New submission from John Feuerstein <john at feurix.com>:

The documentation for str.expandtabs([tabsize]) is wrong:
 
"Return a copy of the string where all tab characters are replaced by one or more spaces, depending on the current column and the given tab size. [...]"

This should read "zero or more spaces":

>>> 'a\tb'.expandtabs(0)
'ab'
>>> 'a\tb'.expandtabs(-1)
'ab'

The description in Objects/unicodeobject.c does not include this error.

----------
assignee: docs at python
components: Documentation
files: expandtabs_doc.diff
keywords: patch
messages: 147222
nosy: docs at python, john.feuerstein
priority: normal
severity: normal
status: open
title: str.expandtabs documentation is wrong
versions: Python 3.3
Added file: http://bugs.python.org/file23625/expandtabs_doc.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13365>
_______________________________________

From report at bugs.python.org  Mon Nov  7 15:46:27 2011
From: report at bugs.python.org (Michael Brooks)
Date: Mon, 07 Nov 2011 14:46:27 +0000
Subject: [issue13358] HTMLParser incorrectly handles cdata elements.
In-Reply-To: <CACDSwDkqg9RHhdoB3grZTT5z6VxQ8MtX8LWD6SOXPCvMMr6g+w@mail.gmail.com>
Message-ID: <CACDSwD=tCRJGbSXFtpnWdxsTZG4mAMDCrnnq2h3X=dvGUX9AYA@mail.gmail.com>


Michael Brooks <firealwaysworks at gmail.com> added the comment:

This one should also have a priority change. Tested python 2.7.3

--MIke

On Sun, Nov 6, 2011 at 12:54 PM, Michael Brooks <report at bugs.python.org>wrote:

>
> Michael Brooks <firealwaysworks at gmail.com> added the comment:
>
> Yes I am running python 2.7.2.
>
> On Sun, Nov 6, 2011 at 12:52 PM, Ezio Melotti <report at bugs.python.org
> >wrote:
>
> >
> > Ezio Melotti <ezio.melotti at gmail.com> added the comment:
> >
> > Have you tried with the latest 2.7? (see msg147170)
> >
> > ----------
> > nosy: +ezio.melotti
> > stage:  -> test needed
> >
> > _______________________________________
> > Python tracker <report at bugs.python.org>
> > <http://bugs.python.org/issue13358>
> > _______________________________________
> >
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue13358>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13358>
_______________________________________

From report at bugs.python.org  Mon Nov  7 15:47:08 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Mon, 07 Nov 2011 14:47:08 +0000
Subject: [issue13365] str.expandtabs documentation is wrong
In-Reply-To: <1320675785.8.0.972158739581.issue13365@psf.upfronthosting.co.za>
Message-ID: <1320677228.91.0.454115105781.issue13365@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

While we're at it, wouldn't it be clearer to say "... where each tab character is replaced by..."?

----------
nosy: +eli.bendersky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13365>
_______________________________________

From report at bugs.python.org  Mon Nov  7 15:48:07 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Mon, 07 Nov 2011 14:48:07 +0000
Subject: [issue6397] Implementing Solaris "/dev/poll" in the "select" module
In-Reply-To: <1246466955.08.0.134631976531.issue6397@psf.upfronthosting.co.za>
Message-ID: <1320677287.84.0.154198950913.issue6397@psf.upfronthosting.co.za>


Changes by Jes?s Cea Avi?n <jcea at jcea.es>:


Removed file: http://bugs.python.org/file23532/0b701eb5e9e3.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6397>
_______________________________________

From report at bugs.python.org  Mon Nov  7 15:49:03 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Mon, 07 Nov 2011 14:49:03 +0000
Subject: [issue6397] Implementing Solaris "/dev/poll" in the "select" module
In-Reply-To: <1246466955.08.0.134631976531.issue6397@psf.upfronthosting.co.za>
Message-ID: <1320677343.44.0.101997681874.issue6397@psf.upfronthosting.co.za>


Changes by Jes?s Cea Avi?n <jcea at jcea.es>:


Added file: http://bugs.python.org/file23626/528fdd816160.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6397>
_______________________________________

From report at bugs.python.org  Mon Nov  7 15:50:08 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Mon, 07 Nov 2011 14:50:08 +0000
Subject: [issue13365] str.expandtabs documentation is wrong
In-Reply-To: <1320675785.8.0.972158739581.issue13365@psf.upfronthosting.co.za>
Message-ID: <1320677408.31.0.439393654771.issue13365@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

Other than that, the patch looks good.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13365>
_______________________________________

From report at bugs.python.org  Mon Nov  7 15:56:49 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Mon, 07 Nov 2011 14:56:49 +0000
Subject: [issue6397] Implementing Solaris "/dev/poll" in the "select" module
In-Reply-To: <1246466955.08.0.134631976531.issue6397@psf.upfronthosting.co.za>
Message-ID: <1320677809.47.0.331406536948.issue6397@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

Please, review.

With current code, each devpoll object has capacity for managing 256 fds, by default. This is about 2048 bytes. The cost seems reasonable, since a normal program will have only a few devpoll objects around. I have considered an optional parameter to tune this, but interaction with rlimit is messy. Even if we manage 65536 fds, the memory cost is about 512Kbytes per devpoll, and you surely can affort it if you are actually managing 65536 descriptors...

The code is not threadsafe. It doesn't crash, but concurrent use of a devpoll has undefined results.

Please, review for integration.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6397>
_______________________________________

From report at bugs.python.org  Mon Nov  7 15:59:00 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 07 Nov 2011 14:59:00 +0000
Subject: [issue13224] Change str(class) to return only the class name
In-Reply-To: <1319053532.35.0.636674659737.issue13224@psf.upfronthosting.co.za>
Message-ID: <1320677940.83.0.932364807607.issue13224@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I misreported: dict.update is actually okay, but collections.Counter.update (a Python method) is a not an unbound method but a function (py3k-style).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13224>
_______________________________________

From report at bugs.python.org  Mon Nov  7 16:05:24 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 07 Nov 2011 15:05:24 +0000
Subject: [issue6397] Implementing Solaris "/dev/poll" in the "select" module
In-Reply-To: <1246466955.08.0.134631976531.issue6397@psf.upfronthosting.co.za>
Message-ID: <1320678324.16.0.891575735941.issue6397@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/issue6397>
_______________________________________

From report at bugs.python.org  Mon Nov  7 16:22:08 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Mon, 07 Nov 2011 15:22:08 +0000
Subject: [issue13193] test_packaging and test_distutils failures
In-Reply-To: <1318800293.23.0.0737706148876.issue13193@psf.upfronthosting.co.za>
Message-ID: <1320679328.49.0.509398297425.issue13193@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

Re. Paul Moore's comment - IMO he's right about the problem, but changing only packaging.manifest._translate_pattern doesn't do it. The equivalent fix has to be made in distutils.filelist.translate_pattern. I've made the change in the pythonv branch, and the test no longer fails.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13193>
_______________________________________

From report at bugs.python.org  Mon Nov  7 16:26:57 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 07 Nov 2011 15:26:57 +0000
Subject: [issue7071] distutils and IronPython compatibility
In-Reply-To: <1254827503.56.0.590175679082.issue7071@psf.upfronthosting.co.za>
Message-ID: <1320679617.74.0.54448860074.issue7071@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I think this change was wrong.  Please see my rationale in http://bugs.python.org/issue12119.

(BTW, I?d be surprised if byte compilation was the only compat issue with distutils and IronPython.  For a start, sys.version[:3] is used to get the version number.  I should be able to get Mono and IronPython in a few weeks or months and see how much issues there are in distutils and distutils2.)

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7071>
_______________________________________

From report at bugs.python.org  Mon Nov  7 16:27:04 2011
From: report at bugs.python.org (Darren Dale)
Date: Mon, 07 Nov 2011 15:27:04 +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: <1320679624.81.0.597632286824.issue11610@psf.upfronthosting.co.za>


Darren Dale <dsdale24 at gmail.com> added the comment:

I just double-checked that the unit tests do not raise any warnings with this patch.

Can it be merged?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11610>
_______________________________________

From report at bugs.python.org  Mon Nov  7 16:38:46 2011
From: report at bugs.python.org (Jon Bryan)
Date: Mon, 07 Nov 2011 15:38:46 +0000
Subject: [issue13345] Invisible Files in Windows 7
In-Reply-To: <1320505886.08.0.490350674026.issue13345@psf.upfronthosting.co.za>
Message-ID: <1998E82D8A41D54D8D9992433169504457E6C2@EXMB02.srn.sandia.gov>


Jon Bryan <jrbryan at sandia.gov> added the comment:

Thanks for the suggestions.

Since I can put the OEM-supplied DLL in another directory and everything works just fine, I'm not going to spend any more time on it.  I assume that it's something to do with file permissions in Win7 that I don't have any inclination to delve into further.  And I can always run it on my old laptop if I have to.

===
Jon

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13345>
_______________________________________

From report at bugs.python.org  Mon Nov  7 16:59:17 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 07 Nov 2011 15:59:17 +0000
Subject: [issue13193] test_packaging and test_distutils failures
In-Reply-To: <1318800293.23.0.0737706148876.issue13193@psf.upfronthosting.co.za>
Message-ID: <1320681557.81.0.740494396189.issue13193@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

[global variables]
> one possible approach might be: Have those bindings be instance variables in a Database class in
> database.py, and have a module-level binding to an instance of it. Then, tests can have their
> own instance which is thrown away aftereach test.
I?m not sure we can do that, or that I understand the suggestion.  If you?re talking about how pprint/textwrap/reprlib use a module-level instance to offer module-level functions with some defaults, I think the database module can?t work that way.  We have module-level classes (Distribution and EggInfoDistribution, no inheritance) and module-level functions (get_distribution, the one in the failing test, for example) which may use any of the four caches and return instances of either class.  If I understand your suggestion correctly, you?d move database._cache_egg to database.EggInfoDistribution._cache, and maybe change the code to move the cache logic to the *Distribution classes instead of in the various functions (thus implementing a singleton registry like logging loggers.  I like this idea.

Writing this made me think of another possible solution: dependency injection!  Just like the functions have a paths argument that defaults to sys.path if None is passed, I could change the internal cache generation function to take arguments for the four caches, so that the tests could pass fresh dictionaries that would not be shared between tests, unlike database-module-level global objects.

> This problem was not trivial to find, because it appears that test execution order may not be
> entirely deterministic: I couldn't see any other reason why the flag would have different values
> on different machines.
Sorry, what flag?

> I believe that you (?ric) had difficulty reproducing it.
More than difficulty: I have not yet reproduced it.  The tests pass on my OS, Debian x86_64 with linux3.  I?ve installed Arch but not cloned/built Python yet.

> Perhaps we don't need to re-implement, but instead add more tests around cache invalidation
> and cache contents.
The packaging database cache API is not fantastic.  Libraries or applications can turn it off entirely, or clear it so that sys.path gets scanned again.  I?m not even sure that our tests do the right thing: They disable the cache in setUp and re-enable it in cleanup, but maybe they should just clear it in cleanup.  (BTW I have added a regrtest check to make sure the cache is re-enabled and clean after tests run.)  In any case, we don?t have tests that check the behavior of the database module with respect to caching.

?There are only two hard problems in Computer Science: cache invalidation and naming things? (Phil Karlton), and I?m less bad at the latter.  The student who implemented most of the database module is not active in our group anymore, but Michael Mulich, who started the module but did not write the cache code, still is.  So there?s hope that we can fix this together (and thanks for all the reports, diagnosis and suggestions so far!).

> Re. Paul Moore's comment - IMO he's right about the problem, but changing only
> packaging.manifest._translate_pattern doesn't do it. The equivalent fix has to be made in
> distutils.filelist.translate_pattern. I've made the change in the pythonv branch, and the test no
> longer fails.
Patches for upstream cpython would be most helpful.  I also think that fixing bugs in the pythonv branch makes it harder to review.

----------
nosy: +michael.mulich

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13193>
_______________________________________

From report at bugs.python.org  Mon Nov  7 17:15:25 2011
From: report at bugs.python.org (Jason R. Coombs)
Date: Mon, 07 Nov 2011 16:15:25 +0000
Subject: [issue13211] urllib2.HTTPError does not have 'reason' attribute.
In-Reply-To: <1318943168.93.0.520705450261.issue13211@psf.upfronthosting.co.za>
Message-ID: <1320682525.11.0.527556813224.issue13211@psf.upfronthosting.co.za>


Changes by Jason R. Coombs <jaraco at jaraco.com>:


----------
hgrepos: +88
keywords: +needs review, patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13211>
_______________________________________

From report at bugs.python.org  Mon Nov  7 17:15:58 2011
From: report at bugs.python.org (Jason R. Coombs)
Date: Mon, 07 Nov 2011 16:15:58 +0000
Subject: [issue13211] urllib2.HTTPError does not have 'reason' attribute.
In-Reply-To: <1318943168.93.0.520705450261.issue13211@psf.upfronthosting.co.za>
Message-ID: <1320682558.43.0.219518187757.issue13211@psf.upfronthosting.co.za>


Changes by Jason R. Coombs <jaraco at jaraco.com>:


Added file: http://bugs.python.org/file23627/fffeff7721c0.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13211>
_______________________________________

From report at bugs.python.org  Mon Nov  7 17:17:43 2011
From: report at bugs.python.org (Jason R. Coombs)
Date: Mon, 07 Nov 2011 16:17:43 +0000
Subject: [issue13211] urllib2.HTTPError does not have 'reason' attribute.
In-Reply-To: <1318943168.93.0.520705450261.issue13211@psf.upfronthosting.co.za>
Message-ID: <1320682663.63.0.218982195865.issue13211@psf.upfronthosting.co.za>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

I've created three changesets, addressing the issue in 2.7, 3.2, and 3.3, including tests. Please review and comment. If there are no objections, I'll push the changesets after 24 hours.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13211>
_______________________________________

From report at bugs.python.org  Mon Nov  7 17:21:56 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 07 Nov 2011 16:21:56 +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: <1320682916.66.0.231240876149.issue11610@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11610>
_______________________________________

From report at bugs.python.org  Mon Nov  7 17:22:43 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Mon, 07 Nov 2011 16:22:43 +0000
Subject: [issue13193] test_packaging and test_distutils failures
In-Reply-To: <1318800293.23.0.0737706148876.issue13193@psf.upfronthosting.co.za>
Message-ID: <1320682952.10361.YahooMailNeo@web25803.mail.ukl.yahoo.com>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

> 
>>? entirely deterministic: I couldn't see any other reason why the flag 
> would have different values
>>? on different machines.
> Sorry, what flag?

By "flag" I mean _cache_generated_egg ("flag" as in Boolean value)

> Patches for upstream cpython would be most helpful.? I also think that fixing 
> bugs in the pythonv branch makes it harder to review.

Ordinarily I'd submit a cpython patch, but in this case it's a one liner as Paul has
suggested, so there's not much to review / comment on.IMO BitBucket makes it
reasonably easy to review short patches like this. Here's the change to
packaging.manifest:

--- a/Lib/packaging/manifest.py??? Sun Nov 06 22:27:53 2011 +0000
+++ b/Lib/packaging/manifest.py??? Mon Nov 07 14:58:23 2011 +0000
@@ -366,7 +366,8 @@
???????? # ditch end of pattern character
???????? empty_pattern = _glob_to_re('')
???????? prefix_re = _glob_to_re(prefix)[:-len(empty_pattern)]
-??????? pattern_re = "^" + os.path.join(prefix_re, ".*" + pattern_re)
+??????? # See issue 13193: Don't use os.path.join
+??????? pattern_re = "^%s/.*%s" % (prefix_re, pattern_re)
???? else:?????????????????????????????? # no prefix -- respect anchor flag
???????? if anchor:
???????????? pattern_re = "^" + pattern_re

and the change to distutils.filelist:

--- a/Lib/distutils/filelist.py??? Mon Nov 07 14:58:23 2011 +0000
+++ b/Lib/distutils/filelist.py??? Mon Nov 07 15:06:18 2011 +0000
@@ -313,7 +313,8 @@
???????? # ditch end of pattern character
???????? empty_pattern = glob_to_re('')
???????? prefix_re = (glob_to_re(prefix))[:-len(empty_pattern)]
-??????? pattern_re = "^" + os.path.join(prefix_re, ".*" + pattern_re)
+??????? # See issue 13193: Don't use os.path.join
+??????? pattern_re = "^%s/.*%s" % (prefix_re, pattern_re)
???? else:?????????????????????????????? # no prefix -- respect anchor flag
???????? if anchor:
???????????? pattern_re = "^" + pattern_re

You'll see I used a different idiom to Paul in my fix :-)

Can the distutils/packaging duplication not be avoided? IMO the correct
cpython fix would address this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13193>
_______________________________________

From report at bugs.python.org  Mon Nov  7 17:25:30 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 07 Nov 2011 16:25:30 +0000
Subject: [issue13283] removal of two unused variable in locale.py
In-Reply-To: <1319796863.15.0.791142726242.issue13283@psf.upfronthosting.co.za>
Message-ID: <1320683130.57.0.350848459715.issue13283@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> ?ric, thanks for paying attention to this.
You?re welcome.  I hope that my commits get reviewed too.

> In this particular case, I checked the code and verified that the
> variables were not used anywhere.
Yep, I can?t imagine third-party code being broken by this, contrary to module-level names for example.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13283>
_______________________________________

From report at bugs.python.org  Mon Nov  7 17:29:33 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 07 Nov 2011 16:29:33 +0000
Subject: [issue7897] Support parametrized tests in unittest
In-Reply-To: <1265768482.24.0.694001982317.issue7897@psf.upfronthosting.co.za>
Message-ID: <1320683373.93.0.855946288026.issue7897@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Another nice API: http://feldboris.alwaysdata.net/blog/unittest-template.html

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7897>
_______________________________________

From report at bugs.python.org  Mon Nov  7 17:33:59 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 07 Nov 2011 16:33:59 +0000
Subject: [issue13341] Incorrect documentation for "u" PyArg_Parse format unit
In-Reply-To: <1320412814.48.0.657162308895.issue13341@psf.upfronthosting.co.za>
Message-ID: <1320683639.02.0.372529044845.issue13341@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13341>
_______________________________________

From report at bugs.python.org  Mon Nov  7 17:43:00 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 07 Nov 2011 16:43:00 +0000
Subject: [issue13349] Uninformal error message in index() and remove()
	functions
In-Reply-To: <1320526177.89.0.678573577515.issue13349@psf.upfronthosting.co.za>
Message-ID: <1320684180.65.0.426790725838.issue13349@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> The good thing about this is ease of debugging.
Exactly!  +1 for the idea.

> On the other hand, the repr of a value might be very long:
You can restrict the length with % formats.

> Also, all values don't have a very informal repr:
Not your problem.  This change will still be much more useful than the current 'x'.  Some reprs are very helpful, other ones give the ID so can be used in debugging, other ones are not helpful at all so authors will have to make them more helpful or debug their code otherwise.

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13349>
_______________________________________

From report at bugs.python.org  Mon Nov  7 17:49:00 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 07 Nov 2011 16:49:00 +0000
Subject: [issue13349] Uninformal error message in index() and remove()
	functions
In-Reply-To: <1320526177.89.0.678573577515.issue13349@psf.upfronthosting.co.za>
Message-ID: <1320684540.52.0.651465901829.issue13349@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> There's also documentation and tests that depend on this actual error message:
> Doc/library/doctest.rst:   ValueError: list.remove(x): x not in list
> Lib/test>/test_xml_etree.py:    ValueError: list.remove(x): x not in list
That?s a well-known doctest problem.  Just update the doc.  Writing robust doctests is an art:

>>> str(someobject)
'output that can change'
>>> 'something I want' in str(someobject)  # more robust, but less useful if it fails
True

>>> something.index(spam)
traceback blah:
ValueError: output that can change
>>> try: something.index(spam)
... except ValueError: print('spam not in something')  # more robust, but ugly
spam not in something

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13349>
_______________________________________

From report at bugs.python.org  Mon Nov  7 17:49:32 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 07 Nov 2011 16:49:32 +0000
Subject: [issue7252] list().index() should provide better error reporting
In-Reply-To: <1257163153.85.0.398972946442.issue7252@psf.upfronthosting.co.za>
Message-ID: <1320684572.56.0.820160648887.issue7252@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> FWIW, quickly grepping through the raises of ValueErrors in the 2.6
> stdlib doesn't bring up any other usage of repeat-with-fake-variable-x.

#13349 begs to differ :)

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7252>
_______________________________________

From report at bugs.python.org  Mon Nov  7 18:03:52 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 07 Nov 2011 17:03:52 +0000
Subject: [issue13364] Duplicated code in decimal module
In-Reply-To: <1320642884.85.0.545330791342.issue13364@psf.upfronthosting.co.za>
Message-ID: <1320685432.3.0.849880718092.issue13364@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Thanks for the report.  If I may offer recommendations about submitting bugs:
- Know that stable branches don?t get code cleanups, only bug fixes, so you have to target 3.3
- Focused bugs (?code duplication in packaging commands?) are much better that over-broad bugs

----------
nosy: +eric.araujo
title: Duplicated Code -> Duplicated code in decimal module
versions:  -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13364>
_______________________________________

From report at bugs.python.org  Mon Nov  7 18:14:03 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 07 Nov 2011 17:14:03 +0000
Subject: [issue13193] test_packaging and test_distutils failures
In-Reply-To: <1318800293.23.0.0737706148876.issue13193@psf.upfronthosting.co.za>
Message-ID: <1320686043.1.0.243895271263.issue13193@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> By "flag" I mean _cache_generated_egg ("flag" as in Boolean value)
Ah, I had forgotten this earlier message:

> I get the opposite failure to Nadeem as far as InstallDataTestCase.test_resources: it works on
> Ubuntu 64-bit, but fails on 32-bit. Digging into it a bit further, I find that _generate_cache in
> Lib/packaging/database.py returns prematurely in the failing case, because _cache_generated_egg is
> True in the failing case but not in the test run which succeeds.

That it depends on the architecture currently baffles me.

> Ordinarily I'd submit a cpython patch, but in this case it's a one liner as Paul has suggested,
> so there's not much to review / comment on.
A patch in the list of files is much easier to find that a one-liner in a message.  Anyway, it?s not your fault.  Antoine was kind enough to get my attention on the buildbot failures; to make this manageable, I will open separate reports with specific names for each different bug.

> Here's the change to packaging.manifest: [snip]
> and the change to distutils.filelist: [snip]
Thanks.  Luckily, these modules recently gained full test coverage, so I will be able to commit the fixes and feel safe.

> You'll see I used a different idiom to Paul in my fix :-)
I?m a big fan of format strings other string concatenation, too.

> Can the distutils/packaging duplication not be avoided?
No.  They are independent modules.  distutils will die; packaging will be improved and cleaned up.  However, contributors can work on packaging only and leave the gruesome backporting work to me.

> IMO the correct cpython fix would address this.
I don?t understand.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13193>
_______________________________________

From report at bugs.python.org  Mon Nov  7 18:52:41 2011
From: report at bugs.python.org (sbt)
Date: Mon, 07 Nov 2011 17:52:41 +0000
Subject: [issue13322] buffered read() and write() does not raise
	BlockingIOError
In-Reply-To: <1320246535.71.0.465783773129.issue13322@psf.upfronthosting.co.za>
Message-ID: <1320688361.58.0.902984697592.issue13322@psf.upfronthosting.co.za>


sbt <shibturn at gmail.com> added the comment:

Testing the patch a bit more thoroughly, I found that data received from the readable end of the pipe can be corrupted by the C implementation.  This seems to be because two of the previously dormant codepaths did not properly maintain the necessary invariants.

I got the failures to go away by adding

        self->pos += avail;

in two places.  However, I really do not know what all the attributes mean.  (Should self->raw_pos also be modified...?)  Someone familiar with the code would need to check whether things are being done properly.  This new patch adds some XXX comments in places  in bufferedio.c which I am unsure about.

----------
Added file: http://bugs.python.org/file23628/write_blockingioerror.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13322>
_______________________________________

From report at bugs.python.org  Mon Nov  7 19:10:14 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Mon, 07 Nov 2011 18:10:14 +0000
Subject: [issue13193] test_packaging and test_distutils failures
In-Reply-To: <1320686043.1.0.243895271263.issue13193@psf.upfronthosting.co.za>
Message-ID: <1320689404.11032.YahooMailNeo@web25807.mail.ukl.yahoo.com>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

>
> That it depends on the architecture currently baffles me.

>

The only explanation I can come up with is that on different machines, the order of the tests might be slightly different. That would allow the flag to be set differently on different machines, based on which other tests have run earlier.

Different ordering could be explained by hash implementations and/or dict bucket sizes being different on different architectures.

>>  Can the distutils/packaging duplication not be avoided?
> No.? They are independent modules.? distutils will die; packaging will be 
> improved and cleaned up.? However, contributors can work on packaging only and 
> leave the gruesome backporting work to me.
> 
>>  IMO the correct cpython fix would address this.
> I don?t understand.

I meant removing the duplication - but from your explanation, I agree that there is no point, since distutils has a limited lifetime.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13193>
_______________________________________

From report at bugs.python.org  Mon Nov  7 19:19:17 2011
From: report at bugs.python.org (Vitja Makarov)
Date: Mon, 07 Nov 2011 18:19:17 +0000
Subject: [issue13284] email.utils.formatdate function does not handle
	timezones correctly.
In-Reply-To: <1319797564.66.0.629117270841.issue13284@psf.upfronthosting.co.za>
Message-ID: <1320689957.13.0.429292213471.issue13284@psf.upfronthosting.co.za>


Vitja Makarov <vitja.makarov at gmail.com> added the comment:

Perhaps it's better to calculate utc-offset for each timestamp cause we never know what is correct timezone for given time.

That could be done in C:

localtime, utc_offset = time.localtime_ex(t)

Where localtime is the same as returned by localtime() and utc_offset is set to tm.tm_gmtoff.
If tm_gmtoff isn't available on the target platform time.timezone or time.altzone will be used depending on time.daylight.


Here is simple python version, that subtracts gmtime from localtime tuple:

import time

def calculate_utc_offset(t):
    """
    Returns localtime offset for given unix-time `t`
    """
    loco = time.localtime(t)
    utc = time.gmtime(t)
    odd = cmp(loco.tm_year, utc.tm_year) or cmp(loco.tm_yday, utc.tm_yday)
    return (1440 * odd +
            60 * (loco.tm_hour - utc.tm_hour) +
            loco.tm_min - utc.tm_min))

----------
versions: +Python 2.6, Python 3.1, Python 3.2, Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13284>
_______________________________________

From report at bugs.python.org  Mon Nov  7 19:28:55 2011
From: report at bugs.python.org (R. David Murray)
Date: Mon, 07 Nov 2011 18:28:55 +0000
Subject: [issue13284] email.utils.formatdate function does not handle
	timezones correctly.
In-Reply-To: <1319797564.66.0.629117270841.issue13284@psf.upfronthosting.co.za>
Message-ID: <1320690535.86.0.917085712203.issue13284@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Unless I misunderstand your concerns, this is a duplicate of issue 665194.

----------
nosy: +r.david.murray
resolution:  -> duplicate
status: open -> closed
superseder:  -> datetime-RFC2822 roundtripping

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13284>
_______________________________________

From report at bugs.python.org  Mon Nov  7 19:49:31 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 07 Nov 2011 18:49:31 +0000
Subject: [issue13348] test_unicode_file fails: shutil.copy2 says "same file"
In-Reply-To: <1320490682.69.0.905628343655.issue13348@psf.upfronthosting.co.za>
Message-ID: <E1RNUG1-0000Mc-8e@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset fcff91a7b397 by Florent Xicluna in branch 'default':
More assertions in test_unicode_file, to chase issue #13348.
http://hg.python.org/cpython/rev/fcff91a7b397

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13348>
_______________________________________

From report at bugs.python.org  Mon Nov  7 19:51:02 2011
From: report at bugs.python.org (Vitja Makarov)
Date: Mon, 07 Nov 2011 18:51:02 +0000
Subject: [issue13284] email.utils.formatdate function does not handle
	timezones correctly.
In-Reply-To: <1319797564.66.0.629117270841.issue13284@psf.upfronthosting.co.za>
Message-ID: <1320691862.11.0.150851776065.issue13284@psf.upfronthosting.co.za>


Vitja Makarov <vitja.makarov at gmail.com> added the comment:

I'm not quite sure. The problem is email.utils.formatdate doesn't respect TZ info changes since it uses time.timezone (or time.altzone) for utc offset. 

Btw it seems that issue 665194 should fix the problem.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13284>
_______________________________________

From report at bugs.python.org  Mon Nov  7 20:02:02 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 07 Nov 2011 19:02:02 +0000
Subject: [issue13366] test_pep277 failures under WIndows
Message-ID: <1320692522.11.0.733588257728.issue13366@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

The 3.x Windows buildbots all fail in test_pep277.



======================================================================
FAIL: test_open (test.test_pep277.UnicodeFileTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\Buildslave\3.x.moore-windows\build\lib\test\test_pep277.py", line 125, in test_open
    self._apply_failure(os.listdir, name, NotADirectoryError)
  File "D:\Buildslave\3.x.moore-windows\build\lib\test\test_pep277.py", line 105, in _apply_failure
    (fn.__name__, filename, exc_filename))
AssertionError: '@test_2416_tmp\\6_\u306b\u307d\u3093\\*.*' != '@test_2416_tmp\\6_\u306b\u307d\u3093'
- @test_2416_tmp\6_\u306b\u307d\u3093\*.*
?                     ----
+ @test_2416_tmp\6_\u306b\u307d\u3093
 : Function 'listdir('@test_2416_tmp\\6_\u306b\u307d\u3093') failed with bad filename in the exception: '@test_2416_tmp\\6_\u306b\u307d\u3093\\*.*'

======================================================================
FAIL: test_open (test.test_pep277.UnicodeNFCFileTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\Buildslave\3.x.moore-windows\build\lib\test\test_pep277.py", line 125, in test_open
    self._apply_failure(os.listdir, name, NotADirectoryError)
  File "D:\Buildslave\3.x.moore-windows\build\lib\test\test_pep277.py", line 105, in _apply_failure
    (fn.__name__, filename, exc_filename))
AssertionError: '@test_2416_tmp\\10_\u0385?\\*.*' != '@test_2416_tmp\\10_\u0385?'
- @test_2416_tmp\10_\u0385?\*.*
?                     ----
+ @test_2416_tmp\10_\u0385?
 : Function 'listdir('@test_2416_tmp\\10_\u0385\xb4') failed with bad filename in the exception: '@test_2416_tmp\\10_\u0385\xb4\\*.*'

======================================================================
FAIL: test_open (test.test_pep277.UnicodeNFDFileTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\Buildslave\3.x.moore-windows\build\lib\test\test_pep277.py", line 125, in test_open
    self._apply_failure(os.listdir, name, NotADirectoryError)
  File "D:\Buildslave\3.x.moore-windows\build\lib\test\test_pep277.py", line 105, in _apply_failure
    (fn.__name__, filename, exc_filename))
AssertionError: '@test_2416_tmp\\9_\u66e8\u05e9\u3093\u0434\u0393?\\*.*' != '@test_2416_tmp\\9_\u66e8\u05e9\u3093\u0434\u0393?'
- @test_2416_tmp\9_\u66e8\u05e9\u3093\u0434\u0393?\*.*
?                        ----
+ @test_2416_tmp\9_\u66e8\u05e9\u3093\u0434\u0393?
 : Function 'listdir('@test_2416_tmp\\9_\u66e8\u05e9\u3093\u0434\u0393\xdf') failed with bad filename in the exception: '@test_2416_tmp\\9_\u66e8\u05e9\u3093\u0434\u0393\xdf\\*.*'

======================================================================
FAIL: test_open (test.test_pep277.UnicodeNFKCFileTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\Buildslave\3.x.moore-windows\build\lib\test\test_pep277.py", line 125, in test_open
    self._apply_failure(os.listdir, name, NotADirectoryError)
  File "D:\Buildslave\3.x.moore-windows\build\lib\test\test_pep277.py", line 105, in _apply_failure
    (fn.__name__, filename, exc_filename))
AssertionError: '@test_2416_tmp\\17_   A\\*.*' != '@test_2416_tmp\\17_   A'
- @test_2416_tmp\17_   A\*.*
?                       ----
+ @test_2416_tmp\17_   A
 : Function 'listdir('@test_2416_tmp\\17_   A') failed with bad filename in the exception: '@test_2416_tmp\\17_   A\\*.*'

======================================================================
FAIL: test_open (test.test_pep277.UnicodeNFKDFileTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\Buildslave\3.x.moore-windows\build\lib\test\test_pep277.py", line 125, in test_open
    self._apply_failure(os.listdir, name, NotADirectoryError)
  File "D:\Buildslave\3.x.moore-windows\build\lib\test\test_pep277.py", line 105, in _apply_failure
    (fn.__name__, filename, exc_filename))
AssertionError: '@test_2416_tmp\\11_ \u0308\u0301\u03a5\u0301\u03a5\u0308\\*.*' != '@test_2416_tmp\\11_ \u0308\u0301\u03a5\u0301\u03a5\u0308'
- @test_2416_tmp\11_ \u0308\u0301\u03a5\u0301\u03a5\u0308\*.*
?                          ----
+ @test_2416_tmp\11_ \u0308\u0301\u03a5\u0301\u03a5\u0308
 : Function 'listdir('@test_2416_tmp\\11_ \u0308\u0301\u03a5\u0301\u03a5\u0308') failed with bad filename in the exception: '@test_2416_tmp\\11_ \u0308\u0301\u03a5\u0301\u03a5\u0308\\*.*'

----------
components: Interpreter Core, Tests
messages: 147248
nosy: ezio.melotti, haypo, loewis, pitrou
priority: deferred blocker
severity: normal
stage: needs patch
status: open
title: test_pep277 failures under WIndows
type: behavior
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13366>
_______________________________________

From report at bugs.python.org  Mon Nov  7 20:09:25 2011
From: report at bugs.python.org (Ross Lagerwall)
Date: Mon, 07 Nov 2011 19:09:25 +0000
Subject: [issue6397] Implementing Solaris "/dev/poll" in the "select" module
In-Reply-To: <1246466955.08.0.134631976531.issue6397@psf.upfronthosting.co.za>
Message-ID: <1320692965.4.0.824803058927.issue6397@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/issue6397>
_______________________________________

From report at bugs.python.org  Mon Nov  7 20:11:47 2011
From: report at bugs.python.org (Ross Lagerwall)
Date: Mon, 07 Nov 2011 19:11:47 +0000
Subject: [issue4489] shutil.rmtree is vulnerable to a symlink attack
In-Reply-To: <1228232522.58.0.0992151848245.issue4489@psf.upfronthosting.co.za>
Message-ID: <1320693107.89.0.81400002429.issue4489@psf.upfronthosting.co.za>


Ross Lagerwall <rosslagerwall at gmail.com> added the comment:

Thanks Charles, I'll take your comments into account and take a look at making a general walker method.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4489>
_______________________________________

From report at bugs.python.org  Mon Nov  7 20:14:55 2011
From: report at bugs.python.org (Florent Xicluna)
Date: Mon, 07 Nov 2011 19:14:55 +0000
Subject: [issue13366] test_pep277 failures under WIndows
In-Reply-To: <1320692522.11.0.733588257728.issue13366@psf.upfronthosting.co.za>
Message-ID: <1320693295.22.0.976474817867.issue13366@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

I'm guilty on this one :-)

----------
assignee:  -> flox
components: +Windows -Interpreter Core
keywords: +buildbot
nosy: +flox

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13366>
_______________________________________

From report at bugs.python.org  Mon Nov  7 20:15:22 2011
From: report at bugs.python.org (R. David Murray)
Date: Mon, 07 Nov 2011 19:15:22 +0000
Subject: [issue13284] email.utils.formatdate function does not handle
	timezones correctly.
In-Reply-To: <1319797564.66.0.629117270841.issue13284@psf.upfronthosting.co.za>
Message-ID: <1320693322.6.0.719097154183.issue13284@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

formatdate doesn't know anything about datetimes, so it doesn't make any sense to me to say that it doesn't notice changes in tzinfo.  That's why the fix for issue 665194 introduces a new method for formatting datetimes.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13284>
_______________________________________

From report at bugs.python.org  Mon Nov  7 20:21:07 2011
From: report at bugs.python.org (Barry A. Warsaw)
Date: Mon, 07 Nov 2011 19:21:07 +0000
Subject: [issue13173] Default values for string.Template
In-Reply-To: <1318540565.49.0.753035083637.issue13173@psf.upfronthosting.co.za>
Message-ID: <1320693667.3.0.523018280579.issue13173@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

When I need defaults, I make them part of the mapping that gets passed into .substitute() and .safe_substitute().  It doesn't feel to me like it's necessary to attach them to the Template instance.  Also, couldn't you just subclass string.Template if you wanted defaults?  OTOH, since it can be done in a backward compatible way, I guess I'm -0 on the change.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13173>
_______________________________________

From report at bugs.python.org  Mon Nov  7 20:21:13 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Mon, 07 Nov 2011 19:21:13 +0000
Subject: [issue13211] urllib2.HTTPError does not have 'reason' attribute.
In-Reply-To: <1318943168.93.0.520705450261.issue13211@psf.upfronthosting.co.za>
Message-ID: <1320693673.4.0.0513497430056.issue13211@psf.upfronthosting.co.za>


Petri Lehtinen <petri at digip.org> added the comment:

Perhaps the reason should include the status code, too? It makes HTTP errors much more useful, as you'll immediately see what's going on from the status code.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13211>
_______________________________________

From report at bugs.python.org  Mon Nov  7 21:12:43 2011
From: report at bugs.python.org (Eric Snow)
Date: Mon, 07 Nov 2011 20:12:43 +0000
Subject: [issue13361] getLogger does not check its argument
In-Reply-To: <1320623185.48.0.617067061365.issue13361@psf.upfronthosting.co.za>
Message-ID: <1320696763.98.0.00998899208908.issue13361@psf.upfronthosting.co.za>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

FYI, the following changesets were also for this issue.  They had the wrong issue number (#13661, which doesn't actually exist so no big deal), which is why they didn't show up in this issue automatically.


New changeset 5f3b7528b144 by Vinay Sajip in branch '2.7':
Closes #13661: Check added for type of logger name.
http://hg.python.org/cpython/rev/5f3b7528b144

New changeset a3ba905447ba by Vinay Sajip in branch '3.2':
Closes #13661: Check added for type of logger name.
http://hg.python.org/cpython/rev/a3ba905447ba

----------
nosy: +eric.snow

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13361>
_______________________________________

From report at bugs.python.org  Mon Nov  7 21:57:19 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 07 Nov 2011 20:57:19 +0000
Subject: [issue13366] test_pep277 failures under WIndows
In-Reply-To: <1320692522.11.0.733588257728.issue13366@psf.upfronthosting.co.za>
Message-ID: <E1RNWFh-0004jO-Jd@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 655d65bcc939 by Florent Xicluna in branch 'default':
Closes #13366: fix test_pep277 failure on Windows.
http://hg.python.org/cpython/rev/655d65bcc939

----------
nosy: +python-dev
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13366>
_______________________________________

From report at bugs.python.org  Mon Nov  7 22:11:18 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 07 Nov 2011 21:11:18 +0000
Subject: [issue13345] Invisible Files in Windows 7
In-Reply-To: <1320444948.85.0.183506060307.issue13345@psf.upfronthosting.co.za>
Message-ID: <1320700278.28.0.248074582115.issue13345@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Closing the report as invalid then.

----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13345>
_______________________________________

From report at bugs.python.org  Mon Nov  7 22:24:32 2011
From: report at bugs.python.org (Florent Xicluna)
Date: Mon, 07 Nov 2011 21:24:32 +0000
Subject: [issue13254] maildir.items() broken
In-Reply-To: <1319447699.1.0.36723918452.issue13254@psf.upfronthosting.co.za>
Message-ID: <1320701072.43.0.896417561988.issue13254@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

test fails on x86 Windows7 2.7 buildbot
(ok on 3.2 and 3.3)


test_unix_mbox (test.test_mailbox.MaildirTestCase) ... D:\cygwin\home\db3l\buildarea\2.7.bolen-windows7\build\lib\sqlite3\test\dbapi.py:649: DeprecationWarning: buffer() not supported in 3.x
  b = sqlite.Binary(chr(0) + "'")
D:\cygwin\home\db3l\buildarea\2.7.bolen-windows7\build\lib\sqlite3\test\types.py:70: DeprecationWarning: buffer() not supported in 3.x
  val = buffer("Guglhupf")
D:\cygwin\home\db3l\buildarea\2.7.bolen-windows7\build\lib\sqlite3\test\types.py:234: DeprecationWarning: buffer() not supported in 3.x
  val = buffer("Guglhupf")
D:\cygwin\home\db3l\buildarea\2.7.bolen-windows7\build\lib\sqlite3\test\types.py:350: DeprecationWarning: buffer() not supported in 3.x
  result = self.con.execute('select ? as "x [bin]"', (buffer(zlib.compress(testdata)),)).fetchone()[0]
D:\cygwin\home\db3l\buildarea\2.7.bolen-windows7\build\lib\sqlite3\test\userfunctions.py:39: DeprecationWarning: buffer() not supported in 3.x
  return buffer("blob")
D:\cygwin\home\db3l\buildarea\2.7.bolen-windows7\build\lib\sqlite3\test\userfunctions.py:200: DeprecationWarning: buffer() not supported in 3.x
  self.assertEqual(val, buffer("blob"))
D:\cygwin\home\db3l\buildarea\2.7.bolen-windows7\build\lib\sqlite3\test\userfunctions.py:237: DeprecationWarning: buffer() not supported in 3.x
  cur.execute("select isblob(?)", (buffer("blob"),))
D:\cygwin\home\db3l\buildarea\2.7.bolen-windows7\build\lib\sqlite3\test\userfunctions.py:255: DeprecationWarning: buffer() not supported in 3.x
  ("foo", 5, 3.14, None, buffer("blob"),))
D:\cygwin\home\db3l\buildarea\2.7.bolen-windows7\build\lib\sqlite3\test\userfunctions.py:347: DeprecationWarning: buffer() not supported in 3.x
  cur.execute("select checkType('blob', ?)", (buffer("blob"),))
test test_mailbox failed -- Traceback (most recent call last):
  File "D:\cygwin\home\db3l\buildarea\2.7.bolen-windows7\build\lib\test\test_mailbox.py", line 803, in test_reread
    self.assertFalse(refreshed())
AssertionError: True is not false

ok

======================================================================
FAIL: test_reread (test.test_mailbox.TestMaildir)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\cygwin\home\db3l\buildarea\2.7.bolen-windows7\build\lib\test\test_mailbox.py", line 803, in test_reread
    self.assertFalse(refreshed())
AssertionError: True is not false

----------------------------------------------------------------------
Ran 280 tests in 5.250s

----------
keywords: +buildbot -patch
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13254>
_______________________________________

From report at bugs.python.org  Mon Nov  7 22:38:14 2011
From: report at bugs.python.org (Jason R. Coombs)
Date: Mon, 07 Nov 2011 21:38:14 +0000
Subject: [issue13211] urllib2.HTTPError does not have 'reason' attribute.
In-Reply-To: <1318943168.93.0.520705450261.issue13211@psf.upfronthosting.co.za>
Message-ID: <1320701894.15.0.154419635988.issue13211@psf.upfronthosting.co.za>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

My initial instinct was to agree - the status code is useful. However, in looking at the FTP code, it sometimes just sets other objects (socket.error for example) as the 'reason'. The docs say 'reason' is a string or another exception.

I'm tempted to leave it as is. This fix is mainly to provide a reasonable value for .reason. The __str__ and .code are already exposed, so to create a reason with a code would create yet another string representation of the error which is different from every other representation already present.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13211>
_______________________________________

From report at bugs.python.org  Mon Nov  7 23:10:24 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 07 Nov 2011 22:10:24 +0000
Subject: [issue13327] Update utime API to not require explicit None argument
In-Reply-To: <1320277592.58.0.341414975391.issue13327@psf.upfronthosting.co.za>
Message-ID: <E1RNXOQ-00032n-Gd@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 59dca1e2363d by Brian Curtin in branch 'default':
Fix #13327. utimensat now has the atime and mtime arguments set as optional,
http://hg.python.org/cpython/rev/59dca1e2363d

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13327>
_______________________________________

From report at bugs.python.org  Mon Nov  7 23:24:26 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 07 Nov 2011 22:24:26 +0000
Subject: [issue13366] test_pep277 failures under WIndows
In-Reply-To: <1320692522.11.0.733588257728.issue13366@psf.upfronthosting.co.za>
Message-ID: <E1RNXc0-0004I7-UD@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 2cd6b417e488 by Florent Xicluna in branch 'default':
Some win32 platforms raise NotADirectoryError, others FileNotFoundError. Issue #13366.
http://hg.python.org/cpython/rev/2cd6b417e488

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13366>
_______________________________________

From report at bugs.python.org  Mon Nov  7 23:26:36 2011
From: report at bugs.python.org (Brian Curtin)
Date: Mon, 07 Nov 2011 22:26:36 +0000
Subject: [issue13327] Update utime API to not require explicit None argument
In-Reply-To: <1320277592.58.0.341414975391.issue13327@psf.upfronthosting.co.za>
Message-ID: <1320704796.72.0.391707019977.issue13327@psf.upfronthosting.co.za>


Brian Curtin <brian at python.org> added the comment:

Changeset 045e8757f10d was also entered for this, which should conclude the changes. Everything seems to have survived the buildbots for now, so closing as fixed. Feel free to reopen if there are any other issues.

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13327>
_______________________________________

From report at bugs.python.org  Mon Nov  7 23:30:23 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 07 Nov 2011 22:30:23 +0000
Subject: [issue13327] Update utime API to not require explicit None argument
In-Reply-To: <1320277592.58.0.341414975391.issue13327@psf.upfronthosting.co.za>
Message-ID: <E1RNXhg-0004rQ-F5@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 5e18ff5476e8 by Brian Curtin in branch 'default':
News updates for #13327.
http://hg.python.org/cpython/rev/5e18ff5476e8

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13327>
_______________________________________

From report at bugs.python.org  Tue Nov  8 00:06:19 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 07 Nov 2011 23:06:19 +0000
Subject: [issue13335] Service application hang in python25.dll
In-Reply-To: <1320324829.1.0.613797933132.issue13335@psf.upfronthosting.co.za>
Message-ID: <1320707179.33.0.390833324516.issue13335@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I am closing this because there is no issue for currently maintained CPython. If you have further questions, try python-list or a question-answer forum such as StackOverflow.

----------
resolution:  -> out of date
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13335>
_______________________________________

From report at bugs.python.org  Tue Nov  8 00:17:12 2011
From: report at bugs.python.org (Florent Xicluna)
Date: Mon, 07 Nov 2011 23:17:12 +0000
Subject: [issue13313] test_time fails: tzset() do not change timezone
In-Reply-To: <1320166603.97.0.58939508903.issue13313@psf.upfronthosting.co.za>
Message-ID: <1320707832.06.0.925324085322.issue13313@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

Maybe it is related.
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=93810

Ambiguous timezone names (AEST vs EST)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13313>
_______________________________________

From report at bugs.python.org  Tue Nov  8 00:19:26 2011
From: report at bugs.python.org (Michael Foord)
Date: Mon, 07 Nov 2011 23:19:26 +0000
Subject: [issue13241] llvm-gcc-4.2 miscompiles Python (XCode 4.1 on Mac OS
	10.7)
In-Reply-To: <1319226560.18.0.474501275115.issue13241@psf.upfronthosting.co.za>
Message-ID: <1320707966.41.0.0823990182131.issue13241@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

On OS X Lion, with XCode 4.2 installed, I find the following works (no need to install macports):

./configure CC=gcc-4.2 --prefix=/dev/null --with-pydebug

----------
nosy: +michael.foord

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13241>
_______________________________________

From report at bugs.python.org  Tue Nov  8 00:27:54 2011
From: report at bugs.python.org (Florent Xicluna)
Date: Mon, 07 Nov 2011 23:27:54 +0000
Subject: [issue13309] test_time fails: time data 'LMT' does not match format
	'%Z'
In-Reply-To: <1320156304.27.0.1872899991.issue13309@psf.upfronthosting.co.za>
Message-ID: <1320708474.68.0.739823788215.issue13309@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

LMT stands for Local Mean Time.

I found a report of someone having an issue parsing timezone with Python 2.6. Looks quite similar.
http://www.aczoom.com/forums/blockhosts/mar-10-151801-domains-blockhosts5599-error-failed-to-parse-date-for-ip-18911419951

----------
components: +Library (Lib)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13309>
_______________________________________

From report at bugs.python.org  Tue Nov  8 00:35:47 2011
From: report at bugs.python.org (Michael Foord)
Date: Mon, 07 Nov 2011 23:35:47 +0000
Subject: [issue13241] llvm-gcc-4.2 miscompiles Python (XCode 4.1 on Mac OS
	10.7)
In-Reply-To: <1319226560.18.0.474501275115.issue13241@psf.upfronthosting.co.za>
Message-ID: <1320708947.81.0.88274906748.issue13241@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

Ah, it seems I have XCode 3.2.6 installed alongside XCode 4.2.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13241>
_______________________________________

From report at bugs.python.org  Tue Nov  8 02:11:31 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 08 Nov 2011 01:11:31 +0000
Subject: [issue1200313] HTMLParser fails to handle charref in attribute value
Message-ID: <1320714691.23.0.787074107265.issue1200313@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

unescape() already converts named, decimal and hexadecimal entities, so this can be closed.

----------
assignee: fdrake -> ezio.melotti
nosy: +ezio.melotti
resolution:  -> out of date
stage: test needed -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1200313>
_______________________________________

From report at bugs.python.org  Tue Nov  8 02:27:54 2011
From: report at bugs.python.org (Florent Xicluna)
Date: Tue, 08 Nov 2011 01:27:54 +0000
Subject: [issue9375] ElementPath parser in ElementTree 1.3 does not reject
	"element//" as invalid
In-Reply-To: <1280043129.76.0.83882182954.issue9375@psf.upfronthosting.co.za>
Message-ID: <1320715674.32.0.179446537758.issue9375@psf.upfronthosting.co.za>


Changes by Florent Xicluna <florent.xicluna at gmail.com>:


----------
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9375>
_______________________________________

From report at bugs.python.org  Tue Nov  8 03:54:58 2011
From: report at bugs.python.org (INADA Naoki)
Date: Tue, 08 Nov 2011 02:54:58 +0000
Subject: [issue13367] PyCapsule_New's argument *must* not a NULL.
Message-ID: <1320720898.69.0.766220401845.issue13367@psf.upfronthosting.co.za>


New submission from INADA Naoki <songofacandy at gmail.com>:

http://docs.python.org/c-api/capsule.html?highlight=capsule#PyCapsule_New

> The pointer argument may not be NULL.

I think "must not" is correct.

----------
assignee: docs at python
components: Documentation
messages: 147269
nosy: docs at python, naoki
priority: normal
severity: normal
status: open
title: PyCapsule_New's argument *must* not a NULL.
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13367>
_______________________________________

From report at bugs.python.org  Tue Nov  8 04:03:50 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 08 Nov 2011 03:03:50 +0000
Subject: [issue13367] PyCapsule_New's argument *must* not a NULL.
In-Reply-To: <1320720898.69.0.766220401845.issue13367@psf.upfronthosting.co.za>
Message-ID: <1320721430.24.0.0910978536943.issue13367@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +larry

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13367>
_______________________________________

From report at bugs.python.org  Tue Nov  8 04:07:18 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Tue, 08 Nov 2011 03:07:18 +0000
Subject: [issue11812] transient socket failure to connect to 'localhost'
In-Reply-To: <1302386214.84.0.811032327589.issue11812@psf.upfronthosting.co.za>
Message-ID: <1320721638.75.0.482409506039.issue11812@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

Checking the testsuite source code, I see several issues:

The server thread only waits for 3 seconds for the connection. If a connection is not created before 3 seconds, the server suicides and when the connection is tried, it will fail. This probably explain why the problem is sporadic and seems to depend of name resolving. If the DNS resolver is "slow", we have a problem.

Also, the event is signaled twice in the server, and the client does a wait and a clear. If the thread scheduler is lucky, the server would signal twice and THEN the client would wait (and return inmediatelly) and clear, completelly missing the second signaling and hanging the client in the next wait (in the teardown).

So, I would propose:

1. Use 127.0.0.1 instead of "localhost".

2. Delete the timeout in the server. I don't see the purpose of it, except be sure the server thread dies eventually. Lets configure the thread as "daemon", and don't mind with the thread join.

3. Cleanup the Event signaling.

4. "time.sleep(0.1)?"... Please... :-)

Opinions?.

I assign the issue to myself. Please, provide feedback and I will create & apply the patch.

I have seen this issue too in 2.7, in my buildbots (OpenIndiana).

You can reproduce the issue easily changing the "self.sock.settimeout(3)" to "self.sock.settimeout(0.01)", for instance.

PS: I see use of test.support.HOST in the testuite, but that attribute is not documented anywhere. :-??

"""
Python 3.2.2 (default, Sep  5 2011, 01:49:10) 
[GCC 4.4.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from test import support
>>> support.HOST
'localhost'
"""

Should it be 127.0.0.1, or not use at all, since it is not documented?.

PPS: I only checked telnetlib, not ftplib.

----------
assignee:  -> jcea
versions: +Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11812>
_______________________________________

From report at bugs.python.org  Tue Nov  8 04:11:50 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Tue, 08 Nov 2011 03:11:50 +0000
Subject: [issue11812] transient socket failure to connect to 'localhost'
In-Reply-To: <1302386214.84.0.811032327589.issue11812@psf.upfronthosting.co.za>
Message-ID: <1320721910.94.0.608955368575.issue11812@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

About the "support.HOST", changing from "localhost" to "127.0.0.1" could be problematic is servers without IPv4 support (servers IPv6 only). I guess this is a theorical problem so far, and that when we find this issue the exception would be pretty obvious...

Opinions?.

What about documenting "support.HOST"?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11812>
_______________________________________

From report at bugs.python.org  Tue Nov  8 04:23:14 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Tue, 08 Nov 2011 03:23:14 +0000
Subject: [issue13368] Possible problem in documentation of module subprocess, 
	method send_signal
Message-ID: <1320722594.89.0.739080107592.issue13368@psf.upfronthosting.co.za>


New submission from Eli Bendersky <eliben at gmail.com>:

docs@ list report by Daniel Dieterle:

in the documentation (http://docs.python.org/library/subprocess.html#subprocess.Popen.send_signal) is a bug.

CTRL_C_EVENT can not be sent to processes started with a creationflags parameter which includes CREATE_NEW_PROCESS_GROUP. Why can be read in the msdn documentation http://msdn.microsoft.com/en-us/library/windows/desktop/ms683155%28v=vs.85%29.aspx .

A workaround using CTRL_C_EVENT nevertheless is described here:
http://stackoverflow.com/questions/7085604/sending-c-to-python-subprocess-objects-on-windows/7980368#7980368 

--

I do not know why the subprocess.CREATE_NEW_PROCESS_GROUP parameter was introduced. But it is useless for terminating a process with os.kill() in combination with signal.SIGTERM, which corresponds to a CTRL-C-EVENT.
A CTRL-C-EVENT is only forwarded to the process if the process group is zero. Therefore the Note in the documentation on Popen.send_signal() is wrong.

----------
assignee: docs at python
components: Documentation
messages: 147272
nosy: docs at python, eli.bendersky
priority: normal
severity: normal
status: open
title: Possible problem in documentation of module subprocess, method send_signal
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13368>
_______________________________________

From report at bugs.python.org  Tue Nov  8 05:00:36 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Tue, 08 Nov 2011 04:00:36 +0000
Subject: [issue13367] PyCapsule_New's argument *must* not a NULL.
In-Reply-To: <1320720898.69.0.766220401845.issue13367@psf.upfronthosting.co.za>
Message-ID: <1320724836.24.0.54431758578.issue13367@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/issue13367>
_______________________________________

From report at bugs.python.org  Tue Nov  8 05:29:16 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 08 Nov 2011 04:29:16 +0000
Subject: [issue13367] PyCapsule_New's argument *must* not a NULL.
In-Reply-To: <1320720898.69.0.766220401845.issue13367@psf.upfronthosting.co.za>
Message-ID: <1320726556.17.0.0985916508197.issue13367@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

In this context, "may" means "allowed to". In other words, it is equivalent to "The pointer argument is not allowed to be NULL".

----------
nosy: +benjamin.peterson
resolution:  -> works for me
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13367>
_______________________________________

From report at bugs.python.org  Tue Nov  8 08:17:13 2011
From: report at bugs.python.org (Florent Xicluna)
Date: Tue, 08 Nov 2011 07:17:13 +0000
Subject: [issue13254] maildir.items() broken
In-Reply-To: <1319447699.1.0.36723918452.issue13254@psf.upfronthosting.co.za>
Message-ID: <1320736633.87.0.30487114034.issue13254@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

This is a transient failure, other builds are successful.

Maybe the line "time.sleep(2.01 + self._box._skewfactor)" could be changed to "time.sleep(2.5 + self._box._skewfactor)" in test_mailbox.TestMaildir.test_reread.

Closing because it's not related to this issue.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13254>
_______________________________________

From report at bugs.python.org  Tue Nov  8 08:50:19 2011
From: report at bugs.python.org (Lucas Sinclair)
Date: Tue, 08 Nov 2011 07:50:19 +0000
Subject: [issue13241] llvm-gcc-4.2 miscompiles Python (XCode 4.1 on Mac OS
	10.7)
In-Reply-To: <1319226560.18.0.474501275115.issue13241@psf.upfronthosting.co.za>
Message-ID: <1320738619.09.0.869321086876.issue13241@psf.upfronthosting.co.za>


Lucas Sinclair <blastocyst at mac.com> added the comment:

Well the configure parameters suggested by Michael Foord worked. I was able to build cpython on a mac. But I could not have guessed how to make it work.

Shouldn't these instructions be added here http://docs.python.org/devguide/ ?

Shouldn't the latest version of OS X be included in the list of *nix systems that cpython is checked to build on ?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13241>
_______________________________________

From report at bugs.python.org  Tue Nov  8 09:15:10 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Tue, 08 Nov 2011 08:15:10 +0000
Subject: [issue11812] transient socket failure to connect to 'localhost'
In-Reply-To: <1320721638.75.0.482409506039.issue11812@psf.upfronthosting.co.za>
Message-ID: <CAH_1eM3SBExT7rmHpLhoJu+_nW0eJvYrOC001iqrdUqNP=tcrw@mail.gmail.com>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

> The server thread only waits for 3 seconds for the connection. If a connection is not created before 3 seconds, the server suicides and when the connection is tried, it will fail. This probably explain why the problem is sporadic and seems to depend of name resolving. If the DNS resolver is "slow", we have a problem.

Indeed, but 3 seconds to resolve localhost is not "slow", it's really
that the name lookup service is broken.

> So, I would propose:
>
> 1. Use 127.0.0.1 instead of "localhost".
>

As noted, this might break on IPv6-only hosts. Not sure this will be a
problem, though. Another, less intrusive solution has been suggested
by Victor: use the address returned by getsockname() instead of
support.HOST when connecting.

> 2. Delete the timeout in the server. I don't see the purpose of it, except be sure the server thread dies eventually. Lets configure the thread as "daemon", and don't mind with the thread join.
>

Sounds like a recipe for masking bugs. Having a dangling thread is
probably not a good idea. If 1) is not enough to fix this failure,
then you can first try to increase this to a "huge" value (e.g. 30
seconds).

> 3. Cleanup the Event signaling.
>

OK.

> 4. "time.sleep(0.1)?"... Please... :-)
>

Yeah, this should be removed.

> I have seen this issue too in 2.7, in my buildbots (OpenIndiana).
>

Please check your name resolution setting :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11812>
_______________________________________

From report at bugs.python.org  Tue Nov  8 09:43:08 2011
From: report at bugs.python.org (Lucas Sinclair)
Date: Tue, 08 Nov 2011 08:43:08 +0000
Subject: [issue9750] sqlite3 iterdump fails on column with reserved name
In-Reply-To: <1283494526.84.0.467033818097.issue9750@psf.upfronthosting.co.za>
Message-ID: <1320741788.88.0.612079602734.issue9750@psf.upfronthosting.co.za>


Lucas Sinclair <blastocyst at mac.com> added the comment:

My patch contains two new dump tests which originally fail, and the fixes to the code that makes them pass.

----------
Added file: http://bugs.python.org/file23629/issue9750.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9750>
_______________________________________

From report at bugs.python.org  Tue Nov  8 09:43:09 2011
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 08 Nov 2011 08:43:09 +0000
Subject: [issue11828] startswith and endswith don't accept None as slice index
In-Reply-To: <1302534548.79.0.822537376297.issue11828@psf.upfronthosting.co.za>
Message-ID: <1320741789.79.0.928827245732.issue11828@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

As I wrote in python-dev:

I agree with Raymond that this should be treated as a feature request and not "fixed" in 2.7 / 3.2. (However the mention of 'find' in the error message for 'index' is a bug and should be fixed.)

As for the feature request, I think that allowing None in more places is more regular and consistent across interfaces. I note that the slice() object also represents "missing" or "default" values as None, so it is not just a carryover from the old string.py.

So, +1 on the feature for 3.3; -1 on the "fix" in 3.2 or 2.7.

----------
nosy: +gvanrossum

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11828>
_______________________________________

From report at bugs.python.org  Tue Nov  8 09:46:22 2011
From: report at bugs.python.org (Ned Deily)
Date: Tue, 08 Nov 2011 08:46:22 +0000
Subject: [issue13241] llvm-gcc-4.2 miscompiles Python (XCode 4.1 on Mac OS
	10.7)
In-Reply-To: <1319226560.18.0.474501275115.issue13241@psf.upfronthosting.co.za>
Message-ID: <1320741982.72.0.639473953965.issue13241@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Lucas, there is nothing particularly special about the configuration parameters that Michael used other than enabling debug.  Prior to Xcode 4, Xcode supplied a "standard" (non-LLVM) gcc as the default compiler, 4.2 for 10.6 and 4.0 for 10.5 and 10.4.  Python is regularly built and supported on these configurations and is known to work using a default ./configure (with no parameters).  Xcode 4.2 is problematic because it no longer includes the non-LLVM gcc and there have been various rumors of problems and at least one patch applied already.  As noted above, I am testing the various significant configure and compiler options right now for Xcode 4.2 and will update this issue with recommendations and patches (if necessary) when that is complete.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13241>
_______________________________________

From report at bugs.python.org  Tue Nov  8 10:57:56 2011
From: report at bugs.python.org (Florent Xicluna)
Date: Tue, 08 Nov 2011 09:57:56 +0000
Subject: [issue13369] timeout with exit code 0 while re-running failed tests
Message-ID: <1320746276.61.0.134506088825.issue13369@psf.upfronthosting.co.za>


New submission from Florent Xicluna <florent.xicluna at gmail.com>:

Seen on Windows 7 builder.

http://www.python.org/dev/buildbot/all/builders/x86%20Windows7%203.x/builds/3949

This build is considered <green> by buildbot.
Actually, the exit code should not be 0.


(...)
[360/360/4] test_descr
324 tests OK.
4 tests failed:
    test_distutils test_logging test_packaging test_pep277
6 tests altered the execution environment:
    test_multiprocessing test_site test_ssl test_subprocess
    test_sysconfig test_tcl
26 tests skipped:
    test_crypt test_curses test_dbm_gnu test_dbm_ndbm test_epoll
    test_fcntl test_fork1 test_gdb test_grp test_ioctl test_kqueue
    test_nis test_openpty test_ossaudiodev test_pipes test_poll
    test_posix test_pty test_pwd test_readline test_resource
    test_syslog test_threadsignals test_wait3 test_wait4
    test_zipfile64
2 skips unexpected on win32:
    test_gdb test_readline
Re-running failed tests in verbose mode
(...)
test_additional_fixers (packaging.tests.test_mixin2to3.Mixin2to3TestCase) ... ok
test_convert_code_only (packaging.tests.test_mixin2to3.Mixin2to3TestCase) ... program finished with exit code 0
elapsedTime=7325.264000

----------
components: Tests
keywords: buildbot
messages: 147280
nosy: flox
priority: low
severity: normal
stage: needs patch
status: open
title: timeout with exit code 0 while re-running failed tests
type: behavior
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13369>
_______________________________________

From report at bugs.python.org  Tue Nov  8 12:21:20 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Tue, 08 Nov 2011 11:21:20 +0000
Subject: [issue13254] maildir.items() broken
In-Reply-To: <1320736633.87.0.30487114034.issue13254@psf.upfronthosting.co.za>
Message-ID: <20111108112108.GC1904@ihaa>


Petri Lehtinen <petri at digip.org> added the comment:

Even better would be to set skewfactor to something negative in this
test, too. I was told that long sleeps in tests are frowned upon.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13254>
_______________________________________

From report at bugs.python.org  Tue Nov  8 12:22:28 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Tue, 08 Nov 2011 11:22:28 +0000
Subject: [issue13211] urllib2.HTTPError does not have 'reason' attribute.
In-Reply-To: <1320701894.15.0.154419635988.issue13211@psf.upfronthosting.co.za>
Message-ID: <20111108112217.GD1904@ihaa>


Petri Lehtinen <petri at digip.org> added the comment:

Ok. Sounds that you've already evaluated this alternative, so I'm fine
with it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13211>
_______________________________________

From report at bugs.python.org  Tue Nov  8 12:47:48 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Tue, 08 Nov 2011 11:47:48 +0000
Subject: [issue11812] transient socket failure to connect to 'localhost'
In-Reply-To: <1302386214.84.0.811032327589.issue11812@psf.upfronthosting.co.za>
Message-ID: <1320752868.46.0.957358226531.issue11812@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

Charles-Fran?ois:

The only way for the server thread being around would be if the test fails badly, not calling teardown (I would do a fake tcp connection to the server in the teardown, followed by a thread.join). In this case, the thread (being "daemon") will die when the tests are done anyway, and the test will be showed as fail in the buildbots, so somebody should take care of it. I would not mask anything.

About using getsockname(), the bind would bind to all IPs of the machine, including real network interfaces. I rather prefer to keep the bind private and not accesible from the external network :-).

I really think that ipv6-only hosts are a non-issue just now. And the failure would be quite self-evident. In Solaris I get this exception: "socket.error: [Errno 126] Cannot assign requested address". Quite clear.

Anyway, we can keep using "localhost", but just delete the socket timeout in the server.

About the nameresolution speed, it is actually happening. Could be, too, a busy machine. I know that some buildbots are running inside a virtual machine, sometimes with little real RAM and possibly paging a lot. The fact is that the 3 second delay is actually happening, and I don't think that solution should be to increase the timeout. That only mask the issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11812>
_______________________________________

From report at bugs.python.org  Tue Nov  8 13:00:54 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 08 Nov 2011 12:00:54 +0000
Subject: [issue11812] transient socket failure to connect to 'localhost'
In-Reply-To: <1302386214.84.0.811032327589.issue11812@psf.upfronthosting.co.za>
Message-ID: <1320753654.5.0.596440845249.issue11812@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Anyway, we can keep using "localhost", but just delete the socket
> timeout in the server.

Please don't. Any problem might then hang the whole test suite.
You can bump it up if you want, though.

> About using getsockname(), the bind would bind to all IPs of the 
> machine, including real network interfaces.

How so?

>>> sock = socket.socket()
>>> sock.bind(("localhost", 0))
>>> sock.getsockname()
('127.0.0.1', 60919)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11812>
_______________________________________

From report at bugs.python.org  Tue Nov  8 13:12:11 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 08 Nov 2011 12:12:11 +0000
Subject: [issue13237] subprocess docs should emphasise convenience functions
In-Reply-To: <1319174702.47.0.36912184976.issue13237@psf.upfronthosting.co.za>
Message-ID: <E1RNkX3-0003zc-1T@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset e929d2a96d9b by Nick Coghlan in branch '3.2':
Issue #13237: Forward port subprocess module updates and explicitly document UTF-8 encoding assumption when universal_newlines=True
http://hg.python.org/cpython/rev/e929d2a96d9b

New changeset d3b159c43ee8 by Nick Coghlan in branch '3.2':
Issue #13237: Remove duplicate data value descriptions from the subprocess docs
http://hg.python.org/cpython/rev/d3b159c43ee8

New changeset 7545f4fb450c by Nick Coghlan in branch '3.2':
Issue #13237: Fix formatting error - the legacy shell commands weren't meant to be under the Notes heading
http://hg.python.org/cpython/rev/7545f4fb450c

New changeset 0b50008bb953 by Nick Coghlan in branch 'default':
Issue #13237: Forward port from 3.2 of subprocess documentation updates. Needed quite a few adjustments to account for new features coming in 3.3
http://hg.python.org/cpython/rev/0b50008bb953

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13237>
_______________________________________

From report at bugs.python.org  Tue Nov  8 13:14:34 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 08 Nov 2011 12:14:34 +0000
Subject: [issue13237] subprocess docs should emphasise convenience functions
In-Reply-To: <1319174702.47.0.36912184976.issue13237@psf.upfronthosting.co.za>
Message-ID: <1320754474.8.0.160509657761.issue13237@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Well, that forward port was definitely more complicated than I expected.

Additional reviews of both 3.2 and 3.3 (i.e. default) would be appreciated - there were quite a few adjustments needed to cope with changes between 2.7 and 3.2 and then additional changes between 3.2 and 3.3.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13237>
_______________________________________

From report at bugs.python.org  Tue Nov  8 13:28:47 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Tue, 08 Nov 2011 12:28: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: <1320755327.23.0.937325279333.issue11812@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

Uhmmmm.... doing a fake connection in the teardown would be problematic if the socket is reused for something else in the meantime. The kernel is suppose to keep the socket in the "not reuse" state for a while, but...

I am seeing too liberal mixing of support.HOST and "localhost". That should be unified.

I need consensus about making test.support.HOST = "127.0.0.1". What do you think?

test_ftplib needs love too, but changes are far more intrusive there. I will wait until you approve changes to telnetlib.py.

Please, review attached changeset.

----------
hgrepos: +89

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11812>
_______________________________________

From report at bugs.python.org  Tue Nov  8 13:30:14 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Tue, 08 Nov 2011 12:30: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: <1320755414.66.0.767739147749.issue11812@psf.upfronthosting.co.za>


Changes by Jes?s Cea Avi?n <jcea at jcea.es>:


Added file: http://bugs.python.org/file23630/2b155a6d25bb.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11812>
_______________________________________

From report at bugs.python.org  Tue Nov  8 13:42:04 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Tue, 08 Nov 2011 12:42:04 +0000
Subject: [issue11812] transient socket failure to connect to 'localhost'
In-Reply-To: <1302386214.84.0.811032327589.issue11812@psf.upfronthosting.co.za>
Message-ID: <1320756124.7.0.499967171941.issue11812@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

Antoine:

Deleting the socket timeout doesn't hang the test if we set the thread to "daemon" and do not do a thread.join() (unneeded in the normal situation, since garbage collecting the test instance will collect the thread too). If you don't like this, I can do a fake connection in teardown (look the proposed changeset). The problem with that is OS port reuse. Quite safe, but only "quite".

If thread.join had a timeout , we could wait for a while and if the thread is still active, do a fake connection and another join. A bit overkill for a test, I guess :-).

I stand corrected about getsockname(). I am neutral to it, although we are still involving DNS. I would rather prefer a direct "127.0.0.1".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11812>
_______________________________________

From report at bugs.python.org  Tue Nov  8 13:46:41 2011
From: report at bugs.python.org (Michael Foord)
Date: Tue, 08 Nov 2011 12:46:41 +0000
Subject: [issue11812] transient socket failure to connect to 'localhost'
In-Reply-To: <1302386214.84.0.811032327589.issue11812@psf.upfronthosting.co.za>
Message-ID: <1320756401.01.0.144454730068.issue11812@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/issue11812>
_______________________________________

From report at bugs.python.org  Tue Nov  8 13:47:51 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 08 Nov 2011 12:47:51 +0000
Subject: [issue11812] transient socket failure to connect to 'localhost'
In-Reply-To: <1320755327.23.0.937325279333.issue11812@psf.upfronthosting.co.za>
Message-ID: <1320756195.3386.3.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Please, review attached changeset.

Doesn't look acceptable to me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11812>
_______________________________________

From report at bugs.python.org  Tue Nov  8 13:50:56 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 08 Nov 2011 12:50:56 +0000
Subject: [issue11812] transient socket failure to connect to 'localhost'
In-Reply-To: <1320756124.7.0.499967171941.issue11812@psf.upfronthosting.co.za>
Message-ID: <1320756380.3386.6.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> If thread.join had a timeout , we could wait for a while and if the
> thread is still active, do a fake connection and another join.

What's wrong with a socket timeout exactly? Everything you're proposing
is ten times more complicated, and more fragile.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11812>
_______________________________________

From report at bugs.python.org  Tue Nov  8 13:59:24 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 08 Nov 2011 12:59:24 +0000
Subject: [issue13238] Add shell command helpers to subprocess module
In-Reply-To: <1319176813.33.0.203455355645.issue13238@psf.upfronthosting.co.za>
Message-ID: <1320757164.66.0.843080550039.issue13238@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

After working on the documentation updates to the subprocess module to emphasise the convenience functions, I've now changed my mind and think it makes sense to keep these additions in that module.

Now that the shell helpers will default to using shlex.quote() and require the "!u" conversion specifier to bypass that behaviour, and also will have distinct names from the ordinary non-shell based versions, my original concerns that lead to me wanting to keep them out of subprocess no longer apply. That means the general preference that subprocess be our "one stop shop" for explicit subprocess invocation can once again take precedence.

I'm actually planning to change the API a bit though, dropping "shell_format" and "shell_format_map" in favour of the following helper class:

    class ShellCommand:
        def __init__(self, command, *, **callkwds):
            self.command = command
            self.callkwds = callkwds
        def format(self, *args, **kwds):
            return _ShellFormatter().vformat(_fmt, args, kwds)
        def format_map(self, mapping):
            return _ShellFormatter().vformat(_fmt, (), mapping)
        def call(self, *args, **kwds):
            if args or kwds:
                cmd = _ShellFormatter().vformat(cmd, args, kwds)
            return subprocess.call(cmd, shell=True, **self.callkwds)
        def check_call(self, *args, **kwds):
            if args or kwds:
                cmd = _ShellFormatter().vformat(cmd, args, kwds)
            return subprocess.check_call(cmd, shell=True, **self.callkwds)
    def shell_output(cmd, *args, **kwds):
        if args or kwds:
            cmd = _ShellFormatter().vformat(cmd, args, kwds)
        data = subprocess.check_output(cmd, shell=True, universal_newlines=True)
        if data[-1:] == "\n":
            data = data[:-1]
        return data

The module level helpers would then just become re module style wrappers:

    def shell_call(command, *args, **kwds):
        return ShellCommand(command).shell_call(*args, **kwds)
    def check_shell_call(command, *args, **kwds):
        return ShellCommand(command).check_shell_call(*args, **kwds)
    def shell_output(command, *args, **kwds):
        return ShellCommand(command).shell_output(*args, **kwds)

----------
title: Add shell command helpers to shutil module -> Add shell command helpers to subprocess module

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13238>
_______________________________________

From report at bugs.python.org  Tue Nov  8 14:02:25 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 08 Nov 2011 13:02:25 +0000
Subject: [issue13238] Add shell command helpers to subprocess module
In-Reply-To: <1319176813.33.0.203455355645.issue13238@psf.upfronthosting.co.za>
Message-ID: <1320757345.01.0.979352890495.issue13238@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

?ric, to answer your question, with the planned version of the new API, a "*.py" value interpolated with "{!u}" should indeed pick up all of those files, since the wildcard will be passed unmodified to the underlying shell, and all shells I am aware of will accept "foo bar.py" as a match for "*.py".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13238>
_______________________________________

From report at bugs.python.org  Tue Nov  8 14:02:41 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Tue, 08 Nov 2011 13:02:41 +0000
Subject: [issue11812] transient socket failure to connect to 'localhost'
In-Reply-To: <1302386214.84.0.811032327589.issue11812@psf.upfronthosting.co.za>
Message-ID: <1320757361.84.0.0322344167494.issue11812@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

Antoine, the problem with this test is the timeout. We can set an arbitrary timeout, but how big is big enough?.

My change doesn't need a timeout at all. Problem solved.

The only "cosmetic" problem is the risk of "leaking" a thread. But it would not affect the testsuite if it is a daemon thread, and we would only "leak" if the test fails, not under normal circunstances. The complexities suggested are heroic effords trying to manage that thread when simply ignoring it would be acceptable.

I could set a timeout of 5 minutes just to satisfy you, but for that time the test should have been done yet, and the thread collected anyway. I see that more a hack that actually setting the thread to daemon and forget it, knowing that it will automatically die when done.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11812>
_______________________________________

From report at bugs.python.org  Tue Nov  8 14:36:24 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 08 Nov 2011 13:36:24 +0000
Subject: [issue11812] transient socket failure to connect to 'localhost'
In-Reply-To: <1320757361.84.0.0322344167494.issue11812@psf.upfronthosting.co.za>
Message-ID: <1320759108.3386.15.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Antoine, the problem with this test is the timeout. We can set an
> arbitrary timeout, but how big is big enough?.

I would say answering this question is your task, since you have access
to that buildbot.

> The only "cosmetic" problem is the risk of "leaking" a thread.

This is not cosmetic, the thread might be keeping all kinds of resources
alive, it might also break other tests which expect there to be a single
running Python thread (if e.g. signals are being tested). We don't want
a failing test to trigger a potential cascade of subsequent failures.

> I could set a timeout of 5 minutes just to satisfy you, but for that
> time the test should have been done yet

The issue is not to satisfy me, it's to satify the buildbots. If you say
that 5 minutes is necessary to reliably resolve "localhost", then surely
there's a configuration problem?

If you say that replacing "localhost" with "127.0.0.1" would fix the
issue, then perhaps we should do that, but we must check that it doesn't
break any other tests (for example IPv6 tests).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11812>
_______________________________________

From report at bugs.python.org  Tue Nov  8 14:43:20 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Tue, 08 Nov 2011 13:43:20 +0000
Subject: [issue11812] transient socket failure to connect to 'localhost'
In-Reply-To: <1302386214.84.0.811032327589.issue11812@psf.upfronthosting.co.za>
Message-ID: <1320759800.74.0.102974366512.issue11812@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

Antoine: Then you would be satisfied if I increase the timeout from 3 seconds to 60 seconds and clean the event signaling?. The current event signaling code has a few race conditions with potential deadlocks.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11812>
_______________________________________

From report at bugs.python.org  Tue Nov  8 14:48:41 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 08 Nov 2011 13:48:41 +0000
Subject: [issue11812] transient socket failure to connect to 'localhost'
In-Reply-To: <1320759800.74.0.102974366512.issue11812@psf.upfronthosting.co.za>
Message-ID: <1320759845.3386.16.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Antoine: Then you would be satisfied if I increase the timeout from 3
> seconds to 60 seconds and clean the event signaling?

Yes!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11812>
_______________________________________

From report at bugs.python.org  Tue Nov  8 14:50:02 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Tue, 08 Nov 2011 13:50:02 +0000
Subject: [issue11812] transient socket failure to connect to 'localhost'
In-Reply-To: <1302386214.84.0.811032327589.issue11812@psf.upfronthosting.co.za>
Message-ID: <1320760202.16.0.230995200277.issue11812@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

Consider too that if something goes bad enough in the test to skip the teardown method, the thread will be alive for a while, possibly contaminating some other tests, like you commented.

This is actually unsolvable, I think. Code that NEED to be executed with no other threads around could/should check the thread count and fail with a clear error message. So we at least can point to the real culprit.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11812>
_______________________________________

From report at bugs.python.org  Tue Nov  8 14:58:23 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 08 Nov 2011 13:58:23 +0000
Subject: [issue11812] transient socket failure to connect to 'localhost'
In-Reply-To: <1320760202.16.0.230995200277.issue11812@psf.upfronthosting.co.za>
Message-ID: <1320760427.3386.17.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Consider too that if something goes bad enough in the test to skip the
> teardown method,

Such as? tearDown is normally like a "finally" block, it always gets
executed (unless perhaps setUp fails).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11812>
_______________________________________

From report at bugs.python.org  Tue Nov  8 14:59:59 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Tue, 08 Nov 2011 13:59:59 +0000
Subject: [issue11812] transient socket failure to connect to 'localhost'
In-Reply-To: <1302386214.84.0.811032327589.issue11812@psf.upfronthosting.co.za>
Message-ID: <1320760799.19.0.719736015644.issue11812@psf.upfronthosting.co.za>


Changes by Jes?s Cea Avi?n <jcea at jcea.es>:


Added file: http://bugs.python.org/file23631/71ab454bfe19.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11812>
_______________________________________

From report at bugs.python.org  Tue Nov  8 15:11:14 2011
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 08 Nov 2011 14:11:14 +0000
Subject: [issue13370] test_ctypes fails on osx 10.7
Message-ID: <1320761474.93.0.268896325495.issue13370@psf.upfronthosting.co.za>


New submission from Ronald Oussoren <ronaldoussoren at mac.com>:

test_ctypes fails when building and testing on OSX 10.7 (Lion).

This is likely caused by changes in the compiler w.r.t. the calling convention.  I've worked around this problem in PyObjC, and will try to port that workaround to ctypes.

BTW. Using --with-system-ffi does not fix the issue for me

----------
assignee: ronaldoussoren
components: Macintosh, ctypes
messages: 147299
nosy: ronaldoussoren
priority: normal
severity: normal
stage: needs patch
status: open
title: test_ctypes fails on osx 10.7
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13370>
_______________________________________

From report at bugs.python.org  Tue Nov  8 15:12:16 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Tue, 08 Nov 2011 14:12:16 +0000
Subject: [issue11812] transient socket failure to connect to 'localhost'
In-Reply-To: <1302386214.84.0.811032327589.issue11812@psf.upfronthosting.co.za>
Message-ID: <1320761536.29.0.752067609927.issue11812@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

Please, review 71ab454bfe19.diff . I am not satisfied with the timeout approach, since the timeout time is arbitrary. I would rather do the fake connection in teardowm, to be sure the server died.

Anyway, this seems to be the  minimal patch to solve the problem at hand "most of the time" (if know the test is failing sporadically with a timeout of 3 seconds, hope it fails once per year with a timeout of 60 seconds).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11812>
_______________________________________

From report at bugs.python.org  Tue Nov  8 15:12:37 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 08 Nov 2011 14:12:37 +0000
Subject: [issue13370] test_ctypes fails on osx 10.7
In-Reply-To: <1320761474.93.0.268896325495.issue13370@psf.upfronthosting.co.za>
Message-ID: <1320761557.82.0.844730454224.issue13370@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> test_ctypes fails when building and testing on OSX 10.7 (Lion).

What is the error message?

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13370>
_______________________________________

From report at bugs.python.org  Tue Nov  8 15:19:45 2011
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 08 Nov 2011 14:19:45 +0000
Subject: [issue13370] test_ctypes fails on osx 10.7
In-Reply-To: <1320761474.93.0.268896325495.issue13370@psf.upfronthosting.co.za>
Message-ID: <1320761985.91.0.754678579636.issue13370@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

I should have included the failures in my first message, sorry about that.

IIRC the workaround in PyObjC I mention in my initial message does explicit sign extension when needed.

W.r.t to the first couple of failures, not that:

   struct.unpack('b', struct.pack('B', 130)) == (-126,)



======================================================================
FAIL: test_byte (ctypes.test.test_cfuncs.CFunctions)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Library/Frameworks/PythonDev.framework/Versions/2.7/lib/python2.7/ctypes/test/test_cfuncs.py", line 21, in test_byte
    self.assertEqual(self.S(), -126)
AssertionError: 130 != -126

======================================================================
FAIL: test_byte_plus (ctypes.test.test_cfuncs.CFunctions)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Library/Frameworks/PythonDev.framework/Versions/2.7/lib/python2.7/ctypes/test/test_cfuncs.py", line 27, in test_byte_plus
    self.assertEqual(self.S(), -126)
AssertionError: 130 != -126

======================================================================
FAIL: test_short (ctypes.test.test_cfuncs.CFunctions)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Library/Frameworks/PythonDev.framework/Versions/2.7/lib/python2.7/ctypes/test/test_cfuncs.py", line 45, in test_short
    self.assertEqual(self.S(), -32766)
AssertionError: 32770 != -32766

======================================================================
FAIL: test_short_plus (ctypes.test.test_cfuncs.CFunctions)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Library/Frameworks/PythonDev.framework/Versions/2.7/lib/python2.7/ctypes/test/test_cfuncs.py", line 51, in test_short_plus
    self.assertEqual(self.S(), -32766)
AssertionError: 32770 != -32766

======================================================================
FAIL: test_doubleresult (ctypes.test.test_functions.FunctionTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Library/Frameworks/PythonDev.framework/Versions/2.7/lib/python2.7/ctypes/test/test_functions.py", line 143, in test_doubleresult
    self.assertEqual(result, -21)
AssertionError: 65771.0 != -21

======================================================================
FAIL: test_floatresult (ctypes.test.test_functions.FunctionTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Library/Frameworks/PythonDev.framework/Versions/2.7/lib/python2.7/ctypes/test/test_functions.py", line 131, in test_floatresult
    self.assertEqual(result, -21)
AssertionError: 65771.0 != -21

======================================================================
FAIL: test_intresult (ctypes.test.test_functions.FunctionTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Library/Frameworks/PythonDev.framework/Versions/2.7/lib/python2.7/ctypes/test/test_functions.py", line 105, in test_intresult
    self.assertEqual(result, -21)
AssertionError: 65771 != -21

======================================================================
FAIL: test_longdoubleresult (ctypes.test.test_functions.FunctionTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Library/Frameworks/PythonDev.framework/Versions/2.7/lib/python2.7/ctypes/test/test_functions.py", line 155, in test_longdoubleresult
    self.assertEqual(result, -21)
AssertionError: 65771.0 != -21

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13370>
_______________________________________

From report at bugs.python.org  Tue Nov  8 15:19:49 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Tue, 08 Nov 2011 14:19:49 +0000
Subject: [issue11812] transient socket failure to connect to 'localhost'
In-Reply-To: <1302386214.84.0.811032327589.issue11812@psf.upfronthosting.co.za>
Message-ID: <1320761989.42.0.193729042207.issue11812@psf.upfronthosting.co.za>


Changes by Jes?s Cea Avi?n <jcea at jcea.es>:


Added file: http://bugs.python.org/file23632/b93657b239a5.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11812>
_______________________________________

From report at bugs.python.org  Tue Nov  8 15:20:14 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Tue, 08 Nov 2011 14:20: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: <1320762014.73.0.286399675331.issue11812@psf.upfronthosting.co.za>


Changes by Jes?s Cea Avi?n <jcea at jcea.es>:


Removed file: http://bugs.python.org/file23631/71ab454bfe19.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11812>
_______________________________________

From report at bugs.python.org  Tue Nov  8 15:21:26 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Tue, 08 Nov 2011 14:21:26 +0000
Subject: [issue11812] transient socket failure to connect to 'localhost'
In-Reply-To: <1302386214.84.0.811032327589.issue11812@psf.upfronthosting.co.za>
Message-ID: <1320762086.04.0.690544560517.issue11812@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

Stupid mistake. Please, review b93657b239a5.diff (erroneous "sock.close()" deleted)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11812>
_______________________________________

From report at bugs.python.org  Tue Nov  8 15:28:25 2011
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 08 Nov 2011 14:28:25 +0000
Subject: [issue13371] Some Carbon extensions don't build on OSX 10.7
Message-ID: <1320762505.71.0.135818589622.issue13371@psf.upfronthosting.co.za>


New submission from Ronald Oussoren <ronaldoussoren at mac.com>:

A number of Carbon wrapper modules don't build on OSX 10.7:

$ make
...

Failed to build these modules:
_Fm                _Qd                _Qdoffs         

This is with '--with-universal-archs=intel', which worked fine on OSX 10.6.

A short part of the compiler output:


/Users/ronald/Projects/python/rw/2.7/Mac/Modules/fm/_Fmmodule.c:26: error: expected ?)? before ?*? token
/Users/ronald/Projects/python/rw/2.7/Mac/Modules/fm/_Fmmodule.c: In function ?Fm_GetFontName?:
/Users/ronald/Projects/python/rw/2.7/Mac/Modules/fm/_Fmmodule.c:60: error: ?GetFontName? undeclared (first use in this function)
/Users/ronald/Projects/python/rw/2.7/Mac/Modules/fm/_Fmmodule.c:60: error: (Each undeclared identifier is reported only once
/Users/ronald/Projects/python/rw/2.7/Mac/Modules/fm/_Fmmodule.c:60: error: for each function it appears in.)
/Users/ronald/Projects/python/rw/2.7/Mac/Modules/fm/_Fmmodule.c:65: warning: implicit declaration of function ?GetFontName?
/Users/ronald/Projects/python/rw/2.7/Mac/Modules/fm/_Fmmodule.c: In function ?Fm_GetFNum?:
/Users/ronald/Projects/python/rw/2.7/Mac/Modules/fm/_Fmmodule.c:78: error: ?GetFNum? undeclared (first use in this function)
/Users/ronald/Projects/python/rw/2.7/Mac/Modules/fm/_Fmmodule.c:83: warning: implicit declaration of function ?GetFNum?
/Users/ronald/Projects/python/rw/2.7/Mac/Modules/fm/_Fmmodule.c: In function ?Fm_RealFont?:
/Users/ronald/Projects/python/rw/2.7/Mac/Modules/fm/_Fmmodule.c:97: error: ?RealFont? undeclared (first use in this function)
/Users/ronald/Projects/python/rw/2.7/Mac/Modules/fm/_Fmmodule.c:103: warning: implicit declaration of function ?RealFont?
/Users/ronald/Projects/python/rw/2.7/Mac/Modules/fm/_Fmmodule.c: In function ?Fm_SetFScaleDisable?:
/Users/ronald/Projects/python/rw/2.7/Mac/Modules/fm/_Fmmodule.c:115: error: ?SetFScaleDisable? undeclared (first use in this function)
/Users/ronald/Projects/python/rw/2.7/Mac/Modules/fm/_Fmmodule.c:120: warning: implicit declaration of function ?SetFScaleDisable?
/Users/ronald/Projects/python/rw/2.7/Mac/Modules/fm/_Fmmodule.c: In function ?Fm_FontMetrics?:
/Users/ronald/Projects/python/rw/2.7/Mac/Modules/fm/_Fmmodule.c:129: error: ?FMetricRec? undeclared (first use in this function)
/Users/ronald/Projects/python/rw/2.7/Mac/Modules/fm/_Fmmodule.c:129: error: expected ?;? before ?theMetrics?


Given the modules and failure it seems that a number of (long) deprecated Carbon functions got removed from Apple's header files.

----------
assignee: ronaldoussoren
components: Macintosh
messages: 147304
nosy: ronaldoussoren
priority: normal
severity: normal
stage: needs patch
status: open
title: Some Carbon extensions don't build on OSX 10.7
type: compile error
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13371>
_______________________________________

From report at bugs.python.org  Tue Nov  8 15:29:19 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 08 Nov 2011 14:29:19 +0000
Subject: [issue11812] transient socket failure to connect to 'localhost'
In-Reply-To: <1320762086.04.0.690544560517.issue11812@psf.upfronthosting.co.za>
Message-ID: <1320762283.3386.18.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Stupid mistake. Please, review b93657b239a5.diff (erroneous "sock.close()" deleted)

Looks good to me, thanks.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11812>
_______________________________________

From report at bugs.python.org  Tue Nov  8 15:29:47 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 08 Nov 2011 14:29:47 +0000
Subject: [issue13371] Some Carbon extensions don't build on OSX 10.7
In-Reply-To: <1320762505.71.0.135818589622.issue13371@psf.upfronthosting.co.za>
Message-ID: <1320762587.93.0.498283547441.issue13371@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
components: +Build

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13371>
_______________________________________

From report at bugs.python.org  Tue Nov  8 15:59:39 2011
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 08 Nov 2011 14:59:39 +0000
Subject: [issue13371] Some Carbon extensions don't build on OSX 10.7
In-Reply-To: <1320762505.71.0.135818589622.issue13371@psf.upfronthosting.co.za>
Message-ID: <1320764379.1.0.189360860234.issue13371@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

_Fm fails because the wrapped functionality is no longer present in the Headers (last seen in the QD.framework headers in the 10.6 SDK)

likewise for _Qdoffs and _Qd.

The attached patch changed the preprocessor guards around these bindings from 

#ifndef __LP64__

To:

#if !defined(__LP64__) && !defined(MAC_OS_X_VERSION_10_7)

That is, disable the bindings for these deprecated APIs when building for 64-bit code or when building with the 10.7 SDK (or later).

There is a small risk with this patch: I'm not 100% sure that Apple will refrain from adding a definition for MAC_OS_X_VERSION_10_7 in a later release of the 10.6 SDK.

----------
keywords: +patch
nosy: +ned.deily
stage: needs patch -> patch review
Added file: http://bugs.python.org/file23633/issue13371.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13371>
_______________________________________

From report at bugs.python.org  Tue Nov  8 16:39:44 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 08 Nov 2011 15:39:44 +0000
Subject: [issue11812] transient socket failure to connect to 'localhost'
In-Reply-To: <1302386214.84.0.811032327589.issue11812@psf.upfronthosting.co.za>
Message-ID: <E1RNnlt-0007wU-Ml@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 76b6b85e4b78 by Jesus Cea in branch '2.7':
Solved a potential deadlock in test_telnetlib.py. Related to issue #11812
http://hg.python.org/cpython/rev/76b6b85e4b78

New changeset 554802e562fa by Jesus Cea in branch '2.7':
Partial patch for issue #11812: Take care of test_telnetlib.py
http://hg.python.org/cpython/rev/554802e562fa

New changeset f94533c9229d by Jesus Cea in branch '3.2':
Solved a potential deadlock in test_telnetlib.py. Related to issue #11812
http://hg.python.org/cpython/rev/f94533c9229d

New changeset 3b9f58f85d3e by Jesus Cea in branch '3.2':
Partial patch for issue #11812: Take care of test_telnetlib.py
http://hg.python.org/cpython/rev/3b9f58f85d3e

New changeset 85c10a905424 by Jesus Cea in branch 'default':
MERGE: Solved a potential deadlock in test_telnetlib.py. Related to issue #11812
http://hg.python.org/cpython/rev/85c10a905424

New changeset ca8a0dfb2176 by Jesus Cea in branch 'default':
MERGE: Partial patch for issue #11812: Take care of test_telnetlib.py
http://hg.python.org/cpython/rev/ca8a0dfb2176

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11812>
_______________________________________

From report at bugs.python.org  Tue Nov  8 17:28:22 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 08 Nov 2011 16:28:22 +0000
Subject: [issue13327] Update utime API to not require explicit None argument
In-Reply-To: <1320277592.58.0.341414975391.issue13327@psf.upfronthosting.co.za>
Message-ID: <E1RNoWx-0005SX-8T@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 8907d646e0df by Jesus Cea in branch 'default':
Commit 59dca1e2363d for issue #13327 introduced a compilation warning
http://hg.python.org/cpython/rev/8907d646e0df

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13327>
_______________________________________

From report at bugs.python.org  Tue Nov  8 18:06:44 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 08 Nov 2011 17:06:44 +0000
Subject: [issue13364] Duplicated code in decimal module
In-Reply-To: <1320642884.85.0.545330791342.issue13364@psf.upfronthosting.co.za>
Message-ID: <1320772004.44.0.905575524055.issue13364@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Sorry, I'm closing this as rejected.  It might possibly have been better to write the code this way to begin with, but the code is already there, it's working, and there's little to be gained by 'fixing' it at this point.

----------
assignee:  -> mark.dickinson
resolution:  -> rejected
status: open -> closed
type:  -> feature request

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13364>
_______________________________________

From report at bugs.python.org  Tue Nov  8 18:13:30 2011
From: report at bugs.python.org (Florent Xicluna)
Date: Tue, 08 Nov 2011 17:13:30 +0000
Subject: [issue13360] UnicodeWarning raised on sequence and set comparisons
In-Reply-To: <1320610932.39.0.0241525481536.issue13360@psf.upfronthosting.co.za>
Message-ID: <1320772410.75.0.452232249313.issue13360@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

Then we'll live with it, or work around when it's possible.
For the purists, hopefully we have Python 3 which allows to mix bytes and strings in a set().

----------
resolution:  -> rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13360>
_______________________________________

From report at bugs.python.org  Tue Nov  8 18:18:54 2011
From: report at bugs.python.org (Giampaolo Rodola')
Date: Tue, 08 Nov 2011 17:18:54 +0000
Subject: [issue6397] Implementing Solaris "/dev/poll" in the "select" module
In-Reply-To: <1246466955.08.0.134631976531.issue6397@psf.upfronthosting.co.za>
Message-ID: <1320772734.36.0.140654289146.issue6397@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/issue6397>
_______________________________________

From report at bugs.python.org  Tue Nov  8 18:31:01 2011
From: report at bugs.python.org (Florent Xicluna)
Date: Tue, 08 Nov 2011 17:31: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: <1320773461.17.0.603996849571.issue12392@psf.upfronthosting.co.za>


Changes by Florent Xicluna <florent.xicluna at gmail.com>:


----------
Removed message: http://bugs.python.org/msg147102

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12392>
_______________________________________

From report at bugs.python.org  Tue Nov  8 18:32:11 2011
From: report at bugs.python.org (Giampaolo Rodola')
Date: Tue, 08 Nov 2011 17:32:11 +0000
Subject: [issue444582] Finding programs in PATH, adding shutil.which
Message-ID: <1320773531.85.0.931656609092.issue444582@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/issue444582>
_______________________________________

From report at bugs.python.org  Tue Nov  8 18:32:13 2011
From: report at bugs.python.org (Xavier de Gaye)
Date: Tue, 08 Nov 2011 17:32:13 +0000
Subject: [issue13372] handle_close called twice in poll2
Message-ID: <1320773533.14.0.440579615875.issue13372@psf.upfronthosting.co.za>


New submission from Xavier de Gaye <xdegaye at gmail.com>:

When use_poll is True, test_handle_close in test_asyncore.py invokes
twice the handle_close() method.

The attached patch:

    modifies test_handle_close so that it fails when handle_close() is
    called more than once

    includes a fix that makes readwrite() behave like poll(): check
    that the dispatcher instance is still in the socket map, before
    calling the handle_xxx methods

----------
components: Library (Lib)
files: handle_close.diff
keywords: patch
messages: 147311
nosy: giampaolo.rodola, josiahcarlson, neologix, stutzbach, xdegaye
priority: normal
severity: normal
status: open
title: handle_close called twice in poll2
type: behavior
versions: Python 3.3
Added file: http://bugs.python.org/file23634/handle_close.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13372>
_______________________________________

From report at bugs.python.org  Tue Nov  8 18:33:12 2011
From: report at bugs.python.org (Florent Xicluna)
Date: Tue, 08 Nov 2011 17:33:12 +0000
Subject: [issue13292] missing versionadded for bytearray
In-Reply-To: <1319975533.88.0.431386848219.issue13292@psf.upfronthosting.co.za>
Message-ID: <1320773592.11.0.323891841078.issue13292@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

Done by Eric, thank you.
Because of a typo, the message was attached to the wrong ticket.


New changeset 8ea34a74f118 by ?ric Araujo in branch '2.7':
Add missing versionadded (fixes #12392)
http://hg.python.org/cpython/rev/8ea34a74f118

----------
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13292>
_______________________________________

From report at bugs.python.org  Tue Nov  8 18:39:08 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Tue, 08 Nov 2011 17:39:08 +0000
Subject: [issue13211] urllib2.HTTPError does not have 'reason' attribute.
In-Reply-To: <1318943168.93.0.520705450261.issue13211@psf.upfronthosting.co.za>
Message-ID: <1320773948.49.0.733111145447.issue13211@psf.upfronthosting.co.za>


Senthil Kumaran <senthil at uthcode.com> added the comment:

Hi Jason & Petri,

urllib2.HTTPError never had a reason attribute. In the docs, it is mentioned that only URLError has the reason attribute. The HTTPError sublasses URLError and addinforurl class, but the further initialization happens only in the addinforurl class atrs.

If you got confused that the HTTPError as args and not reason, the 'args' is not coming from URLError.

HTTPError is raised for peculiar conditions such like authentication failures and it is 'used' as expected failure for certain authentication conditions. URLError is not so, it is seen more as an exception like socket errors.

The example your illustrated is an Authentication failure and as per docs, it is guaranteed to have code attribute to verify the kind of HTTP error are getting. msg is corresponding HTTP error code msg.

Take this example for URLError which will have reason attribute, it will work in both 2.7,3.2 and 3.3

import urllib.request, urllib.error, urllib.parse

try:
    urllib.request.urlopen('http://aninvalidsite/something')
except urllib.error.URLError as exc:
    print(exc.reason)


Because this is a socket error, the reason as "[Errno -2] Name or service not known" and HTTPError may not be a proper exception for this. 

This is more of an IOError which urllib calls a URLError.

I am not sure, how the need for 'reason' attribute for HTTPError exception was felt as the docs just say about 'code'.  (HTTPError  is informed as a subclass of URLError, but HTTPError does not call the URLError 's  __init__ and acts standalone. 

I am not sure, how to go about with this bug. If a new .reason attribute has to be added to HTTPError, then it is a feature request though, I wonder why we need when code and msg serve an adequate purpose.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13211>
_______________________________________

From report at bugs.python.org  Tue Nov  8 18:58:46 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Tue, 08 Nov 2011 17:58:46 +0000
Subject: [issue6397] Implementing Solaris "/dev/poll" in the "select" module
In-Reply-To: <1246466955.08.0.134631976531.issue6397@psf.upfronthosting.co.za>
Message-ID: <1320775126.25.0.93601421109.issue6397@psf.upfronthosting.co.za>


Changes by Jes?s Cea Avi?n <jcea at jcea.es>:


Added file: http://bugs.python.org/file23635/c47a846bed1a.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6397>
_______________________________________

From report at bugs.python.org  Tue Nov  8 19:27:19 2011
From: report at bugs.python.org (Yury Selivanov)
Date: Tue, 08 Nov 2011 18:27:19 +0000
Subject: [issue13241] llvm-gcc-4.2 miscompiles Python (XCode 4.1 on Mac OS
	10.7)
In-Reply-To: <1319226560.18.0.474501275115.issue13241@psf.upfronthosting.co.za>
Message-ID: <1320776839.03.0.794998786145.issue13241@psf.upfronthosting.co.za>


Changes by Yury Selivanov <yselivanov at gmail.com>:


----------
nosy: +Yury.Selivanov

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13241>
_______________________________________

From report at bugs.python.org  Tue Nov  8 19:33:44 2011
From: report at bugs.python.org (Giampaolo Rodola')
Date: Tue, 08 Nov 2011 18:33:44 +0000
Subject: [issue1677872] Efficient reverse line iterator
Message-ID: <1320777224.33.0.5325585827.issue1677872@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/issue1677872>
_______________________________________

From report at bugs.python.org  Tue Nov  8 19:54:39 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Tue, 08 Nov 2011 18:54:39 +0000
Subject: [issue13211] urllib2.HTTPError does not have 'reason' attribute.
In-Reply-To: <1320773948.49.0.733111145447.issue13211@psf.upfronthosting.co.za>
Message-ID: <20111108185427.GA1852@ihaa>


Petri Lehtinen <petri at digip.org> added the comment:

My impression was that because HTTPError is a subclass of URLError, it
should have the same attributes, and maybe some extra. A user reading
the docs doesn't know whether it calls the base class __init__ or not.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13211>
_______________________________________

From report at bugs.python.org  Tue Nov  8 20:02:45 2011
From: report at bugs.python.org (Florent Xicluna)
Date: Tue, 08 Nov 2011 19:02:45 +0000
Subject: [issue1677872] Efficient reverse line iterator
Message-ID: <1320778965.73.0.569361836176.issue1677872@psf.upfronthosting.co.za>


Changes by Florent Xicluna <florent.xicluna at gmail.com>:


----------
nosy: +flox
versions: +Python 3.3 -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1677872>
_______________________________________

From report at bugs.python.org  Tue Nov  8 20:39:48 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 08 Nov 2011 19:39:48 +0000
Subject: [issue13303] Sporadic importlib failures: FileNotFoundError on
	os.rename()
In-Reply-To: <1320058871.09.0.581986884521.issue13303@psf.upfronthosting.co.za>
Message-ID: <E1RNrWE-0008KZ-5X@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 1238cdd288d2 by Charles-Fran?ois Natali in branch 'default':
Back out changeset b6336ba796d4 until fix for #13303.
http://hg.python.org/cpython/rev/1238cdd288d2

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13303>
_______________________________________

From report at bugs.python.org  Tue Nov  8 21:56:15 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Tue, 08 Nov 2011 20:56:15 +0000
Subject: [issue6397] Implementing Solaris "/dev/poll" in the "select" module
In-Reply-To: <1246466955.08.0.134631976531.issue6397@psf.upfronthosting.co.za>
Message-ID: <1320785775.29.0.0609624794374.issue6397@psf.upfronthosting.co.za>


Changes by Jes?s Cea Avi?n <jcea at jcea.es>:


Added file: http://bugs.python.org/file23636/518b32ce893e.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6397>
_______________________________________

From report at bugs.python.org  Tue Nov  8 21:57:30 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Tue, 08 Nov 2011 20:57:30 +0000
Subject: [issue6397] Implementing Solaris "/dev/poll" in the "select" module
In-Reply-To: <1246466955.08.0.134631976531.issue6397@psf.upfronthosting.co.za>
Message-ID: <1320785850.77.0.84731757037.issue6397@psf.upfronthosting.co.za>


Changes by Jes?s Cea Avi?n <jcea at jcea.es>:


Removed file: http://bugs.python.org/file23635/c47a846bed1a.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6397>
_______________________________________

From report at bugs.python.org  Tue Nov  8 21:58:01 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Tue, 08 Nov 2011 20:58:01 +0000
Subject: [issue6397] Implementing Solaris "/dev/poll" in the "select" module
In-Reply-To: <1246466955.08.0.134631976531.issue6397@psf.upfronthosting.co.za>
Message-ID: <1320785881.83.0.597616548317.issue6397@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

Please, check the new changeset, with all your feedback. Thanks!.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6397>
_______________________________________

From report at bugs.python.org  Tue Nov  8 22:12:32 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 08 Nov 2011 21:12:32 +0000
Subject: [issue6570] Tutorial clarity: section 4.7.2, parameters and arguments
In-Reply-To: <1248510940.46.0.953855607394.issue6570@psf.upfronthosting.co.za>
Message-ID: <1320786752.16.0.374832688244.issue6570@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Attached patch, please review.

----------
assignee: docs at python -> ezio.melotti
keywords: +patch
nosy: +eric.araujo, ezio.melotti
stage:  -> commit review
versions: +Python 2.7 -Python 3.1
Added file: http://bugs.python.org/file23637/issue6570.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6570>
_______________________________________

From report at bugs.python.org  Tue Nov  8 22:15:50 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 08 Nov 2011 21:15:50 +0000
Subject: [issue5904] strftime docs do not explain locale effect on result
	string
In-Reply-To: <1241270739.12.0.286821632978.issue5904@psf.upfronthosting.co.za>
Message-ID: <1320786950.01.0.20985209877.issue5904@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti
stage:  -> needs patch
versions: +Python 2.7 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5904>
_______________________________________

From report at bugs.python.org  Tue Nov  8 22:39:55 2011
From: report at bugs.python.org (Jason R. Coombs)
Date: Tue, 08 Nov 2011 21:39:55 +0000
Subject: [issue13211] urllib2.HTTPError does not have 'reason' attribute.
In-Reply-To: <1318943168.93.0.520705450261.issue13211@psf.upfronthosting.co.za>
Message-ID: <1320788395.16.0.0778504667191.issue13211@psf.upfronthosting.co.za>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

That was my point. If HTTPError is a subclass of URLError, then an HTTPError _is an_ URLError, and thus should implement the same public interface.

The problem is better illustrated with this request:

try:
  urllib.request.urlopen('http://api.wordnik.com/v4/word.json/foo/examples')
except urllib2.URLError as exc:
  # We caught a URLError, what's the reason?
  print(exc.reason)

This code will fail with an attribute error, but only when the except clause catches an HTTPError (as it does in this case).

The documentation explicitly states that HTTPError is a subclass of URLError and it doesn't say anything about the addinfourl interface. The documentation strongly suggests (though implicitly) that HTTPError.reason will be present as it is with URLError.

If HTTPError does not implement the reason attribute, then there is no value in making it the subclass of URLError, and HTTPError should probably have the same parent class as URLError. However, this change is even more drastic and would almost certainly violate backward compatibility constraints.

The proposal I've made is generally backward compatible, and addresses the underlying bug (that URLError.__init__ is never called), and the symptom that a HTTPError does not implement the documented public interface.

Perhaps there's a better approach, but I believe based on the example code above, the implementation is broken.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13211>
_______________________________________

From report at bugs.python.org  Tue Nov  8 22:49:31 2011
From: report at bugs.python.org (Jason R. Coombs)
Date: Tue, 08 Nov 2011 21:49:31 +0000
Subject: [issue13211] urllib2.HTTPError does not have 'reason' attribute.
In-Reply-To: <1318943168.93.0.520705450261.issue13211@psf.upfronthosting.co.za>
Message-ID: <1320788971.93.0.660533151988.issue13211@psf.upfronthosting.co.za>


Changes by Jason R. Coombs <jaraco at jaraco.com>:


----------
components: +Library (Lib)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13211>
_______________________________________

From report at bugs.python.org  Tue Nov  8 23:11:28 2011
From: report at bugs.python.org (Arnaud Ysmal)
Date: Tue, 08 Nov 2011 22:11:28 +0000
Subject: [issue13373] Unexpected blocking call to multiprocessing.Queue.get
	with a timeout
Message-ID: <1320790288.25.0.363329173413.issue13373@psf.upfronthosting.co.za>


New submission from Arnaud Ysmal <stacktic at netbsd.org>:

Using get(timeout=1) on a multiprocessing.Queue sometimes leads to a blocking get.

It seems that there is no check whether the timeout has expired after acquiring the lock but before the time.time(), which can cause a call to poll() with a negative timeout.

(patch attached)

----------
components: Library (Lib)
files: multiprocessing_queues.patch
keywords: patch
messages: 147319
nosy: stacktic
priority: normal
severity: normal
status: open
title: Unexpected blocking call to multiprocessing.Queue.get with a timeout
type: behavior
Added file: http://bugs.python.org/file23638/multiprocessing_queues.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13373>
_______________________________________

From report at bugs.python.org  Tue Nov  8 23:23:03 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 08 Nov 2011 22:23:03 +0000
Subject: [issue13373] Unexpected blocking call to multiprocessing.Queue.get
	with a timeout
In-Reply-To: <1320790288.25.0.363329173413.issue13373@psf.upfronthosting.co.za>
Message-ID: <1320790983.23.0.961561708624.issue13373@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +neologix
stage:  -> patch review
versions: +Python 2.7, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13373>
_______________________________________

From report at bugs.python.org  Tue Nov  8 23:25:17 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 08 Nov 2011 22:25:17 +0000
Subject: [issue13373] Unexpected blocking call to multiprocessing.Queue.get
	with a timeout
In-Reply-To: <1320790288.25.0.363329173413.issue13373@psf.upfronthosting.co.za>
Message-ID: <1320791117.36.0.780277919835.issue13373@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13373>
_______________________________________

From report at bugs.python.org  Tue Nov  8 23:41:08 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 08 Nov 2011 22:41:08 +0000
Subject: [issue7412] distutils install race condition
In-Reply-To: <1259571666.51.0.555227768726.issue7412@psf.upfronthosting.co.za>
Message-ID: <1320792068.32.0.155406925012.issue7412@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7412>
_______________________________________

From report at bugs.python.org  Tue Nov  8 23:42:27 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 08 Nov 2011 22:42:27 +0000
Subject: [issue11427] ctypes from_buffer no longer accepts bytes
In-Reply-To: <1299481885.21.0.0627562040827.issue11427@psf.upfronthosting.co.za>
Message-ID: <1320792147.34.0.0624834297457.issue11427@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +meador.inge

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11427>
_______________________________________

From report at bugs.python.org  Tue Nov  8 23:44:38 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 08 Nov 2011 22:44:38 +0000
Subject: [issue11082] ValueError: Content-Length should be specified
In-Reply-To: <1296501492.73.0.362770141375.issue11082@psf.upfronthosting.co.za>
Message-ID: <1320792278.29.0.02962434051.issue11082@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/issue11082>
_______________________________________

From report at bugs.python.org  Tue Nov  8 23:48:17 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 08 Nov 2011 22:48:17 +0000
Subject: [issue9257] cElementTree iterparse requires events as bytes;
	ElementTree uses strings
In-Reply-To: <1279078067.06.0.575324977312.issue9257@psf.upfronthosting.co.za>
Message-ID: <1320792497.15.0.600969053001.issue9257@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +flox
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9257>
_______________________________________

From report at bugs.python.org  Tue Nov  8 23:56:44 2011
From: report at bugs.python.org (Yury Selivanov)
Date: Tue, 08 Nov 2011 22:56:44 +0000
Subject: [issue11682] PEP 380 reference implementation for 3.3
In-Reply-To: <1301110605.68.0.392943983038.issue11682@psf.upfronthosting.co.za>
Message-ID: <1320793004.29.0.526189708894.issue11682@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:

It looks like there is a memory leak bug (on StopIteration exception instances).

Attached is the test to expose it.

It seems that adding 'Py_DECREF(e);' after 'PyErr_SetObject(PyExc_StopIteration, e);' in 'genobject.c' fixes the leak.

----------
Added file: http://bugs.python.org/file23639/test.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11682>
_______________________________________

From report at bugs.python.org  Wed Nov  9 00:08:48 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 08 Nov 2011 23:08:48 +0000
Subject: [issue13093] Redundant code in PyUnicode_EncodeDecimal()
In-Reply-To: <1317569955.86.0.21646060057.issue13093@psf.upfronthosting.co.za>
Message-ID: <1320793728.89.0.444256458476.issue13093@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +facundobatista, mark.dickinson, rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13093>
_______________________________________

From report at bugs.python.org  Wed Nov  9 00:38:59 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 08 Nov 2011 23:38:59 +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: <1320795539.28.0.0337162461819.issue12245@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

LGTM

----------
nosy: +ezio.melotti
stage:  -> commit review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12245>
_______________________________________

From report at bugs.python.org  Wed Nov  9 00:52:14 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 08 Nov 2011 23:52:14 +0000
Subject: [issue8025] TypeError: string argument expected, got 'str'
In-Reply-To: <1267200716.31.0.22497398995.issue8025@psf.upfronthosting.co.za>
Message-ID: <1320796334.3.0.680675063414.issue8025@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

This was fixed in #12434.

----------
assignee:  -> ezio.melotti
resolution:  -> duplicate
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8025>
_______________________________________

From report at bugs.python.org  Wed Nov  9 01:10:07 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 09 Nov 2011 00:10:07 +0000
Subject: [issue13374] Deprecate usage of the Windows ANSI API in the nt module
Message-ID: <1320797406.95.0.49629588961.issue13374@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

Attached patch deprecates the Windows ANSI API (bytes API) in the nt module. Use Unicode filenames instead of bytes filenames to not depend on the ANSI code page anymore and to support any Unicode filename.

The patch changes also os.link(), os.rename() and os.symlink() to not accept two filenames of different types: require two Unicode filenames or two bytes filenames. It is an expected change, it did it to simplify the source code. I change it if necessary.

----------
components: Library (Lib)
files: deprecate_win_bytes_api.patch
keywords: patch
messages: 147323
nosy: haypo
priority: normal
severity: normal
status: open
title: Deprecate usage of the Windows ANSI API in the nt module
versions: Python 3.3
Added file: http://bugs.python.org/file23640/deprecate_win_bytes_api.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13374>
_______________________________________

From report at bugs.python.org  Wed Nov  9 01:10:44 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Wed, 09 Nov 2011 00:10:44 +0000
Subject: [issue11082] ValueError: Content-Length should be specified
In-Reply-To: <1296501492.73.0.362770141375.issue11082@psf.upfronthosting.co.za>
Message-ID: <1320797444.81.0.897545318657.issue11082@psf.upfronthosting.co.za>


Senthil Kumaran <senthil at uthcode.com> added the comment:

Here is the docs patch which will help us close the issue. Addressing Eric's last comment - I believe the what's new and News for this issue was added with the feature, this one was Exception msg change.

----------
Added file: http://bugs.python.org/file23641/issue-11082-docs.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11082>
_______________________________________

From report at bugs.python.org  Wed Nov  9 01:12:14 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 09 Nov 2011 00:12:14 +0000
Subject: [issue13374] Deprecate usage of the Windows ANSI API in the nt module
In-Reply-To: <1320797406.95.0.49629588961.issue13374@psf.upfronthosting.co.za>
Message-ID: <E1RNvlr-0000bm-66@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 6bf07db23445 by Victor Stinner in branch 'default':
Issue #13374: Use Unicode filenames instead of bytes filenames
http://hg.python.org/cpython/rev/6bf07db23445

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13374>
_______________________________________

From report at bugs.python.org  Wed Nov  9 01:20:31 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 09 Nov 2011 00:20:31 +0000
Subject: [issue13374] Deprecate usage of the Windows ANSI API in the nt module
In-Reply-To: <1320797406.95.0.49629588961.issue13374@psf.upfronthosting.co.za>
Message-ID: <1320798031.39.0.394830611567.issue13374@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

The patch deprecates bytes filenames for the following functions:

nt._getfullpathname
nt._isdir
os.access
os.chdir
os.chmod
os.link
os.listdir
os.lstat
os.mkdir
os.open
os.rename
os.rmdir
os.stat
os.symlink
os.unlink
os.utime

Oh, I forgot a test for os.open(bytes).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13374>
_______________________________________

From report at bugs.python.org  Wed Nov  9 01:30:37 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 09 Nov 2011 00:30:37 +0000
Subject: [issue13374] Deprecate usage of the Windows ANSI API in the nt module
In-Reply-To: <1320797406.95.0.49629588961.issue13374@psf.upfronthosting.co.za>
Message-ID: <1320798637.91.0.92847411006.issue13374@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Functions like os.execv() or os.readlink() are not deprecated because the underlying C function really uses a bytes API (execv and readlink).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13374>
_______________________________________

From report at bugs.python.org  Wed Nov  9 01:38:24 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 09 Nov 2011 00:38:24 +0000
Subject: [issue13374] Deprecate usage of the Windows ANSI API in the nt module
In-Reply-To: <1320797406.95.0.49629588961.issue13374@psf.upfronthosting.co.za>
Message-ID: <1320799104.3.0.411909727836.issue13374@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
nosy: +loewis, mhammond

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13374>
_______________________________________

From report at bugs.python.org  Wed Nov  9 02:43:25 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 09 Nov 2011 01:43:25 +0000
Subject: [issue6570] Tutorial clarity: section 4.7.2, parameters and arguments
In-Reply-To: <1248510940.46.0.953855607394.issue6570@psf.upfronthosting.co.za>
Message-ID: <1320803005.22.0.836144602143.issue6570@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

def parrot(voltage, state='a stiff', action='voom', type='Norwegian Blue'):

+accepts one :term:`positional argument` (``voltage``) and three
+:term:`keyword arguments <keyword argument>` (``state``, ``action``,
+and ``type``).  

This is simply false. An argument for voltage is required, the other three are optional. I suggest something like the followinga:

Calls to this function require 1 to 4 arguments. An argument for voltage is required; arguements for the other three parameters are optional because they have default arguments specified.

Arguments can be matched to parameters by either position or 'keyword', where the keyword is the name of a parameter. The two conditions are that each parameter is matched to at most one argument and that keyword matches follow positional matches. The following matches 4 argumnts to the corresponding parameters by position:
  parrot(100, 'loose', 'skid', 'American Red')
This matches the same arguments by keyword (parameter name):
  parrot(state='loose', voltage=100, type='American Red', action='loose') 
Any order is acceptable for such 'keyword arguments'.
A call can mix the two matching methods. This
parrot(100, action='loose')
passes one argument each way and lets 'state' and 'type' get their default values of 'a stiff' and 'Norwegian Blue'.

< add minimal set of bad calls >

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6570>
_______________________________________

From report at bugs.python.org  Wed Nov  9 02:53:11 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 09 Nov 2011 01:53:11 +0000
Subject: [issue6570] Tutorial clarity: section 4.7.2, parameters and arguments
In-Reply-To: <1248510940.46.0.953855607394.issue6570@psf.upfronthosting.co.za>
Message-ID: <1320803591.67.0.494301646711.issue6570@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

> +accepts one :term:`positional argument` (``voltage``) and three
> +:term:`keyword arguments <keyword argument>` (``state``, ``action``,
> +and ``type``).  
>
> This is simply false. An argument for voltage is required, the other
> three are optional. I suggest something like the followinga:

That part refers to the function signature, not the function call.  I tried to avoid using the term "function signature" to avoid introducing yet another term, but maybe the two things should be separated a bit more.

I also tried to avoid the use of 'parameters' (the 'names' in the function signature) and 'arguments' (the actual values passed to the function when it's called) to keep the things simple and also because not everyone agrees on this terminology.

Would adding 'required' before 'positional' and 'optional' before 'keyword arguments' be ok?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6570>
_______________________________________

From report at bugs.python.org  Wed Nov  9 03:17:31 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 09 Nov 2011 02:17:31 +0000
Subject: [issue11082] ValueError: Content-Length should be specified
In-Reply-To: <1296501492.73.0.362770141375.issue11082@psf.upfronthosting.co.za>
Message-ID: <1320805051.27.0.103623311853.issue11082@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

I think the information in the patch should go in the urlopen doc, not in urlencode.  Adding a note to urlencode that says that the result must be encoded is fine, but all the details about the default encoding and the fact that an extra Content-Type header is necessary when the encoding is not iso-8859-1 belong to the urlopen doc IMHO.  (Is the header actually necessary?  I think I always sent utf-8 without header, and the example you added in r88394 also uses utf-8 with no extra headers.)
There are also a few minor issues with the patch -- I'll leave a note in rietveld for that.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11082>
_______________________________________

From report at bugs.python.org  Wed Nov  9 04:33:07 2011
From: report at bugs.python.org (Meador Inge)
Date: Wed, 09 Nov 2011 03:33:07 +0000
Subject: [issue11427] ctypes from_buffer no longer accepts bytes
In-Reply-To: <1299481885.21.0.0627562040827.issue11427@psf.upfronthosting.co.za>
Message-ID: <1320809587.38.0.492861558355.issue11427@psf.upfronthosting.co.za>


Meador Inge <meadori at gmail.com> added the comment:

I agree this is a regression.  I am looking more into it now.

----------
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11427>
_______________________________________

From report at bugs.python.org  Wed Nov  9 04:48:38 2011
From: report at bugs.python.org (Meador Inge)
Date: Wed, 09 Nov 2011 03:48:38 +0000
Subject: [issue13370] test_ctypes fails on osx 10.7
In-Reply-To: <1320761474.93.0.268896325495.issue13370@psf.upfronthosting.co.za>
Message-ID: <1320810518.07.0.613567744547.issue13370@psf.upfronthosting.co.za>


Changes by Meador Inge <meadori at gmail.com>:


----------
nosy: +meador.inge

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13370>
_______________________________________

From report at bugs.python.org  Wed Nov  9 04:51:46 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 09 Nov 2011 03:51:46 +0000
Subject: [issue6570] Tutorial clarity: section 4.7.2, parameters and arguments
In-Reply-To: <1248510940.46.0.953855607394.issue6570@psf.upfronthosting.co.za>
Message-ID: <1320810706.69.0.970666788993.issue6570@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

>Would adding 'required' before 'positional' and 'optional' before 'keyword arguments' be ok?

No! What is false in the original and the above is the equation and confusion of 'required' with 'positional' and 'optional' with 'keyword'. Required/optional is an argument property for all calls to a function as determined by the function definition.  Position/keyword is an argument property for each particular call as determined by the call itself (or the programmer thereof). The two contrasts are logically independent even if there is empirical correlation in the practice of some programmers. All arguments for parrot, both the required voltage argument and the three optional arguments, can be passed by either position or keyword. This is shown by the examples that pass both types of arguments both ways.

(Similarly, both required and optional args can be defined as (pass-by-)keyword-only arguments,
  >>> def f(a,b=2,*,c,d=4): return a,b,c,d
  >>> f(1,c=3)
  (1, 2, 3, 4)
though such possibilities are not relevant here.)

>> An argument for voltage is required, the other three are optional.

Prefix the above with "When calling this function,".

> That part refers to the function signature, not the function call.

I was specifically referring to calls. All parameters in a signature require an argument. A function signature may (optionally ;-) define an argument for any parameter as optional *in function call expressions* by giving an alternate default argument for the parameter.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6570>
_______________________________________

From report at bugs.python.org  Wed Nov  9 04:53:44 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 09 Nov 2011 03:53:44 +0000
Subject: [issue6570] Tutorial clarity: section 4.7.2, parameters and arguments
In-Reply-To: <1248510940.46.0.953855607394.issue6570@psf.upfronthosting.co.za>
Message-ID: <1320810824.51.0.661417210769.issue6570@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

OK, now I got what you mean.

I'll try to come up with a better patch then :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6570>
_______________________________________

From report at bugs.python.org  Wed Nov  9 08:22:39 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 09 Nov 2011 07:22:39 +0000
Subject: [issue13375] Provide a namedtuple style interface for os.walk values
Message-ID: <1320823358.89.0.0610537790817.issue13375@psf.upfronthosting.co.za>


New submission from Nick Coghlan <ncoghlan at gmail.com>:

The 3-tuple values yielded by os.walk could be made easier to work with in some use cases by offering a namedtuple style interface (similar to what is done with sys.float_info).

for dirinfo in os.walk(base_dir):
    print(dirinfo.path)
    print(dirinfo.subdirs)
    print(dirinfo.files)

----------
messages: 147334
nosy: ncoghlan
priority: normal
severity: normal
status: open
title: Provide a namedtuple style interface for os.walk values

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13375>
_______________________________________

From report at bugs.python.org  Wed Nov  9 08:23:01 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 09 Nov 2011 07:23:01 +0000
Subject: [issue13375] Provide a namedtuple style interface for os.walk values
In-Reply-To: <1320823358.89.0.0610537790817.issue13375@psf.upfronthosting.co.za>
Message-ID: <1320823381.95.0.851296999831.issue13375@psf.upfronthosting.co.za>


Changes by Nick Coghlan <ncoghlan at gmail.com>:


----------
stage:  -> needs patch
type:  -> feature request
versions: +Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13375>
_______________________________________

From report at bugs.python.org  Wed Nov  9 08:24:25 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 09 Nov 2011 07:24:25 +0000
Subject: [issue13229] Improve tools for iterating over filesystem directories
In-Reply-To: <1319076330.7.0.757546324527.issue13229@psf.upfronthosting.co.za>
Message-ID: <1320823465.12.0.14358822492.issue13229@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

A related idea is updating os.walk tuples to be a custom object offering a namedtuple style API (similar to sys.float_info).

I created a separate issue for that: #13375

I've also updated the title of this issue to describe the problem it aims to address rather than the specific solution that first occurred to me.

----------
title: Add shutil.filter_walk -> Improve tools for iterating over filesystem directories

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13229>
_______________________________________

From report at bugs.python.org  Wed Nov  9 08:59:15 2011
From: report at bugs.python.org (Sam Cates)
Date: Wed, 09 Nov 2011 07:59:15 +0000
Subject: [issue13376] readline: pre_input_hook not getting called
Message-ID: <1320825555.41.0.989618903693.issue13376@psf.upfronthosting.co.za>


New submission from Sam Cates <python.org at samcates.com>:

OS: Mac 10.7.2
Python: 2.7.1

Setting a pre input hook in readline has no effect.  This simple example illustrates the problem:

#!/usr/bin/python

import readline

def hook():
        readline.insert_text(' from pre_input_hook')
        readline.redisplay()

readline.set_pre_input_hook(hook)

while True:
        line = raw_input('Prompt ("stop" to quit): ')
        if line == 'stop':
                break
        print 'ENTERED: "%s"' % line


The hook never gets called, thus "from pre_input_hook" is never displayed.

----------
assignee: ronaldoussoren
components: Macintosh
messages: 147336
nosy: ronaldoussoren, scates
priority: normal
severity: normal
status: open
title: readline: pre_input_hook not getting called
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13376>
_______________________________________

From report at bugs.python.org  Wed Nov  9 09:36:51 2011
From: report at bugs.python.org (Ned Deily)
Date: Wed, 09 Nov 2011 08:36:51 +0000
Subject: [issue13376] readline: pre_input_hook not getting called
In-Reply-To: <1320825555.41.0.989618903693.issue13376@psf.upfronthosting.co.za>
Message-ID: <1320827811.62.0.82410390239.issue13376@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Since you mention 2.7.1, presumably you are using the Apple-suppled Python 2.7.1 in OS X.  That Python is not linked with GNU readline, rather the BSD libedit library.  As a workaround you could try installing the third-party readline package from PyPI which replaces the Python redline module with one that is statically linked with GNU readline (see  http://pypi.python.org/pypi/readline).  On the other hand, if there are more differences in behavior between Python readline linked with GNU readline and with BSD libedit, they should be documented.

----------
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13376>
_______________________________________

From report at bugs.python.org  Wed Nov  9 09:43:42 2011
From: report at bugs.python.org (Nicolas Bareil)
Date: Wed, 09 Nov 2011 08:43:42 +0000
Subject: [issue10441] some stdlib modules need to be updated to handle SSL
	certificate validation
In-Reply-To: <1289985992.42.0.118640057239.issue10441@psf.upfronthosting.co.za>
Message-ID: <1320828222.09.0.59329257887.issue10441@psf.upfronthosting.co.za>


Nicolas Bareil <nico at chdir.org> added the comment:

Hello,


Your patch about SSLContext is great! But what can we do about python 2.x?

I understand that we have to keep backward compatibility but something has to be done for improving current situation, even Paypal API (*) recommends using urllib.urlopen() to check sensitive things on HTTPS :(

If backporting SSLContext into python 2.x is not an option, what do you think about a DeprecationWarning at runtime?

Thanks,

(*) https://www.x.com/devzone/articles/getting-started-paypal-django
    And even the popular Django paypal module uses urllib2 
    https://github.com/johnboxall/django-paypal

----------
nosy: +nbareil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10441>
_______________________________________

From report at bugs.python.org  Wed Nov  9 09:44:01 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Wed, 09 Nov 2011 08:44:01 +0000
Subject: [issue13377] test_codecs "Segmentation fault" on Windows
Message-ID: <1320828241.01.0.210282714487.issue13377@psf.upfronthosting.co.za>


New submission from Vinay Sajip <vinay_sajip at yahoo.co.uk>:

test_codecs has started failing on Windows: I can't tell if the problem is in the tests.

== CPython 3.3.0a0 (default, Nov 8 2011, 22:34:51) [MSC v.1500 32 bit (Intel)]
==   Windows-7-6.1.7600 little-endian
==   c:\Users\Vinay\Projects\cpython\build\test_python_2612
Testing with flags: sys.flags(debug=0, inspect=0, interactive=0, optimize=0, dont_write_bytecode=0, no_user_site=0, no_site=0, ignore_environment=1, verbose=0, bytes_warning=2, quiet=0)
[1/1] test_codecs
test_badbom (test.test_codecs.UTF32Test) ... ok
test_bug1098990_a (test.test_codecs.UTF32Test) ... ok
test_bug1098990_b (test.test_codecs.UTF32Test) ... ok
test_bug1175396 (test.test_codecs.UTF32Test) ... ok
test_decoder_state (test.test_codecs.UTF32Test) ... ok
test_errors (test.test_codecs.UTF32Test) ... ok
test_handlers (test.test_codecs.UTF32Test) ... ok
test_issue8941 (test.test_codecs.UTF32Test) ... ok
test_only_one_bom (test.test_codecs.UTF32Test) ... ok
test_partial (test.test_codecs.UTF32Test) ... ok
test_readline (test.test_codecs.UTF32Test) ... ok
test_readlinequeue (test.test_codecs.UTF32Test) ... ok
test_bug1098990_a (test.test_codecs.UTF32LETest) ... ok
test_bug1098990_b (test.test_codecs.UTF32LETest) ... ok
test_bug1175396 (test.test_codecs.UTF32LETest) ... ok
test_errors (test.test_codecs.UTF32LETest) ... ok
test_issue8941 (test.test_codecs.UTF32LETest) ... ok
test_partial (test.test_codecs.UTF32LETest) ... ok
test_readline (test.test_codecs.UTF32LETest) ... ok
test_readlinequeue (test.test_codecs.UTF32LETest) ... ok
test_simple (test.test_codecs.UTF32LETest) ... ok
test_bug1098990_a (test.test_codecs.UTF32BETest) ... ok
test_bug1098990_b (test.test_codecs.UTF32BETest) ... ok
test_bug1175396 (test.test_codecs.UTF32BETest) ... ok
test_errors (test.test_codecs.UTF32BETest) ... ok
test_issue8941 (test.test_codecs.UTF32BETest) ... ok
test_partial (test.test_codecs.UTF32BETest) ... ok
test_readline (test.test_codecs.UTF32BETest) ... ok
test_readlinequeue (test.test_codecs.UTF32BETest) ... ok
test_simple (test.test_codecs.UTF32BETest) ... ok
test_badbom (test.test_codecs.UTF16Test) ... ok
test_bug1098990_a (test.test_codecs.UTF16Test) ... ok
test_bug1098990_b (test.test_codecs.UTF16Test) ... ok
test_bug1175396 (test.test_codecs.UTF16Test) ... ok
test_bug691291 (test.test_codecs.UTF16Test) ... ok
test_decoder_state (test.test_codecs.UTF16Test) ... ok
test_errors (test.test_codecs.UTF16Test) ... ok
test_handlers (test.test_codecs.UTF16Test) ... ok
test_only_one_bom (test.test_codecs.UTF16Test) ... ok
test_partial (test.test_codecs.UTF16Test) ... ok
test_readline (test.test_codecs.UTF16Test) ... ok
test_readlinequeue (test.test_codecs.UTF16Test) ... ok
test_bug1098990_a (test.test_codecs.UTF16LETest) ... ok
test_bug1098990_b (test.test_codecs.UTF16LETest) ... ok
test_bug1175396 (test.test_codecs.UTF16LETest) ... ok
test_errors (test.test_codecs.UTF16LETest) ... ok
test_nonbmp (test.test_codecs.UTF16LETest) ... ok
test_partial (test.test_codecs.UTF16LETest) ... ok
test_readline (test.test_codecs.UTF16LETest) ... ok
test_readlinequeue (test.test_codecs.UTF16LETest) ... ok
test_bug1098990_a (test.test_codecs.UTF16BETest) ... ok
test_bug1098990_b (test.test_codecs.UTF16BETest) ... ok
test_bug1175396 (test.test_codecs.UTF16BETest) ... ok
test_errors (test.test_codecs.UTF16BETest) ... ok
test_nonbmp (test.test_codecs.UTF16BETest) ... ok
test_partial (test.test_codecs.UTF16BETest) ... ok
test_readline (test.test_codecs.UTF16BETest) ... ok
test_readlinequeue (test.test_codecs.UTF16BETest) ... ok
test_bug1098990_a (test.test_codecs.UTF8Test) ... ok
test_bug1098990_b (test.test_codecs.UTF8Test) ... ok
test_bug1175396 (test.test_codecs.UTF8Test) ... ok
test_decoder_state (test.test_codecs.UTF8Test) ... ok
test_lone_surrogates (test.test_codecs.UTF8Test) ... ok
test_partial (test.test_codecs.UTF8Test) ... ok
test_readline (test.test_codecs.UTF8Test) ... ok
test_readlinequeue (test.test_codecs.UTF8Test) ... ok
test_surrogatepass_handler (test.test_codecs.UTF8Test) ... ok
test_bom (test.test_codecs.UTF8SigTest) ... ok
test_bug1098990_a (test.test_codecs.UTF8SigTest) ... ok
test_bug1098990_b (test.test_codecs.UTF8SigTest) ... ok
test_bug1175396 (test.test_codecs.UTF8SigTest) ... ok
test_bug1601501 (test.test_codecs.UTF8SigTest) ... ok
test_partial (test.test_codecs.UTF8SigTest) ... ok
test_readline (test.test_codecs.UTF8SigTest) ... ok
test_readlinequeue (test.test_codecs.UTF8SigTest) ... ok
test_stream_bare (test.test_codecs.UTF8SigTest) ... ok
test_stream_bom (test.test_codecs.UTF8SigTest) ... ok
test_bug1098990_a (test.test_codecs.CP65001Test) ... ok
test_bug1098990_b (test.test_codecs.CP65001Test) ... ok
test_bug1175396 (test.test_codecs.CP65001Test) ... ok
test_decode (test.test_codecs.CP65001Test) ... Fatal Python error: Segmentation fault

Current thread 0x00000a20:
  File "c:\Users\Vinay\Projects\cpython\lib\linecache.py", line 81 in updatecache
  File "c:\Users\Vinay\Projects\cpython\lib\linecache.py", line 41 in getlines
  File "c:\Users\Vinay\Projects\cpython\lib\linecache.py", line 15 in getline
  File "c:\Users\Vinay\Projects\cpython\lib\traceback.py", line 100 in extract_tb
  File "c:\Users\Vinay\Projects\cpython\lib\traceback.py", line 75 in format_tb
  File "c:\Users\Vinay\Projects\cpython\lib\traceback.py", line 186 in format_exception
  File "c:\Users\Vinay\Projects\cpython\lib\unittest\result.py", line 160 in _exc_info_to_string
  File "c:\Users\Vinay\Projects\cpython\lib\unittest\result.py", line 121 in addFailure
  File "c:\Users\Vinay\Projects\cpython\lib\unittest\result.py", line 17 in inner
  File "c:\Users\Vinay\Projects\cpython\lib\unittest\runner.py", line 75 in addFailure
  File "c:\Users\Vinay\Projects\cpython\lib\unittest\case.py", line 452 in run
  File "c:\Users\Vinay\Projects\cpython\lib\unittest\case.py", line 492 in __call__
  File "c:\Users\Vinay\Projects\cpython\lib\unittest\suite.py", line 105 in run
  File "c:\Users\Vinay\Projects\cpython\lib\unittest\suite.py", line 67 in __call__
  File "c:\Users\Vinay\Projects\cpython\lib\unittest\suite.py", line 105 in run
  File "c:\Users\Vinay\Projects\cpython\lib\unittest\suite.py", line 67 in __call__
  File "c:\Users\Vinay\Projects\cpython\lib\unittest\runner.py", line 168 in run
  File "c:\Users\Vinay\Projects\cpython\lib\test\support.py", line 1368 in _run_suite
  File "c:\Users\Vinay\Projects\cpython\lib\test\support.py", line 1402 in run_unittest
  File "c:\Users\Vinay\Projects\cpython\lib\test\test_codecs.py", line 2031 in test_main
  File "../lib/test/regrtest.py", line 1203 in runtest_inner
  File "../lib/test/regrtest.py", line 917 in runtest
  File "../lib/test/regrtest.py", line 709 in main
  File "../lib/test/regrtest.py", line 1780 in <module>

----------
components: Library (Lib), Tests, Windows
messages: 147339
nosy: vinay.sajip
priority: normal
severity: normal
status: open
title: test_codecs "Segmentation fault" on Windows
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13377>
_______________________________________

From report at bugs.python.org  Wed Nov  9 09:52:35 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Wed, 09 Nov 2011 08:52:35 +0000
Subject: [issue13377] test_codecs "Segmentation fault" on Windows
In-Reply-To: <1320828241.01.0.210282714487.issue13377@psf.upfronthosting.co.za>
Message-ID: <1320828755.16.0.961240162478.issue13377@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

FWIW, stack trace from VS 2008:


>	python33.dll!_PyLong_New(int size=0x00000002)  Line 145	C
 	python33.dll!PyLong_FromLong(long ival=0x000081b6)  Line 210 + 0x7 bytes	C
 	python33.dll!_pystat_fromstructstat(win32_stat * st=0x00000000)  Line 1726 + 0xc bytes	C
 	python33.dll!posix_do_stat(_object * self=0x1e047e3d, _object * args=0x00000000, char * format=0x1e12ffc0, int (const char *, win32_stat *)* statfunc=0x1e047e00, char * wformat=0x00000000, int (const wchar_t *, win32_stat *)* wstatfunc=0x1e043d60)  Line 1846 + 0x9 bytes	C
 	python33.dll!posix_stat(_object * self=0x013aa148, _object * args=0x02292c50)  Line 3335 + 0x1d bytes	C
 	python33.dll!PyCFunction_Call(_object * func=0x013aa328, _object * arg=0x02292c50, _object * kw=0x00000000)  Line 81 + 0x8 bytes	C
 	python33.dll!call_function(_object * * * pp_stack=0x0021e2fc, int oparg=0x00000000)  Line 4001 + 0x9a bytes	C
 	python33.dll!PyEval_EvalFrameEx(_frame * f=0x018c93f8, int throwflag=0x00000000)  Line 2628	C
 	python33.dll!PyEval_EvalCodeEx(_object * _co=0x01b9cac0, _object * globals=0x018c93f8, _object * locals=0x00000000, _object * * args=0x01e5a9b4, int argcount=0x00000002, _object * * kws=0x01e5a9bc, int kwcount=0x00000000, _object * * defs=0x017f665c, int defcount=0x00000001, _object * kwdefs=0x00000000, _object * closure=0x00000000)  Line 3376 + 0xc bytes	C
 	python33.dll!fast_function(_object * func=0x00000000, _object * * * pp_stack=0x0021e418, int n=0x00000002, int na=0x00000002, int nk=0x00000000)  Line 4102 + 0x39 bytes	C
 	python33.dll!call_function(_object * * * pp_stack=0x0021e418, int oparg=0x00000000)  Line 4022 + 0x10 bytes	C
 	python33.dll!PyEval_EvalFrameEx(_frame * f=0x01e5a870, int throwflag=0x00000000)  Line 2628	C
 	python33.dll!PyEval_EvalCodeEx(_object * _co=0x01b9c980, _object * globals=0x01e5a870, _object * locals=0x00000000, _object * * args=0x01e5e45c, int argcount=0x00000002, _object * * kws=0x01e5e464, int kwcount=0x00000000, _object * * defs=0x01b9283c, int defcount=0x00000001, _object * kwdefs=0x00000000, _object * closure=0x00000000)  Line 3376 + 0xc bytes	C
 	python33.dll!fast_function(_object * func=0x00000000, _object * * * pp_stack=0x0021e534, int n=0x00000002, int na=0x00000002, int nk=0x00000000)  Line 4102 + 0x39 bytes	C
 	python33.dll!call_function(_object * * * pp_stack=0x0021e534, int oparg=0x00000000)  Line 4022 + 0x10 bytes	C
 	python33.dll!PyEval_EvalFrameEx(_frame * f=0x01e5e310, int throwflag=0x00000000)  Line 2628	C
 	python33.dll!PyEval_EvalCodeEx(_object * _co=0x01b9c8e0, _object * globals=0x01e5e310, _object * locals=0x00000000, _object * * args=0x01e5b7d4, int argcount=0x00000003, _object * * kws=0x01e5b7e0, int kwcount=0x00000000, _object * * defs=0x01b9287c, int defcount=0x00000001, _object * kwdefs=0x00000000, _object * closure=0x00000000)  Line 3376 + 0xc bytes	C
 	python33.dll!fast_function(_object * func=0x00000000, _object * * * pp_stack=0x0021e650, int n=0x00000003, int na=0x00000003, int nk=0x00000000)  Line 4102 + 0x39 bytes	C
 	python33.dll!call_function(_object * * * pp_stack=0x0021e650, int oparg=0x00000000)  Line 4022 + 0x10 bytes	C
 	python33.dll!PyEval_EvalFrameEx(_frame * f=0x01e5b670, int throwflag=0x00000000)  Line 2628	C
 	python33.dll!PyEval_EvalCodeEx(_object * _co=0x01735610, _object * globals=0x01e5b670, _object * locals=0x00000000, _object * * args=0x01e48cb8, int argcount=0x00000002, _object * * kws=0x01e48cc0, int kwcount=0x00000000, _object * * defs=0x0172623c, int defcount=0x00000001, _object * kwdefs=0x00000000, _object * closure=0x00000000)  Line 3376 + 0xc bytes	C
 	python33.dll!fast_function(_object * func=0x00000000, _object * * * pp_stack=0x0021e76c, int n=0x00000002, int na=0x00000002, int nk=0x00000000)  Line 4102 + 0x39 bytes	C
 	python33.dll!call_function(_object * * * pp_stack=0x0021e76c, int oparg=0x00000000)  Line 4022 + 0x10 bytes	C
 	python33.dll!PyEval_EvalFrameEx(_frame * f=0x01e48b70, int throwflag=0x00000000)  Line 2628	C
 	python33.dll!PyEval_EvalCodeEx(_object * _co=0x017355c0, _object * globals=0x01e48b70, _object * locals=0x00000000, _object * * args=0x01e3b790, int argcount=0x00000002, _object * * kws=0x01e3b798, int kwcount=0x00000000, _object * * defs=0x0172621c, int defcount=0x00000001, _object * kwdefs=0x00000000, _object * closure=0x00000000)  Line 3376 + 0xc bytes	C
 	python33.dll!fast_function(_object * func=0x00000000, _object * * * pp_stack=0x0021e888, int n=0x00000002, int na=0x00000002, int nk=0x00000000)  Line 4102 + 0x39 bytes	C
 	python33.dll!call_function(_object * * * pp_stack=0x0021e888, int oparg=0x00000000)  Line 4022 + 0x10 bytes	C
 	python33.dll!PyEval_EvalFrameEx(_frame * f=0x01e3b630, int throwflag=0x00000000)  Line 2628	C
 	python33.dll!PyEval_EvalCodeEx(_object * _co=0x01735700, _object * globals=0x01e3b630, _object * locals=0x00000000, _object * * args=0x01e5b644, int argcount=0x00000004, _object * * kws=0x01e5b654, int kwcount=0x00000000, _object * * defs=0x0173085c, int defcount=0x00000002, _object * kwdefs=0x00000000, _object * closure=0x00000000)  Line 3376 + 0xc bytes	C
 	python33.dll!fast_function(_object * func=0x00000000, _object * * * pp_stack=0x0021e9a4, int n=0x00000004, int na=0x00000004, int nk=0x00000000)  Line 4102 + 0x39 bytes	C
 	python33.dll!call_function(_object * * * pp_stack=0x0021e9a4, int oparg=0x00000000)  Line 4022 + 0x10 bytes	C
 	python33.dll!PyEval_EvalFrameEx(_frame * f=0x01e5b4e0, int throwflag=0x00000000)  Line 2628	C
 	python33.dll!fast_function(_object * func=0x00000000, _object * * * pp_stack=0x0021ea64, int n=0x00000003, int na=0x00000003, int nk=0x00000000)  Line 4090	C
 	python33.dll!call_function(_object * * * pp_stack=0x0021ea64, int oparg=0x00000000)  Line 4022 + 0x10 bytes	C
 	python33.dll!PyEval_EvalFrameEx(_frame * f=0x01e5e1a0, int throwflag=0x00000000)  Line 2628	C
 	python33.dll!PyEval_EvalCodeEx(_object * _co=0x01b15660, _object * globals=0x01e5e1a0, _object * locals=0x00000000, _object * * args=0x01e4d474, int argcount=0x00000003, _object * * kws=0x0131705c, int kwcount=0x00000000, _object * * defs=0x00000000, int defcount=0x00000000, _object * kwdefs=0x00000000, _object * closure=0x00000000)  Line 3376 + 0xc bytes	C
 	python33.dll!function_call(_object * func=0x01b14bb8, _object * arg=0x01e4d468, _object * kw=0x01e4b420)  Line 635 + 0x2e bytes	C
 	python33.dll!PyObject_Call(_object * func=0x01b14bb8, _object * arg=0x01e4d468, _object * kw=0x01e4b420)  Line 2150 + 0xd bytes	C
 	python33.dll!ext_do_call(_object * func=0x01b14bb8, _object * * * pp_stack=0x00000000, int flags=0x00000003, int na=0x00000001, int nk=0x00000000)  Line 4316 + 0x8 bytes	C
 	python33.dll!PyEval_EvalFrameEx(_frame * f=0x01e5e030, int throwflag=0x00000000)  Line 2669	C
 	python33.dll!PyEval_EvalCodeEx(_object * _co=0x01b177f0, _object * globals=0x01e5e030, _object * locals=0x00000000, _object * * args=0x01e489e8, int argcount=0x00000003, _object * * kws=0x01e489f4, int kwcount=0x00000000, _object * * defs=0x00000000, int defcount=0x00000000, _object * kwdefs=0x00000000, _object * closure=0x01ca6ef0)  Line 3376 + 0xc bytes	C
 	python33.dll!fast_function(_object * func=0x00000000, _object * * * pp_stack=0x0021ecc8, int n=0x00000003, int na=0x00000003, int nk=0x00000000)  Line 4102 + 0x39 bytes	C
 	python33.dll!call_function(_object * * * pp_stack=0x0021ecc8, int oparg=0x00000000)  Line 4022 + 0x10 bytes	C
 	python33.dll!PyEval_EvalFrameEx(_frame * f=0x01e488a0, int throwflag=0x00000000)  Line 2628	C
 	python33.dll!PyEval_EvalCodeEx(_object * _co=0x01b4bd90, _object * globals=0x01e488a0, _object * locals=0x00000000, _object * * args=0x01c6c198, int argcount=0x00000003, _object * * kws=0x01c6c1a4, int kwcount=0x00000000, _object * * defs=0x00000000, int defcount=0x00000000, _object * kwdefs=0x00000000, _object * closure=0x01e79470)  Line 3376 + 0xc bytes	C
 	python33.dll!fast_function(_object * func=0x00000000, _object * * * pp_stack=0x0021ede4, int n=0x00000003, int na=0x00000003, int nk=0x00000000)  Line 4102 + 0x39 bytes	C
 	python33.dll!call_function(_object * * * pp_stack=0x0021ede4, int oparg=0x00000000)  Line 4022 + 0x10 bytes	C
 	python33.dll!PyEval_EvalFrameEx(_frame * f=0x01c6c030, int throwflag=0x00000000)  Line 2628	C
 	python33.dll!PyEval_EvalCodeEx(_object * _co=0x01b2a160, _object * globals=0x01c6c030, _object * locals=0x00000000, _object * * args=0x022fc8d4, int argcount=0x00000002, _object * * kws=0x0131705c, int kwcount=0x00000000, _object * * defs=0x01b3423c, int defcount=0x00000001, _object * kwdefs=0x00000000, _object * closure=0x00000000)  Line 3376 + 0xc bytes	C
 	python33.dll!function_call(_object * func=0x01b3da08, _object * arg=0x022fc8c8, _object * kw=0x01c68a50)  Line 635 + 0x2e bytes	C
 	python33.dll!PyObject_Call(_object * func=0x01b3da08, _object * arg=0x022fc8c8, _object * kw=0x01c68a50)  Line 2150 + 0xd bytes	C
 	python33.dll!ext_do_call(_object * func=0x01b3da08, _object * * * pp_stack=0x00000000, int flags=0x00000003, int na=0x00000001, int nk=0x00000000)  Line 4316 + 0x8 bytes	C
 	python33.dll!PyEval_EvalFrameEx(_frame * f=0x01c6b300, int throwflag=0x00000000)  Line 2669	C
 	python33.dll!PyEval_EvalCodeEx(_object * _co=0x01b2a250, _object * globals=0x01c6b300, _object * locals=0x00000000, _object * * args=0x01d6f35c, int argcount=0x00000002, _object * * kws=0x00000000, int kwcount=0x00000000, _object * * defs=0x00000000, int defcount=0x00000000, _object * kwdefs=0x00000000, _object * closure=0x00000000)  Line 3376 + 0xc bytes	C
 	python33.dll!function_call(_object * func=0x01b3da98, _object * arg=0x01d6f350, _object * kw=0x00000000)  Line 635 + 0x2e bytes	C
 	python33.dll!PyObject_Call(_object * func=0x01b3da98, _object * arg=0x01d6f350, _object * kw=0x00000000)  Line 2150 + 0xd bytes	C
 	python33.dll!method_call(_object * func=0x01b3da98, _object * arg=0x02292930, _object * kw=0x00000000)  Line 320 + 0x10 bytes	C
 	python33.dll!PyObject_Call(_object * func=0x022fe918, _object * arg=0x02292930, _object * kw=0x00000000)  Line 2150 + 0xd bytes	C
 	python33.dll!slot_tp_call(_object * self=0x024390d0, _object * args=0x02292930, _object * kwds=0x00000000)  Line 5229 + 0x11 bytes	C
 	python33.dll!PyObject_Call(_object * func=0x024390d0, _object * arg=0x02292930, _object * kw=0x00000000)  Line 2150 + 0xd bytes	C
 	python33.dll!do_call(_object * func=0x024390d0, _object * * * pp_stack=0x00000000, int na=0x00000001, int nk=0x00000000)  Line 4221 + 0x8 bytes	C
 	python33.dll!call_function(_object * * * pp_stack=0x0021f0f0, int oparg=0x00000000)  Line 4024 + 0x9 bytes	C
 	python33.dll!PyEval_EvalFrameEx(_frame * f=0x02307900, int throwflag=0x00000000)  Line 2628	C
 	python33.dll!PyEval_EvalCodeEx(_object * _co=0x01b3b8e0, _object * globals=0x02307900, _object * locals=0x00000000, _object * * args=0x022faeec, int argcount=0x00000002, _object * * kws=0x0131705c, int kwcount=0x00000000, _object * * defs=0x01b4409c, int defcount=0x00000001, _object * kwdefs=0x00000000, _object * closure=0x00000000)  Line 3376 + 0xc bytes	C
 	python33.dll!function_call(_object * func=0x01b40f60, _object * arg=0x022faee0, _object * kw=0x01c689c0)  Line 635 + 0x2e bytes	C
 	python33.dll!PyObject_Call(_object * func=0x01b40f60, _object * arg=0x022faee0, _object * kw=0x01c689c0)  Line 2150 + 0xd bytes	C
 	python33.dll!ext_do_call(_object * func=0x01b40f60, _object * * * pp_stack=0x00000000, int flags=0x00000003, int na=0x00000001, int nk=0x00000000)  Line 4316 + 0x8 bytes	C
 	python33.dll!PyEval_EvalFrameEx(_frame * f=0x01c59e40, int throwflag=0x00000000)  Line 2669	C
 	python33.dll!PyEval_EvalCodeEx(_object * _co=0x01b3b7f0, _object * globals=0x01c59e40, _object * locals=0x00000000, _object * * args=0x022fb5b4, int argcount=0x00000002, _object * * kws=0x00000000, int kwcount=0x00000000, _object * * defs=0x00000000, int defcount=0x00000000, _object * kwdefs=0x00000000, _object * closure=0x00000000)  Line 3376 + 0xc bytes	C
 	python33.dll!function_call(_object * func=0x01b40ed0, _object * arg=0x022fb5a8, _object * kw=0x00000000)  Line 635 + 0x2e bytes	C
 	python33.dll!PyObject_Call(_object * func=0x01b40ed0, _object * arg=0x022fb5a8, _object * kw=0x00000000)  Line 2150 + 0xd bytes	C
 	python33.dll!method_call(_object * func=0x01b40ed0, _object * arg=0x02292870, _object * kw=0x00000000)  Line 320 + 0x10 bytes	C
 	python33.dll!PyObject_Call(_object * func=0x022fe8f0, _object * arg=0x02292870, _object * kw=0x00000000)  Line 2150 + 0xd bytes	C
 	python33.dll!slot_tp_call(_object * self=0x02439030, _object * args=0x02292870, _object * kwds=0x00000000)  Line 5229 + 0x11 bytes	C
 	python33.dll!PyObject_Call(_object * func=0x02439030, _object * arg=0x02292870, _object * kw=0x00000000)  Line 2150 + 0xd bytes	C
 	python33.dll!do_call(_object * func=0x02439030, _object * * * pp_stack=0x00000000, int na=0x00000001, int nk=0x00000000)  Line 4221 + 0x8 bytes	C
 	python33.dll!call_function(_object * * * pp_stack=0x0021f3fc, int oparg=0x00000000)  Line 4024 + 0x9 bytes	C
 	python33.dll!PyEval_EvalFrameEx(_frame * f=0x02307788, int throwflag=0x00000000)  Line 2628	C
 	python33.dll!PyEval_EvalCodeEx(_object * _co=0x01b3b8e0, _object * globals=0x02307788, _object * locals=0x00000000, _object * * args=0x022fa1f4, int argcount=0x00000002, _object * * kws=0x0131705c, int kwcount=0x00000000, _object * * defs=0x01b4409c, int defcount=0x00000001, _object * kwdefs=0x00000000, _object * closure=0x00000000)  Line 3376 + 0xc bytes	C
 	python33.dll!function_call(_object * func=0x01b40f60, _object * arg=0x022fa1e8, _object * kw=0x01c68930)  Line 635 + 0x2e bytes	C
 	python33.dll!PyObject_Call(_object * func=0x01b40f60, _object * arg=0x022fa1e8, _object * kw=0x01c68930)  Line 2150 + 0xd bytes	C
 	python33.dll!ext_do_call(_object * func=0x01b40f60, _object * * * pp_stack=0x00000000, int flags=0x00000003, int na=0x00000001, int nk=0x00000000)  Line 4316 + 0x8 bytes	C
 	python33.dll!PyEval_EvalFrameEx(_frame * f=0x01c59cd8, int throwflag=0x00000000)  Line 2669	C
 	python33.dll!PyEval_EvalCodeEx(_object * _co=0x01b3b7f0, _object * globals=0x01c59cd8, _object * locals=0x00000000, _object * * args=0x02297884, int argcount=0x00000002, _object * * kws=0x00000000, int kwcount=0x00000000, _object * * defs=0x00000000, int defcount=0x00000000, _object * kwdefs=0x00000000, _object * closure=0x00000000)  Line 3376 + 0xc bytes	C
 	python33.dll!function_call(_object * func=0x01b40ed0, _object * arg=0x02297878, _object * kw=0x00000000)  Line 635 + 0x2e bytes	C
 	python33.dll!PyObject_Call(_object * func=0x01b40ed0, _object * arg=0x02297878, _object * kw=0x00000000)  Line 2150 + 0xd bytes	C
 	python33.dll!method_call(_object * func=0x01b40ed0, _object * arg=0x01e997b0, _object * kw=0x00000000)  Line 320 + 0x10 bytes	C
 	python33.dll!PyObject_Call(_object * func=0x01b280a8, _object * arg=0x01e997b0, _object * kw=0x00000000)  Line 2150 + 0xd bytes	C
 	python33.dll!slot_tp_call(_object * self=0x022958b0, _object * args=0x01e997b0, _object * kwds=0x00000000)  Line 5229 + 0x11 bytes	C
 	python33.dll!PyObject_Call(_object * func=0x022958b0, _object * arg=0x01e997b0, _object * kw=0x00000000)  Line 2150 + 0xd bytes	C
 	python33.dll!do_call(_object * func=0x022958b0, _object * * * pp_stack=0x00000000, int na=0x00000001, int nk=0x00000000)  Line 4221 + 0x8 bytes	C
 	python33.dll!call_function(_object * * * pp_stack=0x0021f708, int oparg=0x00000000)  Line 4024 + 0x9 bytes	C
 	python33.dll!PyEval_EvalFrameEx(_frame * f=0x01c6a030, int throwflag=0x00000000)  Line 2628	C
 	python33.dll!fast_function(_object * func=0x00000000, _object * * * pp_stack=0x0021f7c8, int n=0x00000002, int na=0x00000002, int nk=0x00000000)  Line 4090	C
 	python33.dll!call_function(_object * * * pp_stack=0x0021f7c8, int oparg=0x00000000)  Line 4022 + 0x10 bytes	C
 	python33.dll!PyEval_EvalFrameEx(_frame * f=0x02307498, int throwflag=0x00000000)  Line 2628	C
 	python33.dll!fast_function(_object * func=0x00000000, _object * * * pp_stack=0x0021f888, int n=0x00000001, int na=0x00000001, int nk=0x00000000)  Line 4090	C
 	python33.dll!call_function(_object * * * pp_stack=0x0021f888, int oparg=0x00000000)  Line 4022 + 0x10 bytes	C
 	python33.dll!PyEval_EvalFrameEx(_frame * f=0x02307320, int throwflag=0x00000000)  Line 2628	C
 	python33.dll!PyEval_EvalCodeEx(_object * _co=0x01ea0d40, _object * globals=0x02307320, _object * locals=0x00000000, _object * * args=0x022ac6ac, int argcount=0x0000001c, _object * * kws=0x022ac71c, int kwcount=0x00000000, _object * * defs=0x00000000, int defcount=0x00000000, _object * kwdefs=0x00000000, _object * closure=0x00000000)  Line 3376 + 0xc bytes	C
 	python33.dll!fast_function(_object * func=0x00000000, _object * * * pp_stack=0x0021f9a4, int n=0x0000001c, int na=0x0000001c, int nk=0x00000000)  Line 4102 + 0x39 bytes	C
 	python33.dll!call_function(_object * * * pp_stack=0x0021f9a4, int oparg=0x00000000)  Line 4022 + 0x10 bytes	C
 	python33.dll!PyEval_EvalFrameEx(_frame * f=0x022ac570, int throwflag=0x00000000)  Line 2628	C
 	python33.dll!fast_function(_object * func=0x00000000, _object * * * pp_stack=0x0021fa64, int n=0x00000000, int na=0x00000000, int nk=0x00000000)  Line 4090	C
 	python33.dll!call_function(_object * * * pp_stack=0x0021fa64, int oparg=0x00000000)  Line 4022 + 0x10 bytes	C
 	python33.dll!PyEval_EvalFrameEx(_frame * f=0x02306030, int throwflag=0x00000000)  Line 2628	C
 	python33.dll!PyEval_EvalCodeEx(_object * _co=0x01819110, _object * globals=0x02306030, _object * locals=0x00000000, _object * * args=0x01c4774c, int argcount=0x00000005, _object * * kws=0x01c47760, int kwcount=0x00000001, _object * * defs=0x01ea562c, int defcount=0x00000003, _object * kwdefs=0x00000000, _object * closure=0x00000000)  Line 3376 + 0xc bytes	C
 	python33.dll!fast_function(_object * func=0x00000000, _object * * * pp_stack=0x0021fb80, int n=0x00000007, int na=0x00000005, int nk=0x00000001)  Line 4102 + 0x39 bytes	C
 	python33.dll!call_function(_object * * * pp_stack=0x0021fb80, int oparg=0x00000000)  Line 4022 + 0x10 bytes	C
 	python33.dll!PyEval_EvalFrameEx(_frame * f=0x01c475d0, int throwflag=0x00000000)  Line 2628	C
 	python33.dll!PyEval_EvalCodeEx(_object * _co=0x017590c0, _object * globals=0x01c475d0, _object * locals=0x00000000, _object * * args=0x017a58ec, int argcount=0x00000005, _object * * kws=0x017a5900, int kwcount=0x00000004, _object * * defs=0x01e91774, int defcount=0x00000007, _object * kwdefs=0x00000000, _object * closure=0x00000000)  Line 3376 + 0xc bytes	C
 	python33.dll!fast_function(_object * func=0x00000000, _object * * * pp_stack=0x0021fc9c, int n=0x0000000d, int na=0x00000005, int nk=0x00000004)  Line 4102 + 0x39 bytes	C
 	python33.dll!call_function(_object * * * pp_stack=0x0021fc9c, int oparg=0x00000000)  Line 4022 + 0x10 bytes	C
 	python33.dll!PyEval_EvalFrameEx(_frame * f=0x017a5610, int throwflag=0x00000000)  Line 2628	C
 	python33.dll!PyEval_EvalCodeEx(_object * _co=0x01747980, _object * globals=0x017a5610, _object * locals=0x00000000, _object * * args=0x017ac1f0, int argcount=0x00000000, _object * * kws=0x017ac1f0, int kwcount=0x00000000, _object * * defs=0x01d79474, int defcount=0x00000017, _object * kwdefs=0x00000000, _object * closure=0x00000000)  Line 3376 + 0xc bytes	C
 	python33.dll!fast_function(_object * func=0x00000000, _object * * * pp_stack=0x0021fdb8, int n=0x00000000, int na=0x00000000, int nk=0x00000000)  Line 4102 + 0x39 bytes	C
 	python33.dll!call_function(_object * * * pp_stack=0x0021fdb8, int oparg=0x00000000)  Line 4022 + 0x10 bytes	C
 	python33.dll!PyEval_EvalFrameEx(_frame * f=0x017ac0b0, int throwflag=0x00000000)  Line 2628	C
 	python33.dll!PyEval_EvalCodeEx(_object * _co=0x01819750, _object * globals=0x017ac0b0, _object * locals=0x013544b0, _object * * args=0x00000000, int argcount=0x00000000, _object * * kws=0x00000000, int kwcount=0x00000000, _object * * defs=0x00000000, int defcount=0x00000000, _object * kwdefs=0x00000000, _object * closure=0x00000000)  Line 3376 + 0xc bytes	C
 	python33.dll!PyEval_EvalCode(_object * co=0x01819750, _object * globals=0x013544b0, _object * locals=0x013544b0)  Line 776 + 0x24 bytes	C
 	python33.dll!run_mod(_mod * mod=0x018b6c20, const char * filename=0x00000000, _object * globals=0x013544b0, _object * locals=0x013544b0, PyCompilerFlags * flags=0x00000000, _arena * arena=0x00000000)  Line 1814 + 0x11 bytes	C
 	python33.dll!PyRun_FileExFlags(_iobuf * fp=0x6e2a7408, const char * filename=0x01c04eb8, int start=0x00000101, _object * globals=0x013544b0, _object * locals=0x013544b0, int closeit=0x00000001, PyCompilerFlags * flags=0x0021ff08)  Line 1771	C
 	python33.dll!PyRun_SimpleFileExFlags(_iobuf * fp=0x6e2a7408, const char * filename=0x01c04eb8, int closeit=0x00000001, PyCompilerFlags * flags=0x0021ff08)  Line 1288 + 0x18 bytes	C
 	python33.dll!PyRun_AnyFileExFlags(_iobuf * fp=0x6e2a7408, const char * filename=0x01c04eb8, int closeit=0x00000001, PyCompilerFlags * flags=0x0021ff08)  Line 1055 + 0x11 bytes	C
 	python33.dll!run_file(_iobuf * fp=0x6e2a7408, const wchar_t * filename=0x01301b5a, PyCompilerFlags * p_cf=0x0021ff08)  Line 299 + 0x18 bytes	C
 	python33.dll!Py_Main(int argc=0x00000007, unsigned short * * argv=0x01301b10)  Line 693 + 0xf bytes	C
 	python.exe!__tmainCRTStartup()  Line 583 + 0x17 bytes	C
 	kernel32.dll!76951114() 	
 	[Frames below may be incorrect and/or missing, no symbols loaded for kernel32.dll]	
 	ntdll.dll!76efb429() 	
 	ntdll.dll!76efb3fc()

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13377>
_______________________________________

From report at bugs.python.org  Wed Nov  9 10:07:42 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Wed, 09 Nov 2011 09:07:42 +0000
Subject: [issue10441] some stdlib modules need to be updated to handle
	SSL	certificate validation
In-Reply-To: <1320828222.09.0.59329257887.issue10441@psf.upfronthosting.co.za>
Message-ID: <4EBA42D4.5060205@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> Your patch about SSLContext is great! But what can we do about python 2.x?

Adding new features to Python 2.7 is certainly not an option.

> what do you think about a DeprecationWarning at runtime?

What API exactly should this deprecate?

----------
title: some stdlib modules need to be updated to handle SSL certificate validation -> some stdlib modules need to be updated to handle SSL	certificate validation

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10441>
_______________________________________

From report at bugs.python.org  Wed Nov  9 10:17:48 2011
From: report at bugs.python.org (Nicolas Bareil)
Date: Wed, 09 Nov 2011 09:17:48 +0000
Subject: [issue10441] some stdlib modules need to be updated to handle
	SSL	certificate validation
In-Reply-To: <4EBA42D4.5060205@v.loewis.de> ("Martin v. Löwis"'s message of "Wed, 09 Nov 2011 09:07:42 +0000")
Message-ID: <878vnphcy8.fsf@puppet.chdir.org>


Nicolas Bareil <nico at chdir.org> added the comment:

Martin v. L?wis <report at bugs.python.org> writes:
>> what do you think about a DeprecationWarning at runtime?
>
> What API exactly should this deprecate?

Ooops, lapsus. I was thinking about a RuntimeWarning raised on HTTPS
request (in httplib.HTTPSConnection.connect for instance).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10441>
_______________________________________

From report at bugs.python.org  Wed Nov  9 10:19:17 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 09 Nov 2011 09:19:17 +0000
Subject: [issue13377] test_codecs "Segmentation fault" on Windows
In-Reply-To: <1320828241.01.0.210282714487.issue13377@psf.upfronthosting.co.za>
Message-ID: <1320830357.24.0.583969599465.issue13377@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

I may be related to recent changes on codecs. My following commit fixed a test_codecs crash, but there is maybe another bug.

changeset:   73466:9042d71962d6
user:        Victor Stinner <victor.stinner at haypocalc.com>
date:        Wed Nov 09 00:02:18 2011 +0100
files:       Objects/unicodeobject.c
description:
Fix the code page decoder

 * unicode_decode_call_errorhandler() now supports the PyUnicode_WCHAR_KIND
   kind
 * unicode_decode_call_errorhandler() calls copy_characters() instead of
   PyUnicode_CopyCharacters()

----------
nosy: +haypo, loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13377>
_______________________________________

From report at bugs.python.org  Wed Nov  9 10:25:15 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 09 Nov 2011 09:25:15 +0000
Subject: [issue13377] test_codecs "Segmentation fault" on Windows
In-Reply-To: <1320828241.01.0.210282714487.issue13377@psf.upfronthosting.co.za>
Message-ID: <1320830715.79.0.581104271375.issue13377@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

The test doesn't crash on our Windows buildbots. Please try to update. If the problem does still exist, reopen the issue.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13377>
_______________________________________

From report at bugs.python.org  Wed Nov  9 10:37:35 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Wed, 09 Nov 2011 09:37:35 +0000
Subject: [issue13377] test_codecs "Segmentation fault" on Windows
In-Reply-To: <1320828241.01.0.210282714487.issue13377@psf.upfronthosting.co.za>
Message-ID: <1320831455.03.0.561669473555.issue13377@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Why was the change necessary? unicode_decode_call_errorhandler shouldn't be called with WSTR strings (i.e. it is only intended to support ready strings).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13377>
_______________________________________

From report at bugs.python.org  Wed Nov  9 10:49:57 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 09 Nov 2011 09:49:57 +0000
Subject: [issue13377] test_codecs "Segmentation fault" on Windows
In-Reply-To: <1320828241.01.0.210282714487.issue13377@psf.upfronthosting.co.za>
Message-ID: <1320832197.87.0.78033027034.issue13377@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> Why was the change necessary?

First because unicode_decode_call_errorhandler() was called with the wrong argument count:

    1.90 -                    v, &outpos, &out))
    1.91 +                    v, &outpos))

decode_code_page_errors() calls MultiByteToWideChar() which expects a wchar_t* buffer.

Compute the maximum character requires to decode the full string. I prefer to work on a wchar_t* string to only decode surrogate pairs and computer the maximum character once.

decode_code_page_errors() can also be called on a substring of a longer string, decode_code_page_strict() can be called for the other part.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13377>
_______________________________________

From report at bugs.python.org  Wed Nov  9 11:17:04 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 09 Nov 2011 10:17:04 +0000
Subject: [issue11682] PEP 380 reference implementation for 3.3
In-Reply-To: <1301110605.68.0.392943983038.issue11682@psf.upfronthosting.co.za>
Message-ID: <1320833824.19.0.616075685755.issue11682@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

In reviewing Zbyszek's doc updates and comparing them against the Grammar, I discovered a gratuitous change in the implementation: it allows a bare (i.e. no parentheses) 'yield from' as an argument to a function, even when there's multiple arguments. By contrast, an ordinary yield expression requires parentheses everywhere other than when it's being used as a statement, or as the sole expression on the RHS of an assignment.

I'll add a new test to ensure "yield from x" requires parentheses whenever "yield x" requires them (and fix the Grammar file on the implementation branch accordingly).

I've also pushed a fix to the branch for the refleak Yury pointed out (once I actually ran regrtest in refleak hunting mode it also pointed out that there was a problem, so I know his suggested change definitely fixed it).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11682>
_______________________________________

From report at bugs.python.org  Wed Nov  9 12:00:22 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 09 Nov 2011 11:00:22 +0000
Subject: [issue11682] PEP 380 reference implementation for 3.3
In-Reply-To: <1301110605.68.0.392943983038.issue11682@psf.upfronthosting.co.za>
Message-ID: <1320836422.58.0.504647896749.issue11682@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

OK, the bitbucket repo now has a more sane version of the new Grammar ('yield from' now requires parentheses wherever 'yield' does).

The updated test_grammar does a more thorough check of the expected acceptance and rejection of yield expressions in various situations and the overly sensitive test in test_parser (that checked for an exact expected parse tree output) is gone.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11682>
_______________________________________

From report at bugs.python.org  Wed Nov  9 12:26:13 2011
From: report at bugs.python.org (Krishna Bharadwaj)
Date: Wed, 09 Nov 2011 11:26:13 +0000
Subject: [issue13359] urllib2 doesn't escape spaces in http requests
In-Reply-To: <1320610427.07.0.982938376676.issue13359@psf.upfronthosting.co.za>
Message-ID: <1320837973.17.0.692674276771.issue13359@psf.upfronthosting.co.za>


Krishna Bharadwaj <krishna.bmsce at gmail.com> added the comment:

I have used the quote method to percent encode the url for spaces and similar characters. This is my first patch. Please let me know if there is anything wrong. I will correct and re-submit it. I ran the test_urllib2.py which gave an OK for 34 tests.

Changes are made in two instances:
1. in the open method.
2. in the __init__ of Request class to ensure that the same issue is addressed at the time of creating Request objects.

----------
keywords: +patch
nosy: +krisys
Added file: http://bugs.python.org/file23642/issue13359.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13359>
_______________________________________

From report at bugs.python.org  Wed Nov  9 13:11:25 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Wed, 09 Nov 2011 12:11:25 +0000
Subject: [issue6397] Implementing Solaris "/dev/poll" in the "select" module
In-Reply-To: <1246466955.08.0.134631976531.issue6397@psf.upfronthosting.co.za>
Message-ID: <1320840685.64.0.905451357646.issue6397@psf.upfronthosting.co.za>


Changes by Jes?s Cea Avi?n <jcea at jcea.es>:


Added file: http://bugs.python.org/file23643/2506e49b9f71.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6397>
_______________________________________

From report at bugs.python.org  Wed Nov  9 13:12:03 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Wed, 09 Nov 2011 12:12:03 +0000
Subject: [issue6397] Implementing Solaris "/dev/poll" in the "select" module
In-Reply-To: <1246466955.08.0.134631976531.issue6397@psf.upfronthosting.co.za>
Message-ID: <1320840723.3.0.517258601407.issue6397@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

Another changeset. Hopefully, final :-).

Please, review.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6397>
_______________________________________

From report at bugs.python.org  Wed Nov  9 13:16:31 2011
From: report at bugs.python.org (Krishna Bharadwaj)
Date: Wed, 09 Nov 2011 12:16:31 +0000
Subject: [issue13375] Provide a namedtuple style interface for os.walk values
In-Reply-To: <1320823358.89.0.0610537790817.issue13375@psf.upfronthosting.co.za>
Message-ID: <1320840991.88.0.343259948775.issue13375@psf.upfronthosting.co.za>


Krishna Bharadwaj <krishna.bmsce at gmail.com> added the comment:

Have included a patch which alters the walk method to yield a namedtuple and the members can be accessed by dirpath, dirnames and filenames.

Got the following results after running the test. 

Ran 61 tests in 0.080s

OK (skipped=4)

Please let me know if the same can be achieved in a better way.

----------
keywords: +patch
nosy: +krisys
Added file: http://bugs.python.org/file23644/issue13375.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13375>
_______________________________________

From report at bugs.python.org  Wed Nov  9 13:21:48 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 09 Nov 2011 12:21:48 +0000
Subject: [issue13375] Provide a namedtuple style interface for os.walk values
In-Reply-To: <1320823358.89.0.0610537790817.issue13375@psf.upfronthosting.co.za>
Message-ID: <1320841308.63.0.983682708449.issue13375@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

This patch needs a test at least.
Also, the "walktuple" type should be defined only once, at the module level (but then, there may be a boostrap issue, I don't know).

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13375>
_______________________________________

From report at bugs.python.org  Wed Nov  9 13:59:48 2011
From: report at bugs.python.org (Krishna Bharadwaj)
Date: Wed, 09 Nov 2011 12:59:48 +0000
Subject: [issue13375] Provide a namedtuple style interface for os.walk values
In-Reply-To: <1320823358.89.0.0610537790817.issue13375@psf.upfronthosting.co.za>
Message-ID: <1320843588.65.0.461902937799.issue13375@psf.upfronthosting.co.za>


Krishna Bharadwaj <krishna.bmsce at gmail.com> added the comment:

Hey Amaury,

can you tell me if the following test cases would suffice? If not, I can think of adding something more comprehensive. Also, can you provide some pointers related to the bootstrap issue so that I can look at the same?

----------
Added file: http://bugs.python.org/file23645/issue13375_tests.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13375>
_______________________________________

From report at bugs.python.org  Wed Nov  9 14:39:11 2011
From: report at bugs.python.org (Ross Lagerwall)
Date: Wed, 09 Nov 2011 13:39:11 +0000
Subject: [issue6397] Implementing Solaris "/dev/poll" in the "select" module
In-Reply-To: <1246466955.08.0.134631976531.issue6397@psf.upfronthosting.co.za>
Message-ID: <1320845951.96.0.80821279018.issue6397@psf.upfronthosting.co.za>


Ross Lagerwall <rosslagerwall at gmail.com> added the comment:

+   increases this value, c:func:`devpoll` will return a possible
+   incomplete list of active file descriptors.

I think this should change to:

+   increases this value, c:func:`devpoll` will return a possibly
+   incomplete list of active file descriptors.

or even better:

+   increases this value, c:func:`devpoll` may return an
+   incomplete list of active file descriptors.

Cheers

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6397>
_______________________________________

From report at bugs.python.org  Wed Nov  9 15:44:13 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Wed, 09 Nov 2011 14:44:13 +0000
Subject: [issue6397] Implementing Solaris "/dev/poll" in the "select" module
In-Reply-To: <1246466955.08.0.134631976531.issue6397@psf.upfronthosting.co.za>
Message-ID: <1320849853.0.0.408181819678.issue6397@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

Thanks, Ross. Your suggestion has been committed in my branch.

Waiting for more feedback.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6397>
_______________________________________

From report at bugs.python.org  Wed Nov  9 16:51:15 2011
From: report at bugs.python.org (sbt)
Date: Wed, 09 Nov 2011 15:51:15 +0000
Subject: [issue13374] Deprecate usage of the Windows ANSI API in the nt module
In-Reply-To: <1320797406.95.0.49629588961.issue13374@psf.upfronthosting.co.za>
Message-ID: <1320853875.11.0.548269501088.issue13374@psf.upfronthosting.co.za>


sbt <shibturn at gmail.com> added the comment:

> Functions like os.execv() or os.readlink() are not deprecated because 
> the underlying C function really uses a bytes API (execv and readlink).

Probably os.execv() should be implemented on Windows with _wexecv() instead of _execv().  Likewise for other functions which have "wide" versions.  Or maybe it wouldn't be worth the effort, since it would mean writing separate Windows implementations.

I don't know what you mean about os.readlink() though: the Windows implementation uses CreateFileW() and DeviceIoControl().

----------
nosy: +sbt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13374>
_______________________________________

From report at bugs.python.org  Wed Nov  9 17:36:42 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 09 Nov 2011 16:36:42 +0000
Subject: [issue13374] Deprecate usage of the Windows ANSI API in the nt module
In-Reply-To: <1320853875.11.0.548269501088.issue13374@psf.upfronthosting.co.za>
Message-ID: <17384482.1kciHZhrRo@dsk000552>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> Probably os.execv() should be implemented on Windows with _wexecv() instead
> of _execv(). 

That's a different story. Would you like to implement it? If yes, please open a 
new issue.

> I don't know what you mean about os.readlink() though: the Windows
> implementation uses CreateFileW() and DeviceIoControl().

Oops, you are right. The Windows implement only accepts Unicode, so no 
deprecation warning is needed here.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13374>
_______________________________________

From report at bugs.python.org  Wed Nov  9 17:44:49 2011
From: report at bugs.python.org (David Marqvar Nielsen)
Date: Wed, 09 Nov 2011 16:44:49 +0000
Subject: [issue3754] cross-compilation support for python build
In-Reply-To: <1220305759.82.0.468834426074.issue3754@psf.upfronthosting.co.za>
Message-ID: <1320857089.05.0.179625198524.issue3754@psf.upfronthosting.co.za>


Changes by David Marqvar Nielsen <david at marqvar.dk>:


----------
nosy: +marqvar

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3754>
_______________________________________

From report at bugs.python.org  Wed Nov  9 17:52:12 2011
From: report at bugs.python.org (Ross Lagerwall)
Date: Wed, 09 Nov 2011 16:52:12 +0000
Subject: [issue6397] Implementing Solaris "/dev/poll" in the "select" module
In-Reply-To: <1246466955.08.0.134631976531.issue6397@psf.upfronthosting.co.za>
Message-ID: <1320857532.22.0.442124100339.issue6397@psf.upfronthosting.co.za>


Ross Lagerwall <rosslagerwall at gmail.com> added the comment:

Is write()ing a devpoll fd a blocking operation in the kernel?
Does it need to have Py_BEGIN_ALLOW_THREADS around it?
The same question applies for open()ing it.

Obviously, the ioctl() call *is* blocking :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6397>
_______________________________________

From report at bugs.python.org  Wed Nov  9 18:38:31 2011
From: report at bugs.python.org (Ross Lagerwall)
Date: Wed, 09 Nov 2011 17:38:31 +0000
Subject: [issue6397] Implementing Solaris "/dev/poll" in the "select" module
In-Reply-To: <1246466955.08.0.134631976531.issue6397@psf.upfronthosting.co.za>
Message-ID: <1320860311.35.0.963885551417.issue6397@psf.upfronthosting.co.za>


Ross Lagerwall <rosslagerwall at gmail.com> added the comment:

Also, you can use Py_RETURN_NONE instead of:
+    Py_INCREF(Py_None);
+    return Py_None;

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6397>
_______________________________________

From report at bugs.python.org  Wed Nov  9 18:40:39 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 09 Nov 2011 17:40:39 +0000
Subject: [issue6397] Implementing Solaris "/dev/poll" in the "select" module
In-Reply-To: <1246466955.08.0.134631976531.issue6397@psf.upfronthosting.co.za>
Message-ID: <1320860439.19.0.491288858796.issue6397@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6397>
_______________________________________

From report at bugs.python.org  Wed Nov  9 18:59:16 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 09 Nov 2011 17:59:16 +0000
Subject: [issue11427] ctypes from_buffer no longer accepts bytes
In-Reply-To: <1299481885.21.0.0627562040827.issue11427@psf.upfronthosting.co.za>
Message-ID: <1320861556.0.0.0866003310341.issue11427@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/issue11427>
_______________________________________

From report at bugs.python.org  Wed Nov  9 19:02:49 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 09 Nov 2011 18:02:49 +0000
Subject: [issue13093] Redundant code in PyUnicode_EncodeDecimal()
In-Reply-To: <1317569955.86.0.21646060057.issue13093@psf.upfronthosting.co.za>
Message-ID: <1320861769.77.0.99238051761.issue13093@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

The code is also present in Python 2.7 and 3.2.

----------
nosy: +haypo
versions: +Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13093>
_______________________________________

From report at bugs.python.org  Wed Nov  9 19:04:47 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 09 Nov 2011 18:04:47 +0000
Subject: [issue13093] Redundant code in PyUnicode_EncodeDecimal()
In-Reply-To: <1317569955.86.0.21646060057.issue13093@psf.upfronthosting.co.za>
Message-ID: <1320861887.44.0.863203275247.issue13093@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

PyUnicode_EncodeDecimal() was used in Python 2 by int, long and complex constructors. In Python 3, the function is no more used: it has been replaced by _PyUnicode_TransformDecimalAndSpaceToASCII().

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13093>
_______________________________________

From report at bugs.python.org  Wed Nov  9 19:04:52 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 09 Nov 2011 18:04:52 +0000
Subject: [issue13093] Redundant code in PyUnicode_EncodeDecimal()
In-Reply-To: <1317569955.86.0.21646060057.issue13093@psf.upfronthosting.co.za>
Message-ID: <1320861892.04.0.392525301578.issue13093@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/issue13093>
_______________________________________

From report at bugs.python.org  Wed Nov  9 19:31:24 2011
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 09 Nov 2011 18:31:24 +0000
Subject: [issue13093] Redundant code in PyUnicode_EncodeDecimal()
In-Reply-To: <1317569955.86.0.21646060057.issue13093@psf.upfronthosting.co.za>
Message-ID: <1320863484.43.0.72304947973.issue13093@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

Looking at it again, the intention was probably to increment
collend so that it points to the first non-garbage character
(or '\0'). If that's the case, the loop should be something
like this:

  while (collend < end) {
      if ((0 < *collend && *collend < 256) ||
          Py_UNICODE_ISSPACE(*collend) ||
          Py_UNICODE_TODECIMAL(*collend) >= 0)
          break;
      collend++;
  }


I can understand if no one wants to touch this given that
the function is deprecated, provided that you agree that
the existing code is redundant but harmless; i.e. it cannot
enter an infinite loop.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13093>
_______________________________________

From report at bugs.python.org  Wed Nov  9 20:02:17 2011
From: report at bugs.python.org (Santoso Wijaya)
Date: Wed, 09 Nov 2011 19:02:17 +0000
Subject: [issue11427] ctypes from_buffer no longer accepts bytes
In-Reply-To: <1299481885.21.0.0627562040827.issue11427@psf.upfronthosting.co.za>
Message-ID: <1320865337.49.0.940153519329.issue11427@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/issue11427>
_______________________________________

From report at bugs.python.org  Wed Nov  9 20:03:41 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 09 Nov 2011 19:03:41 +0000
Subject: [issue13375] Provide a namedtuple style interface for os.walk values
In-Reply-To: <1320823358.89.0.0610537790817.issue13375@psf.upfronthosting.co.za>
Message-ID: <1320865421.93.0.201299524101.issue13375@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Perhaps Raymond has a different view, but I don't this patch makes anything more clear. There's only three things to remember and its convenient to unpack it in the loop like

for path, dirs, files in os.walk(somewhere):
    ...

----------
nosy: +benjamin.peterson, rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13375>
_______________________________________

From report at bugs.python.org  Wed Nov  9 20:07:25 2011
From: report at bugs.python.org (Santoso Wijaya)
Date: Wed, 09 Nov 2011 19:07:25 +0000
Subject: [issue11427] ctypes from_buffer no longer accepts bytes
In-Reply-To: <1299481885.21.0.0627562040827.issue11427@psf.upfronthosting.co.za>
Message-ID: <1320865645.79.0.0831518052174.issue11427@psf.upfronthosting.co.za>


Santoso Wijaya <santoso.wijaya at gmail.com> added the comment:

>From what I understand, even in 2.7 the exception is expected. The doc for `from_buffer` says:

> The source object must support the writeable buffer interface.

Is there any reason why `from_buffer_copy` cannot be used, instead? The latter only requires readable buffer interface.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11427>
_______________________________________

From report at bugs.python.org  Wed Nov  9 20:14:21 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Wed, 09 Nov 2011 19:14:21 +0000
Subject: [issue6397] Implementing Solaris "/dev/poll" in the "select" module
In-Reply-To: <1246466955.08.0.134631976531.issue6397@psf.upfronthosting.co.za>
Message-ID: <1320866061.15.0.282892962692.issue6397@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

They are operations potentially slow, there are not realtime specifications.

My machine is quite capable (16 CPUs), but let's see what a bit of DTRACE scripting tells us:

First, let's time the open:

"""
syscall::open*:entry
/copyinstr(arg0)=="/dev/poll"/
{
    self->ts = timestamp;
}

syscall::open*:return
/self->ts/
{
    @stats = quantize(timestamp-self->ts);
    self->ts = 0;
}
"""

The result, times in nanoseconds:

"""
           value  ------------- Distribution ------------- count    
            2048 |                                         0        
            4096 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ 4497743  
            8192 |                                         17358    
           16384 |                                         1592     
           32768 |                                         2046     
           65536 |                                         812      
          131072 |                                         374      
          262144 |                                         0 
"""

Most "open"s finish in 4 microseconds, but we have a handful of "slow" openings of hundred of microseconds.

Anyway, argueing with the GIL here is a nonissue, since the "open" is only done at object creation, and a sane program will only create a handful of devpoll objets.

Let's see now the write:

"""
syscall::open*:entry
/copyinstr(arg0)=="/dev/poll"/
{
    self->ts = timestamp;
}

syscall::open*:return
/self->ts/
{
    @stats = quantize(timestamp-self->ts);
    self->ts = 0;
}

"""

The results for a single descriptor registered:

"""
           value  ------------- Distribution ------------- count    
             256 |                                         0        
             512 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ 4102701  
            1024 |                                         28514    
            2048 |                                         11269    
            4096 |                                         537      
            8192 |                                         245      
           16384 |                                         377      
           32768 |                                         193      
           65536 |                                         134      
          131072 |                                         71       
          262144 |                                         0  
"""

Most writes are really fast, half a microsecond, but we have sporadic latencies of a hundred of microseconds.

Re-registering 200 sockets per loop, I have:

"""
           value  ------------- Distribution ------------- count    
             512 |                                         0        
            1024 |                                         50       
            2048 |                                         94       
            4096 |                                         157      
            8192 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@  1112314  
           16384 |@                                        22977    
           32768 |                                         1584     
           65536 |                                         842      
          131072 |                                         168      
          262144 |                                         0 
"""

Most writes takes around 8 microseconds.

So now the problem is to estimate how much time I need to release & readquire the GIL. For that, and while we don't have DTRACE integration in python (my next project, I hope), I change sourcecode to add a manual probe using the Solaris High Resolution timers, I get a median time of around 550 nanoseconds (half a microsecond), with a few spikes, when the GIL is not contested. 

So, unlocking the GIL is adding around half microsecond to the syscalls. This is fast, but comparable with the syscall actual duration. Liberating the GIL is doubling the time to register&unregister a socket (supposely we are doing a single socket per iteration, something realistic in real code).

Being realistic, any work we do with the descriptors (like actually reading or writing it) is going to make this 0.5 microsecond gain pointless. Freeing the GIL, we are protected of any kernel contention, and playing for the rules :-).

Anyway I am open to feedback.

PS: I also checked with GIL contention, and results are comparable. That is surprising, maybe related to the GIL improvements in 3.3. I haven't investigated the issue further.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6397>
_______________________________________

From report at bugs.python.org  Wed Nov  9 20:39:33 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Wed, 09 Nov 2011 19:39:33 +0000
Subject: [issue6397] Implementing Solaris "/dev/poll" in the "select" module
In-Reply-To: <1246466955.08.0.134631976531.issue6397@psf.upfronthosting.co.za>
Message-ID: <1320867573.28.0.0010612281581.issue6397@psf.upfronthosting.co.za>


Changes by Jes?s Cea Avi?n <jcea at jcea.es>:


Added file: http://bugs.python.org/file23646/9d687fdd924d.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6397>
_______________________________________

From report at bugs.python.org  Wed Nov  9 20:45:16 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Wed, 09 Nov 2011 19:45:16 +0000
Subject: [issue6397] Implementing Solaris "/dev/poll" in the "select" module
In-Reply-To: <1246466955.08.0.134631976531.issue6397@psf.upfronthosting.co.za>
Message-ID: <1320867916.33.0.792296516979.issue6397@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

New changeset, after Ross feedback. Thanks!.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6397>
_______________________________________

From report at bugs.python.org  Wed Nov  9 20:45:27 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Wed, 09 Nov 2011 19:45:27 +0000
Subject: [issue13309] test_time fails: time data 'LMT' does not match format
	'%Z'
In-Reply-To: <1320156304.27.0.1872899991.issue13309@psf.upfronthosting.co.za>
Message-ID: <1320867927.11.0.180474976332.issue13309@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/issue13309>
_______________________________________

From report at bugs.python.org  Wed Nov  9 20:47:00 2011
From: report at bugs.python.org (Ross Lagerwall)
Date: Wed, 09 Nov 2011 19:47:00 +0000
Subject: [issue6397] Implementing Solaris "/dev/poll" in the "select" module
In-Reply-To: <1246466955.08.0.134631976531.issue6397@psf.upfronthosting.co.za>
Message-ID: <1320868020.18.0.682296818506.issue6397@psf.upfronthosting.co.za>


Ross Lagerwall <rosslagerwall at gmail.com> added the comment:

That was thorough :-) Seems OK though.

+    if (n < size) {
+        PyErr_SetString(PyExc_IOError, "failed to write all pollfds. "
+                "Please, report in http://bugs.python.org/");

If n < size, it's not a Python error is it? I would say it's the OS's fault.

Otherwise, it looks good... although I don't have currently access to a Solaris box to test it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6397>
_______________________________________

From report at bugs.python.org  Wed Nov  9 20:51:27 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Wed, 09 Nov 2011 19:51:27 +0000
Subject: [issue6397] Implementing Solaris "/dev/poll" in the "select" module
In-Reply-To: <1246466955.08.0.134631976531.issue6397@psf.upfronthosting.co.za>
Message-ID: <1320868287.5.0.205092777319.issue6397@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

The timing for the GIL I am providing is for release&acquiring. That is, all the work. In fact I am having in count too the syscall inside the release&acquire, to account for cache issues.

That is, between the release and the acquire, there is a real syscall. Of course, I am not timing it.

So, the timing I am providing is accurate.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6397>
_______________________________________

From report at bugs.python.org  Wed Nov  9 21:01:17 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 09 Nov 2011 20:01:17 +0000
Subject: [issue6397] Implementing Solaris "/dev/poll" in the "select" module
In-Reply-To: <1320868020.18.0.682296818506.issue6397@psf.upfronthosting.co.za>
Message-ID: <1320868598.3370.2.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> That was thorough :-) Seems OK though.
> 
> +    if (n < size) {
> +        PyErr_SetString(PyExc_IOError, "failed to write all pollfds. "
> +                "Please, report in http://bugs.python.org/");
> 
> If n < size, it's not a Python error is it? I would say it's the OS's fault.

No, but it's a Python error if Python wrongly assumes that write() won't
return a partial result. Ideally write() should be retried in a loop
until everything is written out.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6397>
_______________________________________

From report at bugs.python.org  Wed Nov  9 21:22:39 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Wed, 09 Nov 2011 20:22:39 +0000
Subject: [issue13093] Redundant code in PyUnicode_EncodeDecimal()
In-Reply-To: <1317569955.86.0.21646060057.issue13093@psf.upfronthosting.co.za>
Message-ID: <1320870159.7.0.563130401813.issue13093@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

AFAICT, this code was introduced in 0337dad8403e, implementing PEP 293 (see #432401). The intention clearly was what Stefan figured out: compute the list of unencodable characters, to pass the longest run of unencodable characters to the error handler.

Fixing this in this respect is fine with me for all branches.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13093>
_______________________________________

From report at bugs.python.org  Wed Nov  9 21:41:17 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 09 Nov 2011 20:41:17 +0000
Subject: [issue13374] Deprecate usage of the Windows ANSI API in the nt module
In-Reply-To: <1320797406.95.0.49629588961.issue13374@psf.upfronthosting.co.za>
Message-ID: <1320871277.56.0.669004221031.issue13374@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Updated patch:

 * os.rename(), os.symlink(), os.link() accept (bytes, str) and (str, bytes) again
 * ensure that the warning is emited after parsing arguments, not before (to not emit a warning if an int is passed instead of bytes or str)
 * add a test on os.open()

----------
Added file: http://bugs.python.org/file23647/deprecate_win_bytes_api-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13374>
_______________________________________

From report at bugs.python.org  Wed Nov  9 21:53:37 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Wed, 09 Nov 2011 20:53:37 +0000
Subject: [issue13374] Deprecate usage of the Windows ANSI API in the nt module
In-Reply-To: <1320853875.11.0.548269501088.issue13374@psf.upfronthosting.co.za>
Message-ID: <4EBAE846.4050405@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> Probably os.execv() should be implemented on Windows with _wexecv()
> instead of _execv().  Likewise for other functions which have "wide"
> versions.  Or maybe it wouldn't be worth the effort, since it would
> mean writing separate Windows implementations.

Writing separate Windows versions has a long tradition in posixmodule.c,
so in principle it's fine. It still may not be worth the effort since
the function is deprecated in favor of the subprocess module. However,
if code was contributed in that direction, we would likely accept it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13374>
_______________________________________

From report at bugs.python.org  Wed Nov  9 22:04:22 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 09 Nov 2011 21:04:22 +0000
Subject: [issue13374] Deprecate usage of the Windows ANSI API in the nt module
In-Reply-To: <1320797406.95.0.49629588961.issue13374@psf.upfronthosting.co.za>
Message-ID: <1320872662.63.0.756964586705.issue13374@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

deprecate_win_bytes_api-2.patch:
 * test_os.py: catch_warning() should be moved into test_link_bytes()
 * the change on Py_GetFinalPathNameByHandleA may be done in another commit

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13374>
_______________________________________

From report at bugs.python.org  Wed Nov  9 22:12:41 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 09 Nov 2011 21:12:41 +0000
Subject: [issue12442] shutil.disk_usage()
In-Reply-To: <1309366539.23.0.219360747776.issue12442@psf.upfronthosting.co.za>
Message-ID: <E1ROFRe-0002BM-Kn@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset bdb3f0e7e268 by Victor Stinner in branch 'default':
Issue #12442: nt._getdiskusage() is now using the Windows Unicode API
http://hg.python.org/cpython/rev/bdb3f0e7e268

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12442>
_______________________________________

From report at bugs.python.org  Wed Nov  9 22:25:07 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 09 Nov 2011 21:25:07 +0000
Subject: [issue13375] Provide a namedtuple style interface for os.walk values
In-Reply-To: <1320865421.93.0.201299524101.issue13375@psf.upfronthosting.co.za>
Message-ID: <CADiSq7f+UWTugK3+eW1u1AYQCRNhaxjMW6GA=ouZyRyDz4hbzg@mail.gmail.com>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Like any named tuple, the benefits lie in the better repr, and the fact
that if you only want some fields you don't have to unpack the whole tuple.
It's also easier to write variant APIs that add additional fields
accessible only by name.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13375>
_______________________________________

From report at bugs.python.org  Wed Nov  9 22:49:59 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 09 Nov 2011 21:49:59 +0000
Subject: [issue13375] Provide a namedtuple style interface for os.walk values
In-Reply-To: <1320823358.89.0.0610537790817.issue13375@psf.upfronthosting.co.za>
Message-ID: <1320875399.81.0.415818506561.issue13375@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Like any named tuple, the benefits lie in the better repr, and the fact
> that if you only want some fields you don't have to unpack the whole
> tuple.

But, given the common idiom shown by Benjamin, how likely is it that you manipulate the tuple as-is?

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13375>
_______________________________________

From report at bugs.python.org  Wed Nov  9 22:50:35 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Wed, 09 Nov 2011 21:50:35 +0000
Subject: [issue6397] Implementing Solaris "/dev/poll" in the "select" module
In-Reply-To: <1246466955.08.0.134631976531.issue6397@psf.upfronthosting.co.za>
Message-ID: <1320875435.34.0.573701725636.issue6397@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

The problem with partial writes is that the data is not an unstructured stream of bytes, but a concrete binary dump. You can not simply retry again.

My bet is that "/dev/poll" neves does partial writes.

If I am mistaken, I will bug the Illumos people to help me to solve it. So far, this seems a theorical problema.

Just in case it is not, we raise an exception and urge the programmer to report us the issue.

The other option would be to try to be clever and do things like retrying if the partial write is a multiple of the struct size, but what if it not so?.

Instead of guessing and play games, I rather prefer to know if this is actually a problem in the wild. In my tests, with 65530 sockets, I never saw this "impossible" exception.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6397>
_______________________________________

From report at bugs.python.org  Wed Nov  9 22:54:38 2011
From: report at bugs.python.org (Santoso Wijaya)
Date: Wed, 09 Nov 2011 21:54:38 +0000
Subject: [issue13374] Deprecate usage of the Windows ANSI API in the nt module
In-Reply-To: <1320797406.95.0.49629588961.issue13374@psf.upfronthosting.co.za>
Message-ID: <1320875678.97.0.811463524301.issue13374@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/issue13374>
_______________________________________

From report at bugs.python.org  Wed Nov  9 23:17:51 2011
From: report at bugs.python.org (Nekmo)
Date: Wed, 09 Nov 2011 22:17:51 +0000
Subject: [issue13378] Change the variable "nsmap" from global to instance
	(xml.etree.ElementTree)
Message-ID: <1320877071.09.0.895123668254.issue13378@psf.upfronthosting.co.za>


New submission from Nekmo <nintux at gmail.com>:

Currently, the mapping of namespaces is global and can cause failures if multiple instances are used or in multithreading. The variable is in xml.etree.ElementTree._namespace_map. I ask it to be switched to xml.etree._Element instance.

----------
components: XML
messages: 147378
nosy: Nekmo
priority: normal
severity: normal
status: open
title: Change the variable "nsmap" from global to instance (xml.etree.ElementTree)
type: feature request
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13378>
_______________________________________

From report at bugs.python.org  Wed Nov  9 23:28:35 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Wed, 09 Nov 2011 22:28:35 +0000
Subject: [issue13378] Change the variable "nsmap" from global to instance
	(xml.etree.ElementTree)
In-Reply-To: <1320877071.09.0.895123668254.issue13378@psf.upfronthosting.co.za>
Message-ID: <1320877715.92.0.322684883659.issue13378@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

Tagging this as targeting 3.3.

Nekmo, could you possibly poste some code showing the problem?

----------
nosy: +jcea
versions: +Python 3.3 -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13378>
_______________________________________

From report at bugs.python.org  Wed Nov  9 23:32:24 2011
From: report at bugs.python.org (Florent Xicluna)
Date: Wed, 09 Nov 2011 22:32:24 +0000
Subject: [issue13378] Change the variable "nsmap" from global to instance
	(xml.etree.ElementTree)
In-Reply-To: <1320877071.09.0.895123668254.issue13378@psf.upfronthosting.co.za>
Message-ID: <1320877944.45.0.372307947027.issue13378@psf.upfronthosting.co.za>


Changes by Florent Xicluna <florent.xicluna at gmail.com>:


----------
nosy: +flox

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13378>
_______________________________________

From report at bugs.python.org  Wed Nov  9 23:35:50 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Wed, 09 Nov 2011 22:35:50 +0000
Subject: [issue9523] Improve dbm modules
In-Reply-To: <1281021837.96.0.764638089257.issue9523@psf.upfronthosting.co.za>
Message-ID: <1320878150.93.0.0714878959051.issue9523@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/issue9523>
_______________________________________

From report at bugs.python.org  Thu Nov 10 00:22:49 2011
From: report at bugs.python.org (Nekmo)
Date: Wed, 09 Nov 2011 23:22:49 +0000
Subject: [issue13378] Change the variable "nsmap" from global to instance
	(xml.etree.ElementTree)
In-Reply-To: <1320877071.09.0.895123668254.issue13378@psf.upfronthosting.co.za>
Message-ID: <1320880969.81.0.336488235094.issue13378@psf.upfronthosting.co.za>


Nekmo <nintux at gmail.com> added the comment:

In my case, I have several clients, and they define the namespaces. I am interested in return the same namespace that they gave me, for example, the client "A" gives me this:

<house:iq xmlns:house="http://localhost/house" />

To name the namespace, I set it at nsmap:

>>> import xml.etree.ElementTree as etree
>>> etree.register_namespace('house', 'http://localhost/house')
>>> etree._namespace_map
{'http://localhost/house': 'house',
 'http://purl.org/dc/elements/1.1/': 'dc',
 'http://schemas.xmlsoap.org/wsdl/': 'wsdl',
 'http://www.w3.org/1999/02/22-rdf-syntax-ns#': 'rdf',
 'http://www.w3.org/1999/xhtml': 'html',
 'http://www.w3.org/2001/XMLSchema': 'xs',
 'http://www.w3.org/2001/XMLSchema-instance': 'xsi',
 'http://www.w3.org/XML/1998/namespace': 'xml'}

Thus, keeping the name of the namespace:
>>> etree.tostring(etree.Element('{http://localhost/house}iq'))
b'<house:iq xmlns:house="http://localhost/house" />'

But if I have a client "B", which uses a different name, and run in parallel, problems can occur:

<home:iq xmlns:home="http://localhost/house" />

>>> import xml.etree.ElementTree as etree
>>> etree.register_namespace('home', 'http://localhost/house')
>>> etree._namespace_map
{'http://localhost/house': 'home',
 'http://purl.org/dc/elements/1.1/': 'dc',
 'http://schemas.xmlsoap.org/wsdl/': 'wsdl',
 'http://www.w3.org/1999/02/22-rdf-syntax-ns#': 'rdf',
 'http://www.w3.org/1999/xhtml': 'html',
 'http://www.w3.org/2001/XMLSchema': 'xs',
 'http://www.w3.org/2001/XMLSchema-instance': 'xsi',
 'http://www.w3.org/XML/1998/namespace': 'xml'}

Therefore, I ask that _namespace_map is within etree._Element instance, and not global

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13378>
_______________________________________

From report at bugs.python.org  Thu Nov 10 00:24:23 2011
From: report at bugs.python.org (Florent Xicluna)
Date: Wed, 09 Nov 2011 23:24:23 +0000
Subject: [issue13379] Wrong Unicode version in unicodedata docstring
Message-ID: <1320881063.48.0.160068391122.issue13379@psf.upfronthosting.co.za>


New submission from Florent Xicluna <florent.xicluna at gmail.com>:

The unicodedata docstring says "5.2" multiple times.


Modules/unicodedata.c:   unicodedata -- Provides access to the Unicode 5.2 data base.
Modules/unicodedata.c:   Data was extracted from the Unicode 5.2 UnicodeData.txt file.
Modules/unicodedata.c:5.2.0 which is publically available from ftp://ftp.unicode.org/.\n\
Modules/unicodedata.c:UnicodeData File Format 5.2.0 (see\n\


However:

>>> import unicodedata
>>> unicodedata.unidata_version
'6.0.0'

----------
components: Unicode
keywords: easy
messages: 147381
nosy: ezio.melotti, flox
priority: normal
severity: normal
stage: needs patch
status: open
title: Wrong Unicode version in unicodedata docstring
type: behavior
versions: Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13379>
_______________________________________

From report at bugs.python.org  Thu Nov 10 00:39:31 2011
From: report at bugs.python.org (Florent Xicluna)
Date: Wed, 09 Nov 2011 23:39:31 +0000
Subject: [issue13297] xmlrpc.client could accept bytes for input and output
In-Reply-To: <1320018100.14.0.184941596185.issue13297@psf.upfronthosting.co.za>
Message-ID: <1320881971.2.0.4829516336.issue13297@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

Updated with documentation.

----------
nosy: +effbot, fdrake, skip.montanaro
Added file: http://bugs.python.org/file23648/issue13291_xmlrpc_v2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13297>
_______________________________________

From report at bugs.python.org  Thu Nov 10 00:40:15 2011
From: report at bugs.python.org (Florent Xicluna)
Date: Wed, 09 Nov 2011 23:40:15 +0000
Subject: [issue13297] xmlrpc.client could accept bytes for input and output
In-Reply-To: <1320018100.14.0.184941596185.issue13297@psf.upfronthosting.co.za>
Message-ID: <1320882015.08.0.0594976540561.issue13297@psf.upfronthosting.co.za>


Changes by Florent Xicluna <florent.xicluna at gmail.com>:


Removed file: http://bugs.python.org/file23648/issue13291_xmlrpc_v2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13297>
_______________________________________

From report at bugs.python.org  Thu Nov 10 00:40:48 2011
From: report at bugs.python.org (Florent Xicluna)
Date: Wed, 09 Nov 2011 23:40:48 +0000
Subject: [issue13297] xmlrpc.client could accept bytes for input and output
In-Reply-To: <1320018100.14.0.184941596185.issue13297@psf.upfronthosting.co.za>
Message-ID: <1320882048.27.0.33651176952.issue13297@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

Ooops wrong patch.

----------
Added file: http://bugs.python.org/file23649/issue13297_xmlrpc_bytes_v2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13297>
_______________________________________

From report at bugs.python.org  Thu Nov 10 00:45:05 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Wed, 09 Nov 2011 23:45:05 +0000
Subject: [issue11937] Interix support
In-Reply-To: <1303911825.14.0.5833510557.issue11937@psf.upfronthosting.co.za>
Message-ID: <1320882305.8.0.147366002054.issue11937@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

Closing. If anybody disagrees, reopen.

----------
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11937>
_______________________________________

From report at bugs.python.org  Thu Nov 10 00:45:34 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 09 Nov 2011 23:45:34 +0000
Subject: [issue13373] Unexpected blocking call to multiprocessing.Queue.get
	with a timeout
In-Reply-To: <1320790288.25.0.363329173413.issue13373@psf.upfronthosting.co.za>
Message-ID: <E1ROHpa-0007WQ-11@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset e7b6dca28a2f by Antoine Pitrou in branch '2.7':
Issue #13373: multiprocessing.Queue.get() could sometimes block indefinitely
http://hg.python.org/cpython/rev/e7b6dca28a2f

New changeset 9328080a19c0 by Antoine Pitrou in branch '3.2':
Issue #13373: multiprocessing.Queue.get() could sometimes block indefinitely
http://hg.python.org/cpython/rev/9328080a19c0

New changeset f34b4e250b44 by Antoine Pitrou in branch 'default':
Issue #13373: multiprocessing.Queue.get() could sometimes block indefinitely
http://hg.python.org/cpython/rev/f34b4e250b44

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13373>
_______________________________________

From report at bugs.python.org  Thu Nov 10 00:47:58 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 09 Nov 2011 23:47:58 +0000
Subject: [issue13373] Unexpected blocking call to multiprocessing.Queue.get
	with a timeout
In-Reply-To: <1320790288.25.0.363329173413.issue13373@psf.upfronthosting.co.za>
Message-ID: <1320882478.11.0.593813262862.issue13373@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Patch committed, thank you for contributing!

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13373>
_______________________________________

From report at bugs.python.org  Thu Nov 10 01:06:08 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 10 Nov 2011 00:06:08 +0000
Subject: [issue13322] buffered read() and write() does not raise
	BlockingIOError
In-Reply-To: <1320688361.58.0.902984697592.issue13322@psf.upfronthosting.co.za>
Message-ID: <1320883289.3370.6.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

Hi,

> Testing the patch a bit more thoroughly, I found that data received
> from the readable end of the pipe can be corrupted by the C
> implementation.  This seems to be because two of the previously
> dormant codepaths did not properly maintain the necessary invariants.

Ouch. Were they only non-blocking codepaths?

> in two places.  However, I really do not know what all the attributes
> mean.  (Should self->raw_pos also be modified...?)

raw_pos is the position which the underlying raw stream is currently at.
It only needs to be modified when a successful write(), read() or seek()
is done on the raw stream.

Another comment: you set errno to EAGAIN, but it is not sure that was
the actual errno raised by the raw stream (although that's quite
likely). You might want to reflect the actual C errno (but you'd better
set it to 0 before the system call, then).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13322>
_______________________________________

From report at bugs.python.org  Thu Nov 10 02:01:50 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Thu, 10 Nov 2011 01:01:50 +0000
Subject: [issue4111] Add Systemtap/DTrace probes
In-Reply-To: <1223827695.04.0.0893695004368.issue4111@psf.upfronthosting.co.za>
Message-ID: <1320886910.68.0.281422677864.issue4111@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

Anybody still working on this?.

We missed the 2.7 boat. DO NOT MISS THE 3.3 ONE!!! :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4111>
_______________________________________

From report at bugs.python.org  Thu Nov 10 02:03:38 2011
From: report at bugs.python.org (Brett Hoerner)
Date: Thu, 10 Nov 2011 01:03:38 +0000
Subject: [issue4111] Add Systemtap/DTrace probes
In-Reply-To: <1223827695.04.0.0893695004368.issue4111@psf.upfronthosting.co.za>
Message-ID: <1320887018.45.0.954663536885.issue4111@psf.upfronthosting.co.za>


Changes by Brett Hoerner <bretthoerner at gmail.com>:


----------
nosy:  -bretthoerner

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4111>
_______________________________________

From report at bugs.python.org  Thu Nov 10 03:40:34 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 10 Nov 2011 02:40:34 +0000
Subject: [issue13229] Improve tools for iterating over filesystem directories
In-Reply-To: <1319076330.7.0.757546324527.issue13229@psf.upfronthosting.co.za>
Message-ID: <1320892834.02.0.118821277663.issue13229@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

I changed the package name to walkdir: https://bitbucket.org/ncoghlan/walkdir/overview

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13229>
_______________________________________

From report at bugs.python.org  Thu Nov 10 03:45:44 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 10 Nov 2011 02:45:44 +0000
Subject: [issue13375] Provide a namedtuple style interface for os.walk values
In-Reply-To: <1320823358.89.0.0610537790817.issue13375@psf.upfronthosting.co.za>
Message-ID: <1320893144.76.0.939479990555.issue13375@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Why provide any namedtuple interface in any context? After all, you can just unpack them to individual variables.

The point is that the values produced by os.walk() *aren't* just an arbitrary 3-tuple - they have a definite API for describing a directory: the base path, then lists of relative names for any subdirectories and the relative names for any files. Why not make that explicit in the objects produced instead of leaving it as merely implied?

This idea actually came out of the proposal for providing an itertools-inspired toolset for manipulating the output of os.walk() style iteration (#13229 and https://bitbucket.org/ncoghlan/walkdir/overview).

I'll be adding this feature to walkdir regardless, but it seems to make more sense to offer it as standard behaviour.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13375>
_______________________________________

From report at bugs.python.org  Thu Nov 10 03:52:34 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 10 Nov 2011 02:52:34 +0000
Subject: [issue13375] Provide a namedtuple style interface for os.walk values
In-Reply-To: <1320893144.76.0.939479990555.issue13375@psf.upfronthosting.co.za>
Message-ID: <CAPZV6o-cryqioaLU5WuJ83yyxCEyMO6Q8AnZ+fzmOiEGmrzKgQ@mail.gmail.com>


Benjamin Peterson <benjamin at python.org> added the comment:

2011/11/9 Nick Coghlan <report at bugs.python.org>:
>
> Nick Coghlan <ncoghlan at gmail.com> added the comment:
>
> Why provide any namedtuple interface in any context? After all, you can just unpack them to individual variables.
>
> The point is that the values produced by os.walk() *aren't* just an arbitrary 3-tuple - they have a definite API for describing a directory: the base path, then lists of relative names for any subdirectories and the relative names for any files. Why not make that explicit in the objects produced instead of leaving it as merely implied?

You could make this argument for any function that returns a tuple to
return multiple distinct values. I claim that the API in this case is
already simple enough that adding a nametuple does nothing but feature
bloat. What does having a "dirinfo" object with attributes tell you
that simply unpacking the tuple doesn't? You have to remember names in
both cases.

>
> This idea actually came out of the proposal for providing an itertools-inspired toolset for manipulating the output of os.walk() style iteration (#13229 and https://bitbucket.org/ncoghlan/walkdir/overview).
>
> I'll be adding this feature to walkdir regardless, but it seems to make more sense to offer it as standard behaviour.

Indeed, I think using a namedtuple seems more appropriate for your
"fancier" api.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13375>
_______________________________________

From report at bugs.python.org  Thu Nov 10 04:10:49 2011
From: report at bugs.python.org (Meador Inge)
Date: Thu, 10 Nov 2011 03:10:49 +0000
Subject: [issue11427] ctypes from_buffer no longer accepts bytes
In-Reply-To: <1299481885.21.0.0627562040827.issue11427@psf.upfronthosting.co.za>
Message-ID: <1320894649.83.0.85326768542.issue11427@psf.upfronthosting.co.za>


Meador Inge <meadori at gmail.com> added the comment:

Hmmm... I take back what I said before (not sure what I was thinking), I 
don't think this is a regression.  If this ever did work, it must have 
been a bug.  For one reason, Python byte strings are now immutable.  
Allowing their memory to be indirectly mutated in Python via buffers 
created from 'from_buffer' would be very bad.

Also, I can't reproduce the reported behavior with 3.1.3:

Python 3.1.3 (unknown, Nov  9 2011, 19:57:58) 
[GCC 4.6.1 20110908 (Red Hat 4.6.1-9)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import ctypes
>>> (ctypes.c_char*5).from_buffer(b'abcde')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: expected an object with a writable buffer interface

Are you sure it was 3.1.3?  At first I thought you might be using
3.0a, since bytes are mutable in that version, but 'from_buffer'
didn't exist in those times.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11427>
_______________________________________

From report at bugs.python.org  Thu Nov 10 04:25:45 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 10 Nov 2011 03:25:45 +0000
Subject: [issue13375] Provide a namedtuple style interface for os.walk values
In-Reply-To: <1320823358.89.0.0610537790817.issue13375@psf.upfronthosting.co.za>
Message-ID: <1320895545.81.0.133946324166.issue13375@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

I'm persuaded that there's no major gain to be had in building this in at the base layer - it's easy enough to add in a higher level API.

----------
resolution:  -> rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13375>
_______________________________________

From report at bugs.python.org  Thu Nov 10 06:00:41 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 10 Nov 2011 05:00:41 +0000
Subject: [issue13379] Wrong Unicode version in unicodedata docstring
In-Reply-To: <1320881063.48.0.160068391122.issue13379@psf.upfronthosting.co.za>
Message-ID: <1320901241.23.0.409449560897.issue13379@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
assignee:  -> ezio.melotti
keywords: +needs review, patch
stage: needs patch -> commit review
Added file: http://bugs.python.org/file23650/issue13379.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13379>
_______________________________________

From report at bugs.python.org  Thu Nov 10 06:22:41 2011
From: report at bugs.python.org (Meador Inge)
Date: Thu, 10 Nov 2011 05:22:41 +0000
Subject: [issue13380] ctypes: add an internal function for reseting the ctypes
	caches
Message-ID: <1320902561.22.0.487865927239.issue13380@psf.upfronthosting.co.za>


New submission from Meador Inge <meadori at gmail.com>:

Currently it is possible to somewhat easily get false positives for reference leaks when running the ctypes regression tests with -R.  See issue13250 for an example where I got tripped up.  The reason is that the ctypes caches are not cleared in between test runs like they are with some of the other modules that cache objects.

The attached patch adds an internal function for reseting the ctypes caches.  regrtest.py is then fixed up to use it.  Finally, two tests
that previously relied on the caching being present to work in back-to-back runs have been fixed.  In particular, the tests were written to do something like:

# Global
dll = CDLL(_ctypes_test.__file__)

# Local to test
f = dll._testfunc_callback_i_if
f.restype = c_int

MyCallback = CFUNCTYPE(c_int, c_int)

def callback(value)
    return value

cb = MyCallback(callback)
result = f(-10, cb)

f.argtypes = [c_int, MyCallback]
cb = MyCallback(callback)
result = f(-10, cb)

Thus when run in back-to-back runs where caching is cleared in between you effectively get:

# Global
dll = CDLL(_ctypes_test.__file__)

# Local to test
f = dll._testfunc_callback_i_if
f.restype = c_int

MyCallback = CFUNCTYPE(c_int, c_int)

def callback(value):
    return value

cb = MyCallback(callback)
result = f(-10, cb)

f.argtypes = [c_int, MyCallback]
cb = MyCallback(callback)
result = f(-10, cb)

_reset_cache()

f = dll._testfunc_callback_i_if
f.restype = c_int

MyCallback = CFUNCTYPE(c_int, c_int)

cb = MyCallback(callback)
result = f(-10, cb)

which causes:

types.ArgumentError: argument 2: <class 'TypeError'>: expected CFunctionType instance instead of CFunctionType

because the final MyCallback instance passed to f is not of the same type as the MyCallback type saved in f.argtypes.  The fix is to set f.argtypes to None at the beginning of each test.

I would also like to commit this to 2.7 and 3.2.  It will make fixing true reference leaks in those branches easier.

OK?

----------
assignee: meador.inge
components: ctypes
files: ctypes-reset-cache.patch
keywords: patch
messages: 147394
nosy: amaury.forgeotdarc, belopolsky, meador.inge
priority: normal
severity: normal
stage: patch review
status: open
title: ctypes: add an internal function for reseting the ctypes caches
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file23651/ctypes-reset-cache.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13380>
_______________________________________

From report at bugs.python.org  Thu Nov 10 06:23:47 2011
From: report at bugs.python.org (Meador Inge)
Date: Thu, 10 Nov 2011 05:23:47 +0000
Subject: [issue13250] ctypes: reference leak in POINTER code
In-Reply-To: <1319395508.92.0.449724155939.issue13250@psf.upfronthosting.co.za>
Message-ID: <1320902627.0.0.620222053879.issue13250@psf.upfronthosting.co.za>


Meador Inge <meadori at gmail.com> added the comment:

I opened issue13380 for fixing the ctypes regrtest caching problem.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13250>
_______________________________________

From report at bugs.python.org  Thu Nov 10 08:14:55 2011
From: report at bugs.python.org (Florent Xicluna)
Date: Thu, 10 Nov 2011 07:14:55 +0000
Subject: [issue13379] Wrong Unicode version in unicodedata docstring
In-Reply-To: <1320881063.48.0.160068391122.issue13379@psf.upfronthosting.co.za>
Message-ID: <1320909295.27.0.608557292892.issue13379@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

I would change the last sentence with something like:

+   unicodedata -- Provides access to the Unicode database.
 
+   Data was extracted from the UnicodeData.txt file.
+   The current version number is reported in unidata_version constant.


LGTM.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13379>
_______________________________________

From report at bugs.python.org  Thu Nov 10 08:38:13 2011
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 10 Nov 2011 07:38:13 +0000
Subject: [issue13379] Wrong Unicode version in unicodedata docstring
In-Reply-To: <1320881063.48.0.160068391122.issue13379@psf.upfronthosting.co.za>
Message-ID: <E1ROPD0-0000il-Nf@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 6ddda809ea8c by Ezio Melotti in branch '3.2':
#13379: update Unicode version in unicodedata docstrings and comments.
http://hg.python.org/cpython/rev/6ddda809ea8c

New changeset 5fdd0c8032d0 by Ezio Melotti in branch 'default':
#13379: merge with 3.2.
http://hg.python.org/cpython/rev/5fdd0c8032d0

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13379>
_______________________________________

From report at bugs.python.org  Thu Nov 10 08:39:01 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 10 Nov 2011 07:39:01 +0000
Subject: [issue13379] Wrong Unicode version in unicodedata docstring
In-Reply-To: <1320881063.48.0.160068391122.issue13379@psf.upfronthosting.co.za>
Message-ID: <1320910741.6.0.635834110841.issue13379@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Fixed, thanks for the report and the review.

----------
resolution:  -> fixed
stage: commit review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13379>
_______________________________________

From report at bugs.python.org  Thu Nov 10 09:31:39 2011
From: report at bugs.python.org (Florent Xicluna)
Date: Thu, 10 Nov 2011 08:31:39 +0000
Subject: [issue13297] xmlrpc.client could accept bytes for input and output
In-Reply-To: <1320018100.14.0.184941596185.issue13297@psf.upfronthosting.co.za>
Message-ID: <1320913899.17.0.916086444056.issue13297@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

Maybe a flag "use_builtin_types" is preferred?
It should implies both `bytes` and `datetime.datetime` are used for presenting data received.

I don't see a use case where we would like to have `bytes` for binary data but keep `xmlrpc.client.DateTime` for date objects.

Becomes obsolete, if this change is done:
 - xmlrpc.client.Binary
 - xmlrpc.client.DateTime
 - use_datetime flag of `ServerProxy` class and `loads` function

I'm not sure it's necessary to deprecate things here.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13297>
_______________________________________

From report at bugs.python.org  Thu Nov 10 09:49:51 2011
From: report at bugs.python.org (Florent Xicluna)
Date: Thu, 10 Nov 2011 08:49:51 +0000
Subject: [issue2979] use_datetime in SimpleXMLRPCServer
In-Reply-To: <1211846989.94.0.031553096454.issue2979@psf.upfronthosting.co.za>
Message-ID: <1320914991.46.0.486724189971.issue2979@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

See issue #13297 for a similar case with bytes.

Should we implement a "use_builtin_types" flag which supersedes "use_datetime"?

----------
dependencies: +xmlrpc.client could accept bytes for input and output

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2979>
_______________________________________

From report at bugs.python.org  Thu Nov 10 10:51:07 2011
From: report at bugs.python.org (Ronny Pfannschmidt)
Date: Thu, 10 Nov 2011 09:51:07 +0000
Subject: [issue13381] compile fails to compile a ast module object giving a
	incomprehensible error
Message-ID: <1320918667.91.0.713083174884.issue13381@psf.upfronthosting.co.za>


New submission from Ronny Pfannschmidt <ronny.pfannschmidt at gmail.com>:

$ python3.2  -c 'import ast;compile(ast.parse(open("testing/test_keymap.py").read()), "test", "exec")'
Traceback (most recent call last):
  File "<string>", line 1, in <module>
TypeError: AST string must be of type str

note that just compiling the source works fine

----------
files: test_keymap.py
messages: 147401
nosy: Ronny.Pfannschmidt
priority: normal
severity: normal
status: open
title: compile fails to compile a ast module object giving a incomprehensible error
type: behavior
versions: Python 3.2
Added file: http://bugs.python.org/file23652/test_keymap.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13381>
_______________________________________

From report at bugs.python.org  Thu Nov 10 12:10:44 2011
From: report at bugs.python.org (Ronny Pfannschmidt)
Date: Thu, 10 Nov 2011 11:10:44 +0000
Subject: [issue13381] compile fails to compile a ast module object giving a
	incomprehensible error
In-Reply-To: <1320918667.91.0.713083174884.issue13381@psf.upfronthosting.co.za>
Message-ID: <1320923444.97.0.416678367572.issue13381@psf.upfronthosting.co.za>


Changes by Ronny Pfannschmidt <ronny.pfannschmidt at gmail.com>:


----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13381>
_______________________________________

From report at bugs.python.org  Thu Nov 10 13:57:54 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 10 Nov 2011 12:57:54 +0000
Subject: [issue13381] compile fails to compile a ast module object giving a
	incomprehensible error
In-Reply-To: <1320918667.91.0.713083174884.issue13381@psf.upfronthosting.co.za>
Message-ID: <1320929874.42.0.89959529744.issue13381@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Fixed recently.

----------
resolution:  -> out of date
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13381>
_______________________________________

From report at bugs.python.org  Thu Nov 10 14:10:43 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 10 Nov 2011 13:10:43 +0000
Subject: [issue11937] Interix support
In-Reply-To: <1303911825.14.0.5833510557.issue11937@psf.upfronthosting.co.za>
Message-ID: <1320930643.68.0.530384840852.issue11937@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/issue11937>
_______________________________________

From report at bugs.python.org  Thu Nov 10 14:18:18 2011
From: report at bugs.python.org (R. David Murray)
Date: Thu, 10 Nov 2011 13:18:18 +0000
Subject: [issue11937] Interix support
In-Reply-To: <1303911825.14.0.5833510557.issue11937@psf.upfronthosting.co.za>
Message-ID: <1320931098.46.0.375241842002.issue11937@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Just a note that buildbot does work behind a firewall (mine are set up that way). The client calls out to the master.  A really restrictive corporate firewall may need outbound holes punched, but there are no inbound connections to the client.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11937>
_______________________________________

From report at bugs.python.org  Thu Nov 10 14:29:29 2011
From: report at bugs.python.org (Zbyszek Szmek)
Date: Thu, 10 Nov 2011 13:29:29 +0000
Subject: [issue11682] PEP 380 reference implementation for 3.3
In-Reply-To: <1301110605.68.0.392943983038.issue11682@psf.upfronthosting.co.za>
Message-ID: <1320931769.28.0.83325592197.issue11682@psf.upfronthosting.co.za>


Zbyszek Szmek <zbyszek at in.waw.pl> added the comment:

Nick Coghlan wrote:
> I don't want to completely rearrange the yield related sections of the
> language reference as part of incorporating this PEP. If you're happy
> to submit a new pull request with a minimalist change just documenting
> the new features, that would be great, otherwise I'll eventually
> figure out my own set of updates.

OK, I should have it ready before Monday.

> The cross-linking fixes are independent of this PEP, and should be
> handled as a separate tracker issue rather than being rolled into the
> PEP update.
Will do so.

Zbyszek

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11682>
_______________________________________

From report at bugs.python.org  Thu Nov 10 14:29:58 2011
From: report at bugs.python.org (Zbyszek Szmek)
Date: Thu, 10 Nov 2011 13:29:58 +0000
Subject: [issue11682] PEP 380 reference implementation for 3.3
In-Reply-To: <1301110605.68.0.392943983038.issue11682@psf.upfronthosting.co.za>
Message-ID: <1320931798.18.0.861464794631.issue11682@psf.upfronthosting.co.za>


Changes by Zbyszek Szmek <zbyszek at in.waw.pl>:


Removed file: http://bugs.python.org/file23217/0002.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11682>
_______________________________________

From report at bugs.python.org  Thu Nov 10 15:57:04 2011
From: report at bugs.python.org (sbt)
Date: Thu, 10 Nov 2011 14:57:04 +0000
Subject: [issue13322] buffered read() and write() does not raise
	BlockingIOError
In-Reply-To: <1320246535.71.0.465783773129.issue13322@psf.upfronthosting.co.za>
Message-ID: <1320937024.48.0.258665650348.issue13322@psf.upfronthosting.co.za>


sbt <shibturn at gmail.com> added the comment:

> Ouch. Were they only non-blocking codepaths?

Yes.

> raw_pos is the position which the underlying raw stream is currently
> at.  It only needs to be modified when a successful write(), read()
> or seek() is done on the raw stream.

Do you mean self->raw_pos should give the same answer as self.raw.tell()?  (But that seems to be the definition of self->abs_pos.)  Or is it the buffer offset which corresponds to self.raw.tell()?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13322>
_______________________________________

From report at bugs.python.org  Thu Nov 10 19:17:10 2011
From: report at bugs.python.org (Florent Xicluna)
Date: Thu, 10 Nov 2011 18:17:10 +0000
Subject: [issue13297] xmlrpc.client could accept bytes for input and output
In-Reply-To: <1320018100.14.0.184941596185.issue13297@psf.upfronthosting.co.za>
Message-ID: <1320949030.18.0.881032172974.issue13297@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

This patch v3 implements the proposal of use_builtin_types flag.
In this case the use_datetime flag becomes obsolete.

Please comment.

----------
Added file: http://bugs.python.org/file23653/issue13297_xmlrpc_bytes_v3.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13297>
_______________________________________

From report at bugs.python.org  Thu Nov 10 19:23:37 2011
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 10 Nov 2011 18:23:37 +0000
Subject: [issue7777] Support needed for AF_RDS family
In-Reply-To: <1264404460.15.0.913920533968.issue7777@psf.upfronthosting.co.za>
Message-ID: <E1ROZHZ-00022o-E4@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 2293ca739223 by Charles-Fran?ois Natali in branch 'default':
Issue #7777: socket: Add Reliable Datagram Sockets (PF_RDS) support.
http://hg.python.org/cpython/rev/2293ca739223

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7777>
_______________________________________

From report at bugs.python.org  Thu Nov 10 19:23:37 2011
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 10 Nov 2011 18:23:37 +0000
Subject: [issue13303] Sporadic importlib failures: FileNotFoundError on
	os.rename()
In-Reply-To: <1320058871.09.0.581986884521.issue13303@psf.upfronthosting.co.za>
Message-ID: <E1ROZHZ-00022o-EO@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset a9f10c3eff69 by Charles-Fran?ois Natali in branch 'default':
Issue #13303: Fix bytecode file default permission.
http://hg.python.org/cpython/rev/a9f10c3eff69

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13303>
_______________________________________

From report at bugs.python.org  Thu Nov 10 21:13:49 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 10 Nov 2011 20:13:49 +0000
Subject: [issue13322] buffered read() and write() does not raise
	BlockingIOError
In-Reply-To: <1320937024.48.0.258665650348.issue13322@psf.upfronthosting.co.za>
Message-ID: <1320955748.3406.1.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Do you mean self->raw_pos should give the same answer as
> self.raw.tell()?  (But that seems to be the definition of
> self->abs_pos.)  Or is it the buffer offset which corresponds to
> self.raw.tell()?

The latter.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13322>
_______________________________________

From report at bugs.python.org  Thu Nov 10 21:36:11 2011
From: report at bugs.python.org (Florent Xicluna)
Date: Thu, 10 Nov 2011 20:36:11 +0000
Subject: [issue2979] use_builtin_types in SimpleXMLRPCServer
In-Reply-To: <1211846989.94.0.031553096454.issue2979@psf.upfronthosting.co.za>
Message-ID: <1320957371.34.0.685116730687.issue2979@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

This is the proposed patch which could be applied after issue #13297 is solved.

----------
title: use_datetime in SimpleXMLRPCServer -> use_builtin_types in SimpleXMLRPCServer
Added file: http://bugs.python.org/file23654/issue2979_xmlrpc_server.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2979>
_______________________________________

From report at bugs.python.org  Thu Nov 10 21:39:32 2011
From: report at bugs.python.org (Florent Xicluna)
Date: Thu, 10 Nov 2011 20:39:32 +0000
Subject: [issue2979] use_builtin_types in xmlrpc.server
In-Reply-To: <1211846989.94.0.031553096454.issue2979@psf.upfronthosting.co.za>
Message-ID: <1320957572.37.0.484469025107.issue2979@psf.upfronthosting.co.za>


Changes by Florent Xicluna <florent.xicluna at gmail.com>:


----------
components: +XML
title: use_builtin_types in SimpleXMLRPCServer -> use_builtin_types in xmlrpc.server

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2979>
_______________________________________

From report at bugs.python.org  Thu Nov 10 21:56:53 2011
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 10 Nov 2011 20:56:53 +0000
Subject: [issue13149] optimization for append-only StringIO
In-Reply-To: <1318295854.61.0.959309073941.issue13149@psf.upfronthosting.co.za>
Message-ID: <E1RObfv-0008WF-0s@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 8d9a869db675 by Antoine Pitrou in branch 'default':
Issue #13149: Speed up append-only StringIO objects.
http://hg.python.org/cpython/rev/8d9a869db675

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13149>
_______________________________________

From report at bugs.python.org  Thu Nov 10 22:42:29 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Thu, 10 Nov 2011 21:42:29 +0000
Subject: [issue13303] Sporadic importlib failures: FileNotFoundError on
	os.rename()
In-Reply-To: <1320058871.09.0.581986884521.issue13303@psf.upfronthosting.co.za>
Message-ID: <1320961349.01.0.300042065785.issue13303@psf.upfronthosting.co.za>


Changes by Charles-Fran?ois Natali <neologix at free.fr>:


----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13303>
_______________________________________

From report at bugs.python.org  Thu Nov 10 22:42:49 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Thu, 10 Nov 2011 21:42:49 +0000
Subject: [issue7777] Support needed for AF_RDS family
In-Reply-To: <1264404460.15.0.913920533968.issue7777@psf.upfronthosting.co.za>
Message-ID: <1320961369.45.0.971394463066.issue7777@psf.upfronthosting.co.za>


Changes by Charles-Fran?ois Natali <neologix at free.fr>:


----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7777>
_______________________________________

From report at bugs.python.org  Thu Nov 10 22:52:55 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 10 Nov 2011 21:52:55 +0000
Subject: [issue13149] optimization for append-only StringIO
In-Reply-To: <1318295854.61.0.959309073941.issue13149@psf.upfronthosting.co.za>
Message-ID: <1320961975.13.0.396445509488.issue13149@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I've committed an improved version (which also optimizes seek(0); read()).

----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13149>
_______________________________________

From report at bugs.python.org  Fri Nov 11 00:38:14 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 10 Nov 2011 23:38:14 +0000
Subject: [issue13309] test_time fails: time data 'LMT' does not match format
	'%Z'
In-Reply-To: <1320156304.27.0.1872899991.issue13309@psf.upfronthosting.co.za>
Message-ID: <1320968294.41.0.481853718841.issue13309@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

It is definitely a glibc issue. Here's a C snippet to reproduce:

"""
#include <time.h>
#include <stdlib.h>

int main() {
    time_t t;
    struct tm tmp;
    char str[200];

    t = time(NULL);
    tmp = *gmtime(&t);
    tmp.tm_gmtoff = 0;
    tmp.tm_zone = NULL;

    strftime(str, sizeof(str), "%Z", &tmp);
    puts(str);

    t = -2461446500;
    localtime(&t);

    t = time(NULL);
    tmp = *gmtime(&t);
    tmp.tm_gmtoff = 0;
    tmp.tm_zone = NULL;

    strftime(str, sizeof(str), "%Z", &tmp);
    puts(str);

    return 0;
}
"""

Output:
CET
PMT


Calling localtime() or mktime() with a time largely in the past seems to corrupt the glibc's internal time structures (the "char *tm_zone[]").

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13309>
_______________________________________

From report at bugs.python.org  Fri Nov 11 00:41:01 2011
From: report at bugs.python.org (Bill Meng)
Date: Thu, 10 Nov 2011 23:41:01 +0000
Subject: [issue13382] completions in IDLE
Message-ID: <1320968461.58.0.0904951665186.issue13382@psf.upfronthosting.co.za>


New submission from Bill Meng <avorus at charter.net>:

I'm running Python 2.7 on a Mac OS 10.4
When I select Edit/completions from the menu, only the first 10 appear with a slider to the right. But the slider does not move to see the rest of the list.

----------
components: IDLE
messages: 147414
nosy: cpat
priority: normal
severity: normal
status: open
title: completions in IDLE
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13382>
_______________________________________

From report at bugs.python.org  Fri Nov 11 01:23:33 2011
From: report at bugs.python.org (Florent Xicluna)
Date: Fri, 11 Nov 2011 00:23:33 +0000
Subject: [issue13378] Change the variable "nsmap" from global to instance
	(xml.etree.ElementTree)
In-Reply-To: <1320877071.09.0.895123668254.issue13378@psf.upfronthosting.co.za>
Message-ID: <1320971013.93.0.149071174512.issue13378@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

This patch proposes an implementation of the feature.


>>> from xml.etree import ElementTree as ET
>>> ET.tostring(ET.Element('{http://localhost/house}iq'), encoding="unicode", namespaces={'http://localhost/house': 'home'})
'<home:iq xmlns:home="http://localhost/house" />'

----------
keywords: +patch
stage:  -> patch review
Added file: http://bugs.python.org/file23655/issue13378_non_global_namespaces.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13378>
_______________________________________

From report at bugs.python.org  Fri Nov 11 01:37:30 2011
From: report at bugs.python.org (Florent Xicluna)
Date: Fri, 11 Nov 2011 00:37:30 +0000
Subject: [issue13378] Change the variable "nsmap" from global to instance
	(xml.etree.ElementTree)
In-Reply-To: <1320877071.09.0.895123668254.issue13378@psf.upfronthosting.co.za>
Message-ID: <1320971850.86.0.227583687663.issue13378@psf.upfronthosting.co.za>


Changes by Florent Xicluna <florent.xicluna at gmail.com>:


----------
nosy: +scoder

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13378>
_______________________________________

From report at bugs.python.org  Fri Nov 11 01:53:55 2011
From: report at bugs.python.org (Ned Deily)
Date: Fri, 11 Nov 2011 00:53:55 +0000
Subject: [issue13382] IDLE menu scroll bar does not scroll with OS X 10.4
	Apple Tcl/Tk
In-Reply-To: <1320968461.58.0.0904951665186.issue13382@psf.upfronthosting.co.za>
Message-ID: <1320972835.76.0.582210202049.issue13382@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

I can reproduce that using a Python that uses the Apple-suppled Tcl 8.4 framework in OS X 10.4.11. That version of Tcl 8.4 is quite old.  If you are using a Python 2.7.x from a python.org installer, you may be able to use a newer version of Tcl by installing a current Tcl 8.4 (8.4.19.5 is current at the moment) from ActiveState (http://www.activestate.com/activetcl/downloads).  The menu scroll bar seems to work correctly with the newer Tcl.  The python.org Pythons will automatically use the newer ActiveState version if it is installed.  Otherwise, if you must use the Apple Tcl, although the menu scroll bar does not work on the list when you use a mouse, you can still step through the list by selecting a menu item and using the Up and Down arrow keys on the keyboard.

----------
assignee:  -> ned.deily
nosy: +ned.deily
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed
title: completions in IDLE -> IDLE menu scroll bar does not scroll with OS X 10.4 Apple Tcl/Tk

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13382>
_______________________________________

From report at bugs.python.org  Fri Nov 11 03:09:21 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 11 Nov 2011 02:09:21 +0000
Subject: [issue13309] test_time fails: time data 'LMT' does not match format
	'%Z'
In-Reply-To: <1320156304.27.0.1872899991.issue13309@psf.upfronthosting.co.za>
Message-ID: <E1ROgYH-0007by-Sn@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 05164831011e by Antoine Pitrou in branch 'default':
Avoid a glibc bug in test_time (issue #13309)
http://hg.python.org/cpython/rev/05164831011e

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13309>
_______________________________________

From report at bugs.python.org  Fri Nov 11 05:19:35 2011
From: report at bugs.python.org (Ross Lagerwall)
Date: Fri, 11 Nov 2011 04:19:35 +0000
Subject: [issue13309] test_time fails: time data 'LMT' does not match format
	'%Z'
In-Reply-To: <1320156304.27.0.1872899991.issue13309@psf.upfronthosting.co.za>
Message-ID: <1320985175.51.0.603114562774.issue13309@psf.upfronthosting.co.za>


Ross Lagerwall <rosslagerwall at gmail.com> added the comment:

Has it been reported?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13309>
_______________________________________

From report at bugs.python.org  Fri Nov 11 08:06:18 2011
From: report at bugs.python.org (Stefan Behnel)
Date: Fri, 11 Nov 2011 07:06:18 +0000
Subject: [issue13378] Change the variable "nsmap" from global to instance
	(xml.etree.ElementTree)
In-Reply-To: <1320877071.09.0.895123668254.issue13378@psf.upfronthosting.co.za>
Message-ID: <1320995178.85.0.947424354839.issue13378@psf.upfronthosting.co.za>


Stefan Behnel <scoder at users.sourceforge.net> added the comment:

Florent, thanks for the notification.

Nekmo, note that you are misusing this feature. The _namespace_map is meant to provide "well known namespace prefixes" only, so that common namespaces end up using the "expected" prefix. This is also the reason why it maps namespaces to prefixes and not the other way round. It is not meant to temporarily assign arbitrary prefix to namespaces. That is the reason for it being a global option.

That being said, lxml.etree's Element factory takes an "nsmap" parameter that implements the feature you want. It's documented here:

http://lxml.de/tutorial.html#namespaces

Note that it maps prefixes to namespaces and not the other way round. This is because there is a corresponding "nsmap" property on Elements that provides the currently defined prefixes in the context of an Element. ElementTree itself does not (and cannot) support this property because it drops the prefixes during parsing. However, I would still request that an implementation of the parameter to the Element() factory should be compatible for both libraries.

Also look for "nsmap" in the compatibility docs (appears in two sections):

http://lxml.de/compatibility.html

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13378>
_______________________________________

From report at bugs.python.org  Fri Nov 11 09:34:54 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 11 Nov 2011 08:34:54 +0000
Subject: [issue13365] str.expandtabs documentation is wrong
In-Reply-To: <1320675785.8.0.972158739581.issue13365@psf.upfronthosting.co.za>
Message-ID: <E1ROmZO-0001QV-ML@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 84f803fdc0d2 by Eli Bendersky in branch '3.2':
Issue #13365: correct an error in the documentation of str.expandtabs
http://hg.python.org/cpython/rev/84f803fdc0d2

New changeset 25191fe10da9 by Eli Bendersky in branch 'default':
Issue #13365: correct an error in the documentation of str.expandtabs. Patch by John Feuerstein
http://hg.python.org/cpython/rev/25191fe10da9

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13365>
_______________________________________

From report at bugs.python.org  Fri Nov 11 09:35:19 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Fri, 11 Nov 2011 08:35:19 +0000
Subject: [issue13365] str.expandtabs documentation is wrong
In-Reply-To: <1320675785.8.0.972158739581.issue13365@psf.upfronthosting.co.za>
Message-ID: <1321000519.78.0.843660831286.issue13365@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

Committed. Thanks for contributing.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13365>
_______________________________________

From report at bugs.python.org  Fri Nov 11 09:38:03 2011
From: report at bugs.python.org (Stefan Behnel)
Date: Fri, 11 Nov 2011 08:38:03 +0000
Subject: [issue13378] Change the variable "nsmap" from global to instance
	(xml.etree.ElementTree)
In-Reply-To: <1320877071.09.0.895123668254.issue13378@psf.upfronthosting.co.za>
Message-ID: <1321000683.78.0.752150808945.issue13378@psf.upfronthosting.co.za>


Stefan Behnel <scoder at users.sourceforge.net> added the comment:

Reading the proposed patch, I must agree that it makes more sense in ElementTree to support this as a serialiser feature. ET's tree model doesn't have a notion of prefixes, whereas it's native to lxml.etree.

Two major advantages of putting this into the serialiser are: 1) cET doesn't have to be modified, and 2) it does not require additional memory to store the nsmap reference on each Element. The latter by itself is a very valuable property, given that cET aims specifically at a low memory overhead.

I see a couple of drawbacks:

1) it only supports the case that namespaces are globally defined. The implementation cannot handle the case that local namespaces should only be defined in subtrees, or that prefixes are being reused. This is no real restriction because globally defined namespaces are usually just fine. It's more of an inconvenience in some cases, such as multi-namespace languages like SOAP or WSDL+XSD, where namespaces are commonly declared on the subtree where they start being used.

2) lxml.etree cannot support this because it keeps the prefixes in the tree nodes and uses them on serialisation. This cannot easily be overridden because the serialiser is part of libxml2.

I didn't see in the patch how (or if?) the prefix redefinition case is handled. Given that prefixes are always defined globally, it would be nice if this only resulted in an error if two namespaces that are really used in the document map to the same prefix, not always when the namespace dict is redundant by itself.

Also note that it's good to be explicit about the keyword arguments that a function accepts. It aids when help(tostring) tells you directly what you can pass in, instead of just printing "**kw".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13378>
_______________________________________

From report at bugs.python.org  Fri Nov 11 09:49:05 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 11 Nov 2011 08:49:05 +0000
Subject: [issue13191] Typo in argparse documentation
In-Reply-To: <1318795744.19.0.406202573511.issue13191@psf.upfronthosting.co.za>
Message-ID: <E1ROmn8-0002V7-NX@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 61976390763f by Eli Bendersky in branch '3.2':
Issue #13191: typo in argparse docs
http://hg.python.org/cpython/rev/61976390763f

New changeset edf944ab87c5 by Eli Bendersky in branch 'default':
Issue #13191: typo in argparse docs
http://hg.python.org/cpython/rev/edf944ab87c5

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13191>
_______________________________________

From report at bugs.python.org  Fri Nov 11 09:51:26 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Fri, 11 Nov 2011 08:51:26 +0000
Subject: [issue13191] Typo in argparse documentation
In-Reply-To: <1318795744.19.0.406202573511.issue13191@psf.upfronthosting.co.za>
Message-ID: <1321001486.59.0.969920584222.issue13191@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/issue13191>
_______________________________________

From report at bugs.python.org  Fri Nov 11 09:58:48 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Fri, 11 Nov 2011 08:58:48 +0000
Subject: [issue13239] Remove <> operator from Grammar/Grammar
In-Reply-To: <1319188291.02.0.897231487042.issue13239@psf.upfronthosting.co.za>
Message-ID: <1321001928.62.0.40388720869.issue13239@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

Attaching a patch with a clarifying comment in Grammar/Grammar. Should be enough for now?

----------
keywords: +patch
Added file: http://bugs.python.org/file23656/issue13239.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13239>
_______________________________________

From report at bugs.python.org  Fri Nov 11 10:24:07 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Fri, 11 Nov 2011 09:24:07 +0000
Subject: [issue13368] Possible problem in documentation of module subprocess, 
	method send_signal
In-Reply-To: <1320722594.89.0.739080107592.issue13368@psf.upfronthosting.co.za>
Message-ID: <1321003447.55.0.460125503219.issue13368@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

Brian, I see this text (along with the implementation) was added by you in  60197:0ab89e8bdedc

Could you state your opinion on this issue?

----------
nosy: +brian.curtin

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13368>
_______________________________________

From report at bugs.python.org  Fri Nov 11 12:15:20 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 11 Nov 2011 11:15:20 +0000
Subject: [issue13309] test_time fails: time data 'LMT' does not match format
	'%Z'
In-Reply-To: <1320985175.51.0.603114562774.issue13309@psf.upfronthosting.co.za>
Message-ID: <1321009835.3378.1.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Has it been reported?

Yes, in http://sourceware.org/bugzilla/show_bug.cgi?id=13401

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13309>
_______________________________________

From report at bugs.python.org  Fri Nov 11 12:49:12 2011
From: report at bugs.python.org (Jason R. Coombs)
Date: Fri, 11 Nov 2011 11:49:12 +0000
Subject: [issue13383] UnicodeDecodeError in distutils.core.setup when version
	is unicode
Message-ID: <1321012152.18.0.159938975919.issue13383@psf.upfronthosting.co.za>


New submission from Jason R. Coombs <jaraco at jaraco.com>:

If the version or name passed to distutils.core.setup is unicode, this results in a UnicodeDecodeError. Consider this setup.py:

from distutils.core import setup
setup(
        name=u'issue13381',
        version=u'1.0',
        modules=['setup.py'],
)

Run it with python2.7 setup.py sdist --format gztar and you'll get the following:

C:\Python\lib\distutils\dist.py:267: UserWarning: Unknown distribution option: 'modules'
  warnings.warn(msg)
running sdist
running check
warning: check: missing required meta-data: url

warning: check: missing meta-data: either (author and author_email) or (maintainer and maintainer_email) must be supplied

warning: sdist: manifest template 'MANIFEST.in' does not exist (using default file list)

warning: sdist: standard file not found: should have one of README, README.txt

writing manifest file 'MANIFEST'
copying files to foo-1.0...
copying setup.py -> foo-1.0
Creating tar archive
Traceback (most recent call last):
  File "C:\Users\jaraco\bugs\setup.py", line 6, in <module>
    modules=['setup.py'],
  File "C:\Python\lib\distutils\core.py", line 152, in setup
    dist.run_commands()
  File "C:\Python\lib\distutils\dist.py", line 953, in run_commands
    self.run_command(cmd)
  File "C:\Python\lib\distutils\dist.py", line 972, in run_command
    cmd_obj.run()
  File "C:\Python\lib\distutils\command\sdist.py", line 168, in run
    self.make_distribution()
  File "C:\Python\lib\distutils\command\sdist.py", line 451, in make_distribution
    owner=self.owner, group=self.group)
  File "C:\Python\lib\distutils\cmd.py", line 392, in make_archive
    owner=owner, group=group)
  File "C:\Python\lib\distutils\archive_util.py", line 237, in make_archive
    filename = func(base_name, base_dir, **kwargs)
  File "C:\Python\lib\distutils\archive_util.py", line 101, in make_tarball
    tar = tarfile.open(archive_name, 'w|%s' % tar_compression[compress])
  File "C:\Python\lib\tarfile.py", line 1687, in open
    _Stream(name, filemode, comptype, fileobj, bufsize),
  File "C:\Python\lib\tarfile.py", line 431, in __init__
    self._init_write_gz()
  File "C:\Python\lib\tarfile.py", line 459, in _init_write_gz
    self.__write(self.name + NUL)
  File "C:\Python\lib\tarfile.py", line 475, in __write
    self.buf += s
UnicodeDecodeError: 'ascii' codec can't decode byte 0x8b in position 1: ordinal not in range(128)


Since tarfile doesn't support unicode filenames, distutils should encode the generated filename. issue8396 suggests encoding using sys.getfilesystemencoding().

----------
assignee: tarek
components: Distutils
messages: 147427
nosy: eric.araujo, jason.coombs, tarek
priority: normal
severity: normal
status: open
title: UnicodeDecodeError in distutils.core.setup when version is unicode
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13383>
_______________________________________

From report at bugs.python.org  Fri Nov 11 12:51:35 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 11 Nov 2011 11:51:35 +0000
Subject: [issue13383] UnicodeDecodeError in distutils.core.setup when version
	is unicode
In-Reply-To: <1321012152.18.0.159938975919.issue13383@psf.upfronthosting.co.za>
Message-ID: <1321012295.7.0.965437135635.issue13383@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

This is a duplicate of #11638.

----------
nosy: +ezio.melotti
resolution:  -> duplicate
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13383>
_______________________________________

From report at bugs.python.org  Fri Nov 11 12:57:35 2011
From: report at bugs.python.org (Jason R. Coombs)
Date: Fri, 11 Nov 2011 11:57:35 +0000
Subject: [issue11638] python setup.py sdist crashes if version is unicode
In-Reply-To: <1300828733.05.0.475519990909.issue11638@psf.upfronthosting.co.za>
Message-ID: <1321012655.59.0.0153406472836.issue11638@psf.upfronthosting.co.za>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

First, the term 'gztar' doesn't appear in this ticket, and since the issue only applies when sdist --format gztar, I mention that here.

Also, issue8396 suggests encoding using sys.getfilesystemencoding().

----------
nosy: +jason.coombs

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11638>
_______________________________________

From report at bugs.python.org  Fri Nov 11 13:24:55 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 11 Nov 2011 12:24:55 +0000
Subject: [issue13237] subprocess docs should emphasise convenience functions
In-Reply-To: <1319174702.47.0.36912184976.issue13237@psf.upfronthosting.co.za>
Message-ID: <1321014295.46.0.341668131483.issue13237@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Calling this one done - any further adjustments can be handled as new tracker issues.

----------
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13237>
_______________________________________

From report at bugs.python.org  Fri Nov 11 13:37:35 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 11 Nov 2011 12:37:35 +0000
Subject: [issue13349] Uninformal error message in index() and remove()
	functions
In-Reply-To: <1320526177.89.0.678573577515.issue13349@psf.upfronthosting.co.za>
Message-ID: <1321015055.54.0.461330722947.issue13349@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

doctests by their very nature tend to overspecify things - that's why actual regression tests should be written with unittest, while doctest is kept for its originally intended purpose of testing examples included in docstrings and other documentation.

Still, there's also a reason why IGNORE_EXCEPTION_DETAIL is an available doctest option.

----------
nosy: +ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13349>
_______________________________________

From report at bugs.python.org  Fri Nov 11 13:39:17 2011
From: report at bugs.python.org (Giampaolo Rodola')
Date: Fri, 11 Nov 2011 12:39:17 +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: <1321015157.61.0.598804785057.issue3974@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/issue3974>
_______________________________________

From report at bugs.python.org  Fri Nov 11 14:20:16 2011
From: report at bugs.python.org (Florent Xicluna)
Date: Fri, 11 Nov 2011 13:20:16 +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: <1321017616.39.0.439362756614.issue3974@psf.upfronthosting.co.za>


Changes by Florent Xicluna <florent.xicluna at gmail.com>:


----------
nosy: +flox

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3974>
_______________________________________

From report at bugs.python.org  Fri Nov 11 15:19:26 2011
From: report at bugs.python.org (Brian Curtin)
Date: Fri, 11 Nov 2011 14:19:26 +0000
Subject: [issue13368] Possible problem in documentation of module subprocess, 
	method send_signal
In-Reply-To: <1320722594.89.0.739080107592.issue13368@psf.upfronthosting.co.za>
Message-ID: <1321021166.05.0.563844288647.issue13368@psf.upfronthosting.co.za>


Brian Curtin <brian at python.org> added the comment:

> But it is useless for terminating a process with os.kill() in combination with signal.SIGTERM, which corresponds to a CTRL-C-EVENT.

SIGTERM does not correspond to CTRL_C_EVENT. They may be similar in what they do, but os.kill on Windows only works with exactly CTRL_C_EVENT and CTRL_BREAK_EVENT, as this uses GenerateConsoleCtrlEvent which only works with those two values. As the documentation states, anything other than those two constants is sent to TerminateProcess. If you call os.kill with signal.SIGTERM, it would kill the process with return code 15.



I will look into adjusting the text a little, and I also need to look into the tests. I currently have CTRL_C_EVENT tests skipped, probably because I am passing the wrong process stuff as he mentioned. I had it working at some point, but I may have generalized it too far.

----------
assignee: docs at python -> brian.curtin
components: +Windows
stage:  -> needs patch
type:  -> behavior
versions: +Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13368>
_______________________________________

From report at bugs.python.org  Fri Nov 11 15:32:36 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 11 Nov 2011 14:32:36 +0000
Subject: [issue13191] Typo in argparse documentation
In-Reply-To: <1318795744.19.0.406202573511.issue13191@psf.upfronthosting.co.za>
Message-ID: <E1ROs9Z-0005eG-12@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 477f633aa09d by Eli Bendersky in branch '2.7':
Issue #13191: typo in argparse docs
http://hg.python.org/cpython/rev/477f633aa09d

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13191>
_______________________________________

From report at bugs.python.org  Fri Nov 11 15:33:11 2011
From: report at bugs.python.org (flacs)
Date: Fri, 11 Nov 2011 14:33:11 +0000
Subject: [issue8402] glob returns empty list with "[" character in the folder
	name
In-Reply-To: <1271292687.68.0.249436327738.issue8402@psf.upfronthosting.co.za>
Message-ID: <1321021991.66.0.351042059845.issue8402@psf.upfronthosting.co.za>


flacs <0f1ac5 at gmail.com> added the comment:

As a workaround, it is possible to make every glob character a character set of one character (wrapping it with [] ). The gotcha here is that you can't just use multiple replaces because you would escape the escape brackets.

Here is a function adapted from [1]:

def escape_glob(path):
    transdict = {
            '[': '[[]',
            ']': '[]]',
            '*': '[*]',
            '?': '[?]',
            }
    rc = re.compile('|'.join(map(re.escape, transdict)))
    return rc.sub(lambda m: transdict[m.group(0)], path)

[1] http://www.daniweb.com/software-development/python/code/216636

----------
components: +Library (Lib)
nosy: +flacs

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8402>
_______________________________________

From report at bugs.python.org  Fri Nov 11 15:34:09 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 11 Nov 2011 14:34:09 +0000
Subject: [issue8402] glob returns empty list with "[" character in the folder
	name
In-Reply-To: <1271292687.68.0.249436327738.issue8402@psf.upfronthosting.co.za>
Message-ID: <1321022049.23.0.132993323496.issue8402@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/issue8402>
_______________________________________

From report at bugs.python.org  Fri Nov 11 15:42:41 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 11 Nov 2011 14:42:41 +0000
Subject: [issue13161] problems with help() documentation of __i*__ operators
In-Reply-To: <1318436543.45.0.46958950416.issue13161@psf.upfronthosting.co.za>
Message-ID: <E1ROsJK-0006XK-OT@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 369487785e9f by Eli Bendersky in branch '2.7':
Issue #13161: fix doc strings of __i*__ operators
http://hg.python.org/cpython/rev/369487785e9f

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13161>
_______________________________________

From report at bugs.python.org  Fri Nov 11 15:52:42 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 11 Nov 2011 14:52:42 +0000
Subject: [issue13161] problems with help() documentation of __i*__ operators
In-Reply-To: <1318436543.45.0.46958950416.issue13161@psf.upfronthosting.co.za>
Message-ID: <E1ROsT1-0007LE-JT@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 9fbaa190f011 by Eli Bendersky in branch '3.2':
Issue #13161: fix doc strings of __i*__ operators
http://hg.python.org/cpython/rev/9fbaa190f011

New changeset d58de3e9870a by Eli Bendersky in branch 'default':
Issue #13161: fix doc strings of __i*__ operators. Closes #13161
http://hg.python.org/cpython/rev/d58de3e9870a

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13161>
_______________________________________

From report at bugs.python.org  Fri Nov 11 15:53:05 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Fri, 11 Nov 2011 14:53:05 +0000
Subject: [issue13161] problems with help() documentation of __i*__ operators
In-Reply-To: <1318436543.45.0.46958950416.issue13161@psf.upfronthosting.co.za>
Message-ID: <1321023185.39.0.234737213888.issue13161@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/issue13161>
_______________________________________

From report at bugs.python.org  Fri Nov 11 16:19:46 2011
From: report at bugs.python.org (Robert Xiao)
Date: Fri, 11 Nov 2011 15:19:46 +0000
Subject: [issue13384] Unnecessary __future__ import in random module
Message-ID: <1321024786.01.0.759110473236.issue13384@psf.upfronthosting.co.za>


New submission from Robert Xiao <nneonneo at gmail.com>:

Lib/random.py in Python 3.2 contains the line

from __future__ import division

even though it is no longer necessary, as true float division is the default in Python 3.

Trivial patch:

--- lib/python3.2/random.py	2011-09-03 20:32:05.000000000 -0400
+++ lib/python3.2/random.py	2011-11-11 11:11:11.000000000 -0400
@@ -36,7 +36,6 @@
 
 """
 
-from __future__ import division
 from warnings import warn as _warn
 from types import MethodType as _MethodType, BuiltinMethodType as _BuiltinMethodType
 from math import log as _log, exp as _exp, pi as _pi, e as _e, ceil as _ceil

----------
components: Library (Lib)
messages: 147437
nosy: nneonneo
priority: normal
severity: normal
status: open
title: Unnecessary __future__ import in random module
versions: Python 3.2, Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13384>
_______________________________________

From report at bugs.python.org  Fri Nov 11 16:41:37 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 11 Nov 2011 15:41:37 +0000
Subject: [issue13384] Unnecessary __future__ import in random module
In-Reply-To: <1321024786.01.0.759110473236.issue13384@psf.upfronthosting.co.za>
Message-ID: <E1ROtEM-0003RZ-Mr@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 3fdc5a75d6e1 by Brian Curtin in branch '3.2':
Fix #13384. Remove __future__ import in 3.x code.
http://hg.python.org/cpython/rev/3fdc5a75d6e1

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13384>
_______________________________________

From report at bugs.python.org  Fri Nov 11 16:42:27 2011
From: report at bugs.python.org (Brian Curtin)
Date: Fri, 11 Nov 2011 15:42:27 +0000
Subject: [issue13384] Unnecessary __future__ import in random module
In-Reply-To: <1321024786.01.0.759110473236.issue13384@psf.upfronthosting.co.za>
Message-ID: <1321026147.92.0.0549733056165.issue13384@psf.upfronthosting.co.za>


Changes by Brian Curtin <brian at python.org>:


----------
assignee:  -> brian.curtin
nosy: +brian.curtin
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
type:  -> behavior
versions:  -Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13384>
_______________________________________

From report at bugs.python.org  Fri Nov 11 17:30:14 2011
From: report at bugs.python.org (Brian Curtin)
Date: Fri, 11 Nov 2011 16:30:14 +0000
Subject: [issue10854] Output .pyd name in error message of ImportError when
	DLL load fails
In-Reply-To: <1294415325.09.0.315523226252.issue10854@psf.upfronthosting.co.za>
Message-ID: <1321029014.53.0.294573551212.issue10854@psf.upfronthosting.co.za>


Brian Curtin <brian at python.org> added the comment:

Marked #1559549 as a dependency. I combine the patch in this issue with the one over there.

----------
dependencies: +ImportError needs attributes for module and file name

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10854>
_______________________________________

From report at bugs.python.org  Fri Nov 11 19:00:24 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 11 Nov 2011 18:00:24 +0000
Subject: [issue13309] test_time fails: time data 'LMT' does not match format
	'%Z'
In-Reply-To: <1320156304.27.0.1872899991.issue13309@psf.upfronthosting.co.za>
Message-ID: <E1ROvOS-0008JC-QR@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset bcd347cd6bf2 by Florent Xicluna in branch 'default':
Use unittest.skipUnless to skip the test related to the glibc bug, issue #13309.
http://hg.python.org/cpython/rev/bcd347cd6bf2

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13309>
_______________________________________

From report at bugs.python.org  Fri Nov 11 19:02:10 2011
From: report at bugs.python.org (Florent Xicluna)
Date: Fri, 11 Nov 2011 18:02:10 +0000
Subject: [issue13309] test_time fails: time data 'LMT' does not match format
	'%Z'
In-Reply-To: <1320156304.27.0.1872899991.issue13309@psf.upfronthosting.co.za>
Message-ID: <1321034530.49.0.657630691982.issue13309@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

Thank you for the investigation, and the bug report to the glibc team.
I propose to close it as "won't fix".

----------
resolution:  -> wont fix
stage: test needed -> committed/rejected
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13309>
_______________________________________

From report at bugs.python.org  Fri Nov 11 20:16:17 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 11 Nov 2011 19:16:17 +0000
Subject: [issue12875] backport re.compile flags default value documentation
In-Reply-To: <1314854228.49.0.163476055978.issue12875@psf.upfronthosting.co.za>
Message-ID: <E1ROwa6-00078a-OE@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 02e4d3ebbb02 by Eli Bendersky in branch '2.7':
Issue #12875: explicitly specify default value of the optional 'flags' argument to re.* functions. Closes #12875
http://hg.python.org/cpython/rev/02e4d3ebbb02

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12875>
_______________________________________

From report at bugs.python.org  Fri Nov 11 20:19:53 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Fri, 11 Nov 2011 19:19:53 +0000
Subject: [issue12875] backport re.compile flags default value documentation
In-Reply-To: <1314854228.49.0.163476055978.issue12875@psf.upfronthosting.co.za>
Message-ID: <1321039193.68.0.715912223859.issue12875@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/issue12875>
_______________________________________

From report at bugs.python.org  Fri Nov 11 20:39:16 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Fri, 11 Nov 2011 19:39:16 +0000
Subject: [issue13385] Add an explicit re.NOFLAGS flag value to the re module
Message-ID: <1321040356.1.0.483749785774.issue13385@psf.upfronthosting.co.za>


New submission from Eli Bendersky <eliben at gmail.com>:

The flags 're' accept are numeric underneath, and the current value of "no flags" is just 0, which is also specified in the documentation as the default value. However, using raw numeric values is not a good programming practice. 

The suggestion is to add a simple re.NOFLAGS constant to the 're' module with the value of 0, and use it in the documentation instead of plain 0. It's a simple change that won't break anything and may provide better readability for some code, as well as remove the need for plain integer references in the documentation.

See also issues #11957 and #12875.

Adding to nosy people taking part in discussion of the aforementioned issue. If you're not interested, please remove yourself - I apologize in advance.

----------
components: Library (Lib), Regular Expressions
messages: 147443
nosy: eli.bendersky, eric.araujo, eric.smith, ezio.melotti, terry.reedy
priority: normal
severity: normal
status: open
title: Add an explicit re.NOFLAGS flag value to the re module
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13385>
_______________________________________

From report at bugs.python.org  Fri Nov 11 21:25:22 2011
From: report at bugs.python.org (Eric V. Smith)
Date: Fri, 11 Nov 2011 20:25:22 +0000
Subject: [issue13385] Add an explicit re.NOFLAGS flag value to the re module
In-Reply-To: <1321040356.1.0.483749785774.issue13385@psf.upfronthosting.co.za>
Message-ID: <1321043122.64.0.471775686603.issue13385@psf.upfronthosting.co.za>


Eric V. Smith <eric at trueblade.com> added the comment:

Since the flags are OR'd together, I don't see what other value the "no flags" parameter could have, other than zero. That said, I don't feel strongly about it, and if it helps readability I'm not opposed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13385>
_______________________________________

From report at bugs.python.org  Fri Nov 11 21:47:46 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 11 Nov 2011 20:47:46 +0000
Subject: [issue12875] backport re.compile flags default value documentation
In-Reply-To: <1314854228.49.0.163476055978.issue12875@psf.upfronthosting.co.za>
Message-ID: <1321044466.89.0.263607913783.issue12875@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

The documentation now shows::
    match(pattern, string[, flags=0])
Is it normal to have the brackets *and* the default value?

----------
nosy: +amaury.forgeotdarc
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12875>
_______________________________________

From report at bugs.python.org  Fri Nov 11 22:09:24 2011
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 11 Nov 2011 21:09:24 +0000
Subject: [issue12875] backport re.compile flags default value documentation
In-Reply-To: <1314854228.49.0.163476055978.issue12875@psf.upfronthosting.co.za>
Message-ID: <1321045764.42.0.758993951091.issue12875@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

No, it's not.

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12875>
_______________________________________

From report at bugs.python.org  Fri Nov 11 23:04:21 2011
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 11 Nov 2011 22:04:21 +0000
Subject: [issue13239] Remove <> operator from Grammar/Grammar
In-Reply-To: <1319188291.02.0.897231487042.issue13239@psf.upfronthosting.co.za>
Message-ID: <1321049061.38.0.414308237762.issue13239@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

I think the clarification should be enough.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13239>
_______________________________________

From report at bugs.python.org  Fri Nov 11 23:35:50 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 11 Nov 2011 22:35:50 +0000
Subject: [issue13385] Add an explicit re.NOFLAGS flag value to the re module
In-Reply-To: <1321040356.1.0.483749785774.issue13385@psf.upfronthosting.co.za>
Message-ID: <1321050950.51.0.893901148629.issue13385@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

As Eric, I don't really think it's useful, and it might actually be confusing (people will start wondering if there's a difference between 0 and NOFLAGS).

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13385>
_______________________________________

From report at bugs.python.org  Fri Nov 11 23:41:56 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 11 Nov 2011 22:41:56 +0000
Subject: [issue13384] Unnecessary __future__ import in random module
In-Reply-To: <1321024786.01.0.759110473236.issue13384@psf.upfronthosting.co.za>
Message-ID: <1321051316.9.0.697096303338.issue13384@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

I thought we had a policy that future imports would never be removed.

----------
nosy: +rhettinger
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13384>
_______________________________________

From report at bugs.python.org  Fri Nov 11 23:44:35 2011
From: report at bugs.python.org (Brian Curtin)
Date: Fri, 11 Nov 2011 22:44:35 +0000
Subject: [issue13384] Unnecessary __future__ import in random module
In-Reply-To: <1321024786.01.0.759110473236.issue13384@psf.upfronthosting.co.za>
Message-ID: <1321051475.4.0.57418955269.issue13384@psf.upfronthosting.co.za>


Brian Curtin <brian at python.org> added the comment:

That's news to me since it probably pre-dates my involvement around here. I'll revert if that's correct.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13384>
_______________________________________

From report at bugs.python.org  Fri Nov 11 23:59:12 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 11 Nov 2011 22:59:12 +0000
Subject: [issue13385] Add an explicit re.NOFLAGS flag value to the re module
In-Reply-To: <1321040356.1.0.483749785774.issue13385@psf.upfronthosting.co.za>
Message-ID: <1321052352.22.0.996584605639.issue13385@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

I think a proper solution would be fixing #11957.  Adding a NOFLAGS alias for 0 would help fixing #12875, but I don't think it will be useful/use otherwise.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13385>
_______________________________________

From report at bugs.python.org  Sat Nov 12 00:21:52 2011
From: report at bugs.python.org (Cody C)
Date: Fri, 11 Nov 2011 23:21:52 +0000
Subject: [issue12988] IDLE on Win7 crashes when saving to Documents Library
In-Reply-To: <1316123106.02.0.189929579788.issue12988@psf.upfronthosting.co.za>
Message-ID: <1321053712.2.0.676509122107.issue12988@psf.upfronthosting.co.za>


Changes by Cody C <ccarse at gmail.com>:


----------
type:  -> crash

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12988>
_______________________________________

From report at bugs.python.org  Sat Nov 12 00:22:50 2011
From: report at bugs.python.org (Cody C)
Date: Fri, 11 Nov 2011 23:22:50 +0000
Subject: [issue12988] IDLE on Win7 crashes when saving to Documents Library
In-Reply-To: <1316123106.02.0.189929579788.issue12988@psf.upfronthosting.co.za>
Message-ID: <1321053770.27.0.207125013019.issue12988@psf.upfronthosting.co.za>


Cody C <ccarse at gmail.com> added the comment:

Still an issue as of 11/11/11.

----------
nosy: +Cody.C

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12988>
_______________________________________

From report at bugs.python.org  Sat Nov 12 00:25:43 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 11 Nov 2011 23:25:43 +0000
Subject: [issue13384] Unnecessary __future__ import in random module
In-Reply-To: <1321024786.01.0.759110473236.issue13384@psf.upfronthosting.co.za>
Message-ID: <1321053943.67.0.374099707255.issue13384@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Things won't ever be removed from the __future__ module, but there's no harm in removing ones with no effect.

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13384>
_______________________________________

From report at bugs.python.org  Sat Nov 12 01:31:15 2011
From: report at bugs.python.org (Ned Deily)
Date: Sat, 12 Nov 2011 00:31:15 +0000
Subject: [issue12988] IDLE on Win7 crashes when saving to Documents Library
In-Reply-To: <1316123106.02.0.189929579788.issue12988@psf.upfronthosting.co.za>
Message-ID: <1321057875.38.0.652404752999.issue12988@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12988>
_______________________________________

From report at bugs.python.org  Sat Nov 12 01:38:50 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 12 Nov 2011 00:38:50 +0000
Subject: [issue13193] test_packaging and test_distutils failures
In-Reply-To: <1318800293.23.0.0737706148876.issue13193@psf.upfronthosting.co.za>
Message-ID: <E1RP1cF-0006Pj-3g@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 0a94e2f807c7 by Antoine Pitrou in branch '3.2':
Issue #13193: fix distutils.filelist.FileList under Windows
http://hg.python.org/cpython/rev/0a94e2f807c7

New changeset 80d5040f2a78 by Antoine Pitrou in branch '3.2':
Add NEWS entry for #13193
http://hg.python.org/cpython/rev/80d5040f2a78

New changeset 64485e0700ba by Antoine Pitrou in branch 'default':
Issue #13193: Fix distutils.filelist.FileList and
http://hg.python.org/cpython/rev/64485e0700ba

New changeset 557a973709de by Antoine Pitrou in branch '2.7':
Issue #13193: Fix distutils.filelist.FileList under Windows.  The
http://hg.python.org/cpython/rev/557a973709de

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13193>
_______________________________________

From report at bugs.python.org  Sat Nov 12 02:25:33 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 12 Nov 2011 01:25:33 +0000
Subject: [issue13384] Unnecessary __future__ import in random module
In-Reply-To: <1321024786.01.0.759110473236.issue13384@psf.upfronthosting.co.za>
Message-ID: <1321061133.89.0.701210959355.issue13384@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

At one point, for 2.x at least, we weren't removing the "from __future__" imports even after the feature became available.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13384>
_______________________________________

From report at bugs.python.org  Sat Nov 12 02:37:04 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 12 Nov 2011 01:37:04 +0000
Subject: [issue13384] Unnecessary __future__ import in random module
In-Reply-To: <1321024786.01.0.759110473236.issue13384@psf.upfronthosting.co.za>
Message-ID: <1321061824.59.0.524891134647.issue13384@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

AFAIK on 2.x there are a few modules that are supposed to work even with older version of Python (I think I even saw one that is supposed to still be compatible with Python 1.5).
I don't think this is the case for Python 3 though.

----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13384>
_______________________________________

From report at bugs.python.org  Sat Nov 12 02:55:55 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 12 Nov 2011 01:55:55 +0000
Subject: [issue13333] utf-7 inconsistent with surrogates
In-Reply-To: <1320322427.22.0.464090396955.issue13333@psf.upfronthosting.co.za>
Message-ID: <1321062955.22.0.0733620991294.issue13333@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

FWIW Wikipedia says "Other characters must be encoded in UTF-16 (hence U+10000 and higher would be encoded into surrogates) and then in modified Base64."

So one possible interpretation is that while encoding a non-BMP char, it should be first converted in a surrogate pair and then each of the surrogates should be encoded just like any other 16bit code unit.
While decoding, it seems reasonable to do the opposite, i.e. recombine the surrogate pair.

The RFC doesn't say anything about lone surrogates, but I think that the fact that surrogates are used internally doesn't necessarily mean that the codec should be able to encode/decode them when they are not paired.  The other UTF-* codecs reject them, but that's because it is explicitly forbidden by their respective standards.

So I'm +1 about recombining them while decoding, and ?0 about allowing lone surrogates.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13333>
_______________________________________

From report at bugs.python.org  Sat Nov 12 04:23:48 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Sat, 12 Nov 2011 03:23:48 +0000
Subject: [issue13385] Add an explicit re.NOFLAGS flag value to the re module
In-Reply-To: <1321040356.1.0.483749785774.issue13385@psf.upfronthosting.co.za>
Message-ID: <1321068228.69.0.759440101028.issue13385@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

Antoine, what's the outcome of people wondering about the difference? I don't see what's bad about it, it's not as if people are writing (or supposed to write) code that does arithmetic on these flag values. Their only usage is to:

1. Provide no flags
2. Provide a single flag
3. Provide a few flags ORed together

The "OR" (which makes no mathematical sense in this case) is bad enough, but why not provide an easy fix for (1), making it explicit instead of implicit. I think we sometimes forget that not everyone who picks up Python is an old C dog, familiar with these tricks. To newbies for whom Python is the first language, these flags aren't very intuitive to use, I imagine.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13385>
_______________________________________

From report at bugs.python.org  Sat Nov 12 04:32:44 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Sat, 12 Nov 2011 03:32:44 +0000
Subject: [issue12875] backport re.compile flags default value documentation
In-Reply-To: <1314854228.49.0.163476055978.issue12875@psf.upfronthosting.co.za>
Message-ID: <1321068764.24.0.892357143906.issue12875@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

Amaury & Georg,

Grepping through the docs disagrees with your claims ;-) Try to grep for "\=None\]" to see what I mean. There are tons of places where default values are placed inside the brackets. For example in http://docs.python.org/library/csv.html --> look at:

    sniff(sample[, delimiters=None])

or even:

    class csv.DictReader(csvfile[, fieldnames=None[, restkey=None[, restval=None[, dialect='excel'[, *args, **kwds]]]]])

That said, I have absolutely no objections to following an accepted convention. But what is it?

I looked around, and found the following in the documentation guide:

http://docs.python.org/dev/py3k/documenting/fromlatex.html

    There is no optional command. Just give function signatures 
    like they should appear in the output:

    .. function:: open(filename[, mode[, buffering]])

       Description.

This (taken from the 3.3 guide) mentions the 2.x guideline and doesn't mention default values.

So what should I do here? According to Ezio's earlier message, the new style (without brackets) is also being used in Python 2 now. I can do the switch for the 're' module, but can we first get the convention documented somewhere?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12875>
_______________________________________

From report at bugs.python.org  Sat Nov 12 04:51:48 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 12 Nov 2011 03:51:48 +0000
Subject: [issue13385] Add an explicit re.NOFLAGS flag value to the re module
In-Reply-To: <1321040356.1.0.483749785774.issue13385@psf.upfronthosting.co.za>
Message-ID: <1321069908.23.0.413802573366.issue13385@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

If you want to provide no flags, I think it's easier to provide no flags, rather than having to learn some NOFLAGS constant value that can be used to make the fact that you are passing no flags more explicit than it already is.
I might agree that ORing flags might not be the best API ever, but that a separate problem.  So in my opinion there's nothing to fix about 1.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13385>
_______________________________________

From report at bugs.python.org  Sat Nov 12 04:54:57 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 12 Nov 2011 03:54:57 +0000
Subject: [issue12875] backport re.compile flags default value documentation
In-Reply-To: <1314854228.49.0.163476055978.issue12875@psf.upfronthosting.co.za>
Message-ID: <1321070097.1.0.586438710737.issue12875@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

> but can we first get the convention documented somewhere?

+1
This was on my todo list, but feel free to open a new issue about it.

> Grepping through the docs disagrees with your claims 

That's because is not documented and not everyone is aware of the conventions and how/where they should be followed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12875>
_______________________________________

From report at bugs.python.org  Sat Nov 12 05:20:28 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Sat, 12 Nov 2011 04:20:28 +0000
Subject: [issue12875] backport re.compile flags default value documentation
In-Reply-To: <1314854228.49.0.163476055978.issue12875@psf.upfronthosting.co.za>
Message-ID: <1321071628.52.0.659912063651.issue12875@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

Ezio, what do you suggest to do regarding *this* issue?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12875>
_______________________________________

From report at bugs.python.org  Sat Nov 12 05:50:35 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Sat, 12 Nov 2011 04:50:35 +0000
Subject: [issue12767] document threading.Condition.notify
In-Reply-To: <1313548629.79.0.0632318255733.issue12767@psf.upfronthosting.co.za>
Message-ID: <1321073435.23.0.593113745004.issue12767@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

I propose the attached patch for the documentation. Any objections?

----------
keywords: +patch
Added file: http://bugs.python.org/file23657/issue12767.1.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12767>
_______________________________________

From report at bugs.python.org  Sat Nov 12 05:52:24 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Sat, 12 Nov 2011 04:52:24 +0000
Subject: [issue12768] docstrings for the threading module
In-Reply-To: <1313548989.72.0.178892692878.issue12768@psf.upfronthosting.co.za>
Message-ID: <1321073544.48.0.226764189283.issue12768@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

Graeme, any news on this?

If you re-do the patch for current tip and address the review comments, I think we can commit it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12768>
_______________________________________

From report at bugs.python.org  Sat Nov 12 06:04:14 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Sat, 12 Nov 2011 05:04: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: <1321074254.84.0.661453609654.issue12188@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/issue12188>
_______________________________________

From report at bugs.python.org  Sat Nov 12 06:04:41 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Sat, 12 Nov 2011 05:04:41 +0000
Subject: [issue11173] Undocumented public APIs in Python 3.2
In-Reply-To: <1297351155.94.0.957592646254.issue11173@psf.upfronthosting.co.za>
Message-ID: <1321074281.25.0.115352827746.issue11173@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/issue11173>
_______________________________________

From report at bugs.python.org  Sat Nov 12 06:05:29 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Sat, 12 Nov 2011 05:05:29 +0000
Subject: [issue3849] FUD in documentation for urllib.urlopen()
In-Reply-To: <1221246343.23.0.128587140594.issue3849@psf.upfronthosting.co.za>
Message-ID: <1321074329.23.0.413611139401.issue3849@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/issue3849>
_______________________________________

From report at bugs.python.org  Sat Nov 12 06:06:17 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Sat, 12 Nov 2011 05:06:17 +0000
Subject: [issue10838] subprocess __all__ is incomplete
In-Reply-To: <1294260769.5.0.0970426129524.issue10838@psf.upfronthosting.co.za>
Message-ID: <1321074377.07.0.686567502038.issue10838@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/issue10838>
_______________________________________

From report at bugs.python.org  Sat Nov 12 06:06:47 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Sat, 12 Nov 2011 05:06:47 +0000
Subject: [issue5088] optparse: inconsistent default value for append actions
In-Reply-To: <1233140307.53.0.685208172708.issue5088@psf.upfronthosting.co.za>
Message-ID: <1321074407.34.0.566196496473.issue5088@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/issue5088>
_______________________________________

From report at bugs.python.org  Sat Nov 12 06:08:44 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Sat, 12 Nov 2011 05:08:44 +0000
Subject: [issue10501] make_buildinfo regression with unquoted path
In-Reply-To: <1290420103.87.0.191839202946.issue10501@psf.upfronthosting.co.za>
Message-ID: <1321074524.32.0.691186975771.issue10501@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/issue10501>
_______________________________________

From report at bugs.python.org  Sat Nov 12 06:43:03 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 12 Nov 2011 05:43:03 +0000
Subject: [issue12875] backport re.compile flags default value documentation
In-Reply-To: <1314854228.49.0.163476055978.issue12875@psf.upfronthosting.co.za>
Message-ID: <1321076583.92.0.622094066752.issue12875@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

I suggest removing the [].

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12875>
_______________________________________

From report at bugs.python.org  Sat Nov 12 06:49:11 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 12 Nov 2011 05:49:11 +0000
Subject: [issue12767] document threading.Condition.notify
In-Reply-To: <1313548629.79.0.0632318255733.issue12767@psf.upfronthosting.co.za>
Message-ID: <1321076951.08.0.270482807134.issue12767@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

+      This method wakes up at most *n* of the threads
+      The current implementation wakes up exactly *n* threads
+      A future, optimized implementation may occasionally wake up more than
+      one thread.

Isn't this a bit contradictory?

----------
nosy: +ezio.melotti
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12767>
_______________________________________

From report at bugs.python.org  Sat Nov 12 06:51:20 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Sat, 12 Nov 2011 05:51:20 +0000
Subject: [issue12875] backport re.compile flags default value documentation
In-Reply-To: <1314854228.49.0.163476055978.issue12875@psf.upfronthosting.co.za>
Message-ID: <1321077080.2.0.52173967055.issue12875@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

Hmm, I've just notice that this [default=val] pattern already exists in the 're' docs in 2.7, for example:

  subn(repl, string[, count=0])

So my change was consistent within the documentation of this module.

No doubt, the conventions are currently a mess ;-)

I suggest to just convert the whole 're' RST page to the new 3.x convention (i.e. model it after the same RST in the default branch). Is this acceptable? If yes, I will submit a patch for review first.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12875>
_______________________________________

From report at bugs.python.org  Sat Nov 12 06:53:37 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Sat, 12 Nov 2011 05:53:37 +0000
Subject: [issue12767] document threading.Condition.notify
In-Reply-To: <1313548629.79.0.0632318255733.issue12767@psf.upfronthosting.co.za>
Message-ID: <1321077217.37.0.577688016025.issue12767@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

Ezio, thanks for the catch. I missed that one. Attaching a new, fixed patch.

----------
Added file: http://bugs.python.org/file23658/issue12767.2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12767>
_______________________________________

From report at bugs.python.org  Sat Nov 12 07:08:41 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 12 Nov 2011 06:08:41 +0000
Subject: [issue13386] Document documentation conventions for optional args
Message-ID: <1321078121.18.0.541430257552.issue13386@psf.upfronthosting.co.za>


New submission from Ezio Melotti <ezio.melotti at gmail.com>:

AFAIU the conventions for optional argument in the doc are as follow:

If a function has optional arguments and it accepts keyword arguments, the "func(arg=default)" notation should be used, for example:
  str.splitlines(keepends=False)

If a function has optional arguments but it doesn't accept keyword arguments, the "func([arg1])" notation is used instead.  This should apply only to some C functions, for example:
  str.strip([chars])

The notation "func([arg=default])" should never be used, and "func([arg])" should be used only when keyword args are not accepted.

These rules apply to both Python 2 and Python 3.

A thing that is still not clear is what to do in case the default value is a placeholder (like object(), None, -1) and the actual value is then computed in the function.

----------
assignee: docs at python
components: Documentation
messages: 147469
nosy: docs at python, eli.bendersky, eric.araujo, ezio.melotti, georg.brandl
priority: normal
severity: normal
stage: needs patch
status: open
title: Document documentation conventions for optional args
versions: Python 2.7, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13386>
_______________________________________

From report at bugs.python.org  Sat Nov 12 07:13:43 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 12 Nov 2011 06:13:43 +0000
Subject: [issue12875] backport re.compile flags default value documentation
In-Reply-To: <1314854228.49.0.163476055978.issue12875@psf.upfronthosting.co.za>
Message-ID: <1321078423.87.0.530397684862.issue12875@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

I created #13386 about the conventions that should be followed in the doc.

Converting the whole page is fine with me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12875>
_______________________________________

From report at bugs.python.org  Sat Nov 12 11:53:48 2011
From: report at bugs.python.org (Eric V. Smith)
Date: Sat, 12 Nov 2011 10:53:48 +0000
Subject: [issue13386] Document documentation conventions for optional args
In-Reply-To: <1321078121.18.0.541430257552.issue13386@psf.upfronthosting.co.za>
Message-ID: <1321095228.68.0.498192197786.issue13386@psf.upfronthosting.co.za>


Eric V. Smith <eric at trueblade.com> added the comment:

To your last point, I think it's important to specify the default value placeholder (basically a sentinel) in the documentation. For example, if a function takes -1 to mean "all occurrences", then the caller needs to know how what value to pass in in order to let the function compute the value. This is especially true if it's cheaper for the function to compute the value instead of the caller.

I've run into this problem before, where I wanted to pass in some sentinel value and I had to read the source to figure out what it was. I think the function was in the standard library, but now I can't recall what it was.

----------
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13386>
_______________________________________

From report at bugs.python.org  Sat Nov 12 12:11:00 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 12 Nov 2011 11:11:00 +0000
Subject: [issue13294] http.server - HEAD request when no resource is defined.
In-Reply-To: <1319985642.06.0.787750282348.issue13294@psf.upfronthosting.co.za>
Message-ID: <1321096260.2.0.934021437227.issue13294@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Hi Karl,
I?m not clear about what problem or need this report describes.  Is it a proposition to add a new method for SimpleHTTPRequestHandler to handle HEAD requests?

----------
nosy: +eric.araujo
versions: +Python 3.3 -Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13294>
_______________________________________

From report at bugs.python.org  Sat Nov 12 12:18:29 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 12 Nov 2011 11:18:29 +0000
Subject: [issue13297] xmlrpc.client could accept bytes for input and output
In-Reply-To: <1320018100.14.0.184941596185.issue13297@psf.upfronthosting.co.za>
Message-ID: <1321096709.03.0.465750741481.issue13297@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I made comments on Rietveld but there was a glitch, I?m not sure the email was sent.

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13297>
_______________________________________

From report at bugs.python.org  Sat Nov 12 12:19:29 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 12 Nov 2011 11:19:29 +0000
Subject: [issue13298] Result type depends on order of operands for bytes and
	bytearray
In-Reply-To: <1320020077.78.0.866789839878.issue13298@psf.upfronthosting.co.za>
Message-ID: <1321096769.66.0.0908892411605.issue13298@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/issue13298>
_______________________________________

From report at bugs.python.org  Sat Nov 12 12:20:06 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 12 Nov 2011 11:20:06 +0000
Subject: [issue13299] namedtuple row factory for sqlite3
In-Reply-To: <1320021145.59.0.53370875256.issue13299@psf.upfronthosting.co.za>
Message-ID: <1321096806.39.0.823016476216.issue13299@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> collections.namedtuple provides a much nicer interface than sqlite3.Row
Definitely!

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13299>
_______________________________________

From report at bugs.python.org  Sat Nov 12 12:27:54 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 12 Nov 2011 11:27:54 +0000
Subject: [issue13329] Runs normal as console script but falls as CGI
In-Reply-To: <1320290534.75.0.190110850785.issue13329@psf.upfronthosting.co.za>
Message-ID: <1321097274.11.0.250444912964.issue13329@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

The contents are valid UTF-8; the problem does not seem related to PYTHONIOENCODING (run ?python3.2 Test.py | cat? so that stdout is not a tty; this used to be buggy in 2.x, hence PYTHONIOENCODING, but in 3.x the encoding of stdout is UTF-8 even in a pipeline).

Nick, we?ll need more info about your setup, as well as the full traceback.  Thanks!

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13329>
_______________________________________

From report at bugs.python.org  Sat Nov 12 12:39:18 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 12 Nov 2011 11:39:18 +0000
Subject: [issue13336] packaging.command.Command.copy_file doesn't implement
	preserve_mode and preserve_times
In-Reply-To: <1320343597.32.0.412564968356.issue13336@psf.upfronthosting.co.za>
Message-ID: <1321097958.03.0.798064907436.issue13336@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Thanks for the report.  Have you found the bug with a real setup.cfg or hook, or were you just reading the code?

I?m not sure how hard to fix this will be.  The copy_file method delegates to shutil.copyfile, but this does not have the arguments we need, contrary to the former distutils file_util.copy_file function.

Currently it?s only build_py that uses this parameter: 

        # if a file is read-only in the working
        # directory, we want it to be installed read/write so that the next
        # installation of the same module distribution can overwrite it
        # without problems.  (This might be a Unix-specific issue.)  Thus
        # we turn off 'preserve_mode' when copying to the build directory,
        # since the build directory is supposed to be exactly what the
        # installation will look like (ie. we preserve mode when
        # installing).

Depending on whether shutil supports what we need, different patches could be made:
- Change code to use the right shutil function
- Add code in copy_file to walk and chmod
- Remove the preserve_* arguments and add another method for build_py

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13336>
_______________________________________

From report at bugs.python.org  Sat Nov 12 12:40:37 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 12 Nov 2011 11:40:37 +0000
Subject: [issue13282] the table of contents in epub file is too long
In-Reply-To: <1319796506.79.0.347343158897.issue13282@psf.upfronthosting.co.za>
Message-ID: <1321098037.18.0.989522788185.issue13282@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Thanks for the report.  I do not know if this something that we can fix in the CPython repository by editing some template or config file or if it requires a patch to Sphinx first.  Georg?

----------
nosy: +eric.araujo, georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13282>
_______________________________________

From report at bugs.python.org  Sat Nov 12 12:51:38 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 12 Nov 2011 11:51:38 +0000
Subject: [issue13281] Make robotparser.RobotFileParser ignore blank lines
In-Reply-To: <1319747444.2.0.491041533825.issue13281@psf.upfronthosting.co.za>
Message-ID: <1321098698.65.0.563736894098.issue13281@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

First, I?d like to remind that the robots spec is not an official Internet spec backed up by an official body.  It?s also not as important as (say) HTTP parsing.

For this bug, IMO the guiding principle should be Postel?s Law.  What harm is there in being more lenient than the spec?  People apparently want to parse the robots.txt with blank lines from last.fm and whitehouse.gov, and I don?t think there are people that depend on the fact that blank lines cause the rest of the file to be ignored.  Hence, I think too that we should be pragmatic and allow blank lines, to follow the precedent established by other tools and be pragmatic.

If you feel strongly about this, I can contact the robotstxt.org people.

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13281>
_______________________________________

From report at bugs.python.org  Sat Nov 12 13:24:43 2011
From: report at bugs.python.org (karl)
Date: Sat, 12 Nov 2011 12:24:43 +0000
Subject: [issue13294] http.server - HEAD request when no resource is defined.
In-Reply-To: <1319985642.06.0.787750282348.issue13294@psf.upfronthosting.co.za>
Message-ID: <1321100683.13.0.75317921813.issue13294@psf.upfronthosting.co.za>


karl <karl+pythonbugs at la-grange.net> added the comment:

Eric,

Two possible solutions to explore:

Either the HEAD reports exactly the same thing than a GET without the body, because it is the role of the GET, but that means indeed adding support for the HEAD. 

or creating a catch-all answer for all unknown or not implemented methods with a "501 Method not implemented" response from the server.

Right now the HEAD returns something :)

I still need to propose a patch. Daily job get into the way :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13294>
_______________________________________

From report at bugs.python.org  Sat Nov 12 13:43:22 2011
From: report at bugs.python.org (Florent Xicluna)
Date: Sat, 12 Nov 2011 12:43:22 +0000
Subject: [issue13387] add exact_type argument to assertIsInstance
Message-ID: <1321101802.89.0.94542095022.issue13387@psf.upfronthosting.co.za>


New submission from Florent Xicluna <florent.xicluna at gmail.com>:

Sometimes we want to check the exact type of an object.
The method assertIsInstance could be misleading in such case.

The current workaround is:
assertIs(type(obj), some_class)

However we can add an argument to the method to keep the benefit of  having a nice failure message.

Examples:
  assertIsInstance(stdobj, dict, exact_type=True)
  assertIsInstance(myobj, dict, exact_type=MyDict)

----------
components: Tests
messages: 147480
nosy: flox, georg.brandl, michael.foord
priority: normal
severity: normal
status: open
title: add exact_type argument to assertIsInstance
type: feature request
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13387>
_______________________________________

From report at bugs.python.org  Sat Nov 12 14:37:34 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 12 Nov 2011 13:37:34 +0000
Subject: [issue13249] argparse.ArgumentParser() lists arguments in the wrong
	order
In-Reply-To: <1319394759.74.0.692830705102.issue13249@psf.upfronthosting.co.za>
Message-ID: <1321105054.77.0.689204900535.issue13249@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Thanks, I?ve made some comments on Rietveld.

> Added a recommendation to only use keywords, which seems sane given
> the number of arguments.
I looked for that but couldn?t find it.

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13249>
_______________________________________

From report at bugs.python.org  Sat Nov 12 14:41:00 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 12 Nov 2011 13:41:00 +0000
Subject: [issue13387] add exact_type argument to assertIsInstance
In-Reply-To: <1321101802.89.0.94542095022.issue13387@psf.upfronthosting.co.za>
Message-ID: <1321105260.23.0.178816731991.issue13387@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

I'm not sure this is common enough to justify a new arg.  The status quo has the advantage that is quite close with what we would use in an 'if' statement (i.e. either "if isinstance(obj, some_class):" or "if type(obj) is some_class:").

----------
nosy: +ezio.melotti, rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13387>
_______________________________________

From report at bugs.python.org  Sat Nov 12 14:45:07 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 12 Nov 2011 13:45:07 +0000
Subject: [issue12103] Document how to use open with os.O_CLOEXEC
In-Reply-To: <1305716485.42.0.643130250278.issue12103@psf.upfronthosting.co.za>
Message-ID: <1321105507.74.0.0284067789286.issue12103@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
keywords: +easy
nosy: +eric.araujo
title: Documentation of open() does not claim 'e' support in mode string -> Document how to use open with os.O_CLOEXEC
versions: +Python 3.3 -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12103>
_______________________________________

From report at bugs.python.org  Sat Nov 12 14:47:26 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 12 Nov 2011 13:47:26 +0000
Subject: [issue13264] Monkeypatching using metaclass
In-Reply-To: <1319546705.67.0.958518065524.issue13264@psf.upfronthosting.co.za>
Message-ID: <1321105646.49.0.177467260015.issue13264@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

It seems to me this is not a bug.  Closing?

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13264>
_______________________________________

From report at bugs.python.org  Sat Nov 12 14:48:19 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 12 Nov 2011 13:48:19 +0000
Subject: [issue13286] PEP 3151 breaks backward compatibility: it should be
	documented
In-Reply-To: <1319811530.69.0.689775391155.issue13286@psf.upfronthosting.co.za>
Message-ID: <1321105699.57.0.526979704686.issue13286@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/issue13286>
_______________________________________

From report at bugs.python.org  Sat Nov 12 14:49:21 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 12 Nov 2011 13:49:21 +0000
Subject: [issue13386] Document documentation conventions for optional args
In-Reply-To: <1321078121.18.0.541430257552.issue13386@psf.upfronthosting.co.za>
Message-ID: <1321105761.57.0.964875859354.issue13386@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

The problem is when the default placeholder is some unique object() or some _internal value (we had something similar with a socket timeout once).
Also for something like str.strip(), would you document chars=None or chars=" \n\r\t\v\f"?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13386>
_______________________________________

From report at bugs.python.org  Sat Nov 12 15:03:11 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Sat, 12 Nov 2011 14:03:11 +0000
Subject: [issue13193] test_packaging and test_distutils failures
In-Reply-To: <1318800293.23.0.0737706148876.issue13193@psf.upfronthosting.co.za>
Message-ID: <1321106591.13.0.898904626081.issue13193@psf.upfronthosting.co.za>


Nadeem Vawda <nadeem.vawda at gmail.com> added the comment:

I'm no longer getting the failures on either Ubuntu or Windows (and the
Windows buildbots are now green), so tentatively marking this as fixed.
Feel free to reopen if something is still broken.

----------
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13193>
_______________________________________

From report at bugs.python.org  Sat Nov 12 15:11:34 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 12 Nov 2011 14:11:34 +0000
Subject: [issue12344] Add **kwargs to reinitialize_command
In-Reply-To: <1308190105.67.0.431736719114.issue12344@psf.upfronthosting.co.za>
Message-ID: <1321107094.51.0.197622550379.issue12344@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I?ve spent some time on this.

First, I decided that the former name (reinitialize_command) of the method was better.  The get_* name could create the impression that the returned object was independent from the internal caches (command_obj, have_run), but it was not.  I changed the name back (not pushed yet; I can?t push today).

Second, I wrote tests before adding **kwargs.  It turns out I ended up removing two buggy lines in dist.py!  Thomas, if you could review that patch to tell me 1) if you can understand what it?s doing 2) if removing the two lines was right (they?ve been here since the first commit; on one hand there were no tests, but on the other there were commands depending on that code that did work well), that would be a great help.  You?ve dug into that code, so if you can?t follow my patch it?d be a sign that it needs more comments.

Finally, adding **kwargs was a two-line change in dist.py, a cleanup in some commands to use it, and two more tests.

BTW, some things I said were stupid:
>> In Distributions.get_reinitialized_command should the
>> reinitialization of the subcommands also get passed the kwargs?
> Yes, the kwargs need to be passed all the way.
That made no sense.  Subcommands don?t have the same options as their parent.  The kwargs are only for the command given as argument; to edit the options of a subcommand, reinitialize_command needs to be called for that subcommand too.

>> Unfortunately my understanding of the (sub)command flow is not rock solid.
My reply to that was off-mark.  Documenting how subcommands work is on my todo list, and I?ll be glad to have your feedback on that if you have time.

----------
stage:  -> patch review
title: Add **kwargs to get_reinitialized_command -> Add **kwargs to reinitialize_command
versions: +3rd party

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12344>
_______________________________________

From report at bugs.python.org  Sat Nov 12 15:11:46 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 12 Nov 2011 14:11:46 +0000
Subject: [issue12344] Add **kwargs to reinitialize_command
In-Reply-To: <1308190105.67.0.431736719114.issue12344@psf.upfronthosting.co.za>
Message-ID: <1321107106.44.0.314307360512.issue12344@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


Added file: http://bugs.python.org/file23659/fix-reinitialize-command.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12344>
_______________________________________

From report at bugs.python.org  Sat Nov 12 15:14:34 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 12 Nov 2011 14:14:34 +0000
Subject: [issue12344] Add **kwargs to reinitialize_command
In-Reply-To: <1308190105.67.0.431736719114.issue12344@psf.upfronthosting.co.za>
Message-ID: <1321107274.69.0.872084676715.issue12344@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

BTW, here?s the changeset to rename get_reinit_etc.

----------
Added file: http://bugs.python.org/file23660/rename-grc.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12344>
_______________________________________

From report at bugs.python.org  Sat Nov 12 15:28:49 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 12 Nov 2011 14:28:49 +0000
Subject: [issue12119] distutils and python -B
In-Reply-To: <1305822053.61.0.184404379566.issue12119@psf.upfronthosting.co.za>
Message-ID: <1321108129.16.0.926093798868.issue12119@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

A 1999 comment in build_py from Greg Ward agrees with me:

    # XXX hey! we can't control whether we optimize or not; that's up
    # to the invocation of the current Python interpreter (at least
    # according to the py_compile docs).  That sucks.

If Tarek doesn?t object, I will make the change I proposed in my earlier message in distutils.

----------
title: test_distutils failure -> distutils and python -B

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12119>
_______________________________________

From report at bugs.python.org  Sat Nov 12 15:35:07 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 12 Nov 2011 14:35:07 +0000
Subject: [issue13193] test_packaging and test_distutils failures
In-Reply-To: <1318800293.23.0.0737706148876.issue13193@psf.upfronthosting.co.za>
Message-ID: <1321108507.89.0.308466488672.issue13193@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> This problem was not trivial to find, because it appears that test execution order may not be
> entirely deterministic: I couldn't see any other reason why the flag would have different values
> on different machines.
On my machine, it looks like unittest runs them in the order they?re found.  I have only one core, but maybe tests are run in parallel on your machine, so with the missing call to enable_cache, that would explain the test failures.

Antoine, I appreciate that you took time to fix this bug while I was without Internet and without Windows, but unfortunately I will have to backout your commit.  Postel?s Law doesn?t win here: It is documented that the MANIFEST template only accepts /-delimited paths, so I have to find a fix for the tests without changing the code to avoid breaking the feature freeze.  I?ll get a Windows VM before I do that, to avoid making the bots red again.

In the future, please feel free to add unittest.expectedFailure decorators to problematic tests when I?m too long to come up with a fix, so that other people can see when their commits add problems.

----------
resolution: fixed -> 
stage: committed/rejected -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13193>
_______________________________________

From report at bugs.python.org  Sat Nov 12 15:38:30 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 12 Nov 2011 14:38:30 +0000
Subject: [issue13204] sys.flags.__new__ crashes
In-Reply-To: <1318889665.83.0.350090316357.issue13204@psf.upfronthosting.co.za>
Message-ID: <1321108710.54.0.290006909663.issue13204@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

You are right.  Even if it?s an undocumented internal type, there is no reason not to fix it.  There are plenty of similar crash fixes committed in the repo.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13204>
_______________________________________

From report at bugs.python.org  Sat Nov 12 15:42:47 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 12 Nov 2011 14:42:47 +0000
Subject: [issue13193] test_packaging and test_distutils failures
In-Reply-To: <1321108507.89.0.308466488672.issue13193@psf.upfronthosting.co.za>
Message-ID: <1321108682.8829.4.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Antoine, I appreciate that you took time to fix this bug while I was
> without Internet and without Windows, but unfortunately I will have to
> backout your commit.  Postel?s Law doesn?t win here: It is documented
> that the MANIFEST template only accepts /-delimited paths,

?Just like in the setup script, file and directory names in the manifest
template should always be slash-separated?

That's "should", not "must".
Also, I thought people did undocumented things with distutils, and we
had to support these undocumented uses?

> In the future, please feel free to add unittest.expectedFailure
> decorators to problematic tests when I?m too long to come up with a
> fix, so that other people can see when their commits add problems.

I don't see how adding "expected failures" solves anything. It's not
clear why this failure should have been expected, rather than a bug.
A "commit adding problem" should be fixed or reverted; marking some
failures expected is just dodging the issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13193>
_______________________________________

From report at bugs.python.org  Sat Nov 12 15:50:03 2011
From: report at bugs.python.org (Florent Xicluna)
Date: Sat, 12 Nov 2011 14:50:03 +0000
Subject: [issue13387] add exact_type argument to assertIsInstance
In-Reply-To: <1321101802.89.0.94542095022.issue13387@psf.upfronthosting.co.za>
Message-ID: <1321109403.28.0.155188700459.issue13387@psf.upfronthosting.co.za>


Changes by Florent Xicluna <florent.xicluna at gmail.com>:


Added file: http://bugs.python.org/file23661/grep_test_is_instance.log

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13387>
_______________________________________

From report at bugs.python.org  Sat Nov 12 15:50:18 2011
From: report at bugs.python.org (Florent Xicluna)
Date: Sat, 12 Nov 2011 14:50:18 +0000
Subject: [issue13387] add exact_type argument to assertIsInstance
In-Reply-To: <1321101802.89.0.94542095022.issue13387@psf.upfronthosting.co.za>
Message-ID: <1321109418.96.0.253992686306.issue13387@psf.upfronthosting.co.za>


Changes by Florent Xicluna <florent.xicluna at gmail.com>:


Added file: http://bugs.python.org/file23662/grep_test_exact_type.log

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13387>
_______________________________________

From report at bugs.python.org  Sat Nov 12 15:50:48 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 12 Nov 2011 14:50:48 +0000
Subject: [issue13180] pysetup silently ignores invalid entries in setup.cfg
In-Reply-To: <1318614439.75.0.304667021355.issue13180@psf.upfronthosting.co.za>
Message-ID: <1321109448.75.0.710423514039.issue13180@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I want to explore ideas about a schema/type system, so I?m removing the easy keyword.

----------
keywords:  -easy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13180>
_______________________________________

From report at bugs.python.org  Sat Nov 12 15:52:03 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 12 Nov 2011 14:52:03 +0000
Subject: [issue13294] http.server: HEAD request should not return a body
In-Reply-To: <1319985642.06.0.787750282348.issue13294@psf.upfronthosting.co.za>
Message-ID: <1321109523.04.0.759813302823.issue13294@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> Right now the HEAD returns something :)
Ah, so this is a bug.

> I still need to propose a patch.
A patch to add a test (for 2.7 or 3.2, see devguide) would be a great first step.

----------
title: http.server - HEAD request when no resource is defined. -> http.server: HEAD request should not return a body
type: feature request -> behavior
versions: +Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13294>
_______________________________________

From report at bugs.python.org  Sat Nov 12 15:52:19 2011
From: report at bugs.python.org (Florent Xicluna)
Date: Sat, 12 Nov 2011 14:52:19 +0000
Subject: [issue13387] add exact_type argument to assertIsInstance
In-Reply-To: <1321101802.89.0.94542095022.issue13387@psf.upfronthosting.co.za>
Message-ID: <1321109539.53.0.831806439115.issue13387@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

At least in the standard library test suite, it should be useful.
When the test is stricter, it catches errors earlier.

I remember when assertIsInstance was made available (issue #7031), we started to rewrite some expressions
  self.assertEqual(type(result), str)
with
  self.assertIsInstance(result, str)

Actually, it means we relaxed the test.
Today, I don't want to use assertIsInstance anymore because I want to check the exact type() of the result.

The attached files list the usage of both in Lib/test/*py:
 - 325 assertIsInstance
 - 234 assert. . .type(. . .)

IMHO, some assertIsInstance can be stricter.
Most of the other type() tests can be replaced with this method.

----------
keywords: +patch
Added file: http://bugs.python.org/file23663/issue13387_exact_type.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13387>
_______________________________________

From report at bugs.python.org  Sat Nov 12 15:55:25 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 12 Nov 2011 14:55:25 +0000
Subject: [issue13387] add exact_type argument to assertIsInstance
In-Reply-To: <1321101802.89.0.94542095022.issue13387@psf.upfronthosting.co.za>
Message-ID: <1321109725.4.0.38518808855.issue13387@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I find that assertIs(type(x), someclass) is very clear, whereas an assertIsInstance that would not behave like isinstance depending on one argument would be non-obvious to me.

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13387>
_______________________________________

From report at bugs.python.org  Sat Nov 12 16:05:59 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 12 Nov 2011 15:05:59 +0000
Subject: =?utf-8?q?=5Bissue1011113=5D_Make_=E2=80=9Cinstall=E2=80=9D_find_the_buil?=
	=?utf-8?q?d=5Fbase_directory?=
Message-ID: <1321110359.98.0.819051824684.issue1011113@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I?ve found a distutils commit that shows that this option was removed on purpose, because people might except that using ?install -b foo? would affect the build command, but it does not.  I don?t think it?s a problem.  For people who run build and install in separate steps, it should be possible to say ?build -b spam? and then ?install -b spam?.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1011113>
_______________________________________

From report at bugs.python.org  Sat Nov 12 16:11:20 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 12 Nov 2011 15:11:20 +0000
Subject: [issue13193] test_packaging and test_distutils failures
In-Reply-To: <1318800293.23.0.0737706148876.issue13193@psf.upfronthosting.co.za>
Message-ID: <1321110680.4.0.982879003872.issue13193@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> That's "should", not "must".
I read that ?should? as a polite ?must?.

> Also, I thought people did undocumented things with distutils, and we
> had to support these undocumented uses?
People rely on undocumented features and sometimes on bugs.  Thus, we cannot refactor or otherwise clean up internals.  Here, you did change internals.

> I don't see how adding "expected failures" solves anything. [...].
If a buildbot is red for a week because of me and another developer commits something that creates another test failure, they won?t see that a buildbot has turned red because it already was.  It?s just a temporary edition to avoid polluting the buildbots output.

> A "commit adding problem" should be fixed or reverted
The point is that fixing it may take tome.  Reverting is fine by me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13193>
_______________________________________

From report at bugs.python.org  Sat Nov 12 16:14:49 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 12 Nov 2011 15:14:49 +0000
Subject: [issue9831] test_distutils should honor PYTHONDONTWRITEBYTECODE
In-Reply-To: <1284198380.71.0.192975016699.issue9831@psf.upfronthosting.co.za>
Message-ID: <1321110889.42.0.398846224973.issue9831@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I now think the change I did was wrong.  See #12119.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9831>
_______________________________________

From report at bugs.python.org  Sat Nov 12 16:21:29 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 12 Nov 2011 15:21:29 +0000
Subject: [issue13193] test_packaging and test_distutils failures
In-Reply-To: <1321110680.4.0.982879003872.issue13193@psf.upfronthosting.co.za>
Message-ID: <1321111005.8829.6.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> > A "commit adding problem" should be fixed or reverted
> The point is that fixing it may take tome.  Reverting is fine by me.

But we have no way of knowing you will be taking tome to do it.
Ideally, you should have reverted it yourself (or applied whatever
test-skipping solution you see fit).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13193>
_______________________________________

From report at bugs.python.org  Sat Nov 12 16:25:03 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 12 Nov 2011 15:25:03 +0000
Subject: [issue12246] Support installation when running from an uninstalled
	Python
In-Reply-To: <1307045342.56.0.466799281748.issue12246@psf.upfronthosting.co.za>
Message-ID: <1321111503.01.0.0448468425506.issue12246@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Paul Moore reported that a Python built in its checkout on Windows has no problem installing, so I?d like to revisit this.  The patch was also incomplete: The install module was changed, but people could still call ?pysetup run install_dist?, and that command was not touched.

To support this on Unix too, we have to either fix sysconfig (#6087) or override some sysconfig paths in packaging.

I will shoot an email at python-dev.  There is no pattern for Lib/site-packages in .hgignore, which makes me think that this issue just never showed up before; I think I need approval before I go ahead.

----------
nosy: +pmoore
resolution: fixed -> 
stage: committed/rejected -> needs patch
status: closed -> open
title: Warn when trying to install third-party module from an uninstalled checkout -> Support installation when running from an uninstalled Python

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12246>
_______________________________________

From report at bugs.python.org  Sat Nov 12 16:25:41 2011
From: report at bugs.python.org (Florent Xicluna)
Date: Sat, 12 Nov 2011 15:25:41 +0000
Subject: [issue13387] add exact_type argument to assertIsInstance
In-Reply-To: <1321101802.89.0.94542095022.issue13387@psf.upfronthosting.co.za>
Message-ID: <1321111541.17.0.897829516535.issue13387@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

I would say that this one is clear too:
  aelf.assertTrue(isinstance(obj, cls))

except that the failure message is not very friendly:
  AssertionError: False is not true


If we keep assertIsInstance, more people will continue to misuse it just because the method exist, when they really want to check (type(obj) is cls).

An option could be to add a snippet to the documentation of `assertIsInstance` stating that the right way to check exact type is `assertIs(type(obj), cls)`.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13387>
_______________________________________

From report at bugs.python.org  Sat Nov 12 16:27:20 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 12 Nov 2011 15:27:20 +0000
Subject: [issue13170] distutils2 test failures
In-Reply-To: <1318523837.27.0.295397321545.issue13170@psf.upfronthosting.co.za>
Message-ID: <1321111640.33.0.603906212637.issue13170@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

All three issues fixed, thanks!  I can?t push today but I will as soon as possible, probably Monday.

I will open another report for the change I reverted in config; it was done on purpose by another developer to fix a bug with distutils2?s own setup script, so there is a real bug to fix here.

----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13170>
_______________________________________

From report at bugs.python.org  Sat Nov 12 16:29:25 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 12 Nov 2011 15:29:25 +0000
Subject: [issue12659] Add tests for packaging.tests.support
In-Reply-To: <1312033884.07.0.964621452644.issue12659@psf.upfronthosting.co.za>
Message-ID: <1321111765.29.0.0174707585338.issue12659@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I ported the patch to distutils2, but it fails because of some unittest internal problem.  Help welcome.

----------
Added file: http://bugs.python.org/file23664/test_support.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12659>
_______________________________________

From report at bugs.python.org  Sat Nov 12 16:32:21 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 12 Nov 2011 15:32:21 +0000
Subject: [issue13387] add exact_type argument to assertIsInstance
In-Reply-To: <1321101802.89.0.94542095022.issue13387@psf.upfronthosting.co.za>
Message-ID: <1321111941.5.0.993176570822.issue13387@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

>I would say that this one is clear too:
>  aelf.assertTrue(isinstance(obj, cls))
> except that the failure message is not very friendly:
>  AssertionError: False is not true
Yeah, you have to give something as third argument to ease debugging.

> If we keep assertIsInstance, more people will continue to misuse it just because the
> method exist, when they really want to check (type(obj) is cls).
If they make that mistake, it is because they don?t understand what isinstance does.

> An option could be to add a snippet to the documentation of `assertIsInstance` stating
> that the right way to check exact type is `assertIs(type(obj), cls)`.
My point was that maybe they think they really want to check the type, but with Python you don?t have to care that much most of the time.

+1 on a doc addition (I can even volunteer a patch)
-0.5 on the proposed new argument

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13387>
_______________________________________

From report at bugs.python.org  Sat Nov 12 16:34:19 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 12 Nov 2011 15:34:19 +0000
Subject: [issue1677872] Efficient reverse line iterator
Message-ID: <1321112059.6.0.0808369427311.issue1677872@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/issue1677872>
_______________________________________

From report at bugs.python.org  Sat Nov 12 16:41:01 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 12 Nov 2011 15:41:01 +0000
Subject: [issue13385] Add an explicit re.NOFLAGS flag value to the re module
In-Reply-To: <1321040356.1.0.483749785774.issue13385@psf.upfronthosting.co.za>
Message-ID: <1321112461.72.0.0056348209031.issue13385@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I had too the need to find out the value to pass when there are no flags, so a mention of 0 in the doc would have been enough for me.  -0 on a new constant.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13385>
_______________________________________

From report at bugs.python.org  Sat Nov 12 16:48:57 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Sat, 12 Nov 2011 15:48:57 +0000
Subject: [issue13336] packaging.command.Command.copy_file doesn't implement
	preserve_mode and preserve_times
In-Reply-To: <1321097958.03.0.798064907436.issue13336@psf.upfronthosting.co.za>
Message-ID: <1321112925.57641.YahooMailNeo@web25805.mail.ukl.yahoo.com>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

> 

> 
> ?ric Araujo <merwok at netwok.org> added the comment:
> 
> Thanks for the report.? Have you found the bug with a real setup.cfg or hook, or 
> were you just reading the code?
> 

I found the bug with a real setup.cfg (executable permission not set IIRC) and tracked it to copy_file. The copy_tree function wasn't used, I was just making an observation from scanning the code.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13336>
_______________________________________

From report at bugs.python.org  Sat Nov 12 16:59:51 2011
From: report at bugs.python.org (Florent Xicluna)
Date: Sat, 12 Nov 2011 15:59:51 +0000
Subject: [issue13297] xmlrpc.client could accept bytes for input and output
In-Reply-To: <1320018100.14.0.184941596185.issue13297@psf.upfronthosting.co.za>
Message-ID: <1321113591.08.0.0755954194773.issue13297@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

Thank you for your comments.
Uploaded a new version.

----------
Added file: http://bugs.python.org/file23665/issue13297_xmlrpc_bytes_v4.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13297>
_______________________________________

From report at bugs.python.org  Sat Nov 12 17:29:28 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 12 Nov 2011 16:29:28 +0000
Subject: [issue13198] Remove duplicate definition of write_record_file
In-Reply-To: <1318857154.54.0.641953188635.issue13198@psf.upfronthosting.co.za>
Message-ID: <1321115368.45.0.0249807061976.issue13198@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Here?s the patch produced by Mike and I so far.

----------
keywords: +patch
Added file: http://bugs.python.org/file23666/remove-duplicate-write_record_file.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13198>
_______________________________________

From report at bugs.python.org  Sat Nov 12 17:32:52 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 12 Nov 2011 16:32:52 +0000
Subject: [issue13239] Remove <> operator from Grammar/Grammar
In-Reply-To: <1319188291.02.0.897231487042.issue13239@psf.upfronthosting.co.za>
Message-ID: <1321115572.85.0.0460184533893.issue13239@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

+1 for a comment too.  I?d even make it shorter:

# don't look at <>, it's not a real operator (see PEP 401)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13239>
_______________________________________

From report at bugs.python.org  Sat Nov 12 17:34:49 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 12 Nov 2011 16:34:49 +0000
Subject: [issue11638] python setup.py sdist --formats tar* crashes if version
	is unicode
In-Reply-To: <1300828733.05.0.475519990909.issue11638@psf.upfronthosting.co.za>
Message-ID: <1321115689.47.0.501065591889.issue11638@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> since the issue only applies when sdist --format gztar, I mention that here.
bztar will probably have the same issue.

> Also, issue8396 suggests encoding using sys.getfilesystemencoding().
Good one!

----------
title: python setup.py sdist crashes if version is unicode -> python setup.py sdist --formats tar* crashes if version is unicode

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11638>
_______________________________________

From report at bugs.python.org  Sat Nov 12 17:44:49 2011
From: report at bugs.python.org (Roy Smith)
Date: Sat, 12 Nov 2011 16:44:49 +0000
Subject: [issue13249] argparse.ArgumentParser() lists arguments in the wrong
	order
In-Reply-To: <1319394759.74.0.692830705102.issue13249@psf.upfronthosting.co.za>
Message-ID: <1321116289.5.0.6009963564.issue13249@psf.upfronthosting.co.za>


Roy Smith <roy at panix.com> added the comment:

New patch uploaded.

The added recommendation is around line 161 (look for 'Recommended usage is to only use keyword arguments')

----------
Added file: http://bugs.python.org/file23667/Issue13249-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13249>
_______________________________________

From report at bugs.python.org  Sat Nov 12 18:49:15 2011
From: report at bugs.python.org (Michael Foord)
Date: Sat, 12 Nov 2011 17:49:15 +0000
Subject: [issue13387] add exact_type argument to assertIsInstance
In-Reply-To: <1321101802.89.0.94542095022.issue13387@psf.upfronthosting.co.za>
Message-ID: <1321120155.74.0.924742740232.issue13387@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

I think your proposed workaround is good enough and no extra effort to type than the suggested change to assertIsInstance.

-1 on a new method

I think the behaviour of isinstance is clear enough that people who misunderstand what assertIsInstance is doing have a problem with basic Python - and will continue to make the mistake whatever we do to assertIsInstance.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13387>
_______________________________________

From report at bugs.python.org  Sat Nov 12 18:53:54 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 12 Nov 2011 17:53:54 +0000
Subject: [issue13387] add exact_type argument to assertIsInstance
In-Reply-To: <1321101802.89.0.94542095022.issue13387@psf.upfronthosting.co.za>
Message-ID: <1321120434.69.0.398772879947.issue13387@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I don't think there's a point in adding such an extra argument.
Why don't you just write
    self.assertIs(type(myobj), sometype)

? How is the error message not good enough?

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13387>
_______________________________________

From report at bugs.python.org  Sat Nov 12 19:05:47 2011
From: report at bugs.python.org (Eric Snow)
Date: Sat, 12 Nov 2011 18:05:47 +0000
Subject: [issue13387] add exact_type argument to assertIsInstance
In-Reply-To: <1321101802.89.0.94542095022.issue13387@psf.upfronthosting.co.za>
Message-ID: <1321121147.91.0.255945352561.issue13387@psf.upfronthosting.co.za>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

@msg147513
> Why don't you just write
>     self.assertIs(type(myobj), sometype)

+1

----------
nosy: +eric.snow

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13387>
_______________________________________

From report at bugs.python.org  Sat Nov 12 19:14:06 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Sat, 12 Nov 2011 18:14:06 +0000
Subject: [issue13385] Add an explicit re.NOFLAGS flag value to the re module
In-Reply-To: <1321040356.1.0.483749785774.issue13385@psf.upfronthosting.co.za>
Message-ID: <1321121646.61.0.204138011725.issue13385@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

I think we have enough < 0 to reject the issue. Closing.

----------
resolution:  -> rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13385>
_______________________________________

From report at bugs.python.org  Sat Nov 12 19:23:36 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Sat, 12 Nov 2011 18:23:36 +0000
Subject: [issue13329] Runs normal as console script but falls as CGI
In-Reply-To: <1320290534.75.0.190110850785.issue13329@psf.upfronthosting.co.za>
Message-ID: <1321122216.71.0.694438192001.issue13329@psf.upfronthosting.co.za>


Changes by Petri Lehtinen <petri at digip.org>:


----------
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13329>
_______________________________________

From report at bugs.python.org  Sat Nov 12 19:28:20 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Sat, 12 Nov 2011 18:28:20 +0000
Subject: [issue12875] backport re.compile flags default value documentation
In-Reply-To: <1314854228.49.0.163476055978.issue12875@psf.upfronthosting.co.za>
Message-ID: <1321122500.09.0.891552780325.issue12875@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

I have converted the Doc/library/re.rst doc of 2.7 to follow the new convention of 3.x, patch attached.

----------
keywords: +patch
Added file: http://bugs.python.org/file23668/issue12875.1.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12875>
_______________________________________

From report at bugs.python.org  Sat Nov 12 19:37:09 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 12 Nov 2011 18:37:09 +0000
Subject: [issue12767] document threading.Condition.notify
In-Reply-To: <1313548629.79.0.0632318255733.issue12767@psf.upfronthosting.co.za>
Message-ID: <E1RPIRg-0005KU-Pw@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 63a24bff6f36 by Eli Bendersky in branch '3.2':
Issue #12767: documenting threading.Condition.notify
http://hg.python.org/cpython/rev/63a24bff6f36

New changeset ac12dcea69e1 by Eli Bendersky in branch 'default':
Issue 12767: document the argument of threading.Condition.notify
http://hg.python.org/cpython/rev/ac12dcea69e1

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12767>
_______________________________________

From report at bugs.python.org  Sat Nov 12 19:42:01 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 12 Nov 2011 18:42:01 +0000
Subject: [issue12767] document threading.Condition.notify
In-Reply-To: <1313548629.79.0.0632318255733.issue12767@psf.upfronthosting.co.za>
Message-ID: <E1RPIWU-0005iO-HS@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 63a00d019bb2 by Eli Bendersky in branch '2.7':
Closes issue 12767: document the argument of threading.Condition.notify
http://hg.python.org/cpython/rev/63a00d019bb2

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12767>
_______________________________________

From report at bugs.python.org  Sat Nov 12 19:44:23 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Sat, 12 Nov 2011 18:44:23 +0000
Subject: [issue13239] Remove <> operator from Grammar/Grammar
In-Reply-To: <1319188291.02.0.897231487042.issue13239@psf.upfronthosting.co.za>
Message-ID: <1321123463.81.0.739035837531.issue13239@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

?ric, do you feel strongly about the wording, or can I just go ahead and commit my version if I like it more :) ?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13239>
_______________________________________

From report at bugs.python.org  Sat Nov 12 19:46:30 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Sat, 12 Nov 2011 18:46:30 +0000
Subject: [issue13388] document hg commit hooks in the devguide
Message-ID: <1321123590.65.0.736191202752.issue13388@psf.upfronthosting.co.za>


New submission from Eli Bendersky <eliben at gmail.com>:

----
Our Hg repo has some useful hooks on commit messages that allow to
specify which issue to notify for commits, and which issue to close.
AFAIU, it's currently documented only in the code of the hook
(http://hg.python.org/hooks/file/tip/hgroundup.py).

I think adding a short description into the devguide would be a good
idea, probably here:
http://docs.python.org/devguide/committing.html#commit-messages-and-news-entries
----

+1d by Brett and Georg on pydev. I'll prepare a patch.

----------
assignee: eli.bendersky
components: Devguide
messages: 147520
nosy: brett.cannon, eli.bendersky, ezio.melotti, georg.brandl
priority: normal
severity: normal
status: open
title: document hg commit hooks in the devguide

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13388>
_______________________________________

From report at bugs.python.org  Sat Nov 12 19:52:15 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Sat, 12 Nov 2011 18:52:15 +0000
Subject: [issue13386] Document documentation conventions for optional args
In-Reply-To: <1321078121.18.0.541430257552.issue13386@psf.upfronthosting.co.za>
Message-ID: <1321123935.4.0.082871273641.issue13386@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

You should also explicitly specify what happens in several optional but not keyword args are needed. AFAIU the convention is:

   func(arg1, arg2[, opt1, opt2])

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13386>
_______________________________________

From report at bugs.python.org  Sat Nov 12 20:10:27 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Sat, 12 Nov 2011 19:10:27 +0000
Subject: [issue13388] document hg commit hooks in the devguide
In-Reply-To: <1321123590.65.0.736191202752.issue13388@psf.upfronthosting.co.za>
Message-ID: <1321125027.68.0.0178445632996.issue13388@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

Attaching a patch with the suggested change. Based on the doc-string in the implementation of the hook.

----------
keywords: +patch
Added file: http://bugs.python.org/file23669/issue13388.1.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13388>
_______________________________________

From report at bugs.python.org  Sat Nov 12 20:12:25 2011
From: report at bugs.python.org (Florent Xicluna)
Date: Sat, 12 Nov 2011 19:12:25 +0000
Subject: [issue13387] suggest assertIs(type(obj), cls) for exact type checking
In-Reply-To: <1321101802.89.0.94542095022.issue13387@psf.upfronthosting.co.za>
Message-ID: <1321125145.44.0.402320123302.issue13387@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

> +1 on a doc addition (I can even volunteer a patch)

I agree we can highlight the difference between assertIs(type(obj), cls) and assertIsInstance(obj, cls) in the documentation.

Let's forget this patch and keep it simple.

----------
assignee:  -> docs at python
components: +Documentation
nosy: +docs at python
stage:  -> needs patch
title: add exact_type argument to assertIsInstance -> suggest assertIs(type(obj), cls) for exact type checking
type: feature request -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13387>
_______________________________________

From report at bugs.python.org  Sat Nov 12 20:14:39 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Sat, 12 Nov 2011 19:14:39 +0000
Subject: [issue13388] document hg commit hooks in the devguide
In-Reply-To: <1321123590.65.0.736191202752.issue13388@psf.upfronthosting.co.za>
Message-ID: <1321125279.79.0.590589897443.issue13388@psf.upfronthosting.co.za>


Petri Lehtinen <petri at digip.org> added the comment:

I'm not sure if it matters, but Sphinx documentation suggests using ^ as the underlining character for subsubsections.

Otherwise, looks good.

----------
nosy: +petri.lehtinen

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13388>
_______________________________________

From report at bugs.python.org  Sat Nov 12 20:19:07 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Sat, 12 Nov 2011 19:19:07 +0000
Subject: [issue13388] document hg commit hooks in the devguide
In-Reply-To: <1321123590.65.0.736191202752.issue13388@psf.upfronthosting.co.za>
Message-ID: <1321125547.33.0.590866266169.issue13388@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

Petri, I have actually tried to stay consistent within the same document, and it uses ' for this level of heading. Perhaps it's just not following the Sphinx guide?

IIRC the restructured text parser will also shout at you if these are inconsistent.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13388>
_______________________________________

From report at bugs.python.org  Sat Nov 12 20:20:24 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Sat, 12 Nov 2011 19:20:24 +0000
Subject: [issue13388] document hg commit hooks in the devguide
In-Reply-To: <1321123590.65.0.736191202752.issue13388@psf.upfronthosting.co.za>
Message-ID: <1321125624.67.0.28477295791.issue13388@psf.upfronthosting.co.za>


Petri Lehtinen <petri at digip.org> added the comment:

Ah, sorry. I didn't check other files in the devguide. The ReST parser is OK with any underline character, as long as it's consistent within a single file.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13388>
_______________________________________

From report at bugs.python.org  Sat Nov 12 20:28:43 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 12 Nov 2011 19:28:43 +0000
Subject: [issue11999] sporadic failure in test_mailbox
In-Reply-To: <1304507847.24.0.74411710498.issue11999@psf.upfronthosting.co.za>
Message-ID: <E1RPJFg-0000Yw-Bf@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset d2b0751174f6 by Petri Lehtinen in branch '2.7':
Update mailbox.Maildir tests
http://hg.python.org/cpython/rev/d2b0751174f6

New changeset b3c5e1c62839 by Petri Lehtinen in branch '3.2':
Update mailbox.Maildir tests
http://hg.python.org/cpython/rev/b3c5e1c62839

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11999>
_______________________________________

From report at bugs.python.org  Sat Nov 12 20:40:20 2011
From: report at bugs.python.org (Daniel Urban)
Date: Sat, 12 Nov 2011 19:40:20 +0000
Subject: [issue13264] Monkeypatching using metaclass
In-Reply-To: <1319546705.67.0.958518065524.issue13264@psf.upfronthosting.co.za>
Message-ID: <1321126820.45.0.691459690394.issue13264@psf.upfronthosting.co.za>


Daniel Urban <urban.dani+py at gmail.com> added the comment:

> It seems to me this is not a bug.

+1

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13264>
_______________________________________

From report at bugs.python.org  Sat Nov 12 22:36:12 2011
From: report at bugs.python.org (sbt)
Date: Sat, 12 Nov 2011 21:36:12 +0000
Subject: [issue13374] Deprecate usage of the Windows ANSI API in the nt module
In-Reply-To: <1320797406.95.0.49629588961.issue13374@psf.upfronthosting.co.za>
Message-ID: <1321133772.03.0.698103185151.issue13374@psf.upfronthosting.co.za>


sbt <shibturn at gmail.com> added the comment:

I notice that the patch changes rename() and link() to use
win32_decode_filename() to coerce the filename to unicode before using
the "wide" win32 api.  (Previously, rename() first tried the wide api,
falling back to narrow if that failed; link() used wide if the args were
both unicode, narrow otherwise.  Some other functions like symlink()
already only use the wide api.)

Is this approach of coercing to unicode and only using the wide api
"blessed"?  I certainly think it should be.  If so then one can get
rid lots windows specific code.

And are we able to assume that on Windows we have access to wide libc
functions?  _wcsicmp(), _snwprintf(), _wputenv() are all used already,
so I guess we already make that assumption.  It looks like a lot of the
windows specific code attempts to reimplement basic libc functions using
the win32 api just to support unicode - presumably there was a time when
we could not assume that wide libc functions would be available.  Other functions like execv() and spawnv() were never given unicode support.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13374>
_______________________________________

From report at bugs.python.org  Sun Nov 13 00:17:14 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 12 Nov 2011 23:17:14 +0000
Subject: [issue13389] Clear lists freelist in gc.collect()
Message-ID: <1321139834.96.0.0231630453756.issue13389@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

Complete gc collections currently clear all freelists, except for the freelist of list objects. Attached patch fixes the omission.

----------
components: Interpreter Core
files: listfreelist.patch
keywords: patch
messages: 147530
nosy: pitrou
priority: normal
severity: normal
stage: patch review
status: open
title: Clear lists freelist in gc.collect()
type: resource usage
versions: Python 3.3
Added file: http://bugs.python.org/file23670/listfreelist.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13389>
_______________________________________

From report at bugs.python.org  Sun Nov 13 00:24:29 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 12 Nov 2011 23:24:29 +0000
Subject: [issue13390] Hunt memory allocations in addition to reference leaks
Message-ID: <1321140269.61.0.335726830367.issue13390@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

This patch adds a counting of the number of allocated memory blocks (through the PyObject_Malloc API). Together with -R, it can help chase those memory leaks which aren't reference leaks (see c6dafa2e2594).

The sys.getallocedblocks() function is also available in non-debug mode. This is meant to help 3rd party extension writers, who rarely have access to debug builds.

To avoid too many false positives, issue13389 is a prerequisite (at least for the "test -R" part of the patch). Even after it, there are still a couple "test -R" failures; we'd have to investigate them.

----------
components: Interpreter Core, Tests
files: debugblocks.patch
keywords: patch
messages: 147531
nosy: ncoghlan, pitrou, tim_one
priority: normal
severity: normal
stage: patch review
status: open
title: Hunt memory allocations in addition to reference leaks
type: resource usage
versions: Python 3.3
Added file: http://bugs.python.org/file23671/debugblocks.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13390>
_______________________________________

From report at bugs.python.org  Sun Nov 13 00:31:52 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 12 Nov 2011 23:31:52 +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: <1321140712.68.0.956561048104.issue7732@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Victor, can you fix the test failures on Windows and 2.7?
Otherwise the commit should be reverted.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7732>
_______________________________________

From report at bugs.python.org  Sun Nov 13 00:44:44 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 12 Nov 2011 23:44:44 +0000
Subject: [issue13389] Clear lists freelist in gc.collect()
In-Reply-To: <1321139834.96.0.0231630453756.issue13389@psf.upfronthosting.co.za>
Message-ID: <1321141484.42.0.377558005765.issue13389@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Dicts also have a freelist which isn't freed either. New patch attached.

----------
Added file: http://bugs.python.org/file23672/listdictfreelist.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13389>
_______________________________________

From report at bugs.python.org  Sun Nov 13 00:47:15 2011
From: report at bugs.python.org (=?utf-8?q?Andreas_St=C3=BChrk?=)
Date: Sat, 12 Nov 2011 23:47:15 +0000
Subject: [issue13390] Hunt memory allocations in addition to reference leaks
In-Reply-To: <1321140269.61.0.335726830367.issue13390@psf.upfronthosting.co.za>
Message-ID: <1321141635.21.0.0118929175974.issue13390@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/issue13390>
_______________________________________

From report at bugs.python.org  Sun Nov 13 00:48:35 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 12 Nov 2011 23:48:35 +0000
Subject: [issue13380] ctypes: add an internal function for reseting the ctypes
	caches
In-Reply-To: <1320902561.22.0.487865927239.issue13380@psf.upfronthosting.co.za>
Message-ID: <1321141715.12.0.787943617681.issue13380@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Two things:
- you duplicated the part with "CFUNCTYPE(c_int)(lambda: None)" without removing the original chunk of code
- some platforms can't compile ctypes, you must handle that case in regrtest

Otherwise, good idea.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13380>
_______________________________________

From report at bugs.python.org  Sun Nov 13 00:53:01 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 12 Nov 2011 23:53:01 +0000
Subject: [issue13389] Clear lists freelist in gc.collect()
In-Reply-To: <1321139834.96.0.0231630453756.issue13389@psf.upfronthosting.co.za>
Message-ID: <1321141981.04.0.101285669107.issue13389@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Fix the return values and add documentation.

----------
Added file: http://bugs.python.org/file23673/listdictfreelist.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13389>
_______________________________________

From report at bugs.python.org  Sun Nov 13 00:53:06 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 12 Nov 2011 23:53:06 +0000
Subject: [issue13389] Clear lists and dicts freelist in gc.collect()
In-Reply-To: <1321139834.96.0.0231630453756.issue13389@psf.upfronthosting.co.za>
Message-ID: <1321141986.19.0.561743571178.issue13389@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
title: Clear lists freelist in gc.collect() -> Clear lists and dicts freelist in gc.collect()

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13389>
_______________________________________

From report at bugs.python.org  Sun Nov 13 00:53:23 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 12 Nov 2011 23:53:23 +0000
Subject: [issue13389] Clear lists and dicts freelist in gc.collect()
In-Reply-To: <1321139834.96.0.0231630453756.issue13389@psf.upfronthosting.co.za>
Message-ID: <1321142003.02.0.197458409534.issue13389@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


Removed file: http://bugs.python.org/file23672/listdictfreelist.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13389>
_______________________________________

From report at bugs.python.org  Sun Nov 13 01:05:13 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 13 Nov 2011 00:05:13 +0000
Subject: [issue13385] Add an explicit re.NOFLAGS flag value to the re module
In-Reply-To: <1321040356.1.0.483749785774.issue13385@psf.upfronthosting.co.za>
Message-ID: <1321142713.08.0.593112691332.issue13385@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Thank you for closing this.  I think it would only add clutter to a module that is already puts readers into information overload.

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13385>
_______________________________________

From report at bugs.python.org  Sun Nov 13 01:16:34 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 13 Nov 2011 00:16:34 +0000
Subject: [issue13374] Deprecate usage of the Windows ANSI API in the nt module
In-Reply-To: <1321133772.03.0.698103185151.issue13374@psf.upfronthosting.co.za>
Message-ID: <4EBF0C56.3040201@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> Is this approach of coercing to unicode and only using the wide api
> "blessed"?

It's not. If people use byte strings, they specifically ask for what
they get; Python shouldn't second-guess the data types.

> I certainly think it should be.  If so then one can get
> rid lots windows specific code.

How so? This entire handling of file names is windows specific;
dealing with different file name data types doesn't make it more
windows specific than it already is.

> And are we able to assume that on Windows we have access to wide libc
> functions?

Yes, but Python should avoid using them.

> _wcsicmp(), _snwprintf(), _wputenv() are all used already,
> so I guess we already make that assumption.  It looks like a lot of the
> windows specific code attempts to reimplement basic libc functions using
> the win32 api just to support unicode - presumably there was a time when
> we could not assume that wide libc functions would be available.

No:
a) we try to get rid of MS libc as much as possible. Ideally, some
   future version of Python will not rely on libc at all for Windows.
   If Microsoft had chosen to make the C library a system API, this
   we would happily use it. Alas, they chose to make it an API of their
   compiler instead, so we really shouldn't use it.
b) the wide libc functions assume a 16-bit wchar_t type. This is not a
   good match for Python's unicode data type, which readily supports
   32-bit characters.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13374>
_______________________________________

From report at bugs.python.org  Sun Nov 13 01:45:22 2011
From: report at bugs.python.org (Dave Mankoff)
Date: Sun, 13 Nov 2011 00:45:22 +0000
Subject: [issue13391] string.strip Does Not Remove Zero-Width-Space (ZWSP)
Message-ID: <1321145122.08.0.463222804165.issue13391@psf.upfronthosting.co.za>


New submission from Dave Mankoff <mankyd at gmail.com>:

Title pretty much says it all. Simple test case:

>>> len(u' \t\r\n\u200B'.strip())
1

Should be zero.

Same problem in Python3:

>>> len(' \t\r\n\u200B'.strip())
1

----------
components: Unicode
messages: 147538
nosy: ezio.melotti, mankyd
priority: normal
severity: normal
status: open
title: string.strip Does Not Remove Zero-Width-Space (ZWSP)
type: behavior
versions: Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13391>
_______________________________________

From report at bugs.python.org  Sun Nov 13 02:06:27 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 13 Nov 2011 01:06:27 +0000
Subject: [issue13390] Hunt memory allocations in addition to reference leaks
In-Reply-To: <1321140269.61.0.335726830367.issue13390@psf.upfronthosting.co.za>
Message-ID: <1321146387.5.0.535843344881.issue13390@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

I added some review comments to the patch, but I'm not sure how usable this is going to be in practice. References generally stay fairly stable while using the interactive interpreter, but the new block accounting jumps around all over the place due to the internal free lists (which *don't* count in for 'gettotalrefcounts', but *do* count in the new block accounting). The following interpreter session has both this patch and the #13389 patch applied:

>>> a = sys.getallocedblocks()
[76652 refs, 21773 blocks]
>>> a
21779
[76652 refs, 21774 blocks]
>>> x = [None]*10000
[76652 refs, 21776 blocks]
>>> del x
[66650 refs, 21775 blocks]
>>> gc.collect(); gc.collect(); gc.collect()
0
0
0
[66650 refs, 21756 blocks]
>>> b = sys.getallocedblocks()
[66652 refs, 21772 blocks]
>>> b - a
-2
[66652 refs, 21772 blocks]

So, generally +1 on the idea, but I think we should hide at least the initial implementation behind PY_REF_DEBUG until we're sure we've worked the kinks out of it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13390>
_______________________________________

From report at bugs.python.org  Sun Nov 13 02:20:53 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 13 Nov 2011 01:20:53 +0000
Subject: [issue13392] Writing a pyc file is not atomic under Windows
Message-ID: <1321147252.88.0.159545157159.issue13392@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

#13146 solved the issue of writing pyc files under POSIX. Under Windows, the problem still exists, as the following buildbot failure shows:

[317/360] test_multiprocessing
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\multiprocessing\forking.py", line 373, in main
    prepare(preparation_data)
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\multiprocessing\forking.py", line 499, in prepare
    '__parents_main__', file, path_name, etc
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\test\regrtest.py", line 175, in <module>
    import packaging.command
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\packaging\command\__init__.py", line 4, in <module>
    from packaging.util import resolve_name
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\packaging\util.py", line 5, in <module>
    import csv
EOFError: EOF read where not expected
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\multiprocessing\forking.py", line 373, in main
    prepare(preparation_data)
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\multiprocessing\forking.py", line 499, in prepare
    '__parents_main__', file, path_name, etc
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\test\regrtest.py", line 175, in <module>
    import packaging.command
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\packaging\command\__init__.py", line 4, in <module>
    from packaging.util import resolve_name
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\packaging\util.py", line 5, in <module>
    import csv
EOFError: EOF read where not expected
[etc.]

(from http://www.python.org/dev/buildbot/all/builders/x86%20XP-4%203.x/builds/5551/steps/test/logs/stdio)

Attached patch uses MoveFileEx to perform a (hopefully atomic) rename from a temporary file when creating the pyc file.
The same strategy cannot be created for importlib since MoveFileEx isn't exposed at the Python level (we could delete the tmp file if renaming fails, though; it simply means another process beat us to it, which shouldn't be a problem here).

----------
components: Interpreter Core
files: winimport.patch
keywords: patch
messages: 147540
nosy: brett.cannon, haypo, ncoghlan, neologix, pitrou, python-dev, r.david.murray
priority: normal
severity: normal
stage: patch review
status: open
title: Writing a pyc file is not atomic under Windows
versions: Python 3.3
Added file: http://bugs.python.org/file23674/winimport.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13392>
_______________________________________

From report at bugs.python.org  Sun Nov 13 02:24:32 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 13 Nov 2011 01:24:32 +0000
Subject: [issue13391] string.strip Does Not Remove Zero-Width-Space (ZWSP)
In-Reply-To: <1321145122.08.0.463222804165.issue13391@psf.upfronthosting.co.za>
Message-ID: <1321147472.51.0.561946075049.issue13391@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
versions: +Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13391>
_______________________________________

From report at bugs.python.org  Sun Nov 13 03:41:13 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 13 Nov 2011 02:41:13 +0000
Subject: [issue13281] Make robotparser.RobotFileParser ignore blank lines
In-Reply-To: <1319747444.2.0.491041533825.issue13281@psf.upfronthosting.co.za>
Message-ID: <1321152073.57.0.740311792935.issue13281@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

My suggested doc change is how to change the doc along with the patch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13281>
_______________________________________

From report at bugs.python.org  Sun Nov 13 04:04:52 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 13 Nov 2011 03:04:52 +0000
Subject: [issue13346] re.split() should behave like string.split() for
	maxsplit=0 and maxsplit=-1
In-Reply-To: <1320461196.01.0.560612390683.issue13346@psf.upfronthosting.co.za>
Message-ID: <1321153492.45.0.748616755407.issue13346@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

The two methods are defined differently, and act as defined, so this is a feature request, not a bug report.

str.split([sep[, maxsplit]]) 
... If maxsplit is given, at most maxsplit splits are done (thus, the list will have at most maxsplit+1 elements). If maxsplit is not specified, then there is no limit on the number of splits (all possible splits are made).

re.split(pattern, string, maxsplit=0, flags=0)
...If maxsplit is nonzero, at most maxsplit splits occur,

Clearly, if maxsplit for re.split is the default of 0, it must do all splits. There is a difference between being optional with no default (possible with C-coded functions) and with a default.

Logically, both should have a default of None, meaning no limit. But I agree with Ezio and do not see that happening for Python 3.

As for negative values, I would have maxsplit treated as a count and make negative values a ValueError.

----------
nosy: +terry.reedy
status: open -> closed
type: behavior -> feature request
versions:  -Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13346>
_______________________________________

From report at bugs.python.org  Sun Nov 13 04:07:05 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 13 Nov 2011 03:07:05 +0000
Subject: [issue12875] backport re.compile flags default value documentation
In-Reply-To: <1314854228.49.0.163476055978.issue12875@psf.upfronthosting.co.za>
Message-ID: <1321153625.33.0.343168291097.issue12875@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

This patch looks fine.

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12875>
_______________________________________

From report at bugs.python.org  Sun Nov 13 04:08:34 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 13 Nov 2011 03:08:34 +0000
Subject: [issue12875] backport re.compile flags default value documentation
In-Reply-To: <1314854228.49.0.163476055978.issue12875@psf.upfronthosting.co.za>
Message-ID: <1321153714.53.0.202579446188.issue12875@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

LGTM

----------
stage:  -> commit review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12875>
_______________________________________

From report at bugs.python.org  Sun Nov 13 04:08:59 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 13 Nov 2011 03:08:59 +0000
Subject: [issue13346] re.split() should behave like string.split() for
	maxsplit=0 and maxsplit=-1
In-Reply-To: <1320461196.01.0.560612390683.issue13346@psf.upfronthosting.co.za>
Message-ID: <1321153739.76.0.103683809717.issue13346@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Terry, thanks for closing this.  The API for str.split() has been set in stone for a very long time.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13346>
_______________________________________

From report at bugs.python.org  Sun Nov 13 04:11:11 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 13 Nov 2011 03:11:11 +0000
Subject: [issue13349] Uninformal error message in index() and remove()
	functions
In-Reply-To: <1320526177.89.0.678573577515.issue13349@psf.upfronthosting.co.za>
Message-ID: <1321153871.0.0.142321144878.issue13349@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Improving error messages has been a long, slow process as people are irritated enough to make a change. Please go ahead.

Guido has explicitly excluded exception detail from the language spec multiple times. Test that depend on details are broken. Doc examples are updated as such details change. (So if you do upgrade the message, change the tests and examples ;-).

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13349>
_______________________________________

From report at bugs.python.org  Sun Nov 13 04:44:46 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 13 Nov 2011 03:44:46 +0000
Subject: [issue13391] string.strip Does Not Remove Zero-Width-Space (ZWSP)
In-Reply-To: <1321145122.08.0.463222804165.issue13391@psf.upfronthosting.co.za>
Message-ID: <1321155886.61.0.331754899674.issue13391@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

str.strip uses Py_UNICODE_ISSPACE that in turn uses _PyUnicode_IsWhitespace (see Objects/unicodetype_db.h#l3347), and according to the comment there it "Returns 1 for Unicode characters having the bidirectional type 'WS', 'B' or 'S' or the category 'Zs', 0 otherwise."
The category of U+200B is 'Cf', and its bidirectional type is 'BN' so 0 is returned and the character is not stripped.

OTOH, Unicode defines the White_Space property and assigns it to 26 chars, whereas _PyUnicode_IsWhitespace includes 4 more chars (1C, 1D, 1E, 1F) that should probably be removed.

I'll close this issue because str.strip() is correct regarding U+200B.

@Martin
Do you think those 4 chars should be removed?
If so I'll open another issue.

----------
assignee:  -> ezio.melotti
nosy: +loewis
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13391>
_______________________________________

From report at bugs.python.org  Sun Nov 13 05:11:45 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 13 Nov 2011 04:11:45 +0000
Subject: [issue13355] random.triangular error when low = high=mode
In-Reply-To: <1320577016.77.0.989776485745.issue13355@psf.upfronthosting.co.za>
Message-ID: <1321157505.37.0.920741069522.issue13355@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

3.2 doc entry:

random.triangular(low, high, mode) 
Return a random floating point number N such that low <= N <= high and with the specified mode between those bounds. The low and high bounds default to zero and one. The mode argument defaults to the midpoint between the bounds, giving a symmetric distribution.

3.2 behavior:
>>> from random import triangular
>>> triangular(1,1)
1.0
>>> triangular(1,1,1)
Traceback (most recent call last):
  File "<pyshell#2>", line 1, in <module>
    triangular(1,1,1)
  File "C:\Programs\Python32\lib\random.py", line 346, in triangular
    c = 0.5 if mode is None else (mode - low) / (high - low)
ZeroDivisionError: division by zero

I regard is as a bug that explicitly giving a 'default value' causes the function to fail. 

The last sentence of the doc is a lie: the actual default for mode is None: 

>>> triangular(1,1,None)
1.0

and if it is None, it *not* calculated (low + .5(high-low)). The actual internal third parameter is the fraction of the range (high-low) that is the up slope versus the down slope of the distribution. The code calls that 'c', as calculated by the line shown in the traceback. The fix is simple: add 'or low==high' to the condition.

    c = 0.5 if (mode is None or low==high) else (mode - low) / (high - low)

Contrary to the doc ('mode between those bounds'), the definition on Wikipedia and code include the degenerate cases of mode == low or high. The code in effect treats modes outside the range as being at an endpoint.

Suggested doc revision, with defaults given in the signature as normal:

random.triangular(low=0.0, high=1.0, mode=None) 
Return a random floating point number N from a triangular distribution such that low <= N <= high with the specified mode between or at those bounds. A mode outside a bound is treated as being at the bound. The default mode argument corresponds to the midpoint between the bounds, giving a symmetric distribution.

----------
components: +Library (Lib) -Extension Modules
keywords: +patch
nosy: +terry.reedy
stage:  -> needs patch
title: random.triangular error when low = mode -> random.triangular error when low = high=mode
type:  -> behavior
versions: +Python 2.7, Python 3.2, Python 3.3 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13355>
_______________________________________

From report at bugs.python.org  Sun Nov 13 05:15:02 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 13 Nov 2011 04:15:02 +0000
Subject: [issue13393] Improve BufferedReader.read1()
Message-ID: <1321157701.74.0.443809978111.issue13393@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

The main current user of BufferedReader.read1() is TextIOWrapper. In this context, read1() is used to signal that we want to bypass binary buffering as much as possible, since TextIOWrapper does its own buffering. The current read1() implementation is therefore suboptimal: it copies data around, and limits the number of bytes that you're allowed to get in one call (even if the raw stream would satisfy more).

Attached patch improves read1() in this respect. Also, a separate modification of TextIOWrapper is needed to take advantage of it, which I will attach in another patch.

----------
components: IO, Library (Lib)
files: bufioread1.patch
keywords: patch
messages: 147549
nosy: pitrou
priority: normal
severity: normal
stage: patch review
status: open
title: Improve BufferedReader.read1()
type: performance
versions: Python 3.3
Added file: http://bugs.python.org/file23675/bufioread1.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13393>
_______________________________________

From report at bugs.python.org  Sun Nov 13 05:16:11 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 13 Nov 2011 04:16:11 +0000
Subject: [issue13393] Improve BufferedReader.read1()
In-Reply-To: <1321157701.74.0.443809978111.issue13393@psf.upfronthosting.co.za>
Message-ID: <1321157771.55.0.723141408109.issue13393@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


Added file: http://bugs.python.org/file23676/textioread.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13393>
_______________________________________

From report at bugs.python.org  Sun Nov 13 08:34:19 2011
From: report at bugs.python.org (Oleg Plakhotnyuk)
Date: Sun, 13 Nov 2011 07:34:19 +0000
Subject: [issue13394] Patch to increase aifc lib test coverage with couple of
	minor fixes
Message-ID: <1321169659.12.0.870815067565.issue13394@psf.upfronthosting.co.za>


New submission from Oleg Plakhotnyuk <olegus8 at gmail.com>:

I've increased coverage of aifc.py by test_aifc.py:

before:
[1/1] test_aifc
lines   cov%   module   (path)
  560    63%   aifc   (/Users/family/Documents/code/python/repo/Lib/aifc.py)
...

after:
[1/1] test_aifc
lines   cov%   module   (path)
  561    82%   aifc   (/Users/family/Documents/code/python/repo/Lib/aifc.py)
...

I have also encountered couple of problems in aifc.py:
1. When using setmark() with string name to write to aiff file, you get Exception TypeError: "'str' does not support the buffer interface".
2. When using close() of Aifc_write object, it attempts to close it again in __del__() which ends with ValueError: write to closed file.

I propose following solutions to above problems in patch attached:
1. Use bytes type for mark names, because entire aifc library already uses bytes anyway.
2. Make file pointer check in close() and reset it after actually closing the file.

I don't think that these fixes will cause major backward compatibility problems, because with current version of aifc there is no way to write markers at all anyway.

I plan to increase test coverage of aifc.py further in subsequent patches. Just want to make it in several small steps :-)

Please provide any feedback regarding to what should I do to make this patch committed.

Thanks!

----------
components: Library (Lib), Tests
files: test_aifc.patch
keywords: patch
messages: 147550
nosy: Oleg.Plakhotnyuk
priority: normal
severity: normal
status: open
title: Patch to increase aifc lib test coverage with couple of minor fixes
type: behavior
versions: Python 3.4
Added file: http://bugs.python.org/file23677/test_aifc.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13394>
_______________________________________

From report at bugs.python.org  Sun Nov 13 08:46:46 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 13 Nov 2011 07:46:46 +0000
Subject: [issue13394] Patch to increase aifc lib test coverage with couple of
	minor fixes
In-Reply-To: <1321169659.12.0.870815067565.issue13394@psf.upfronthosting.co.za>
Message-ID: <1321170406.74.0.555211237441.issue13394@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +r.david.murray
stage:  -> patch review
versions: +Python 3.2, Python 3.3 -Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13394>
_______________________________________

From report at bugs.python.org  Sun Nov 13 09:14:12 2011
From: report at bugs.python.org (Oleg Plakhotnyuk)
Date: Sun, 13 Nov 2011 08:14:12 +0000
Subject: [issue13394] Patch to increase aifc lib test coverage with couple of
	minor fixes
In-Reply-To: <1321169659.12.0.870815067565.issue13394@psf.upfronthosting.co.za>
Message-ID: <1321172052.79.0.924939782647.issue13394@psf.upfronthosting.co.za>


Oleg Plakhotnyuk <olegus8 at gmail.com> added the comment:

Thanks for your review, Ezio!
Here goes new patch with all issues you've mentioned been fixed.

----------
Added file: http://bugs.python.org/file23678/test_aifc2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13394>
_______________________________________

From report at bugs.python.org  Sun Nov 13 09:26:23 2011
From: report at bugs.python.org (Hugo Silva)
Date: Sun, 13 Nov 2011 08:26:23 +0000
Subject: [issue13395] Python ISO-8859-1 encoding problem
Message-ID: <1321172783.32.0.41912586077.issue13395@psf.upfronthosting.co.za>


New submission from Hugo Silva <hugoslv at gmail.com>:

Hi all,

I'm facing a huge encoding problem in Python when dealing with ISO-8859-1 / Latin-1 character set.

When using os.listdir to get the contents of a folder I'm getting the strings encoded in ISO-8859-1 (ex: ''Ol\xe1 Mundo''), however in the Python interpreter the same string is encoded to a different charset:

In : 'Ol? Mundo'.decode('latin-1')
Out: u'Ol\xa0 Mundo'

How can I force Python to decode the string to the same format. I've seen that os.listdir is returning the strings correctly encoded but the interpreter is not ('?' character corresponds to '\xe1' in ISO-8859-1, not to '\xa0'):

http://en.wikipedia.org/wiki/ISO/IEC_8859-1

This is happening 

Any thoughts on how to overcome ?

Regards,

----------
components: Unicode
messages: 147552
nosy: Hugo.Silva, ezio.melotti
priority: normal
severity: normal
status: open
title: Python ISO-8859-1 encoding problem
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13395>
_______________________________________

From report at bugs.python.org  Sun Nov 13 09:32:24 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 13 Nov 2011 08:32:24 +0000
Subject: [issue13395] Python ISO-8859-1 encoding problem
In-Reply-To: <1321172783.32.0.41912586077.issue13395@psf.upfronthosting.co.za>
Message-ID: <1321173144.14.0.112692685924.issue13395@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

This doesn't seem a bug to me, so you should ask for help somewhere else.
You can try to pass a unicode arg to listdir to get unicode back, and double check what the input actually is.

----------
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13395>
_______________________________________

From report at bugs.python.org  Sun Nov 13 10:33:29 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 13 Nov 2011 09:33:29 +0000
Subject: [issue13395] Python ISO-8859-1 encoding problem
In-Reply-To: <1321172783.32.0.41912586077.issue13395@psf.upfronthosting.co.za>
Message-ID: <1321176809.5.0.980290991333.issue13395@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Apparently, you are using the interactive shell on Microsoft Windows. This will use the "OEM code page"; which one that is depends on the exact Windows regional version you are using.

You shouldn't decode the string with 'latin-1', but with sys.stdin.encoding. Alternatively, you should use Unicode string literals in Python in the first place.

In any case, Ezio is right: this is not a help forum, but a bug tracker.

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13395>
_______________________________________

From report at bugs.python.org  Sun Nov 13 12:56:08 2011
From: report at bugs.python.org (Paul Moore)
Date: Sun, 13 Nov 2011 11:56:08 +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: <1321185368.46.0.0336729842306.issue10181@psf.upfronthosting.co.za>


Changes by Paul Moore <p.f.moore at gmail.com>:


----------
nosy: +pmoore

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10181>
_______________________________________

From report at bugs.python.org  Sun Nov 13 17:27:30 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 13 Nov 2011 16:27:30 +0000
Subject: [issue13390] Hunt memory allocations in addition to reference leaks
In-Reply-To: <1321140269.61.0.335726830367.issue13390@psf.upfronthosting.co.za>
Message-ID: <1321201650.05.0.752795585328.issue13390@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Thanks for the comments, here is a new patch addressing them.
I've kept the C API available in all builds (since it's private), but sys.getallocatedblocks() is only available in debug builds.

As for the memory leak run results, I think we may have to devise a heuristic where results like [1,0,1] (or similar variation of 0s, 1s, and -1s) are considered a success, but others like [1,1,1] are a failure.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13390>
_______________________________________

From report at bugs.python.org  Sun Nov 13 17:40:17 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 13 Nov 2011 16:40:17 +0000
Subject: [issue2771] Test issue
In-Reply-To: <1210005645.74.0.283923986194.issue2771@psf.upfronthosting.co.za>
Message-ID: <1321202417.06.0.568759232005.issue2771@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy:  -python-dev
resolution: fixed -> 
stage: committed/rejected -> test needed
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2771>
_______________________________________

From report at bugs.python.org  Sun Nov 13 17:41:32 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 13 Nov 2011 16:41:32 +0000
Subject: [issue2771] Test issue
In-Reply-To: <1210005645.74.0.283923986194.issue2771@psf.upfronthosting.co.za>
Message-ID: <E1RPd7R-00076s-4n@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 0e94d9bef251 by Ezio Melotti in branch 'default':
Closes #2771. #13388 now needs to be updated.
http://hg.python.org/test/rev/0e94d9bef251

----------
nosy: +python-dev
resolution:  -> fixed
stage: test needed -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2771>
_______________________________________

From report at bugs.python.org  Sun Nov 13 17:43:41 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sun, 13 Nov 2011 16:43:41 +0000
Subject: [issue13396] new method random.getrandbytes()
Message-ID: <1321202621.61.0.74333018382.issue13396@psf.upfronthosting.co.za>


New submission from Amaury Forgeot d'Arc <amauryfa at gmail.com>:

I noticed that several usages of random.getrandbits() actually need bytes.  A few examples:
- Lib/test/test_zlib.py calls "random.getrandbits(8 * _1M).to_bytes()"
- Twisted uses the %x format and then call .decode('hex')
Another examples found with Code Search:
- struct.pack("Q", random.getrandbits(64))
- for i in range(8): ClientChallenge+= chr(random.getrandbits(8))
- key = sha1(str(random.getrandbits(8*20))).digest()

random.getrandbits() itself is not a cheap call: it ends with a call to _PyLong_FromByteArray, and transformation to bytes will involve more copy, conversions from 30bit digits (or 15bit digits) to bytes, or worse.

This patch adds random.getrandbytes(), which creates a bytes string directly from calls to genrand_int32().

----------
files: getrandbytes.patch
keywords: patch
messages: 147557
nosy: amaury.forgeotdarc, rhettinger
priority: normal
severity: normal
status: open
title: new method random.getrandbytes()
type: feature request
versions: Python 3.2, Python 3.3
Added file: http://bugs.python.org/file23679/getrandbytes.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13396>
_______________________________________

From report at bugs.python.org  Sun Nov 13 17:45:03 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 13 Nov 2011 16:45:03 +0000
Subject: [issue2771] Test issue
In-Reply-To: <1210005645.74.0.283923986194.issue2771@psf.upfronthosting.co.za>
Message-ID: <1321202703.49.0.733465325207.issue2771@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy:  -python-dev
resolution: fixed -> 
stage: committed/rejected -> test needed
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2771>
_______________________________________

From report at bugs.python.org  Sun Nov 13 17:45:22 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 13 Nov 2011 16:45:22 +0000
Subject: [issue2771] Test issue
In-Reply-To: <1210005645.74.0.283923986194.issue2771@psf.upfronthosting.co.za>
Message-ID: <E1RPdB8-0007Tc-7U@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset e4fcac92a80a by Ezio Melotti in branch 'default':
Closes #2771. #13388 now needs to be updated.
http://hg.python.org/test/rev/e4fcac92a80a

----------
nosy: +python-dev
resolution:  -> fixed
stage: test needed -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2771>
_______________________________________

From report at bugs.python.org  Sun Nov 13 17:45:22 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 13 Nov 2011 16:45:22 +0000
Subject: [issue13388] document hg commit hooks in the devguide
In-Reply-To: <1321123590.65.0.736191202752.issue13388@psf.upfronthosting.co.za>
Message-ID: <E1RPdB8-0007Tc-7b@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset e4fcac92a80a by Ezio Melotti in branch 'default':
Closes #2771. #13388 now needs to be updated.
http://hg.python.org/test/rev/e4fcac92a80a

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13388>
_______________________________________

From report at bugs.python.org  Sun Nov 13 17:46:52 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 13 Nov 2011 16:46:52 +0000
Subject: [issue13388] document hg commit hooks in the devguide
In-Reply-To: <1321123590.65.0.736191202752.issue13388@psf.upfronthosting.co.za>
Message-ID: <1321202812.91.0.60110693085.issue13388@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

...because the hook now supports multiple issue id in the same commit message.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13388>
_______________________________________

From report at bugs.python.org  Sun Nov 13 17:48:37 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Sun, 13 Nov 2011 16:48:37 +0000
Subject: [issue13396] new method random.getrandbytes()
In-Reply-To: <1321202621.61.0.74333018382.issue13396@psf.upfronthosting.co.za>
Message-ID: <1321202917.28.0.895616292391.issue13396@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/issue13396>
_______________________________________

From report at bugs.python.org  Sun Nov 13 17:52:29 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 13 Nov 2011 16:52:29 +0000
Subject: [issue13390] Hunt memory allocations in addition to reference leaks
In-Reply-To: <1321140269.61.0.335726830367.issue13390@psf.upfronthosting.co.za>
Message-ID: <1321203149.11.0.686901516536.issue13390@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


Added file: http://bugs.python.org/file23680/debugblocks2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13390>
_______________________________________

From report at bugs.python.org  Sun Nov 13 17:52:45 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 13 Nov 2011 16:52:45 +0000
Subject: [issue13390] Hunt memory allocations in addition to reference leaks
In-Reply-To: <1321140269.61.0.335726830367.issue13390@psf.upfronthosting.co.za>
Message-ID: <1321203165.26.0.893591168218.issue13390@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


Added file: http://bugs.python.org/file23681/debugblocks3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13390>
_______________________________________

From report at bugs.python.org  Sun Nov 13 17:53:23 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 13 Nov 2011 16:53:23 +0000
Subject: [issue13390] Hunt memory allocations in addition to reference leaks
In-Reply-To: <1321140269.61.0.335726830367.issue13390@psf.upfronthosting.co.za>
Message-ID: <1321203203.87.0.820110814312.issue13390@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

And the latest patch (debugblocks3.patch) adds said heuristic.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13390>
_______________________________________

From report at bugs.python.org  Sun Nov 13 18:02:55 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 13 Nov 2011 17:02:55 +0000
Subject: [issue13396] new method random.getrandbytes()
In-Reply-To: <1321202621.61.0.74333018382.issue13396@psf.upfronthosting.co.za>
Message-ID: <1321203775.25.0.709544388666.issue13396@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Good idea, IMO.

+            cum = set()
+            for i in range(100):
+                val = getbytes(span)
+                cum |= set(i for i in range(span) if val[i])
+            self.assertEqual(len(cum), span)

I find this test a bit strange. Also, perhaps it should be bitwise rather than bytewise.

----------
nosy: +pitrou
stage:  -> patch review
versions:  -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13396>
_______________________________________

From report at bugs.python.org  Sun Nov 13 18:39:25 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 13 Nov 2011 17:39:25 +0000
Subject: [issue13204] sys.flags.__new__ crashes
In-Reply-To: <1318889665.83.0.350090316357.issue13204@psf.upfronthosting.co.za>
Message-ID: <1321205965.57.0.362596370555.issue13204@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Thanks for the patch. You should add the same tests for sys.version_info and sys.getwindowsversion.

----------
nosy: +pitrou
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13204>
_______________________________________

From report at bugs.python.org  Sun Nov 13 19:03:29 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 13 Nov 2011 18:03:29 +0000
Subject: [issue13355] random.triangular error when low = high=mode
In-Reply-To: <1320577016.77.0.989776485745.issue13355@psf.upfronthosting.co.za>
Message-ID: <1321207409.79.0.323827354967.issue13355@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

I've got this one.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13355>
_______________________________________

From report at bugs.python.org  Sun Nov 13 19:42:54 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 13 Nov 2011 18:42:54 +0000
Subject: [issue13217] Missing header dependencies in Makefile
In-Reply-To: <1318983258.55.0.960297108265.issue13217@psf.upfronthosting.co.za>
Message-ID: <E1RPf0n-0007Kw-Qd@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 36375075d6aa by Antoine Pitrou in branch 'default':
Issue #13217: add missing header dependencies in the Makefile for unicodeobject.o.
http://hg.python.org/cpython/rev/36375075d6aa

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13217>
_______________________________________

From report at bugs.python.org  Sun Nov 13 19:44:19 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 13 Nov 2011 18:44:19 +0000
Subject: [issue13217] Missing header dependencies in Makefile
In-Reply-To: <1318983258.55.0.960297108265.issue13217@psf.upfronthosting.co.za>
Message-ID: <1321209859.55.0.605416182001.issue13217@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Thank you for the patch. I only applied it to 3.3, since 3.2 doesn't have the additional header files.

----------
resolution:  -> invalid
stage: patch review -> committed/rejected
status: open -> closed
versions:  -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13217>
_______________________________________

From report at bugs.python.org  Sun Nov 13 19:55:51 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 13 Nov 2011 18:55:51 +0000
Subject: [issue13396] new method random.getrandbytes()
In-Reply-To: <1321202621.61.0.74333018382.issue13396@psf.upfronthosting.co.za>
Message-ID: <1321210551.77.0.202538005605.issue13396@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
assignee:  -> rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13396>
_______________________________________

From report at bugs.python.org  Sun Nov 13 20:01:57 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 13 Nov 2011 19:01:57 +0000
Subject: [issue13396] new method random.getrandbytes()
In-Reply-To: <1321202621.61.0.74333018382.issue13396@psf.upfronthosting.co.za>
Message-ID: <1321210917.23.0.838369487291.issue13396@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

How would this work for other random number generators that don't supply genrand_int32()?

The API for random is supposed to be easily subclassable and reusable for other random number generators.  The requirements for those generators is intentionally kept minimal (i.e. they only need to supply random(), seed(), getstate() and setstate() and optionally getrandbits()).

I'm -0 on making this API fatter.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13396>
_______________________________________

From report at bugs.python.org  Sun Nov 13 20:04:12 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Sun, 13 Nov 2011 19:04:12 +0000
Subject: [issue13388] document hg commit hooks in the devguide
In-Reply-To: <1321123590.65.0.736191202752.issue13388@psf.upfronthosting.co.za>
Message-ID: <1321211052.28.0.499168805715.issue13388@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

Nice, I didn't know about issue #2771 ;-)

Will update the patch!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13388>
_______________________________________

From report at bugs.python.org  Sun Nov 13 20:15:39 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sun, 13 Nov 2011 19:15:39 +0000
Subject: [issue13396] new method random.getrandbytes()
In-Reply-To: <1321202621.61.0.74333018382.issue13396@psf.upfronthosting.co.za>
Message-ID: <1321211739.41.0.761105963652.issue13396@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

> How would this work for other random number generators that don't
> supply genrand_int32()?

genrand_int32 is an internal function, only available in C for the Mersenne Twister generator.
random.SystemRandom() should provide getrandbytes as well, it would just call os.urandom(); I don't know other generators.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13396>
_______________________________________

From report at bugs.python.org  Sun Nov 13 20:50:04 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 13 Nov 2011 19:50:04 +0000
Subject: [issue13396] new method random.getrandbytes()
In-Reply-To: <1321202621.61.0.74333018382.issue13396@psf.upfronthosting.co.za>
Message-ID: <1321213804.4.0.114738908598.issue13396@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

> genrand_int32 is an internal function, 
> only available in C for the Mersenne Twister generator.

Yes, I know.  I'm the one added that code ;-)

>  I don't know other generators.

The problem is that we need an API that will accommodate other random number generators and not be specific to the MersenneTwister.  Right now, the starting point for everything in the random module is an underlying generator supplying a random() method returning a float and an optional getrandombits() method which returns an int (possibly a long int).  The latter is easily convertible to bytes with to_bytes() which uses a fast O(n) algorithm. ISTM, the getrandbytes() proposal amounts to a micro-optimization of existing capabilities, and it comes at the expense of fattening the API.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13396>
_______________________________________

From report at bugs.python.org  Sun Nov 13 21:41:35 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 13 Nov 2011 20:41:35 +0000
Subject: [issue13396] new method random.getrandbytes()
In-Reply-To: <1321213804.4.0.114738908598.issue13396@psf.upfronthosting.co.za>
Message-ID: <1321216608.3282.2.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> The problem is that we need an API that will accommodate other random
> number generators and not be specific to the MersenneTwister.  Right
> now, the starting point for everything in the random module is an
> underlying generator supplying a random() method returning a float and
> an optional getrandombits() method which returns an int (possibly a
> long int).

Well, you can provide a default getrandombytes() which calls into
getrandombits(), and specialize it in the case genrand_int32() exists.

>   The latter is easily convertible to bytes with to_bytes() which uses
> a fast O(n) algorithm.

Well, O(n) doesn't necessarily equate fast. Can Amaury post benchmark
numbers of getrandbits().to_bytes() vs getrandbytes()?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13396>
_______________________________________

From report at bugs.python.org  Sun Nov 13 22:00:30 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 13 Nov 2011 21:00:30 +0000
Subject: [issue13397] Option for XMLRPC clients to automatically transform
	Fault exceptions into standard exceptions
Message-ID: <1321218030.66.0.0560016220773.issue13397@psf.upfronthosting.co.za>


New submission from Raymond Hettinger <raymond.hettinger at gmail.com>:

Currently, an XMLRPC client communicating with a server running Python can make Python style calls but exceptions get collapsed into a standard FaultException making it difficult to program in a Pythonic style:

proxy = xmlrpc.client.ServerProxy("http://localhost:8000/")
try:
    value = proxy.lookup('somekey')
except xmlrpc.client.Fault as err:
    if err.faultCode == 1 and 'KeyError' in err.faultString:
        k = re.search(r":.(\w+)' not found$", err.faultString).groups(1)
        raise KeyError(k)
 
It would be better if we could do this automatically (search for a pure python exception of the same name and raise it instead of a Fault):

proxy = xmlrpc.client.ServerProxy("http://localhost:8000/", python_exceptions=True)

try:
   value = proxy.lookup('somekey')
except KeyError as e:
   ...

----------
messages: 147572
nosy: rhettinger
priority: normal
severity: normal
status: open
title: Option for XMLRPC clients to automatically transform Fault exceptions into standard exceptions
type: feature request
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13397>
_______________________________________

From report at bugs.python.org  Sun Nov 13 22:00:47 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 13 Nov 2011 21:00:47 +0000
Subject: [issue13397] Option for XMLRPC clients to automatically transform
	Fault exceptions into standard exceptions
In-Reply-To: <1321218030.66.0.0560016220773.issue13397@psf.upfronthosting.co.za>
Message-ID: <1321218047.91.0.413804646757.issue13397@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
components: +Library (Lib)
priority: normal -> low

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13397>
_______________________________________

From report at bugs.python.org  Sun Nov 13 22:04:53 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 13 Nov 2011 21:04:53 +0000
Subject: [issue13397] Option for XMLRPC clients to automatically transform
	Fault exceptions into standard exceptions
In-Reply-To: <1321218030.66.0.0560016220773.issue13397@psf.upfronthosting.co.za>
Message-ID: <1321218293.17.0.454677377742.issue13397@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +flox, loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13397>
_______________________________________

From report at bugs.python.org  Sun Nov 13 22:14:58 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sun, 13 Nov 2011 21:14:58 +0000
Subject: [issue13396] new method random.getrandbytes()
In-Reply-To: <1321202621.61.0.74333018382.issue13396@psf.upfronthosting.co.za>
Message-ID: <1321218898.3.0.176661098379.issue13396@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

./python -m timeit -s "from random import getrandbits" "getrandbits(8000000).to_bytes(1000000, 'little')"
10 loops, best of 3: 25 msec per loop

./python -m timeit -s "from random import getrandbytes" "getrandbytes(1000000)"
100 loops, best of 3: 9.66 msec per loop

For the Mersenne Twister, getrandbytes() is ~2.5 times faster (A length of 1000 gives exactly the same ratio)
When applied to the SytemRandom object, the difference is less impressive (probably because os.urandom is slow) but getrandbytes is still 20ms faster.

Updated patch to add getrandbytes at the module level, and to SystemRandom.

----------
Added file: http://bugs.python.org/file23682/getrandbytes.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13396>
_______________________________________

From report at bugs.python.org  Sun Nov 13 22:15:12 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sun, 13 Nov 2011 21:15:12 +0000
Subject: [issue13396] new method random.getrandbytes()
In-Reply-To: <1321202621.61.0.74333018382.issue13396@psf.upfronthosting.co.za>
Message-ID: <1321218912.45.0.520541620794.issue13396@psf.upfronthosting.co.za>


Changes by Amaury Forgeot d'Arc <amauryfa at gmail.com>:


Removed file: http://bugs.python.org/file23679/getrandbytes.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13396>
_______________________________________

From report at bugs.python.org  Sun Nov 13 23:52:12 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 13 Nov 2011 22:52:12 +0000
Subject: [issue12875] backport re.compile flags default value documentation
In-Reply-To: <1314854228.49.0.163476055978.issue12875@psf.upfronthosting.co.za>
Message-ID: <E1RPiu8-0008VU-D7@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 87ecfd5cd5d1 by Eli Bendersky in branch '2.7':
Normalize the keyword arguments documentation notation in re.rst. Closes issue #12875
http://hg.python.org/cpython/rev/87ecfd5cd5d1

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12875>
_______________________________________

From report at bugs.python.org  Sun Nov 13 23:53:25 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Sun, 13 Nov 2011 22:53:25 +0000
Subject: [issue12875] backport re.compile flags default value documentation
In-Reply-To: <1314854228.49.0.163476055978.issue12875@psf.upfronthosting.co.za>
Message-ID: <1321224805.75.0.125369253558.issue12875@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/issue12875>
_______________________________________

From report at bugs.python.org  Mon Nov 14 00:04:07 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Sun, 13 Nov 2011 23:04:07 +0000
Subject: [issue13388] document hg commit hooks in the devguide
In-Reply-To: <1321123590.65.0.736191202752.issue13388@psf.upfronthosting.co.za>
Message-ID: <1321225447.89.0.990119500176.issue13388@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

An updated patch attached, explaining that several issues can be mentioned in a single commit message

----------
Added file: http://bugs.python.org/file23683/issue13388.2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13388>
_______________________________________

From report at bugs.python.org  Mon Nov 14 00:08:24 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 13 Nov 2011 23:08:24 +0000
Subject: [issue13239] Remove <> operator from Grammar/Grammar
In-Reply-To: <1319188291.02.0.897231487042.issue13239@psf.upfronthosting.co.za>
Message-ID: <E1RPj9o-00018Z-QE@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset a259511351d9 by Eli Bendersky in branch '3.2':
Clarify the existence of the <> operator in Grammar/Grammar with a comment, for issue 13239
http://hg.python.org/cpython/rev/a259511351d9

New changeset 410115400838 by Eli Bendersky in branch 'default':
Clarify the existence of the <> operator in Grammar/Grammar with a comment. Closes issue 13239
http://hg.python.org/cpython/rev/410115400838

----------
nosy: +python-dev
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13239>
_______________________________________

From report at bugs.python.org  Mon Nov 14 00:13:56 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Sun, 13 Nov 2011 23:13:56 +0000
Subject: [issue13386] Document documentation conventions for optional args
In-Reply-To: <1321078121.18.0.541430257552.issue13386@psf.upfronthosting.co.za>
Message-ID: <1321226036.83.0.180792769739.issue13386@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

Ezio, regarding your latest message:

  "The problem is when the default placeholder is some unique object() or some _internal value (we had something similar with a socket timeout once)."

I hope this should be rare enough not to present a significant problem with the _convention_. Such cases can be reviewed specifically and the best way to document will be discussed per case.

  "Also for something like str.strip(), would you document chars=None or chars=" \n\r\t\v\f"?"

I think it would be better to document chars=None, because this is a simple value the user can pass (if he wants to do it explicitly), without thinking (and forgetting) about the specific delimeters. That None actually means " \n\r\t\v\f" should be explicitly documented below the function signature, of course.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13386>
_______________________________________

From report at bugs.python.org  Mon Nov 14 00:16:56 2011
From: report at bugs.python.org (=?utf-8?q?Maciej_Blizi=C5=84ski?=)
Date: Sun, 13 Nov 2011 23:16:56 +0000
Subject: [issue13398] _cursesmodule missing Python.h on Solaris
Message-ID: <1321226216.89.0.228790993845.issue13398@psf.upfronthosting.co.za>


New submission from Maciej Blizi?ski <maciej.blizinski at gmail.com>:

Compilation of Python 3.2.2 fails on Solaris 9 as follows:

/opt/SUNWspro/bin/cc  -xcode=pic32 -xO3 -m32 -xarch=v8 -I/opt/csw/include  -c ./Modules/_cursesmodule.c -o Modules/_cursesmodule.o
"./Modules/_cursesmodule.c", line 105: cannot find include file: "Python.h"
"./Modules/_cursesmodule.c", line 117: cannot find include file: "py_curses.h"
"./Modules/_cursesmodule.c", line 130: warning: no explicit type given
"./Modules/_cursesmodule.c", line 130: syntax error before or at: attr_t
"./Modules/_cursesmodule.c", line 130: warning: old-style declaration or incorrect type for: attr_t
"./Modules/_cursesmodule.c", line 139: warning: no explicit type given
"./Modules/_cursesmodule.c", line 139: syntax error before or at: *
(...)

The problem seems to be a missing -I flag for the compiler, pointing at the Include directory in Python sources.

----------
components: Build
messages: 147578
nosy: automatthias
priority: normal
severity: normal
status: open
title: _cursesmodule missing Python.h on Solaris
type: compile error
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13398>
_______________________________________

From report at bugs.python.org  Mon Nov 14 00:17:56 2011
From: report at bugs.python.org (=?utf-8?q?Maciej_Blizi=C5=84ski?=)
Date: Sun, 13 Nov 2011 23:17:56 +0000
Subject: [issue13398] _cursesmodule does not build,
	doesn't find Python.h on Solaris
In-Reply-To: <1321226216.89.0.228790993845.issue13398@psf.upfronthosting.co.za>
Message-ID: <1321226276.77.0.198460471752.issue13398@psf.upfronthosting.co.za>


Changes by Maciej Blizi?ski <maciej.blizinski at gmail.com>:


----------
title: _cursesmodule missing Python.h on Solaris -> _cursesmodule does not build, doesn't find Python.h on Solaris

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13398>
_______________________________________

From report at bugs.python.org  Mon Nov 14 00:24:28 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Sun, 13 Nov 2011 23:24:28 +0000
Subject: [issue11836] multiprocessing.queues.SimpleQueue is undocumented
In-Reply-To: <1302623785.46.0.16009713021.issue11836@psf.upfronthosting.co.za>
Message-ID: <1321226668.56.0.93861998362.issue11836@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

Sandro - yep, the sentinels arg is also undocumented in multiprocessing.PipeConnection.recv() and further down the road...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11836>
_______________________________________

From report at bugs.python.org  Mon Nov 14 00:27:14 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 13 Nov 2011 23:27:14 +0000
Subject: [issue13229] Improve tools for iterating over filesystem directories
In-Reply-To: <1319076330.7.0.757546324527.issue13229@psf.upfronthosting.co.za>
Message-ID: <1321226834.06.0.578802152825.issue13229@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

And walkdir is now a published package: http://walkdir.readthedocs.org

My plan for this issue now is to maintain walkdir as a standalone package for 2.7 and 3.2, but still add the functionality to shutil for 3.3+.

However, I'll gather feedback on the PyPI module for a while before making any changes to the 3.3 repo.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13229>
_______________________________________

From report at bugs.python.org  Mon Nov 14 00:28:20 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Sun, 13 Nov 2011 23:28:20 +0000
Subject: [issue11836] multiprocessing.queues.SimpleQueue is undocumented
In-Reply-To: <1302623785.46.0.16009713021.issue11836@psf.upfronthosting.co.za>
Message-ID: <1321226900.38.0.793699754532.issue11836@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

However, sentinels *are* mentioned in the multiprocessing doc, below multiprocessing.Process:

"
sentinel

    A numeric handle of a system object which will become ?ready? when the process ends.

    On Windows, this is an OS handle usable with the WaitForSingleObject and WaitForMultipleObjects family of API calls. On Unix, this is a file descriptor usable with primitives from the select module.

    You can use this value if you want to wait on several events at once. Otherwise calling join() is simpler.

    New in version 3.3.
"

>From a cursory glance on the implementation in Lib/multiprocessing/connection.py, this is the same sentinel.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11836>
_______________________________________

From report at bugs.python.org  Mon Nov 14 02:09:25 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 14 Nov 2011 01:09:25 +0000
Subject: [issue13374] Deprecate usage of the Windows ANSI API in the nt module
In-Reply-To: <1321133772.03.0.698103185151.issue13374@psf.upfronthosting.co.za>
Message-ID: <201111140211.12312.victor.stinner@haypocalc.com>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> I notice that the patch changes rename() and link() to use
> win32_decode_filename() to coerce the filename to unicode before using
> the "wide" win32 api.

Well, I did that to simplify the source code.

> (Previously, rename() first tried the wide api,
> falling back to narrow if that failed; link() used wide if the args were
> both unicode, narrow otherwise.  Some other functions like symlink()
> already only use the wide api.)

I can change my patch to mimick the previous behaviour: try Unicode-Unicode, 
or fall back to encoding both arguments to the filesystem encoding.

> Is this approach of coercing to unicode and only using the wide api
> "blessed"?  I certainly think it should be.  If so then one can get
> rid lots windows specific code.

It was already discussed before to drop the bytes API to decode Unicode 
filenames in Python and only use the Unicode Windows API. There is no consensus 
on this topic: the statut is that the bytes API is kept but deprecated. bytes 
filenames will continue to use the bytes Windows API.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13374>
_______________________________________

From report at bugs.python.org  Mon Nov 14 03:57:30 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 14 Nov 2011 02:57:30 +0000
Subject: [issue13396] new method random.getrandbytes()
In-Reply-To: <1321202621.61.0.74333018382.issue13396@psf.upfronthosting.co.za>
Message-ID: <1321239450.66.0.515569086823.issue13396@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

The differential cost of generating n random bytes is negligible compared to actually doing anything with the bytes once their generated.  

This optimization is close to being a total waste (saving 15 milliseconds for the abnormal case of generating 1 million random bytes).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13396>
_______________________________________

From report at bugs.python.org  Mon Nov 14 05:21:47 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 14 Nov 2011 04:21:47 +0000
Subject: [issue12875] backport re.compile flags default value documentation
In-Reply-To: <1314854228.49.0.163476055978.issue12875@psf.upfronthosting.co.za>
Message-ID: <1321244507.49.0.996028111586.issue12875@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
resolution:  -> fixed
stage: commit review -> committed/rejected

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12875>
_______________________________________

From report at bugs.python.org  Mon Nov 14 06:11:06 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 14 Nov 2011 05:11:06 +0000
Subject: [issue13386] Document documentation conventions for optional args
In-Reply-To: <1321078121.18.0.541430257552.issue13386@psf.upfronthosting.co.za>
Message-ID: <1321247466.98.0.478442835897.issue13386@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

> You should also explicitly specify what happens in several optional but 
> not keyword args are needed. AFAIU the convention is:
>   func(arg1, arg2[, opt1, opt2])

IIUC that would mean that either you pass only arg1 and arg2, or you also pass both opt1 and opt2.
I think the correct notation for that is e.g.:
  str.startswith(prefix[, start[, end]])

I also saw "func(foo[, bar][, baz])" for cases where either bar or baz can be passed, but since this requires keyword arguments, the "func(foo, bar=x, baz=y)" notation should be used instead, and the documentation should then explain that either one can be passed.

I also agree with what you said in your last message.  What can't be expressed with a notation can always be described with words.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13386>
_______________________________________

From report at bugs.python.org  Mon Nov 14 06:14:23 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Mon, 14 Nov 2011 05:14:23 +0000
Subject: [issue13386] Document documentation conventions for optional args
In-Reply-To: <1321078121.18.0.541430257552.issue13386@psf.upfronthosting.co.za>
Message-ID: <1321247663.36.0.389972500363.issue13386@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

What you say makes sense, now I just have to dig up where I saw instances of [, opt1, opt2]

If anything, this is another proof that such conventions must be agreed upon and meticulously documented.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13386>
_______________________________________

From report at bugs.python.org  Mon Nov 14 11:00:19 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Mon, 14 Nov 2011 10:00:19 +0000
Subject: [issue13386] Document documentation conventions for optional args
In-Reply-To: <1321078121.18.0.541430257552.issue13386@psf.upfronthosting.co.za>
Message-ID: <1321264819.97.0.0984047667997.issue13386@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/issue13386>
_______________________________________

From report at bugs.python.org  Mon Nov 14 11:50:26 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 14 Nov 2011 10:50:26 +0000
Subject: [issue13386] Document documentation conventions for optional args
In-Reply-To: <1321078121.18.0.541430257552.issue13386@psf.upfronthosting.co.za>
Message-ID: <1321267826.56.0.639528864898.issue13386@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13386>
_______________________________________

From report at bugs.python.org  Mon Nov 14 13:21:30 2011
From: report at bugs.python.org (Baptiste Carvello)
Date: Mon, 14 Nov 2011 12:21:30 +0000
Subject: [issue13386] Document documentation conventions for optional args
In-Reply-To: <1321078121.18.0.541430257552.issue13386@psf.upfronthosting.co.za>
Message-ID: <1321273290.66.0.751978720206.issue13386@psf.upfronthosting.co.za>


Baptiste Carvello <devel at baptiste-carvello.net> added the comment:

Hi all, here is a relevant user story. I'm afraid it won't help you much, but it highlights the importance of consistent conventions in doc.

My girlfriend is learning Python with no prior programing experience. She quite naturally got used to calling help(function), and noted the following:

1) she naturally understood the meaning of the [opt] notation

2) she did not understand the opt=default notation, as she didn't have a sufficient experience with Python to recognize the syntax

3) even after learning what it meant, she still found that notation obscure and unappealing

4) she got annoyed that two completely different notations where used for two very close concepts

5) she got annoyed that there was no user-discoverable and user-understandable document introducing those notations (if there is one, my mistake :-)

I have no ovious solutions to the annoyances. Regarding 4), maybe the [opt=default] notation has something good after all: that it reminds of the [opt] one. And regarding 5), if there is a canonical document about documentation conventions, I could try to summarize it in a language aimed at beginners.

----------
nosy: +baptiste.carvello

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13386>
_______________________________________

From report at bugs.python.org  Mon Nov 14 13:40:09 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 14 Nov 2011 12:40:09 +0000
Subject: [issue13386] Document documentation conventions for optional args
In-Reply-To: <1321078121.18.0.541430257552.issue13386@psf.upfronthosting.co.za>
Message-ID: <1321274409.88.0.235362900008.issue13386@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Thanks for the feedback!

> 1) she naturally understood the meaning of the [opt] notation

I guess this depends on her background, I've seen people trying to use [] in function calls because they saw them in the doc or confusing them for lists, so I guess that each notation has its pros and cons.

> 2) she did not understand the opt=default notation, as she didn't 
> have a sufficient experience with Python to recognize the syntax

I agree that at the beginning it could be a bit confusing, but keyword arguments are an important part of Python and it's among the first things that one should learn.  After that it should be even more natural than [].

> 3) even after learning what it meant, she still found that notation 
> obscure and unappealing

...or maybe not.  Can she say what in particular is obscure and unappealing?

> 4) she got annoyed that two completely different notations where used 
> for two very close concepts

This is a good point, and we are trying to move to the arg=default notation.  Unfortunately there are still places that use the old notation.  C functions that have optional arguments but don't accept keyword arguments are a bit unusual, and IIUC in most of the cases that's an implementation detail that could be removed.

> 5) she got annoyed that there was no user-discoverable and 
> user-understandable document introducing those notations (if there is > one, my mistake :-)

This brings ups another interesting point.  These conventions will probably end up in the "documenting" section, that is aimed to doc writers.  Do we need an introductory page aimed to the readers that explains the conventions used in the doc?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13386>
_______________________________________

From report at bugs.python.org  Mon Nov 14 13:41:32 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Mon, 14 Nov 2011 12:41:32 +0000
Subject: [issue6397] Implementing Solaris "/dev/poll" in the "select" module
In-Reply-To: <1246466955.08.0.134631976531.issue6397@psf.upfronthosting.co.za>
Message-ID: <1321274492.09.0.480363473919.issue6397@psf.upfronthosting.co.za>


Changes by Jes?s Cea Avi?n <jcea at jcea.es>:


Added file: http://bugs.python.org/file23684/11f08326afd0.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6397>
_______________________________________

From report at bugs.python.org  Mon Nov 14 13:43:39 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 14 Nov 2011 12:43:39 +0000
Subject: [issue12681] unittest expectedFailure could take a message argument
	like skip does
In-Reply-To: <1312285316.59.0.648531105022.issue12681@psf.upfronthosting.co.za>
Message-ID: <1321274619.14.0.103281234791.issue12681@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Maybe we could add an expected_issue(id) decorator to test.support.

----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12681>
_______________________________________

From report at bugs.python.org  Mon Nov 14 13:43:57 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 14 Nov 2011 12:43:57 +0000
Subject: [issue3932] HTMLParser cannot handle '&' and non-ascii characters in
	attribute names
In-Reply-To: <1222086790.7.0.800001604957.issue3932@psf.upfronthosting.co.za>
Message-ID: <1321274637.06.0.896590756441.issue3932@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
assignee:  -> ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3932>
_______________________________________

From report at bugs.python.org  Mon Nov 14 13:44:10 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 14 Nov 2011 12:44:10 +0000
Subject: [issue13357] HTMLParser parses attributes incorrectly.
In-Reply-To: <1320606546.64.0.752508532419.issue13357@psf.upfronthosting.co.za>
Message-ID: <1321274650.59.0.0313002647312.issue13357@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
assignee:  -> ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13357>
_______________________________________

From report at bugs.python.org  Mon Nov 14 13:44:28 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 14 Nov 2011 12:44:28 +0000
Subject: [issue12629] HTMLParser silently stops parsing with malformed
	attributes
In-Reply-To: <1311532507.83.0.00235537878353.issue12629@psf.upfronthosting.co.za>
Message-ID: <1321274668.13.0.361717128983.issue12629@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
assignee:  -> ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12629>
_______________________________________

From report at bugs.python.org  Mon Nov 14 13:45:57 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 14 Nov 2011 12:45:57 +0000
Subject: [issue755670] improve HTMLParser attribute processing regexps
Message-ID: <1321274757.93.0.647821654495.issue755670@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
assignee:  -> ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue755670>
_______________________________________

From report at bugs.python.org  Mon Nov 14 13:46:11 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 14 Nov 2011 12:46:11 +0000
Subject: [issue1745761] Bad attributes/data handling in SGMLib
Message-ID: <1321274771.89.0.0427434336665.issue1745761@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
assignee:  -> ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1745761>
_______________________________________

From report at bugs.python.org  Mon Nov 14 13:46:42 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Mon, 14 Nov 2011 12:46:42 +0000
Subject: [issue6397] Implementing Solaris "/dev/poll" in the "select" module
In-Reply-To: <1246466955.08.0.134631976531.issue6397@psf.upfronthosting.co.za>
Message-ID: <1321274802.37.0.47073781425.issue6397@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

New changeset. The only change is:

"""
diff --git a/Modules/selectmodule.c b/Modules/selectmodule.c
--- a/Modules/selectmodule.c
+++ b/Modules/selectmodule.c
@@ -685,8 +685,16 @@
         return -1;
     }
     if (n < size) {
-        PyErr_SetString(PyExc_IOError, "failed to write all pollfds. "
-                "Please, report in http://bugs.python.org/");
+        /*
+        ** Data writed to /dev/poll is a binary data structure. It is not
+        ** clear what to do if a partial write occurred. For now, raise
+        ** an exception and see if we actually found this problem in
+        ** the wild.
+        */
+        PyErr_Format(PyExc_IOError, "failed to write all pollfds. "
+                "Please, report at http://bugs.python.org/. "
+                "Data to report: Size tried: %d, actual size written: %d",
+                size, n);
         return -1;
     }
     return 0;
"""

If there are no disagreements, I will commit to default (3.3) soon (in a few hours/a day).

Thanks!.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6397>
_______________________________________

From report at bugs.python.org  Mon Nov 14 13:50:50 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Mon, 14 Nov 2011 12:50:50 +0000
Subject: [issue13396] new method random.getrandbytes()
In-Reply-To: <1321202621.61.0.74333018382.issue13396@psf.upfronthosting.co.za>
Message-ID: <1321275050.85.0.261268386034.issue13396@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/issue13396>
_______________________________________

From report at bugs.python.org  Mon Nov 14 13:57:05 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Mon, 14 Nov 2011 12:57:05 +0000
Subject: [issue13398] _cursesmodule does not build,
	doesn't find Python.h on Solaris
In-Reply-To: <1321226216.89.0.228790993845.issue13398@psf.upfronthosting.co.za>
Message-ID: <1321275425.99.0.942012342535.issue13398@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

Maciej, could you possibly provide a "diff" file to apply?. I care about Solaris support, but I don't have a Solaris 9 around for testing. Only Solaris 10 and OpenIndiana.

Try to provide a minimal patch, please.

----------
nosy: +jcea
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13398>
_______________________________________

From report at bugs.python.org  Mon Nov 14 13:58:05 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Mon, 14 Nov 2011 12:58:05 +0000
Subject: [issue13398] _cursesmodule does not build,
	doesn't find Python.h on Solaris
In-Reply-To: <1321226216.89.0.228790993845.issue13398@psf.upfronthosting.co.za>
Message-ID: <1321275485.24.0.386652561921.issue13398@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

BTW, have you tried to compile with GCC?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13398>
_______________________________________

From report at bugs.python.org  Mon Nov 14 14:23:41 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 14 Nov 2011 13:23:41 +0000
Subject: [issue13239] Remove <> operator from Grammar/Grammar
In-Reply-To: <1319188291.02.0.897231487042.issue13239@psf.upfronthosting.co.za>
Message-ID: <1321277021.94.0.169866167348.issue13239@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

+# <> isn't actually a valid comparison operator in Python. It's here for the
+# sake of a __future__ import described in PEP 401

If we wanted to be exact, the operator isn?t here for a __future__ import but for a feature enabled by a __future__ import.  But I don?t feel strongly about this at all :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13239>
_______________________________________

From report at bugs.python.org  Mon Nov 14 14:24:35 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 14 Nov 2011 13:24:35 +0000
Subject: [issue13264] Monkeypatching using metaclass
In-Reply-To: <1319546705.67.0.958518065524.issue13264@psf.upfronthosting.co.za>
Message-ID: <1321277075.6.0.634068255615.issue13264@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Artem, if you have further information to make us reconsider this issue, please add a new message.

----------
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13264>
_______________________________________

From report at bugs.python.org  Mon Nov 14 14:46:02 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 14 Nov 2011 13:46:02 +0000
Subject: [issue13386] Document documentation conventions for optional args
In-Reply-To: <1321078121.18.0.541430257552.issue13386@psf.upfronthosting.co.za>
Message-ID: <1321278362.5.0.837227592765.issue13386@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> Do we need an introductory page aimed to the readers that explains
> the conventions used in the doc?

Explaining notational conventions at the start of a technical reference sounds like a best practice to me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13386>
_______________________________________

From report at bugs.python.org  Mon Nov 14 15:24:19 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 14 Nov 2011 14:24:19 +0000
Subject: [issue11751] Increase distutils.filelist / packaging.manifest test
	coverage
In-Reply-To: <1301857658.21.0.439945432416.issue11751@psf.upfronthosting.co.za>
Message-ID: <E1RPxSB-00071d-CM@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 3dda26cfc1d7 by ?ric Araujo in branch 'default':
Increase test coverage for manifest (#11751).
http://hg.python.org/distutils2/rev/3dda26cfc1d7

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11751>
_______________________________________

From report at bugs.python.org  Mon Nov 14 15:24:19 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 14 Nov 2011 14:24:19 +0000
Subject: [issue13170] distutils2 test failures
In-Reply-To: <1318523837.27.0.295397321545.issue13170@psf.upfronthosting.co.za>
Message-ID: <E1RPxSB-00071d-Ao@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 5b096fc6e65d by ?ric Araujo in branch 'default':
Fix import in install_data (#13170).  Thanks to David Barnett.
http://hg.python.org/distutils2/rev/5b096fc6e65d

New changeset 2d469ccfe30e by ?ric Araujo in branch 'python3':
Merge fixes for #13170 and #12386 and other misc. changes from default
http://hg.python.org/distutils2/rev/2d469ccfe30e

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13170>
_______________________________________

From report at bugs.python.org  Mon Nov 14 15:24:20 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 14 Nov 2011 14:24:20 +0000
Subject: [issue12915] Add inspect.locate and inspect.resolve
In-Reply-To: <1315326633.9.0.910127000285.issue12915@psf.upfronthosting.co.za>
Message-ID: <E1RPxSB-00071d-Bh@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 5df1065ddb8b by ?ric Araujo in branch 'default':
Expand tests and fix bugs in util.resolve_name.
http://hg.python.org/distutils2/rev/5df1065ddb8b

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12915>
_______________________________________

From report at bugs.python.org  Mon Nov 14 15:24:21 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 14 Nov 2011 14:24:21 +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: <E1RPxSB-00071d-BO@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset cb49bc384957 by ?ric Araujo in branch 'default':
Fix writing of the RESOURCES file (#12386).
http://hg.python.org/distutils2/rev/cb49bc384957

New changeset 2d469ccfe30e by ?ric Araujo in branch 'python3':
Merge fixes for #13170 and #12386 and other misc. changes from default
http://hg.python.org/distutils2/rev/2d469ccfe30e

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12386>
_______________________________________

From report at bugs.python.org  Mon Nov 14 15:34:28 2011
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Mon, 14 Nov 2011 14:34:28 +0000
Subject: [issue13399] Don't print traceback for recognized options in packaging
Message-ID: <1321281268.02.0.339671708656.issue13399@psf.upfronthosting.co.za>


New submission from Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:

$ python3.3 setup.py build --some-option
usage: setup.py [global_opts] cmd1 [cmd1_opts] [cmd2 [cmd2_opts] ...]
   or: setup.py --help [cmd1 cmd2 ...]
   or: setup.py --help-commands
   or: setup.py cmd --help

error: option --some-option not recognized
$ pysetup3.3 run build --some-option
option --some-option not recognized
Traceback (most recent call last):
  File "/usr/lib64/python3.3/packaging/fancy_getopt.py", line 239, in getopt
    opts, args = getopt.getopt(args, short_opts, self.long_opts)
  File "/usr/lib64/python3.3/getopt.py", line 93, in getopt
    opts, args = do_longs(opts, args[0][2:], longopts, args[1:])
  File "/usr/lib64/python3.3/getopt.py", line 157, in do_longs
    has_arg, opt = long_has_args(opt, longopts)
  File "/usr/lib64/python3.3/getopt.py", line 174, in long_has_args
    raise GetoptError(_('option --%s not recognized') % opt, opt)
getopt.GetoptError: option --some-option not recognized

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/lib64/python3.3/packaging/run.py", line 653, in main
    return dispatcher()
  File "/usr/lib64/python3.3/packaging/run.py", line 642, in __call__
    return func(self, self.args)
  File "/usr/lib64/python3.3/packaging/run.py", line 91, in wrapper
    return f(*args, **kwargs)
  File "/usr/lib64/python3.3/packaging/run.py", line 271, in _run
    args = dispatcher._parse_command_opts(parser, args)
  File "/usr/lib64/python3.3/packaging/run.py", line 491, in _parse_command_opts
    args, opts = parser.getopt(args[1:])
  File "/usr/lib64/python3.3/packaging/fancy_getopt.py", line 241, in getopt
    raise PackagingArgError(msg)
packaging.errors.PackagingArgError: option --some-option not recognized

----------
assignee: tarek
components: Distutils2
keywords: easy
messages: 147599
nosy: Arfrever, alexis, eric.araujo, tarek
priority: normal
severity: normal
status: open
title: Don't print traceback for recognized options in packaging
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13399>
_______________________________________

From report at bugs.python.org  Mon Nov 14 15:35:30 2011
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Mon, 14 Nov 2011 14:35:30 +0000
Subject: [issue13399] Don't print traceback for unrecognized options in
	packaging
In-Reply-To: <1321281268.02.0.339671708656.issue13399@psf.upfronthosting.co.za>
Message-ID: <1321281330.5.0.71955422373.issue13399@psf.upfronthosting.co.za>


Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:


----------
title: Don't print traceback for recognized options in packaging -> Don't print traceback for unrecognized options in packaging

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13399>
_______________________________________

From report at bugs.python.org  Mon Nov 14 15:40:23 2011
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Mon, 14 Nov 2011 14:40:23 +0000
Subject: [issue13400] packaging: build command should accept --compile,
	--no-compile and --optimize options
Message-ID: <1321281623.21.0.854677924579.issue13400@psf.upfronthosting.co.za>


New submission from Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:

build command of packaging should accept --compile, --no-compile and --optimize options and pass them to build_py command.

----------
assignee: tarek
components: Distutils2
keywords: easy
messages: 147600
nosy: Arfrever, alexis, eric.araujo, tarek
priority: normal
severity: normal
status: open
title: packaging: build command should accept --compile, --no-compile and --optimize options
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13400>
_______________________________________

From report at bugs.python.org  Mon Nov 14 15:48:17 2011
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Mon, 14 Nov 2011 14:48:17 +0000
Subject: [issue13399] Don't print traceback for unrecognized actions,
	commands and options in packaging
In-Reply-To: <1321281268.02.0.339671708656.issue13399@psf.upfronthosting.co.za>
Message-ID: <1321282097.37.0.693088956627.issue13399@psf.upfronthosting.co.za>


Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com> added the comment:

$ pysetup3.3 unknown_action
Unrecognized action "unknown_action"
Traceback (most recent call last):
  File "/usr/lib64/python3.3/packaging/run.py", line 650, in main
    dispatcher = Dispatcher(args)
  File "/usr/lib64/python3.3/packaging/run.py", line 404, in __init__
    raise PackagingArgError(msg)
packaging.errors.PackagingArgError: Unrecognized action "unknown_action"
$ pysetup3.3 run unknown_command
Invalid command unknown_command
Traceback (most recent call last):
  File "/usr/lib64/python3.3/packaging/command/__init__.py", line 57, in get_command_class
    cls = _COMMANDS[name]
KeyError: 'unknown_command'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/lib64/python3.3/packaging/run.py", line 448, in _parse_command_opts
    cmd_class = get_command_class(command)
  File "/usr/lib64/python3.3/packaging/command/__init__.py", line 59, in get_command_class
    raise PackagingModuleError("Invalid command %s" % name)
packaging.errors.PackagingModuleError: Invalid command unknown_command

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/lib64/python3.3/packaging/run.py", line 653, in main
    return dispatcher()
  File "/usr/lib64/python3.3/packaging/run.py", line 642, in __call__
    return func(self, self.args)
  File "/usr/lib64/python3.3/packaging/run.py", line 91, in wrapper
    return f(*args, **kwargs)
  File "/usr/lib64/python3.3/packaging/run.py", line 271, in _run
    args = dispatcher._parse_command_opts(parser, args)
  File "/usr/lib64/python3.3/packaging/run.py", line 450, in _parse_command_opts
    raise PackagingArgError(msg)
packaging.errors.PackagingArgError: Invalid command unknown_command

----------
title: Don't print traceback for unrecognized options in packaging -> Don't print traceback for unrecognized actions, commands and options in packaging

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13399>
_______________________________________

From report at bugs.python.org  Mon Nov 14 16:20:11 2011
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Mon, 14 Nov 2011 15:20:11 +0000
Subject: [issue13401] test_argparse fails with root permissions
Message-ID: <1321284011.15.0.976219743674.issue13401@psf.upfronthosting.co.za>


New submission from Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:

$ python3.3 -B -m test.test_argparse
...
======================================================================
FAIL: test_failures_many_groups_listargs (__main__.TestFileTypeW)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/lib64/python3.3/test/test_argparse.py", line 216, in wrapper
    test_func(self)
  File "/usr/lib64/python3.3/test/test_argparse.py", line 235, in test_failures
    raises(ArgumentParserError, parser.parse_args, args)
AssertionError: ArgumentParserError not raised by parse_args

======================================================================
FAIL: test_failures_many_groups_sysargs (__main__.TestFileTypeW)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/lib64/python3.3/test/test_argparse.py", line 216, in wrapper
    test_func(self)
  File "/usr/lib64/python3.3/test/test_argparse.py", line 235, in test_failures
    raises(ArgumentParserError, parser.parse_args, args)
AssertionError: ArgumentParserError not raised by parse_args

======================================================================
FAIL: test_failures_no_groups_listargs (__main__.TestFileTypeW)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/lib64/python3.3/test/test_argparse.py", line 216, in wrapper
    test_func(self)
  File "/usr/lib64/python3.3/test/test_argparse.py", line 235, in test_failures
    raises(ArgumentParserError, parser.parse_args, args)
AssertionError: ArgumentParserError not raised by parse_args

======================================================================
FAIL: test_failures_no_groups_sysargs (__main__.TestFileTypeW)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/lib64/python3.3/test/test_argparse.py", line 216, in wrapper
    test_func(self)
  File "/usr/lib64/python3.3/test/test_argparse.py", line 235, in test_failures
    raises(ArgumentParserError, parser.parse_args, args)
AssertionError: ArgumentParserError not raised by parse_args

======================================================================
FAIL: test_failures_one_group_listargs (__main__.TestFileTypeW)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/lib64/python3.3/test/test_argparse.py", line 216, in wrapper
    test_func(self)
  File "/usr/lib64/python3.3/test/test_argparse.py", line 235, in test_failures
    raises(ArgumentParserError, parser.parse_args, args)
AssertionError: ArgumentParserError not raised by parse_args

======================================================================
FAIL: test_failures_one_group_sysargs (__main__.TestFileTypeW)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/lib64/python3.3/test/test_argparse.py", line 216, in wrapper
    test_func(self)
  File "/usr/lib64/python3.3/test/test_argparse.py", line 235, in test_failures
    raises(ArgumentParserError, parser.parse_args, args)
AssertionError: ArgumentParserError not raised by parse_args

----------------------------------------------------------------------
Ran 1611 tests in 8.405s

FAILED (failures=6)
Traceback (most recent call last):
  File "/usr/lib64/python3.3/runpy.py", line 160, in _run_module_as_main
    "__main__", fname, loader, pkg_name)
  File "/usr/lib64/python3.3/runpy.py", line 73, in _run_code
    exec(code, run_globals)
  File "/usr/lib64/python3.3/test/test_argparse.py", line 4773, in <module>
    test_main()
  File "/usr/lib64/python3.3/test/test_argparse.py", line 4765, in test_main
    support.run_unittest(__name__)
  File "/usr/lib64/python3.3/test/support.py", line 1402, in run_unittest
    _run_suite(suite)
  File "/usr/lib64/python3.3/test/support.py", line 1377, in _run_suite
    raise TestFailed(err)
test.support.TestFailed: multiple errors occurred

----------
components: Tests
keywords: easy
messages: 147602
nosy: Arfrever, bethard
priority: normal
severity: normal
status: open
title: test_argparse fails with root permissions
versions: Python 2.7, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13401>
_______________________________________

From report at bugs.python.org  Mon Nov 14 16:59:08 2011
From: report at bugs.python.org (Jesus Rivero)
Date: Mon, 14 Nov 2011 15:59:08 +0000
Subject: [issue13401] test_argparse fails with root permissions
In-Reply-To: <1321284011.15.0.976219743674.issue13401@psf.upfronthosting.co.za>
Message-ID: <1321286348.15.0.116280927701.issue13401@psf.upfronthosting.co.za>


Changes by Jesus Rivero <neurogeek at gentoo.org>:


----------
nosy: +Neurogeek

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13401>
_______________________________________

From report at bugs.python.org  Mon Nov 14 17:10:23 2011
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Mon, 14 Nov 2011 16:10:23 +0000
Subject: [issue13401] test_argparse fails with root permissions
In-Reply-To: <1321284011.15.0.976219743674.issue13401@psf.upfronthosting.co.za>
Message-ID: <1321287023.3.0.636506898606.issue13401@psf.upfronthosting.co.za>


Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:


----------
keywords: +patch
Added file: http://bugs.python.org/file23685/python-test_argparse.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13401>
_______________________________________

From report at bugs.python.org  Mon Nov 14 17:14:55 2011
From: report at bugs.python.org (Dave Mankoff)
Date: Mon, 14 Nov 2011 16:14:55 +0000
Subject: [issue13391] string.strip Does Not Remove Zero-Width-Space (ZWSP)
In-Reply-To: <1321145122.08.0.463222804165.issue13391@psf.upfronthosting.co.za>
Message-ID: <1321287295.23.0.839628268177.issue13391@psf.upfronthosting.co.za>


Dave Mankoff <mankyd at gmail.com> added the comment:

I appreciated the quick turnaround on this.

Perhaps I am misunderstanding the resolution. I understand that strip uses _PyUnicode_IsWhitespace, and that _PyUnicode_IsWhitespace "Returns 1 for Unicode characters having the bidirectional type 'WS', 'B' or 'S' or the category 'Zs', 0 otherwise." However, perhaps this is where the functionality is missing?

Upon further inspection, it looks like there may be other missing white-space characters, such as U+FEFF, "Zero Width No-Break Space". Whatever unicode categories their in, they're still a form of white-space and should still be removed, no?

This was not the behavior I expected from strip(). 
This affects string.issspace() as well.  I now have to put var.strip().strip(u'\u200B\ufeff') anywhere I want to test for whitespace strings in all my future python code. (I was bit by exactly this issue in my code which is what caused me to file the issue in the first place.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13391>
_______________________________________

From report at bugs.python.org  Mon Nov 14 17:29:45 2011
From: report at bugs.python.org (Baptiste Carvello)
Date: Mon, 14 Nov 2011 16:29:45 +0000
Subject: [issue13386] Document documentation conventions for optional args
In-Reply-To: <1321274409.88.0.235362900008.issue13386@psf.upfronthosting.co.za>
Message-ID: <4EC141EC.7010709@baptiste-carvello.net>


Baptiste Carvello <devel at baptiste-carvello.net> added the comment:

Le 14/11/2011 13:40, Ezio Melotti a ?crit :

>> 1) she naturally understood the meaning of the [opt] notation
>
> I guess this depends on her background, I've seen people trying to use [] in function calls because they saw them in the doc or confusing them for lists, so I guess that each notation has its pros and cons.
> 

agreed, the [] notation also has its dangers. But the current situation
doesn't avoid them, because users will meet both notations.

>> 2) she did not understand the opt=default notation, as she didn't 
>> have a sufficient experience with Python to recognize the syntax
>
> I agree that at the beginning it could be a bit confusing, but keyword arguments are an important part of Python and it's among the first things that one should learn.  After that it should be even more natural than [].
> 

the thing is, beginners need to use other people's functions before they
really get into writing their own. You need some practice with a syntax
before you are able to recognize it in another context.

>> 3) even after learning what it meant, she still found that notation 
>> obscure and unappealing
> 
> ...or maybe not.  Can she say what in particular is obscure and unappealing?
> 

I'd say the fact that the main information (that the argument is
optional) is not highlighted and only appears as a side-effect of having
a default. Inversely, a lot of importance is given to the value of the
default, which most users can ignore at first.

>> 4) she got annoyed that two completely different notations where used 
>> for two very close concepts
> 
> This is a good point, and we are trying to move to the arg=default notation.  Unfortunately there are still places that use the old notation.  C functions that have optional arguments but don't accept keyword arguments are a bit unusual, and IIUC in most of the cases that's an implementation detail that could be removed.
> 

That would would solve the problem for the stdlib, but other C libraries
also have optional arguments which don't accept keyword arguments (for
example NumPy ufuncs). Will converting to a keyword argument work for
all of them?

>> 5) she got annoyed that there was no user-discoverable and 
>> user-understandable document introducing those notations (if there is > one, my mistake :-)
> 
> This brings ups another interesting point.  These conventions will probably end up in the "documenting" section, that is aimed to doc writers.  Do we need an introductory page aimed to the readers that explains the conventions used in the doc?
> 

I would say we need one. It should probably also be part of the "help()"
tool, as the function prototype is the first information that
help(function) displays.

Cheers,
Baptiste

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13386>
_______________________________________

From report at bugs.python.org  Mon Nov 14 17:30:43 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 14 Nov 2011 16:30:43 +0000
Subject: [issue13391] string.strip Does Not Remove Zero-Width-Space (ZWSP)
In-Reply-To: <1321145122.08.0.463222804165.issue13391@psf.upfronthosting.co.za>
Message-ID: <1321288243.47.0.0134334996595.issue13391@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

I think those shouldn't be considered whitespace, so they shouldn't be stripped either.
Even if _PyUnicode_IsWhitespace doesn't match exactly the Unicode definition of White_Space, they both agree that ZWSP and ZWNBSP are not whitespace.  ZWNBSP is also used as BOM, and its usage as a zero-width space has been deprecated in favor of WORD JOINER (U+2060).  Similarly WJ is not considered a whitespace.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13391>
_______________________________________

From report at bugs.python.org  Mon Nov 14 17:39:42 2011
From: report at bugs.python.org (Dave Mankoff)
Date: Mon, 14 Nov 2011 16:39:42 +0000
Subject: [issue13391] string.strip Does Not Remove Zero-Width-Space (ZWSP)
In-Reply-To: <1321145122.08.0.463222804165.issue13391@psf.upfronthosting.co.za>
Message-ID: <1321288782.21.0.988984351527.issue13391@psf.upfronthosting.co.za>


Dave Mankoff <mankyd at gmail.com> added the comment:

But why are they not a space? I mean, they literally have the word space in their name and are used as separators between words. I can't really see any reason why you wouldn't want this behavior - there's not time when I would be thankful that strip removed all spaces except for ZWSP and the likes.

As to deprecation, yes, that is true, but they still exist and will continue to do so. (My issue arose when a 3rd party delivered an all whitespace string to me.)

I can't really debate this further as there's not much more to say. I hope the issue will be reconsidered. Thanks again for taking the time to discuss.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13391>
_______________________________________

From report at bugs.python.org  Mon Nov 14 17:44:04 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 14 Nov 2011 16:44:04 +0000
Subject: [issue5819] Add PYTHONPREFIXES environment variable
In-Reply-To: <1240475142.53.0.423262271042.issue5819@psf.upfronthosting.co.za>
Message-ID: <1321289044.4.0.939371285996.issue5819@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

See also #1298835 and PEP 405.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5819>
_______________________________________

From report at bugs.python.org  Mon Nov 14 17:47:16 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 14 Nov 2011 16:47:16 +0000
Subject: [issue1298835] Add a vendor-packages directory for system-supplied
	modules
Message-ID: <1321289236.88.0.73982795024.issue1298835@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> not all OSes have vendors
I realized that because French is my native language, I interpret ?vendor? as ?seller? (the meaning of ?vendeur?), but I think that in English it just means ?distributor? and has no relation with selling.  vendor-packages is arguably better that system-packages, as system can actually mean a lot of things.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1298835>
_______________________________________

From report at bugs.python.org  Mon Nov 14 17:50:37 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 14 Nov 2011 16:50:37 +0000
Subject: [issue13402] Document absoluteness of sys.executable
Message-ID: <1321289437.84.0.982753479785.issue13402@psf.upfronthosting.co.za>


New submission from ?ric Araujo <merwok at netwok.org>:

I wanted to know if sys.executable was always an absolute path but the doc does not talk about that.

(My use case is that I?d like to reload a process and I wonder if I can call os.execve or if I need to use os.execvpe.)

----------
assignee: docs at python
components: Documentation
messages: 147609
nosy: docs at python, eric.araujo
priority: normal
severity: normal
status: open
title: Document absoluteness of sys.executable
versions: Python 2.7, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13402>
_______________________________________

From report at bugs.python.org  Mon Nov 14 17:53:03 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 14 Nov 2011 16:53:03 +0000
Subject: [issue13388] document hg commit hooks in the devguide
In-Reply-To: <1321123590.65.0.736191202752.issue13388@psf.upfronthosting.co.za>
Message-ID: <1321289583.65.0.157411180222.issue13388@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

+1 to most of the patch, except one piece of wording: ?commit message hooks?.  This does not occur in the Mercurial documentation or help, and is misleading (commits happen on your maching, the hooks run on the server).  I?d just use ?hooks? or ?Mercurial hooks?.

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13388>
_______________________________________

From report at bugs.python.org  Mon Nov 14 17:57:14 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 14 Nov 2011 16:57:14 +0000
Subject: [issue12629] HTMLParser silently stops parsing with malformed
	attributes
In-Reply-To: <1311532507.83.0.00235537878353.issue12629@psf.upfronthosting.co.za>
Message-ID: <E1RPzqA-0006YA-J5@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 3c3009f63700 by Ezio Melotti in branch '2.7':
#1745761, #755670, #13357, #12629, #1200313: improve attribute handling in HTMLParser.
http://hg.python.org/cpython/rev/3c3009f63700

New changeset 16ed15ff0d7c by Ezio Melotti in branch '3.2':
#1745761, #755670, #13357, #12629, #1200313: improve attribute handling in HTMLParser.
http://hg.python.org/cpython/rev/16ed15ff0d7c

New changeset 426f7a2b1826 by Ezio Melotti in branch 'default':
#1745761, #755670, #13357, #12629, #1200313: merge with 3.2.
http://hg.python.org/cpython/rev/426f7a2b1826

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12629>
_______________________________________

From report at bugs.python.org  Mon Nov 14 17:57:14 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 14 Nov 2011 16:57:14 +0000
Subject: [issue755670] improve HTMLParser attribute processing regexps
Message-ID: <E1RPzqA-0006YA-Ix@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 3c3009f63700 by Ezio Melotti in branch '2.7':
#1745761, #755670, #13357, #12629, #1200313: improve attribute handling in HTMLParser.
http://hg.python.org/cpython/rev/3c3009f63700

New changeset 16ed15ff0d7c by Ezio Melotti in branch '3.2':
#1745761, #755670, #13357, #12629, #1200313: improve attribute handling in HTMLParser.
http://hg.python.org/cpython/rev/16ed15ff0d7c

New changeset 426f7a2b1826 by Ezio Melotti in branch 'default':
#1745761, #755670, #13357, #12629, #1200313: merge with 3.2.
http://hg.python.org/cpython/rev/426f7a2b1826

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue755670>
_______________________________________

From report at bugs.python.org  Mon Nov 14 17:57:15 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 14 Nov 2011 16:57:15 +0000
Subject: [issue1745761] Bad attributes/data handling in SGMLib
Message-ID: <E1RPzqA-0006YA-JA@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 3c3009f63700 by Ezio Melotti in branch '2.7':
#1745761, #755670, #13357, #12629, #1200313: improve attribute handling in HTMLParser.
http://hg.python.org/cpython/rev/3c3009f63700

New changeset 16ed15ff0d7c by Ezio Melotti in branch '3.2':
#1745761, #755670, #13357, #12629, #1200313: improve attribute handling in HTMLParser.
http://hg.python.org/cpython/rev/16ed15ff0d7c

New changeset 426f7a2b1826 by Ezio Melotti in branch 'default':
#1745761, #755670, #13357, #12629, #1200313: merge with 3.2.
http://hg.python.org/cpython/rev/426f7a2b1826

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1745761>
_______________________________________

From report at bugs.python.org  Mon Nov 14 17:57:15 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 14 Nov 2011 16:57:15 +0000
Subject: [issue1200313] HTMLParser fails to handle charref in attribute value
Message-ID: <E1RPzqA-0006YA-JK@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 3c3009f63700 by Ezio Melotti in branch '2.7':
#1745761, #755670, #13357, #12629, #1200313: improve attribute handling in HTMLParser.
http://hg.python.org/cpython/rev/3c3009f63700

New changeset 16ed15ff0d7c by Ezio Melotti in branch '3.2':
#1745761, #755670, #13357, #12629, #1200313: improve attribute handling in HTMLParser.
http://hg.python.org/cpython/rev/16ed15ff0d7c

New changeset 426f7a2b1826 by Ezio Melotti in branch 'default':
#1745761, #755670, #13357, #12629, #1200313: merge with 3.2.
http://hg.python.org/cpython/rev/426f7a2b1826

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1200313>
_______________________________________

From report at bugs.python.org  Mon Nov 14 17:57:16 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 14 Nov 2011 16:57:16 +0000
Subject: [issue13357] HTMLParser parses attributes incorrectly.
In-Reply-To: <1320606546.64.0.752508532419.issue13357@psf.upfronthosting.co.za>
Message-ID: <E1RPzqA-0006YA-JF@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 3c3009f63700 by Ezio Melotti in branch '2.7':
#1745761, #755670, #13357, #12629, #1200313: improve attribute handling in HTMLParser.
http://hg.python.org/cpython/rev/3c3009f63700

New changeset 16ed15ff0d7c by Ezio Melotti in branch '3.2':
#1745761, #755670, #13357, #12629, #1200313: improve attribute handling in HTMLParser.
http://hg.python.org/cpython/rev/16ed15ff0d7c

New changeset 426f7a2b1826 by Ezio Melotti in branch 'default':
#1745761, #755670, #13357, #12629, #1200313: merge with 3.2.
http://hg.python.org/cpython/rev/426f7a2b1826

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13357>
_______________________________________

From report at bugs.python.org  Mon Nov 14 17:58:11 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 14 Nov 2011 16:58:11 +0000
Subject: [issue13249] argparse.ArgumentParser() lists arguments in the wrong
	order
In-Reply-To: <1319394759.74.0.692830705102.issue13249@psf.upfronthosting.co.za>
Message-ID: <1321289891.78.0.333370554336.issue13249@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I would not use a note directive.  Notes and warnings distract and sometimes scare readers.  For a simple coding recommendation like this, I think a regular paragraph would suffice.  To make sure it?s not lost after pages of options description, maybe it could be put right after the signature?  Also, it would be nice to explicit the why of this recommendation (e.g. ?due to the number of arguments, it is recommended to always use keyword arguments for this function?).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13249>
_______________________________________

From report at bugs.python.org  Mon Nov 14 17:59:42 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 14 Nov 2011 16:59:42 +0000
Subject: [issue11836] multiprocessing.queues.SimpleQueue is undocumented
In-Reply-To: <1302623785.46.0.16009713021.issue11836@psf.upfronthosting.co.za>
Message-ID: <1321289982.83.0.348342831466.issue11836@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Well, the sentinels argument, right now, is meant to be used internally. I don't think it's a good thing to document it, since I don't think it's a very clean API (I know, I introduced it :-)) - it's just so that concurrent.futures can detect dead processes.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11836>
_______________________________________

From report at bugs.python.org  Mon Nov 14 18:01:58 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 14 Nov 2011 17:01:58 +0000
Subject: [issue1745761] Bad attributes/data handling in SGMLib
Message-ID: <1321290118.45.0.572095829279.issue1745761@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Fixed, thanks for the report!

----------
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed
versions: +Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1745761>
_______________________________________

From report at bugs.python.org  Mon Nov 14 18:07:52 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 14 Nov 2011 17:07:52 +0000
Subject: [issue755670] improve HTMLParser attribute processing regexps
Message-ID: <1321290472.77.0.0716113957939.issue755670@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Fixed, thanks for the report!

----------
dependencies:  -allow HTMLParser to continue after a parse error
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed
versions: +Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue755670>
_______________________________________

From report at bugs.python.org  Mon Nov 14 18:12:08 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 14 Nov 2011 17:12:08 +0000
Subject: [issue12629] HTMLParser silently stops parsing with malformed
	attributes
In-Reply-To: <1311532507.83.0.00235537878353.issue12629@psf.upfronthosting.co.za>
Message-ID: <1321290728.24.0.545149592099.issue12629@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Fixed, thanks for the report!
Apparently the correct way to parse <y z=""o"" /> is:
starttag y
attribute z with value ""
attribute o"" with no value
So this is what HTMLParser does now.

----------
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed
versions: +Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12629>
_______________________________________

From report at bugs.python.org  Mon Nov 14 18:16:53 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 14 Nov 2011 17:16:53 +0000
Subject: [issue1200313] HTMLParser fails to handle charref in attribute value
Message-ID: <1321291013.89.0.103798729193.issue1200313@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

There was actually a bug with entities in unquoted attribute values. I fixed it and added tests for all the cases (quoted and unquoted).

----------
versions: +Python 2.7, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1200313>
_______________________________________

From report at bugs.python.org  Mon Nov 14 18:29:27 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 14 Nov 2011 17:29:27 +0000
Subject: [issue13403] Option for XMLPRC Server to support HTTPS
Message-ID: <1321291767.37.0.486686259371.issue13403@psf.upfronthosting.co.za>


New submission from Raymond Hettinger <raymond.hettinger at gmail.com>:

The xmlrpc.client module supports secure transport using https; however, the xmlrpc.server does not have an https option.

Adding this support isn't difficult.  Here's an example of how to it could be implemented:  http://code.activestate.com/recipes/496786-simple-xml-rpc-server-over-https/

----------
components: Library (Lib)
messages: 147622
nosy: rhettinger
priority: normal
severity: normal
status: open
title: Option for XMLPRC Server to support HTTPS
type: feature request
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13403>
_______________________________________

From report at bugs.python.org  Mon Nov 14 18:33:42 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 14 Nov 2011 17:33:42 +0000
Subject: [issue13404] Add support for system.methodSignature() to XMLRPC Server
Message-ID: <1321292022.85.0.26720578121.issue13404@psf.upfronthosting.co.za>


New submission from Raymond Hettinger <raymond.hettinger at gmail.com>:

Currently, the server has a stub method that returns: 'signatures not supported'.

Using the inspect module, it shouldn't be difficult to provide function/method signatures for over-the-wire introspection.

----------
components: Library (Lib)
messages: 147623
nosy: rhettinger
priority: normal
severity: normal
status: open
title: Add support for system.methodSignature() to XMLRPC Server
type: feature request
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13404>
_______________________________________

From report at bugs.python.org  Mon Nov 14 18:47:49 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 14 Nov 2011 17:47:49 +0000
Subject: [issue13396] new method random.getrandbytes()
In-Reply-To: <1321202621.61.0.74333018382.issue13396@psf.upfronthosting.co.za>
Message-ID: <1321292869.42.0.409199446607.issue13396@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
priority: normal -> low

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13396>
_______________________________________

From report at bugs.python.org  Mon Nov 14 18:59:05 2011
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 14 Nov 2011 17:59:05 +0000
Subject: [issue2775] Implement PEP 3108
In-Reply-To: <1210097469.77.0.880435072777.issue2775@psf.upfronthosting.co.za>
Message-ID: <1321293545.72.0.31351673612.issue2775@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Just so people know, if the profile situation isn't resolved by 3.3 I'm considering PEP 3108 done.

IOW, if anyone wants to step forward and deal with cProfile/profile, that would be appreciated. =)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2775>
_______________________________________

From report at bugs.python.org  Mon Nov 14 19:01:53 2011
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 14 Nov 2011 18:01:53 +0000
Subject: [issue2377] Replace __import__ w/ importlib.__import__
In-Reply-To: <1205808012.99.0.46136974085.issue2377@psf.upfronthosting.co.za>
Message-ID: <1321293713.62.0.338765041448.issue2377@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Just some notes on the branch:

The FAILING file contains tests known to fail. There is a comment explaining the failure and possible fixes. If something makes it here and stays for a while it probably means upstream changes are needed (eg. test_pydoc needs ImportError to grow an attribute as to what import failed).

Python/pythonrun.c contains XXX markers of what is left to be done (although currently the zipimport comment is out-of-date and there needs to be one for exposing some APIs created in importlib.__init__). If you are looking for something to do, just search for XXX and try to tackle one of the comments.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2377>
_______________________________________

From report at bugs.python.org  Mon Nov 14 19:18:05 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 14 Nov 2011 18:18:05 +0000
Subject: [issue6397] Implementing Solaris "/dev/poll" in the "select" module
In-Reply-To: <1246466955.08.0.134631976531.issue6397@psf.upfronthosting.co.za>
Message-ID: <E1RQ16P-0006Yz-A3@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 8f7ab4bf7ad9 by Jesus Cea in branch 'default':
Issue #6397: Support '/dev/poll' polling objects in select module, under Solaris & derivatives.
http://hg.python.org/cpython/rev/8f7ab4bf7ad9

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6397>
_______________________________________

From report at bugs.python.org  Mon Nov 14 19:18:54 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Mon, 14 Nov 2011 18:18:54 +0000
Subject: [issue6397] Implementing Solaris "/dev/poll" in the "select" module
In-Reply-To: <1246466955.08.0.134631976531.issue6397@psf.upfronthosting.co.za>
Message-ID: <1321294734.84.0.608609012155.issue6397@psf.upfronthosting.co.za>


Changes by Jes?s Cea Avi?n <jcea at jcea.es>:


----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6397>
_______________________________________

From report at bugs.python.org  Mon Nov 14 20:42:06 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Mon, 14 Nov 2011 19:42:06 +0000
Subject: [issue13405] Add DTrace probes
Message-ID: <1321299726.66.0.343368151185.issue13405@psf.upfronthosting.co.za>


New submission from Jes?s Cea Avi?n <jcea at jcea.es>:

I want this to 3.3. I will concentrate in DTrace under Solaris and derivatives, for now. No SystemTap.

Original details, useful for context: issue4111.

My reference is going to be Solaris/OpenIndiana patches for Python DTrace support.

----------
assignee: jcea
components: Interpreter Core
messages: 147627
nosy: jcea
priority: normal
severity: normal
status: open
title: Add DTrace probes
type: feature request
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13405>
_______________________________________

From report at bugs.python.org  Mon Nov 14 20:43:12 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Mon, 14 Nov 2011 19:43:12 +0000
Subject: [issue13405] Add DTrace probes
In-Reply-To: <1321299726.66.0.343368151185.issue13405@psf.upfronthosting.co.za>
Message-ID: <1321299792.15.0.901775804699.issue13405@psf.upfronthosting.co.za>


Changes by Jes?s Cea Avi?n <jcea at jcea.es>:


----------
dependencies: +Add Systemtap/DTrace probes

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13405>
_______________________________________

From report at bugs.python.org  Mon Nov 14 20:49:28 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 14 Nov 2011 19:49:28 +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: <E1RQ2Wk-00076D-BB@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 555871844962 by Victor Stinner in branch '2.7':
Issue #7732: Try to fix the a failing test on Windows
http://hg.python.org/cpython/rev/555871844962

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7732>
_______________________________________

From report at bugs.python.org  Mon Nov 14 20:50:20 2011
From: report at bugs.python.org (sbt)
Date: Mon, 14 Nov 2011 19:50:20 +0000
Subject: [issue11836] multiprocessing.queues.SimpleQueue is undocumented
In-Reply-To: <1302623785.46.0.16009713021.issue11836@psf.upfronthosting.co.za>
Message-ID: <1321300220.35.0.384210185231.issue11836@psf.upfronthosting.co.za>


sbt <shibturn at gmail.com> added the comment:

> Well, the sentinels argument, right now, is meant to be used 
> internally. I don't think it's a good thing to document it, 
> since I don't think it's a very clean API (I know, I introduced 
> it :-))

Wouldn't a better alternative be to have a wait function which can deal with readable pipe connections and integer handles?

On Unix this would just delegate to select().

On Windows it could work as follows:
* initiate an overlapped read on each connection
* call WaitForMultipleObjects()
* cancel each overlapped read
* continue any read which succeeded but only gave a partial message
* store read messages on associated connection objects

I did start on such a patch.  It worked, but I did not get round to writing tests for it...

----------
nosy: +sbt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11836>
_______________________________________

From report at bugs.python.org  Mon Nov 14 20:51:22 2011
From: report at bugs.python.org (Eric Snow)
Date: Mon, 14 Nov 2011 19:51:22 +0000
Subject: [issue13386] Document documentation conventions for optional args
In-Reply-To: <1321078121.18.0.541430257552.issue13386@psf.upfronthosting.co.za>
Message-ID: <1321300282.25.0.688847778889.issue13386@psf.upfronthosting.co.za>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

>> 4) she got annoyed that two completely different notations where used 
>> for two very close concepts
>
> This is a good point, and we are trying to move to the arg=default
> notation.  Unfortunately there are still places that use the old
> notation.  C functions that have optional arguments but don't accept
> keyword arguments are a bit unusual, and IIUC in most of the cases
> that's an implementation detail that could be removed.

So would it be worth the effort to identify each such place in the built-ins/stdlib and eventually change them all?  I've seen support for doing so in other tracker issues and think it's a good idea personally.

----------
nosy: +eric.snow

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13386>
_______________________________________

From report at bugs.python.org  Mon Nov 14 20:56:55 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Mon, 14 Nov 2011 19:56:55 +0000
Subject: [issue4111] Add Systemtap/DTrace probes
In-Reply-To: <1223827695.04.0.0893695004368.issue4111@psf.upfronthosting.co.za>
Message-ID: <1321300615.51.0.542722700137.issue4111@psf.upfronthosting.co.za>


Changes by Jes?s Cea Avi?n <jcea at jcea.es>:


----------
resolution:  -> out of date
status: open -> closed
superseder:  -> Add DTrace probes

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4111>
_______________________________________

From report at bugs.python.org  Mon Nov 14 21:06:10 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Mon, 14 Nov 2011 20:06:10 +0000
Subject: [issue13405] Add DTrace probes
In-Reply-To: <1321299726.66.0.343368151185.issue13405@psf.upfronthosting.co.za>
Message-ID: <1321301170.84.0.717218916712.issue13405@psf.upfronthosting.co.za>


Changes by Jes?s Cea Avi?n <jcea at jcea.es>:


----------
hgrepos: +90

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13405>
_______________________________________

From report at bugs.python.org  Mon Nov 14 21:44:01 2011
From: report at bugs.python.org (Roy Smith)
Date: Mon, 14 Nov 2011 20:44:01 +0000
Subject: [issue13249] argparse.ArgumentParser() lists arguments in the wrong
	order
In-Reply-To: <1319394759.74.0.692830705102.issue13249@psf.upfronthosting.co.za>
Message-ID: <1321303441.98.0.46290300458.issue13249@psf.upfronthosting.co.za>


Roy Smith <roy at panix.com> added the comment:

Before I build another patch, would you be OK with leaving it as a note, but adding the "due to the number of arguments" language?  There's a lot of text here, and people tend to just zoom in on the bits and pieces they need right now.  I think there is value in making this stand out as a note.

If you feel strongly this should not be a note, let me know and I'll change it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13249>
_______________________________________

From report at bugs.python.org  Mon Nov 14 21:53:37 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 14 Nov 2011 20:53:37 +0000
Subject: [issue11836] multiprocessing.queues.SimpleQueue is undocumented
In-Reply-To: <1321300220.35.0.384210185231.issue11836@psf.upfronthosting.co.za>
Message-ID: <1321303727.3282.1.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Wouldn't a better alternative be to have a wait function which can
> deal with readable pipe connections and integer handles?
> 
> On Unix this would just delegate to select().
> 
> On Windows it could work as follows:
> * initiate an overlapped read on each connection
> * call WaitForMultipleObjects()
> * cancel each overlapped read
> * continue any read which succeeded but only gave a partial message
> * store read messages on associated connection objects

This sounds like a good direction to me.
(of course it must also preserve existing functionality;
test_concurrent_futures will check for that)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11836>
_______________________________________

From report at bugs.python.org  Mon Nov 14 21:53:38 2011
From: report at bugs.python.org (Eric Snow)
Date: Mon, 14 Nov 2011 20:53:38 +0000
Subject: [issue2775] Implement PEP 3108
In-Reply-To: <1210097469.77.0.880435072777.issue2775@psf.upfronthosting.co.za>
Message-ID: <1321304018.13.0.739022093524.issue2775@psf.upfronthosting.co.za>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

For the stat module in the "Obsolete" section[1], should the entry be updated to indicate that the module was left alone (see issue 2874)?

Would it be worth having the "Merging C and Python Impl..." section[2] include a reference to PEP 399?


[1] http://www.python.org/dev/peps/pep-3108/#obsolete
[2] http://www.python.org/dev/peps/pep-3108/#merging-c-and-python-implementations-of-the-same-interface

----------
nosy: +eric.snow

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2775>
_______________________________________

From report at bugs.python.org  Mon Nov 14 21:55:36 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 14 Nov 2011 20:55:36 +0000
Subject: [issue13405] Add DTrace probes
In-Reply-To: <1321299726.66.0.343368151185.issue13405@psf.upfronthosting.co.za>
Message-ID: <1321304136.95.0.678333301319.issue13405@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +Garen, belopolsky, chrismiles, danchr, dhduvall, dmalcolm, fche, glyph, hazmat, jbaker, laca, mjw, movement, neologix, pitrou, rhettinger, robert.kern, ronaldoussoren, serverhorror, sirg3, twleung, wsanchez

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13405>
_______________________________________

From report at bugs.python.org  Mon Nov 14 22:33:07 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 14 Nov 2011 21:33:07 +0000
Subject: [issue13391] string.strip Does Not Remove Zero-Width-Space (ZWSP)
In-Reply-To: <1321145122.08.0.463222804165.issue13391@psf.upfronthosting.co.za>
Message-ID: <1321306387.0.0.638362418668.issue13391@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> But why are they not a space?

Because the Unicode standard says they are not. We have a good tradition in Python to follow standards where they apply, and it appears that the Unicode standard is crystal clear that the characters in question are *not* white space. Why should we second-guess the Unicode consortium when discussing Unicode questions? See also

http://en.wikipedia.org/wiki/Whitespace_character

IOW: get the Unicode consortium to declare them as whitespace, and we happily follow.

Ezio: I do think that _PyUnicode_IsWhitespace should use the White_Space property (from PropList.txt). I'm not quite sure how they computed that property (or whether it's manually curated). Since that's a behavioral change, it can only go into 3.3.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13391>
_______________________________________

From report at bugs.python.org  Mon Nov 14 22:33:26 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 14 Nov 2011 21:33:26 +0000
Subject: [issue13333] utf-7 inconsistent with surrogates
In-Reply-To: <1320322427.22.0.464090396955.issue13333@psf.upfronthosting.co.za>
Message-ID: <1321306406.85.0.189203327675.issue13333@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Here is a patch.

----------
keywords: +patch
stage:  -> patch review
Added file: http://bugs.python.org/file23686/utf7.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13333>
_______________________________________

From report at bugs.python.org  Tue Nov 15 00:00:21 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 14 Nov 2011 23:00:21 +0000
Subject: [issue13404] Add support for system.methodSignature() to XMLRPC Server
In-Reply-To: <1321292022.85.0.26720578121.issue13404@psf.upfronthosting.co.za>
Message-ID: <1321311621.64.0.398241850935.issue13404@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +flox, loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13404>
_______________________________________

From report at bugs.python.org  Tue Nov 15 00:01:34 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 14 Nov 2011 23:01:34 +0000
Subject: [issue13401] test_argparse fails with root permissions
In-Reply-To: <1321284011.15.0.976219743674.issue13401@psf.upfronthosting.co.za>
Message-ID: <1321311694.01.0.456367778669.issue13401@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13401>
_______________________________________

From report at bugs.python.org  Tue Nov 15 00:02:08 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 14 Nov 2011 23:02:08 +0000
Subject: [issue13393] Improve BufferedReader.read1()
In-Reply-To: <1321157701.74.0.443809978111.issue13393@psf.upfronthosting.co.za>
Message-ID: <1321311728.26.0.68141389559.issue13393@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +neologix, sbt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13393>
_______________________________________

From report at bugs.python.org  Tue Nov 15 00:10:39 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 14 Nov 2011 23:10:39 +0000
Subject: [issue13389] Clear lists and dicts freelist in gc.collect()
In-Reply-To: <1321139834.96.0.0231630453756.issue13389@psf.upfronthosting.co.za>
Message-ID: <E1RQ5fU-0001Ws-SI@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 910986542a75 by Antoine Pitrou in branch 'default':
Issue #13389: Full garbage collection passes now clear the freelists for
http://hg.python.org/cpython/rev/910986542a75

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13389>
_______________________________________

From report at bugs.python.org  Tue Nov 15 00:12:00 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 14 Nov 2011 23:12:00 +0000
Subject: [issue13406] Deprecation warnings when running the test suite
Message-ID: <1321312320.0.0.525763918067.issue13406@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

Now that the unicode-internal codec is deprecated, the test suite spouts some warning (in test_codecs, test_codeccallbacks and test_unicode). Example:

[344/361] test_codecs
/home/antoine/cpython/default/Lib/test/test_codecs.py:1024: DeprecationWarning: unicode_internal codecs has been deprecated
  self.assertEqual(uni, internal.decode("unicode_internal"))
/home/antoine/cpython/default/Lib/unittest/case.py:135: DeprecationWarning: unicode_internal codecs has been deprecated
  callable_obj(*args, **kwargs)
/home/antoine/cpython/default/Lib/test/test_codecs.py:1047: DeprecationWarning: unicode_internal codecs has been deprecated
  ab = "ab".encode("unicode_internal").decode()
/home/antoine/cpython/default/Lib/test/test_codecs.py:1050: DeprecationWarning: unicode_internal codecs has been deprecated
  "UnicodeInternalTest")
/home/antoine/cpython/default/Lib/test/test_codecs.py:1034: DeprecationWarning: unicode_internal codecs has been deprecated
  b"\x00\x00\x00\x00\x00\x11\x11\x00".decode("unicode_internal")
/home/antoine/cpython/default/Lib/test/test_codecs.py:1056: DeprecationWarning: unicode_internal codecs has been deprecated
  self.assertEqual(encoder("a")[1], 1)
/home/antoine/cpython/default/Lib/test/test_codecs.py:1057: DeprecationWarning: unicode_internal codecs has been deprecated
  self.assertEqual(encoder("\xe9\u0142")[1], 2)
/home/antoine/cpython/default/Lib/test/test_codecs.py:1515: DeprecationWarning: unicode_internal codecs has been deprecated
  (b, size) = codecs.getencoder(encoding)(s)
/home/antoine/cpython/default/Lib/test/test_codecs.py:1517: DeprecationWarning: unicode_internal codecs has been deprecated
  (chars, size) = codecs.getdecoder(encoding)(b)

----------
components: Tests
keywords: easy
messages: 147637
nosy: ezio.melotti, haypo, pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: Deprecation warnings when running the test suite
type: behavior
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13406>
_______________________________________

From report at bugs.python.org  Tue Nov 15 00:12:18 2011
From: report at bugs.python.org (=?utf-8?q?Francisco_Mart=C3=ADn_Brugu=C3=A9?=)
Date: Mon, 14 Nov 2011 23:12:18 +0000
Subject: [issue12659] Add tests for packaging.tests.support
In-Reply-To: <1312033884.07.0.964621452644.issue12659@psf.upfronthosting.co.za>
Message-ID: <1321312338.76.0.736985405333.issue12659@psf.upfronthosting.co.za>


Francisco Mart?n Brugu? <francismb at email.de> added the comment:

Hi ?ric,
I've mutated test_support.py a bit and now passes in https://bitbucket.org/tarek/distutils2 changeset:6c3d67ed3adb.

I've added runTest to Tester, used os.unlink also removed the test fake_dec test as in support.py from distutils2 version is not present.

Best regards,

Francis

----------
Added file: http://bugs.python.org/file23687/test_support_v1.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12659>
_______________________________________

From report at bugs.python.org  Tue Nov 15 00:14:09 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 14 Nov 2011 23:14:09 +0000
Subject: [issue13389] Clear lists and dicts freelist in gc.collect()
In-Reply-To: <1321139834.96.0.0231630453756.issue13389@psf.upfronthosting.co.za>
Message-ID: <1321312449.76.0.559662798912.issue13389@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/issue13389>
_______________________________________

From report at bugs.python.org  Tue Nov 15 00:26:29 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 14 Nov 2011 23:26:29 +0000
Subject: [issue13333] utf-7 inconsistent with surrogates
In-Reply-To: <1320322427.22.0.464090396955.issue13333@psf.upfronthosting.co.za>
Message-ID: <1321313189.41.0.128207798922.issue13333@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Can you please regenerate the patch against default's head?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13333>
_______________________________________

From report at bugs.python.org  Tue Nov 15 00:29:37 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 14 Nov 2011 23:29:37 +0000
Subject: [issue13333] utf-7 inconsistent with surrogates
In-Reply-To: <1320322427.22.0.464090396955.issue13333@psf.upfronthosting.co.za>
Message-ID: <1321313377.55.0.440998517099.issue13333@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

It's a patch for 3.2.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13333>
_______________________________________

From report at bugs.python.org  Tue Nov 15 00:30:29 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 14 Nov 2011 23:30:29 +0000
Subject: [issue13404] Add support for system.methodSignature() to XMLRPC Server
In-Reply-To: <1321292022.85.0.26720578121.issue13404@psf.upfronthosting.co.za>
Message-ID: <1321313429.38.0.988169029646.issue13404@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

How do you infer the data types for the parameters?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13404>
_______________________________________

From report at bugs.python.org  Tue Nov 15 00:32:18 2011
From: report at bugs.python.org (Dave Mankoff)
Date: Mon, 14 Nov 2011 23:32:18 +0000
Subject: [issue13391] string.strip Does Not Remove Zero-Width-Space (ZWSP)
In-Reply-To: <1321145122.08.0.463222804165.issue13391@psf.upfronthosting.co.za>
Message-ID: <1321313538.46.0.801341205797.issue13391@psf.upfronthosting.co.za>


Dave Mankoff <mankyd at gmail.com> added the comment:

So I contacted the Unicode Technical Committee about the issue and received a promptly received a response back. They pointed that the ZWSP was, once upon a time considered white space but that was changed in Unicode 4.0.1

http://www.unicode.org/review/resolved-pri.html#pri21

One particular comment worth noting: "... for historical reasons the general category is still Zs (Space Separator)".

Perhaps this ticket can be changed to a feature request? In addition to stripping out whitespace, it is useful to remove any non-printable characters from a string (or know if a string contains any non-printable characters).

Perhaps a boolean keyword parameter, "control_chars" could be added to isspace and strip? Thus:

>>> u' \t\r\n\u200B'.isspace(control_chars=True)
True

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13391>
_______________________________________

From report at bugs.python.org  Tue Nov 15 00:32:58 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 14 Nov 2011 23:32:58 +0000
Subject: [issue13333] utf-7 inconsistent with surrogates
In-Reply-To: <1320322427.22.0.464090396955.issue13333@psf.upfronthosting.co.za>
Message-ID: <1321313578.54.0.976523501322.issue13333@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Please don't use git-style diffs then, since otherwise the review can't figure out what the patch applies to (and neither could I figure that out).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13333>
_______________________________________

From report at bugs.python.org  Tue Nov 15 00:40:02 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 14 Nov 2011 23:40:02 +0000
Subject: [issue13391] string.strip Does Not Remove Zero-Width-Space (ZWSP)
In-Reply-To: <1321145122.08.0.463222804165.issue13391@psf.upfronthosting.co.za>
Message-ID: <1321314002.99.0.546734848083.issue13391@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Making it a feature request would procedurally be ok. However, I'd immediately refuse that as feature creep. Use regular expressions for more advanced stripping than what the .strip method provides.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13391>
_______________________________________

From report at bugs.python.org  Tue Nov 15 00:41:47 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 14 Nov 2011 23:41:47 +0000
Subject: [issue13391] string.strip Does Not Remove Zero-Width-Space (ZWSP)
In-Reply-To: <1321145122.08.0.463222804165.issue13391@psf.upfronthosting.co.za>
Message-ID: <1321314107.79.0.556836565025.issue13391@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

I would also object to the feature creep.

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13391>
_______________________________________

From report at bugs.python.org  Tue Nov 15 00:42:41 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 14 Nov 2011 23:42:41 +0000
Subject: [issue13333] utf-7 inconsistent with surrogates
In-Reply-To: <1320322427.22.0.464090396955.issue13333@psf.upfronthosting.co.za>
Message-ID: <1321314161.1.0.726215293402.issue13333@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Here is a non-git diff then :)

----------
Added file: http://bugs.python.org/file23688/utf7-nogit.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13333>
_______________________________________

From report at bugs.python.org  Tue Nov 15 01:16:37 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Tue, 15 Nov 2011 00:16:37 +0000
Subject: [issue13333] utf-7 inconsistent with surrogates
In-Reply-To: <1320322427.22.0.464090396955.issue13333@psf.upfronthosting.co.za>
Message-ID: <1321316197.18.0.445391914779.issue13333@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

LGTM.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13333>
_______________________________________

From report at bugs.python.org  Tue Nov 15 01:22:25 2011
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Tue, 15 Nov 2011 00:22:25 +0000
Subject: [issue4147] xml.dom.minidom toprettyxml: omit whitespace for
	text-only elements
In-Reply-To: <1224430404.43.0.0672391440841.issue4147@psf.upfronthosting.co.za>
Message-ID: <1321316545.71.0.317217185713.issue4147@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/issue4147>
_______________________________________

From report at bugs.python.org  Tue Nov 15 01:55:07 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 15 Nov 2011 00:55:07 +0000
Subject: [issue13333] utf-7 inconsistent with surrogates
In-Reply-To: <1320322427.22.0.464090396955.issue13333@psf.upfronthosting.co.za>
Message-ID: <E1RQ7Id-00017J-C8@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset ddfcb0de564f by Antoine Pitrou in branch '3.2':
Issue #13333: The UTF-7 decoder now accepts lone surrogates
http://hg.python.org/cpython/rev/ddfcb0de564f

New changeset 250091e60f28 by Antoine Pitrou in branch 'default':
Issue #13333: The UTF-7 decoder now accepts lone surrogates
http://hg.python.org/cpython/rev/250091e60f28

New changeset 050772822bde by Antoine Pitrou in branch '2.7':
Issue #13333: The UTF-7 decoder now accepts lone surrogates
http://hg.python.org/cpython/rev/050772822bde

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13333>
_______________________________________

From report at bugs.python.org  Tue Nov 15 01:58:42 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 15 Nov 2011 00:58:42 +0000
Subject: [issue13333] utf-7 inconsistent with surrogates
In-Reply-To: <1320322427.22.0.464090396955.issue13333@psf.upfronthosting.co.za>
Message-ID: <1321318722.19.0.513170544877.issue13333@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I made a little fix to the patch for wide unicode builds and then committed it. Thank you!

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13333>
_______________________________________

From report at bugs.python.org  Tue Nov 15 02:34:20 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 15 Nov 2011 01:34:20 +0000
Subject: [issue1298835] Add a vendor-packages directory for system-supplied
	modules
Message-ID: <1321320860.74.0.550878295092.issue1298835@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

In English also, to vend is to sell, direct from Fr. *vendre*. However, ideas are not necessarily sold for money, but for assent, adoption, or other action. My dictionary has 'publish' as a secondary meaning of vend. So 'vendor-packages' is fine within the common metaphorical meaning of selling ideas. And it rolls off the tongue better than 'publisher-packages' or 'distributor-packages'.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1298835>
_______________________________________

From report at bugs.python.org  Tue Nov 15 02:45:06 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 15 Nov 2011 01:45:06 +0000
Subject: [issue13249] argparse.ArgumentParser() lists arguments in the wrong
	order
In-Reply-To: <1319394759.74.0.692830705102.issue13249@psf.upfronthosting.co.za>
Message-ID: <1321321506.0.0.795015431997.issue13249@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I agree with Eric both as to placement (first paragraph) and wording (with explanation). I don't have time to review otherwise at the moment.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13249>
_______________________________________

From report at bugs.python.org  Tue Nov 15 04:20:09 2011
From: report at bugs.python.org (Meador Inge)
Date: Tue, 15 Nov 2011 03:20:09 +0000
Subject: [issue13380] ctypes: add an internal function for reseting the ctypes
	caches
In-Reply-To: <1320902561.22.0.487865927239.issue13380@psf.upfronthosting.co.za>
Message-ID: <1321327209.06.0.0780855163317.issue13380@psf.upfronthosting.co.za>


Meador Inge <meadori at gmail.com> added the comment:

> - you duplicated the part with "CFUNCTYPE(c_int)(lambda: None)" without 
> removing the original chunk of code
> - some platforms can't compile ctypes, you must handle that case in 
> regrtest

Both fixed.  Thanks for the review.  Second patch attached.

----------
Added file: http://bugs.python.org/file23689/ctypes-reset-cache-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13380>
_______________________________________

From report at bugs.python.org  Tue Nov 15 05:11:56 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Tue, 15 Nov 2011 04:11:56 +0000
Subject: [issue13405] Add DTrace probes
In-Reply-To: <1321299726.66.0.343368151185.issue13405@psf.upfronthosting.co.za>
Message-ID: <1321330316.86.0.0249104974932.issue13405@psf.upfronthosting.co.za>


Changes by Jes?s Cea Avi?n <jcea at jcea.es>:


----------
keywords: +patch
Added file: http://bugs.python.org/file23690/05fde8943685.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13405>
_______________________________________

From report at bugs.python.org  Tue Nov 15 05:17:50 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Tue, 15 Nov 2011 04:17:50 +0000
Subject: [issue13405] Add DTrace probes
In-Reply-To: <1321299726.66.0.343368151185.issue13405@psf.upfronthosting.co.za>
Message-ID: <1321330670.22.0.413485695901.issue13405@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

Based on work done by skip.montanaro for issue4111.

05fde8943685.diff compiles correctly under Solaris 10 & derivatives, both in 32 and 64 bits.

I am working on 2.7 because I consider this feature important enough for providing a patch against 2.7, available to interested users. Of course, the plan is to integrate in 3.3 natively.

Currently the patch define two probes: function__entry and function__return. Both have three parameters: source code file, function and linenumber.

The code doesn't work under MacOS, I guess, and I can't help there.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13405>
_______________________________________

From report at bugs.python.org  Tue Nov 15 05:31:16 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Tue, 15 Nov 2011 04:31:16 +0000
Subject: [issue13405] Add DTrace probes
In-Reply-To: <1321299726.66.0.343368151185.issue13405@psf.upfronthosting.co.za>
Message-ID: <1321331476.22.0.824509287634.issue13405@psf.upfronthosting.co.za>


Changes by Jes?s Cea Avi?n <jcea at jcea.es>:


Added file: http://bugs.python.org/file23691/1563b5a70362.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13405>
_______________________________________

From report at bugs.python.org  Tue Nov 15 06:07:40 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Tue, 15 Nov 2011 05:07:40 +0000
Subject: [issue13386] Document documentation conventions for optional args
In-Reply-To: <1321078121.18.0.541430257552.issue13386@psf.upfronthosting.co.za>
Message-ID: <1321333660.49.0.964004049538.issue13386@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

""So would it be worth the effort to identify each such place in the built-ins/stdlib and eventually change them all?  I've seen support for doing so in other tracker issues and think it's a good idea personally.""

Probably, if this will bring some added value in addition to being easier to document.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13386>
_______________________________________

From report at bugs.python.org  Tue Nov 15 08:40:17 2011
From: report at bugs.python.org (anatoly techtonik)
Date: Tue, 15 Nov 2011 07:40:17 +0000
Subject: [issue4147] xml.dom.minidom toprettyxml: omit whitespace for
	text-only elements
In-Reply-To: <1224430404.43.0.0672391440841.issue4147@psf.upfronthosting.co.za>
Message-ID: <1321342817.75.0.759190127054.issue4147@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

I would revert this patch (leaving several test cases though) until a proper fix is available.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4147>
_______________________________________

From report at bugs.python.org  Tue Nov 15 09:11:39 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Tue, 15 Nov 2011 08:11:39 +0000
Subject: [issue13390] Hunt memory allocations in addition to reference leaks
In-Reply-To: <1321140269.61.0.335726830367.issue13390@psf.upfronthosting.co.za>
Message-ID: <1321344699.51.0.923120188191.issue13390@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

> Together with -R, it can help chase those memory leaks which aren't 
> reference leaks (see c6dafa2e2594).

Valgrind does a much better job at this: it will also show you where the leaked blocks were allocated.
OTOH, Valgrind is Linux-only and slow, but since I haven't used the '-R' option much, I don't know how usable this will be in practice (detecting memory leaks is one thing, identifying them is even better :-).

----------
nosy: +neologix

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13390>
_______________________________________

From report at bugs.python.org  Tue Nov 15 09:26:09 2011
From: report at bugs.python.org (xhantu)
Date: Tue, 15 Nov 2011 08:26:09 +0000
Subject: [issue7503] multiprocessing AuthenticationError "digest sent was
	rejected" when pickling proxy
In-Reply-To: <1260777234.55.0.247151929734.issue7503@psf.upfronthosting.co.za>
Message-ID: <1321345569.4.0.530613055413.issue7503@psf.upfronthosting.co.za>


xhantu <pwojke at rz-online.de> added the comment:

Confirmed for Python 2.7.1 on Ubuntu.

Problematic are the __reduce__ methods of multiprocessing.process.AuthenticationString and multiprocessing.managers.BaseProxy. Pickling of an authkey in BaseProxy is only done and allowed when Popen.thread_is_spawning() is True. The comments state this is done because of security reasons.

If you pass proxies with multiprocessing after process initialization then no authkey is available after unpickle, a random authkey will be used with results in an digest error. Because of this fallback in case no authkey is available, using None as authkey didn't work in my case.

This bug looks like a design flaw of multiprocessing. If security was really a concern, encryption should be used along with authentication for communication. And passing None as authkey should disable authentication as stated in the documentation and should not use a random authkey.

Disabling the Popen.thread_is_spawning() checks allows passing of proxies. I have done this during runtime by replacing the __reduce__ methods of the affected classes to avoid patching the installed python.

----------
nosy: +xhantu

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7503>
_______________________________________

From report at bugs.python.org  Tue Nov 15 09:27:41 2011
From: report at bugs.python.org (xhantu)
Date: Tue, 15 Nov 2011 08:27:41 +0000
Subject: [issue7503] multiprocessing AuthenticationError "digest sent was
	rejected" when pickling proxy
In-Reply-To: <1260777234.55.0.247151929734.issue7503@psf.upfronthosting.co.za>
Message-ID: <1321345661.19.0.403731751933.issue7503@psf.upfronthosting.co.za>


xhantu <pwojke at rz-online.de> added the comment:

forgot to set version in classification

----------
versions: +Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7503>
_______________________________________

From report at bugs.python.org  Tue Nov 15 09:40:13 2011
From: report at bugs.python.org (R. David Murray)
Date: Tue, 15 Nov 2011 08:40:13 +0000
Subject: [issue4147] xml.dom.minidom toprettyxml: omit whitespace for
	text-only elements
In-Reply-To: <1224430404.43.0.0672391440841.issue4147@psf.upfronthosting.co.za>
Message-ID: <1321346413.27.0.738070011821.issue4147@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Yeah, I just haven't found time to do the revert yet (my first naive attempt using hg commands failed and I haven't found time to figure it out or do the reverse-patch method).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4147>
_______________________________________

From report at bugs.python.org  Tue Nov 15 09:41:45 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 15 Nov 2011 08:41:45 +0000
Subject: [issue4147] xml.dom.minidom toprettyxml: omit whitespace for
	text-only elements
In-Reply-To: <1224430404.43.0.0672391440841.issue4147@psf.upfronthosting.co.za>
Message-ID: <1321346505.88.0.546455393755.issue4147@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
assignee:  -> ezio.melotti
nosy: +benjamin.peterson, georg.brandl
priority: normal -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4147>
_______________________________________

From report at bugs.python.org  Tue Nov 15 10:03:28 2011
From: report at bugs.python.org (=?utf-8?q?Maciej_Blizi=C5=84ski?=)
Date: Tue, 15 Nov 2011 09:03:28 +0000
Subject: [issue13398] _cursesmodule does not build,
	doesn't find Python.h on Solaris
In-Reply-To: <1321226216.89.0.228790993845.issue13398@psf.upfronthosting.co.za>
Message-ID: <1321347808.63.0.922017997279.issue13398@psf.upfronthosting.co.za>


Maciej Blizi?ski <maciej.blizinski at gmail.com> added the comment:

I haven't tried building with GCC, Python has always been built with Sun Studio at OpenCSW.  I've got very similar build files for Python 2.6, 2.7, 3.0, and 3.1 -- none of them have this problem, so this is a regression in 3.2.

What diff would you like to see? The problem manifests itself with pristine Python sources, no patches are needed to reproduce it.

When the modules are built, how normally get the -I flags are set so that the modules can find the Python.h file?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13398>
_______________________________________

From report at bugs.python.org  Tue Nov 15 10:23:27 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 15 Nov 2011 09:23:27 +0000
Subject: [issue13390] Hunt memory allocations in addition to reference leaks
In-Reply-To: <1321140269.61.0.335726830367.issue13390@psf.upfronthosting.co.za>
Message-ID: <1321349007.73.0.445073774631.issue13390@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

This will likely be a decent "you have a problem" indicator, but you may still need tools like Valgrind to actually track down the *cause* of that problem.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13390>
_______________________________________

From report at bugs.python.org  Tue Nov 15 11:05:53 2011
From: report at bugs.python.org (Peter Funk)
Date: Tue, 15 Nov 2011 10:05:53 +0000
Subject: [issue4147] xml.dom.minidom toprettyxml: omit whitespace for
	text-only elements
In-Reply-To: <1224430404.43.0.0672391440841.issue4147@psf.upfronthosting.co.za>
Message-ID: <1321351553.15.0.814996413875.issue4147@psf.upfronthosting.co.za>


Changes by Peter Funk <pefu at users.sourceforge.net>:


----------
nosy: +pefu

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4147>
_______________________________________

From report at bugs.python.org  Tue Nov 15 11:21:33 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 15 Nov 2011 10:21:33 +0000
Subject: [issue4147] xml.dom.minidom toprettyxml: omit whitespace for
	text-only elements
In-Reply-To: <1224430404.43.0.0672391440841.issue4147@psf.upfronthosting.co.za>
Message-ID: <1321352493.31.0.122616592798.issue4147@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Here is a new patch based on Dan's last patch.
Correct me if I'm wrong, but it seems to me that it's not possible for a node to have only text-nodes as children and yet have more than one child; i.e. you can't have two or more adjacent text nodes, because they would be considered as a single text node.  I therefore changed the check with all() to check if there's only a child and if it's a text node.
I also added a test that checks where the \n and \t are added, because testing only that the DOM is preserved is not enough.

----------
stage: test needed -> commit review
Added file: http://bugs.python.org/file23692/issue4147.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4147>
_______________________________________

From report at bugs.python.org  Tue Nov 15 11:29:21 2011
From: report at bugs.python.org (sengels)
Date: Tue, 15 Nov 2011 10:29:21 +0000
Subject: [issue13407] tarfile.getmembers misses members again
Message-ID: <1321352961.33.0.0944615995053.issue13407@psf.upfronthosting.co.za>


New submission from sengels <ps_ml at gmx.de>:

This bug seems to be related to http://bugs.python.org/issue13158

When I try to run the following code:

import tarfile

tf = tarfile.open("kdelibs-4.7.3.tar.bz2", "r")
print(len(tf.getnames()))

against this tarball: http://www.winkde.org/pub/kde/ports/win32/repository/other/kdelibs-4.7.3.tar.bz2 it will output 150 members. This is not enough and other tools like 7zip or bsdtar report a lot more (should be around 9237).

----------
messages: 147663
nosy: sengels
priority: normal
severity: normal
status: open
title: tarfile.getmembers misses members again
versions: Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13407>
_______________________________________

From report at bugs.python.org  Tue Nov 15 11:30:19 2011
From: report at bugs.python.org (sengels)
Date: Tue, 15 Nov 2011 10:30:19 +0000
Subject: [issue13407] tarfile.getnames misses members again
In-Reply-To: <1321352961.33.0.0944615995053.issue13407@psf.upfronthosting.co.za>
Message-ID: <1321353019.81.0.17628748283.issue13407@psf.upfronthosting.co.za>


Changes by sengels <ps_ml at gmx.de>:


----------
title: tarfile.getmembers misses members again -> tarfile.getnames misses members again

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13407>
_______________________________________

From report at bugs.python.org  Tue Nov 15 13:24:28 2011
From: report at bugs.python.org (sbt)
Date: Tue, 15 Nov 2011 12:24:28 +0000
Subject: [issue13322] buffered read() and write() does not raise
	BlockingIOError
In-Reply-To: <1320246535.71.0.465783773129.issue13322@psf.upfronthosting.co.za>
Message-ID: <1321359868.2.0.101061021337.issue13322@psf.upfronthosting.co.za>


sbt <shibturn at gmail.com> added the comment:

Here is an updated patch which uses the real errno.

It also gets rid of the restore_pos argument of _bufferedwriter_flush_unlocked() which is always set to false -- 
I guess buffered_flush_and_rewind_unlocked() is used instead.

----------
Added file: http://bugs.python.org/file23693/write_blockingioerror.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13322>
_______________________________________

From report at bugs.python.org  Tue Nov 15 14:02:27 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 15 Nov 2011 13:02:27 +0000
Subject: [issue13408] Rename packaging.resources back to datafiles
Message-ID: <1321362147.83.0.710071986655.issue13408@psf.upfronthosting.co.za>


New submission from ?ric Araujo <merwok at netwok.org>:

The code dealing with the new resources subsystem used to be called datafiles (module distutils2.datafiles, file dist-info/DATAFILES, etc.).  I believe it is a better name and we should use it again:

- it would make clear that it?s an evolution of distutils? data_files
- it would make clear that it?s related to install_data and data_files

?resources? is overly vague and ambiguous.  It can refer to natural resources, computer resources, links to more information, etc.  ?data files? is less vague and less abstract: it refers to files that are not modules, scripts or C files.

----------
assignee: tarek
components: Distutils2
messages: 147665
nosy: alexis, eric.araujo, tarek
priority: normal
severity: normal
status: open
title: Rename packaging.resources back to datafiles
versions: 3rd party, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13408>
_______________________________________

From report at bugs.python.org  Tue Nov 15 14:06:56 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 15 Nov 2011 13:06:56 +0000
Subject: [issue6501] Fatal error on startup with invalid PYTHONIOENCODING
In-Reply-To: <1247826105.17.0.941734297485.issue6501@psf.upfronthosting.co.za>
Message-ID: <1321362416.69.0.507136691814.issue6501@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> Currently different environment variables are treated differently.  For example,
> mistakes in PYTHONHOME and PYTHONIOENCODING cause fatal error while an error in
> PYTHONSTARTUP is reported but does not terminate python:

If PYTHONSTARTUP is the only envvar with non-fatal errors, I think it?s okay.  PYTHONHOME contains vital information, PYTHONIOENCODING is set by the programmer/admin and their code probably depends on it, but PYTHONSTARTUP is just niceties for the interactive interpreter, so non-vital IMO.

----------
nosy: +eric.araujo
versions: +Python 2.7, Python 3.3 -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6501>
_______________________________________

From report at bugs.python.org  Tue Nov 15 14:40:42 2011
From: report at bugs.python.org (Baptiste Carvello)
Date: Tue, 15 Nov 2011 13:40:42 +0000
Subject: [issue13386] Document documentation conventions for optional args
In-Reply-To: <1321300282.25.0.688847778889.issue13386@psf.upfronthosting.co.za>
Message-ID: <4EC26BD0.7050004@baptiste-carvello.net>


Baptiste Carvello <devel at baptiste-carvello.net> added the comment:

Le 14/11/2011 20:51, Eric Snow a ?crit :
> 
> So would it be worth the effort to identify each such place in the built-ins/stdlib and eventually change them all?  I've seen support for doing so in other tracker issues and think it's a good idea personally.
> 

I ran a few grep searches from the root of a recent hg tip:

1) grep -n -r --include=*.py --include=*.c --exclude="topics.py" -E
'.+\(.*\[[[:space:]]*,.*\].*\)' .

This looks for variants of "function(args [, opt])". There were 231
hits, I caught no false positives.

2) grep -n -r --include=*.py --include=*.c --exclude="topics.py" -E
'.+\(.*\[.*,[[:space:]]*\].*\)' .

As this pattern is valid Python syntax, I got mostly false positives,
but also a few interesting cases such as "range([start,] stop[, step])"
or "islice(seq, [start,] stop [, step])"

I'm afraid those last examples cannot be described with valid Python syntax.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13386>
_______________________________________

From report at bugs.python.org  Tue Nov 15 14:52:53 2011
From: report at bugs.python.org (lasizoillo)
Date: Tue, 15 Nov 2011 13:52:53 +0000
Subject: [issue13405] Add DTrace probes
In-Reply-To: <1321299726.66.0.343368151185.issue13405@psf.upfronthosting.co.za>
Message-ID: <1321365173.62.0.359573581129.issue13405@psf.upfronthosting.co.za>


Changes by lasizoillo <lasizoillo at gmail.com>:


----------
nosy: +lasizoillo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13405>
_______________________________________

From report at bugs.python.org  Tue Nov 15 15:01:02 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 15 Nov 2011 14:01:02 +0000
Subject: [issue13386] Document documentation conventions for optional args
In-Reply-To: <1321078121.18.0.541430257552.issue13386@psf.upfronthosting.co.za>
Message-ID: <1321365662.73.0.290122962966.issue13386@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

>>> C functions that have optional arguments but don't accept keyword arguments are a bit unusual,
>>> and IIUC in most of the cases that's an implementation detail that could be removed.
>> So would it be worth the effort to identify each such place in the built-ins/stdlib and
>> eventually change them all?  I've seen support for doing so in other tracker issues and think
>> it's a good idea personally.
Me too.  (Can you give the #ids of these other issues?)

> Probably, if this will bring some added value in addition to being easier to document.
I think we should fix C functions to accept kwargs for the sake of Python programmers, not merely to ease documentation (that would just be a nice side-effect :)


> a few interesting cases such as "range([start,] stop[, step])"or "islice(seq, [start,] stop [, step])"
> I'm afraid those last examples cannot be described with valid Python syntax.
Sphinx lets us give multiple signatures.  I?ve just checked that this markup is valid and does not create duplicate index entries

  .. function:: range(stop)
                range(start, stop)
                range(start, stop, step)

:)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13386>
_______________________________________

From report at bugs.python.org  Tue Nov 15 15:06:16 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 15 Nov 2011 14:06:16 +0000
Subject: [issue12659] Add tests for packaging.tests.support
In-Reply-To: <1312033884.07.0.964621452644.issue12659@psf.upfronthosting.co.za>
Message-ID: <E1RQJeC-0000fe-FT@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 659bf2a679d2 by ?ric Araujo in branch 'default':
Add tests for tests.support (#12659), thanks to Francisco Mart?n Brugu?
http://hg.python.org/distutils2/rev/659bf2a679d2

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12659>
_______________________________________

From report at bugs.python.org  Tue Nov 15 15:15:32 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 15 Nov 2011 14:15:32 +0000
Subject: [issue13386] Document documentation conventions for optional args
In-Reply-To: <1321078121.18.0.541430257552.issue13386@psf.upfronthosting.co.za>
Message-ID: <1321366532.24.0.684001648462.issue13386@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

> Me too.  (Can you give the #ids of these other issues?)

See for example #13012.

> I think we should fix C functions to accept kwargs for the sake of 
> Python programmers, not merely to ease documentation (that would just 
> be a nice side-effect :)

And also for compatibility for other implementations like PyPy.  I'm still not sure that is a good idea to do a mass conversion of all the functions though.

> Sphinx lets us give multiple signatures.  I?ve just checked that this 
> markup is valid and does not create duplicate index entries

This is something I was considering, but I'm afraid it might get too verbose (and introduce yet another convention).  Sometimes this feature is also (mis?)used to group similar functions.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13386>
_______________________________________

From report at bugs.python.org  Tue Nov 15 15:20:54 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 15 Nov 2011 14:20:54 +0000
Subject: [issue13386] Document documentation conventions for optional args
In-Reply-To: <1321078121.18.0.541430257552.issue13386@psf.upfronthosting.co.za>
Message-ID: <1321366854.08.0.0957593955417.issue13386@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

>> I think we should fix C functions to accept kwargs for the sake of Python programmers
> And also for compatibility for other implementations like PyPy.
Good point.

> I'm still not sure that is a good idea to do a mass conversion of all the functions though.
If there were only a handful of them it may be okay, but otherwise one issue per class or module sounds good.

>> Sphinx lets us give multiple signatures
> This is something I was considering, but I'm afraid it might get too verbose
I find my example for range much more readable that the current markup with brackets.

> (and introduce yet another convention).
I can live with this special case for the two or three functions that need it.  It becomes moot if range gets fixed to support kwargs :)

> Sometimes this feature is also (mis?)used to group similar functions.
IIUC it *is* the intended use case for the syntax, not a misuse: You tell Sphinx that you want link targets for these functions to end up here, and then you write doc.  See for example the os docs: this syntax allows for nice grouping.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13386>
_______________________________________

From report at bugs.python.org  Tue Nov 15 15:22:27 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 15 Nov 2011 14:22:27 +0000
Subject: [issue13390] Hunt memory allocations in addition to reference leaks
In-Reply-To: <1321344699.51.0.923120188191.issue13390@psf.upfronthosting.co.za>
Message-ID: <1321366652.3272.3.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Valgrind does a much better job at this: it will also show you where
> the leaked blocks were allocated.
> OTOH, Valgrind is Linux-only and slow, but since I haven't used the
> '-R' option much, I don't know how usable this will be in practice
> (detecting memory leaks is one thing, identifying them is even
> better :-).

Yes, Valgrind is much more exhaustive and precise, but you have to build
Python --with-valgrind, to find the correct options to pass to Valgrind,
and also to parse the output. For example, OpenSSL seems to cause lots
of errors such as:

==20599== Conditional jump or move depends on uninitialised value(s)
==20599==    at 0xA2BB0B3: BN_div (in /usr/lib64/libcrypto.so.1.0.0)
==20599==    by 0xA2C125E: BN_nnmod (in /usr/lib64/libcrypto.so.1.0.0)
==20599==    by 0xA2C15CD: BN_mod_mul (in /usr/lib64/libcrypto.so.1.0.0)
==20599==    by 0xA2C37F0: BN_BLINDING_convert_ex
(in /usr/lib64/libcrypto.so.1.0.0)
==20599==    by 0xA2E15D6: ??? (in /usr/lib64/libcrypto.so.1.0.0)
==20599==    by 0x9FE6363: ssl3_get_client_key_exchange
(in /usr/lib64/libssl.so.1.0.0)
==20599==    by 0x9FE83A7: ssl3_accept (in /usr/lib64/libssl.so.1.0.0)
==20599==    by 0xF804190: PySSL_SSLdo_handshake (_ssl.c:390)
==20599==    by 0x47C0E9: PyEval_EvalFrameEx (ceval.c:3985)
==20599==    by 0x47CAC3: PyEval_EvalCodeEx (ceval.c:3376)
==20599==    by 0x47B3F1: PyEval_EvalFrameEx (ceval.c:4099)
==20599==    by 0x47C1DB: PyEval_EvalFrameEx (ceval.c:4089)

Right now this patch will allow to enrich the daily refleak runs (those
that send an e-mail to python-checkins). If someone finds a way to
sanitize Valgrind output, a daily Valgrind run would be cool as well.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13390>
_______________________________________

From report at bugs.python.org  Tue Nov 15 15:23:19 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 15 Nov 2011 14:23:19 +0000
Subject: [issue12344] Add **kwargs to reinitialize_command
In-Reply-To: <1308190105.67.0.431736719114.issue12344@psf.upfronthosting.co.za>
Message-ID: <1321366999.08.0.115170265284.issue12344@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I?ve noticed that setuptools? Command class also allows keyword arguments in its constructor.  I?m not sure if it would be useful, but I?ve not looked in depth at the packaging codebase to see if there is code that could use that.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12344>
_______________________________________

From report at bugs.python.org  Tue Nov 15 15:26:38 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 15 Nov 2011 14:26:38 +0000
Subject: [issue12659] Add tests for packaging.tests.support
In-Reply-To: <1312033884.07.0.964621452644.issue12659@psf.upfronthosting.co.za>
Message-ID: <1321367198.77.0.455288242825.issue12659@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> I've added runTest to Tester
It turns out this was the only change needed.  Tarek?s repo on bitbucket is not up-to-date, I should have given you the hg.python.org link.  (You can edit .hg/hgrc in your repo and run ?hg pull -u? to get missing changesets.)

When you add more tests in packaging?s test_support, please add the runTest method too, so that both versions are synchronized.  Thanks!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12659>
_______________________________________

From report at bugs.python.org  Tue Nov 15 15:41:35 2011
From: report at bugs.python.org (=?utf-8?q?Lars_Gust=C3=A4bel?=)
Date: Tue, 15 Nov 2011 14:41:35 +0000
Subject: [issue13407] tarfile.getnames misses members again
In-Reply-To: <1321352961.33.0.0944615995053.issue13407@psf.upfronthosting.co.za>
Message-ID: <1321368095.75.0.812071544145.issue13407@psf.upfronthosting.co.za>


Lars Gust?bel <lars at gustaebel.de> added the comment:

Some testing reveals that the bz2 module < 3.3 cannot fully decompress the file in question. Only the first 900k are decompressed. Thus, this issue is not related to issue13158 or the tarfile module.

----------
nosy: +lars.gustaebel

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13407>
_______________________________________

From report at bugs.python.org  Tue Nov 15 15:45:26 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Tue, 15 Nov 2011 14:45:26 +0000
Subject: [issue13407] tarfile.getnames misses members again
In-Reply-To: <1321352961.33.0.0944615995053.issue13407@psf.upfronthosting.co.za>
Message-ID: <1321368326.06.0.185712646042.issue13407@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

Isn't this a duplicate of issue #1625?

----------
nosy: +neologix

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13407>
_______________________________________

From report at bugs.python.org  Tue Nov 15 15:47:16 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 15 Nov 2011 14:47:16 +0000
Subject: [issue1625] bz2.BZ2File doesn't support multiple streams
In-Reply-To: <1197624030.23.0.503522059328.issue1625@psf.upfronthosting.co.za>
Message-ID: <1321368436.43.0.425547452803.issue1625@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/issue1625>
_______________________________________

From report at bugs.python.org  Tue Nov 15 15:47:33 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Tue, 15 Nov 2011 14:47:33 +0000
Subject: [issue13398] _cursesmodule does not build,
	doesn't find Python.h on Solaris
In-Reply-To: <1321226216.89.0.228790993845.issue13398@psf.upfronthosting.co.za>
Message-ID: <1321368453.65.0.177664234776.issue13398@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

Can you add the missing library path in CFLAGS and LDFLAGS environment variables?.

Something like: (from a fresh source code)

./configure OPTIONS CFLAGS=-Ipath LDFLAGS=-Ipath

If that works, we can explore why the path is not detected automatically.

Do your path contains any unusual character, like spaces?

Tell me the exact "configure" line you are using.

Have you tried to build python 3.3? (unreleased yet, current development version)

The include directorios is defined in "Makefile", variable PY_CPPFLAGS. In my system, that is "-I. -I$(srcdir)/Include $(CONFIGURE_CPPFLAGS) $(CPPFLAGS". What is the value in your system? (after the configure step).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13398>
_______________________________________

From report at bugs.python.org  Tue Nov 15 15:48:50 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Tue, 15 Nov 2011 14:48:50 +0000
Subject: [issue13398] _cursesmodule does not build,
	doesn't find Python.h on Solaris
In-Reply-To: <1321226216.89.0.228790993845.issue13398@psf.upfronthosting.co.za>
Message-ID: <1321368530.92.0.326093505242.issue13398@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

BTW, is only curses building failing?. Is the rest of the code built correctly?. That would be a good hint.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13398>
_______________________________________

From report at bugs.python.org  Tue Nov 15 15:52:58 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 15 Nov 2011 14:52:58 +0000
Subject: [issue13398] _cursesmodule does not build,
	doesn't find Python.h on Solaris
In-Reply-To: <1321226216.89.0.228790993845.issue13398@psf.upfronthosting.co.za>
Message-ID: <1321368778.11.0.523345270127.issue13398@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

This module also fails to build on my Debian.  I had the libcursesw headers installed and one day it was not enough; installing libcurses headers fixes it.  I don?t know if it?s the same problem or something related to Debian multiarch.

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13398>
_______________________________________

From report at bugs.python.org  Tue Nov 15 16:07:44 2011
From: report at bugs.python.org (Dave Mankoff)
Date: Tue, 15 Nov 2011 15:07:44 +0000
Subject: [issue13391] string.strip Does Not Remove Zero-Width-Space (ZWSP)
In-Reply-To: <1321145122.08.0.463222804165.issue13391@psf.upfronthosting.co.za>
Message-ID: <1321369664.5.0.609093664254.issue13391@psf.upfronthosting.co.za>


Dave Mankoff <mankyd at gmail.com> added the comment:

"Use regular expressions for more advanced stripping than what the .strip method provides."

So I guess this brings me back to my original issue. I'm not looking for particularly advanced stripping. I just want to remove all whitespace and other non-printing characters. I personally can never think of a time when I wouldn't want this (especially with isspace). Maybe in some applications, the control characters are useful and shouldn't be stripped, but I would argue that _that_ is the more advanced use case for most people.

Thus strip and isspace are now unusable methods in Python for common use cases. This seems unfortunate.

I can understand the claims of feature creep. I even understand that having isspace compare itself against non-whitespace characters may seem counter-intuitive on its face. But certainly there must be a satisfactory remedy here.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13391>
_______________________________________

From report at bugs.python.org  Tue Nov 15 16:14:00 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 15 Nov 2011 15:14:00 +0000
Subject: [issue11254] distutils doesn't byte-compile .py files to __pycache__
	during installation
In-Reply-To: <1298195698.48.0.330644441328.issue11254@psf.upfronthosting.co.za>
Message-ID: <E1RQKho-0007mb-D0@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset c10946a17420 by ?ric Araujo in branch 'default':
Clean up byte-compilation code in packaging (#11254 followup).
http://hg.python.org/cpython/rev/c10946a17420

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11254>
_______________________________________

From report at bugs.python.org  Tue Nov 15 16:16:06 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 15 Nov 2011 15:16:06 +0000
Subject: [issue13322] buffered read() and write() does not raise
	BlockingIOError
In-Reply-To: <1320246535.71.0.465783773129.issue13322@psf.upfronthosting.co.za>
Message-ID: <1321370166.19.0.116737557308.issue13322@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Thanks again. Just a nit: the tests should be in MiscIOTest, since they don't directly instantiate the individual classes. Also, perhaps it would be nice to check that the exception's "errno" attribute is EAGAIN.

----------
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13322>
_______________________________________

From report at bugs.python.org  Tue Nov 15 16:19:29 2011
From: report at bugs.python.org (kxroberto)
Date: Tue, 15 Nov 2011 15:19:29 +0000
Subject: [issue1481032] patch smtplib:when SMTPDataError,
	rset crashes with sslerror
Message-ID: <1321370369.74.0.218774769156.issue1481032@psf.upfronthosting.co.za>


kxroberto <kxroberto at users.sourceforge.net> added the comment:

ping!
perhaps I forgot to write that I uploaded the cleaned patch also on 2010-08-23. I really think this simple patch is necessary. Just seen the same problem again - as I forgot the patch in one of my recent Python update installations.

When SMTPDataError, SMTPRecipientsRefused, SMTPSenderRefused should be raised, very likely a subsequent error (like closed connection etc.) overlappes the original Exception during self.rset(), and one will not be able to locate the problem on user level in eons ..

This patch is still in my vital-patches collection which I have to apply after every Python update since years.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1481032>
_______________________________________

From report at bugs.python.org  Tue Nov 15 16:24:26 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 15 Nov 2011 15:24:26 +0000
Subject: [issue13391] string.strip Does Not Remove Zero-Width-Space (ZWSP)
In-Reply-To: <1321145122.08.0.463222804165.issue13391@psf.upfronthosting.co.za>
Message-ID: <1321370666.08.0.718934922878.issue13391@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

> So I guess this brings me back to my original issue. I'm not looking 
> for particularly advanced stripping. I just want to remove all 
> whitespace and other non-printing characters.

.strip only strips whitespace.  Stripping non-printing characters and additional 'whitespace' is something that is too specific for a builtin method, especially because people might disagree on the characters that are considered whitespace and non-printing.

> Thus strip and isspace are now unusable methods in Python for common
> use cases. This seems unfortunate.

I believe they work fine for the common case -- in fact these methods have been around for years and no one complained.
Also Unicode has a number of more or less space-like characters that are not whitespace and whitespace chars that don't look like whitespace.
If one needs to strip a different set of (whitespace) chars, it's always possible to pass it to .strip or to define a new function like
def mystrip(s):
    return s.strip().strip(u'\u200B\ufeff')

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13391>
_______________________________________

From report at bugs.python.org  Tue Nov 15 16:39:47 2011
From: report at bugs.python.org (Dan Kenigsberg)
Date: Tue, 15 Nov 2011 15:39:47 +0000
Subject: [issue4147] xml.dom.minidom toprettyxml: omit whitespace for
	text-only elements
In-Reply-To: <1224430404.43.0.0672391440841.issue4147@psf.upfronthosting.co.za>
Message-ID: <1321371587.38.0.528679978741.issue4147@psf.upfronthosting.co.za>


Dan Kenigsberg <danken at redhat.com> added the comment:

Technically, adjacent Text nodes are not illegal, but preserving this oddity in pretty-print is impossible. It is perfectly fine to pretty-print only the simple case of len()==1.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4147>
_______________________________________

From report at bugs.python.org  Tue Nov 15 17:02:05 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 15 Nov 2011 16:02:05 +0000
Subject: [issue13238] Add shell command helpers to subprocess module
In-Reply-To: <1319176813.33.0.203455355645.issue13238@psf.upfronthosting.co.za>
Message-ID: <1321372925.45.0.639421145099.issue13238@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


Added file: http://bugs.python.org/file23694/b267e72c8c10.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13238>
_______________________________________

From report at bugs.python.org  Tue Nov 15 17:11:03 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 15 Nov 2011 16:11:03 +0000
Subject: [issue13238] Add shell command helpers to subprocess module
In-Reply-To: <1319176813.33.0.203455355645.issue13238@psf.upfronthosting.co.za>
Message-ID: <1321373463.47.0.234808535923.issue13238@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

>        def __init__(self, command, *, **callkwds):
Is the '*' marker needed?

>            self.callkwds = callkwds
These aren?t used in the module-level functions.  What is the use case?

If you forgive me for the nitpick, the docstrings have too much indenting.

> a "*.py" value interpolated with "{!u}" should indeed pick up all of those files,
> since the wildcard will be passed unmodified to the underlying shell
Great.

(This patch will also serve as a nice example of creating a string formatter.  I?ve seen the PyCon video about them, but I thought I was missing a piece since I didn?t see how you hook the format function to your custom formatter; it looks like the answer is that you don?t.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13238>
_______________________________________

From report at bugs.python.org  Tue Nov 15 17:47:43 2011
From: report at bugs.python.org (ipatrol)
Date: Tue, 15 Nov 2011 16:47:43 +0000
Subject: [issue10772] Several actions for argparse arguments missing from docs
In-Reply-To: <1293327184.11.0.454888760887.issue10772@psf.upfronthosting.co.za>
Message-ID: <1321375663.43.0.916956418058.issue10772@psf.upfronthosting.co.za>


ipatrol <ipatrol6010 at yahoo.com> added the comment:

The patch has been submitted, now we just need to apply it and update the online docs accordingly.

----------
status: open -> pending
versions: +Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10772>
_______________________________________

From report at bugs.python.org  Tue Nov 15 17:48:25 2011
From: report at bugs.python.org (Brian Curtin)
Date: Tue, 15 Nov 2011 16:48:25 +0000
Subject: [issue10772] Several actions for argparse arguments missing from docs
In-Reply-To: <1293327184.11.0.454888760887.issue10772@psf.upfronthosting.co.za>
Message-ID: <1321375705.55.0.177221485465.issue10772@psf.upfronthosting.co.za>


Changes by Brian Curtin <brian at python.org>:


----------
status: pending -> open
versions:  -Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10772>
_______________________________________

From report at bugs.python.org  Tue Nov 15 17:51:14 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 15 Nov 2011 16:51:14 +0000
Subject: [issue10772] Several actions for argparse arguments missing from docs
In-Reply-To: <1293327184.11.0.454888760887.issue10772@psf.upfronthosting.co.za>
Message-ID: <1321375874.25.0.774430387459.issue10772@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10772>
_______________________________________

From report at bugs.python.org  Tue Nov 15 17:58:25 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 15 Nov 2011 16:58:25 +0000
Subject: [issue10772] Several actions for argparse arguments missing from docs
In-Reply-To: <1293327184.11.0.454888760887.issue10772@psf.upfronthosting.co.za>
Message-ID: <1321376305.96.0.750364134533.issue10772@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Ezio made further comments, follow the ?review? link.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10772>
_______________________________________

From report at bugs.python.org  Tue Nov 15 18:03:34 2011
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 15 Nov 2011 17:03:34 +0000
Subject: [issue2775] Implement PEP 3108
In-Reply-To: <1210097469.77.0.880435072777.issue2775@psf.upfronthosting.co.za>
Message-ID: <1321376614.14.0.28561584423.issue2775@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Answers to Eric's questions: yes and yes, but I probably won't bother until I do a final update to the PEP.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2775>
_______________________________________

From report at bugs.python.org  Tue Nov 15 18:05:35 2011
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 15 Nov 2011 17:05:35 +0000
Subject: [issue13392] Writing a pyc file is not atomic under Windows
In-Reply-To: <1321147252.88.0.159545157159.issue13392@psf.upfronthosting.co.za>
Message-ID: <1321376735.92.0.332722247055.issue13392@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

I say go with the deletion for importlib. If the failure is a sign of success, then just go with it and not worry about the failure. __pycache__ guarantees that we are not losing out by clobbering some other Python version's pyc file.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13392>
_______________________________________

From report at bugs.python.org  Tue Nov 15 18:27:31 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 15 Nov 2011 17:27:31 +0000
Subject: [issue11805] package_data only allows one glob per-package
In-Reply-To: <1302301429.27.0.797210396018.issue11805@psf.upfronthosting.co.za>
Message-ID: <1321378051.04.0.391182679832.issue11805@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> Looking at sysconfig.cfg makes it all pretty clear, though it was hard to find this
> information a while ago.
Yeah, you had to be here when the resources code was committed, or to stumble on it while reading the source code.  It?s one of the big things I will document as part of #12779.

> So what exactly is the verdict then?  Keep package_data for now, but encourage resources,
> and dump data_files all together?  Or...?
The reverse: resources are the new way of installing data_files.  package_data is obsoleted by that system and removed.

> But as far as I can see, there's no way in packaging to describe a module that works like sysconfig
> itself! (A module with a resource which is expected to live alongside the .py file).
For bootstrapping reasons, sysconfig.cfg needs to be the one exception to the rule.  (Yes, I think about moving distutils.cfg and wininst-*.exe files according to sysconfig ?and pydoc data and venv shell scripts!  I will make sure we reach agreement on python-dev first, of course :)

The point is that it is not possible to have a data file living alongside the py file.  It is by design.  The new system caters to downstream packagers while trying not to be bothersome to Python authors.  Why do you care where your data file is installed, as long as your code can get it?

There is one argument against this system: It means that your code has a runtime dependency on a function provided by the packaging tool.  This is one of my griefs against setuptools.  The difference here is that the dist-info dir is an accepted PEP and packaging is in the stdlib, and that the dependency is minimal (it does not make you learn a parallel import system for example).  However, one drawback is that we expect and support a transition period where people have parallel setup.cfg and setup.py (with the setup.py possibly taking its info from setup.cfg), so adding support for d2 will not only require adding a setup.cfg and modularizing complex setup.py into hooks: it will require code editions to have code branches for database.get_file and __file__ + open.  That won?t look good.

> Installing the cfg file to {purelib} would work in practice, but if the distribution containing
> sysconfig was later changed to include a C extension, then the code would get silently switched to
> install into platlib, and the .cfg file would no longer be alongside the .py file.
> 
> (This is only actually the case when purebase and base differ - which never happens on Windows, and
> I don't really understand when it would happen on Unix. So I can't really say how likely and/or
> important this possibility is. But it's certainly there.)
There is a distinction between prefix and exec-prefix.  I think it may come from a time where you?d have one tree served for many machines by an NFS server and architecture-specific trees on a local filesystem.

> [...]
> OK, having said all that, I do think that saying "package_data was wrong, let?s move away from that"
> is a bit user-unfriendly. Whether it causes issues for OS distributors, or is "wrong" as a matter of
> principle, people do use it, a lot.
Because they had no alternative: you couldn?t predict where data_files would end up, so package_data + __file__ was the universal kludge.

> It's the basis of the whole egg concept (a package and its data as a single self-contained object)
distutils2 does not support the egg concept.  In a post-PEP 376 world, an installed distribution can be one or more modules with a dist-info directory, one or more packages with a dist-info directory, etc.

> If you don't support it, I predict that people are simply going to invent more and more elaborate
> hacks to emulate it.
Interesting.  I have to go now, but be sure I?ll think over this, bring it up on pydev and make sure the situation is acceptable before Py 3.3b1 / d2 1.0b1.

----------
assignee: tarek -> eric.araujo
keywords: +easy
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11805>
_______________________________________

From report at bugs.python.org  Tue Nov 15 19:04:28 2011
From: report at bugs.python.org (kxroberto)
Date: Tue, 15 Nov 2011 18:04:28 +0000
Subject: [issue1486713] HTMLParser : A auto-tolerant parsing mode
Message-ID: <1321380268.09.0.45069324035.issue1486713@psf.upfronthosting.co.za>


kxroberto <kxroberto at users.sourceforge.net> added the comment:

I looked at the new patch http://hg.python.org/lookup/r86952 for Py3 (regarding the extended tolerance and local backporting to Python2.7):

What I miss are the calls of a kind of self.warning(msg,i,k) function in non-strict/tolerant mode (where self.error is called in strict mode). Such function could be empty or could be a silent simple counter (like in the old patch) - and could be easily sub-classed for advanced use.
I often want at least the possibilty of a HTML error log - so the HTML author (sometimes its me myself) can be noticed to get it more strict on the long run ;-) ...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1486713>
_______________________________________

From report at bugs.python.org  Tue Nov 15 19:20:13 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 15 Nov 2011 18:20:13 +0000
Subject: [issue13392] Writing a pyc file is not atomic under Windows
In-Reply-To: <1321147252.88.0.159545157159.issue13392@psf.upfronthosting.co.za>
Message-ID: <E1RQNc1-0001bs-Ku@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset b75b41237380 by Antoine Pitrou in branch 'default':
Issue #13392: Writing a pyc file should now be atomic under Windows as well.
http://hg.python.org/cpython/rev/b75b41237380

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13392>
_______________________________________

From report at bugs.python.org  Tue Nov 15 19:21:20 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 15 Nov 2011 18:21:20 +0000
Subject: [issue13392] Writing a pyc file is not atomic under Windows
In-Reply-To: <1321147252.88.0.159545157159.issue13392@psf.upfronthosting.co.za>
Message-ID: <1321381280.95.0.682867493041.issue13392@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Ok, done. Let's see if that fixes the sporadic failures on the buildbots.

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13392>
_______________________________________

From report at bugs.python.org  Tue Nov 15 19:26:03 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 15 Nov 2011 18:26:03 +0000
Subject: [issue13380] ctypes: add an internal function for reseting the ctypes
	caches
In-Reply-To: <1320902561.22.0.487865927239.issue13380@psf.upfronthosting.co.za>
Message-ID: <1321381563.89.0.671383453823.issue13380@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

The patch looks good to me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13380>
_______________________________________

From report at bugs.python.org  Tue Nov 15 20:01:14 2011
From: report at bugs.python.org (=?utf-8?q?Micha=C5=82_Le=C5=9Bniewski?=)
Date: Tue, 15 Nov 2011 19:01:14 +0000
Subject: [issue13409] Invalid expression error if a regex ends with a backslash
Message-ID: <1321383674.07.0.558206383571.issue13409@psf.upfronthosting.co.za>


New submission from Micha? Le?niewski <mlesniew at gmail.com>:

If a regular expression ends with a backslash, an exception is raised. Of course, the backslash has to be escaped. The simplest example, that causes the error is a regular expression, that should match only a single backslash:

    import re
    r = re.compile("\\")

----------
components: Regular Expressions
messages: 147696
nosy: ezio.melotti, mlesniew
priority: normal
severity: normal
status: open
title: Invalid expression error if a regex ends with a backslash
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13409>
_______________________________________

From report at bugs.python.org  Tue Nov 15 20:16:18 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 15 Nov 2011 19:16:18 +0000
Subject: [issue13409] Invalid expression error if a regex ends with a backslash
In-Reply-To: <1321383674.07.0.558206383571.issue13409@psf.upfronthosting.co.za>
Message-ID: <1321384578.66.0.856430623812.issue13409@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

You either have to double escape it (once for python and then for the regex engine) or use raw strings:
>>> re.match("\\\\", '\\').group()
'\\'
>>> re.match(r"\\", '\\').group()
'\\'

----------
assignee:  -> ezio.melotti
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13409>
_______________________________________

From report at bugs.python.org  Tue Nov 15 20:23:33 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 15 Nov 2011 19:23:33 +0000
Subject: [issue1486713] HTMLParser : A auto-tolerant parsing mode
Message-ID: <1321385013.16.0.676984079713.issue1486713@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

The HTMLParser is not suitable for validation, even the strict mode allows some non valid markup (and it might be removed soon).
Also I don't think it's easy to call a self.warnings() without trying the strict mode first.  The tolerant parsing just allow more things, without making any distinction between valid and not.

----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1486713>
_______________________________________

From report at bugs.python.org  Tue Nov 15 20:27:12 2011
From: report at bugs.python.org (Paul Moore)
Date: Tue, 15 Nov 2011 19:27:12 +0000
Subject: [issue11805] package_data only allows one glob per-package
In-Reply-To: <1321378051.04.0.391182679832.issue11805@psf.upfronthosting.co.za>
Message-ID: <CACac1F-mPKkL=Q2YWKD=d2VXzzrWGNxZOC_04UE1khOXO0hfwg@mail.gmail.com>


Paul Moore <p.f.moore at gmail.com> added the comment:

One important point - in the "new world" where data files living
alongside code is unsupported, the bdist_msi and bdist_wininst
installers need to be updated to install data files as needed. This
may work already (I'll do some tests to see how well when I get back
to my PC with dev builds on it) but right now bdist_wininst for
example does not support the full generality of the resource mechanism
(and it's not clear to me how it can be made to...) so there will be
restrictions on what can be allowed until the wininst format is
updated.

For installs from source, the suggested "new world" is fine. But
without a binary install process that's as flexible as a source
install, the current "alongside the code" approach has the benefit of
working well with the existing installer technology.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11805>
_______________________________________

From report at bugs.python.org  Tue Nov 15 20:35:02 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 15 Nov 2011 19:35:02 +0000
Subject: [issue4442] document immutable type subclassing via __new__
In-Reply-To: <1227719282.37.0.890069433685.issue4442@psf.upfronthosting.co.za>
Message-ID: <1321385702.16.0.635450300151.issue4442@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
stage:  -> needs patch
versions: +Python 3.2, Python 3.3 -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4442>
_______________________________________

From report at bugs.python.org  Tue Nov 15 20:37:26 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 15 Nov 2011 19:37:26 +0000
Subject: [issue11990] redirected output - stdout writes newline as \n in
	windows
In-Reply-To: <1304458030.29.0.258748957891.issue11990@psf.upfronthosting.co.za>
Message-ID: <1321385846.29.0.983271022195.issue11990@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11990>
_______________________________________

From report at bugs.python.org  Tue Nov 15 20:41:49 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 15 Nov 2011 19:41:49 +0000
Subject: [issue964437] idle help is modal
Message-ID: <1321386109.59.0.988942859936.issue964437@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +terry.reedy
stage:  -> patch review
versions: +Python 3.3 -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue964437>
_______________________________________

From report at bugs.python.org  Tue Nov 15 20:48:04 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 15 Nov 2011 19:48:04 +0000
Subject: [issue13392] Writing a pyc file is not atomic under Windows
In-Reply-To: <1321147252.88.0.159545157159.issue13392@psf.upfronthosting.co.za>
Message-ID: <E1RQOz1-00028i-Qb@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 12940d9f8031 by Antoine Pitrou in branch 'default':
Fix regression under Windows following b75b41237380 (from issue #13392)
http://hg.python.org/cpython/rev/12940d9f8031

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13392>
_______________________________________

From report at bugs.python.org  Tue Nov 15 20:54:18 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 15 Nov 2011 19:54:18 +0000
Subject: [issue13297] xmlrpc.client could accept bytes for input and output
In-Reply-To: <1320018100.14.0.184941596185.issue13297@psf.upfronthosting.co.za>
Message-ID: <E1RQP4y-0002mW-P0@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 0175883d9513 by Florent Xicluna in branch 'default':
Closes #13297: use bytes type to send and receive binary data through XMLRPC.
http://hg.python.org/cpython/rev/0175883d9513

----------
nosy: +python-dev
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13297>
_______________________________________

From report at bugs.python.org  Tue Nov 15 20:57:50 2011
From: report at bugs.python.org (Brian Curtin)
Date: Tue, 15 Nov 2011 19:57:50 +0000
Subject: [issue10652] test___all_ + test_tcl fails (Windows installed binary)
In-Reply-To: <1291819198.8.0.493152862608.issue10652@psf.upfronthosting.co.za>
Message-ID: <1321387070.74.0.616034631241.issue10652@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/issue10652>
_______________________________________

From report at bugs.python.org  Tue Nov 15 21:03:00 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 15 Nov 2011 20:03:00 +0000
Subject: [issue11261] urlopen breaks when data parameter is used.
In-Reply-To: <1298239651.85.0.222287222979.issue11261@psf.upfronthosting.co.za>
Message-ID: <1321387380.33.0.919749200686.issue11261@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11261>
_______________________________________

From report at bugs.python.org  Tue Nov 15 21:07:02 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 15 Nov 2011 20:07:02 +0000
Subject: [issue4395] Document auto __ne__ generation;
	provide a use case for non-trivial __ne__
In-Reply-To: <1227464493.77.0.130820783094.issue4395@psf.upfronthosting.co.za>
Message-ID: <1321387622.98.0.47874545215.issue4395@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
versions: +Python 3.3 -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4395>
_______________________________________

From report at bugs.python.org  Tue Nov 15 21:32:04 2011
From: report at bugs.python.org (Florent Xicluna)
Date: Tue, 15 Nov 2011 20:32:04 +0000
Subject: [issue2979] use_builtin_types in xmlrpc.server
In-Reply-To: <1211846989.94.0.031553096454.issue2979@psf.upfronthosting.co.za>
Message-ID: <1321389124.52.0.597916584649.issue2979@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

Patch updated with documentation.

----------
nosy: +eric.araujo
stage: patch review -> commit review
Added file: http://bugs.python.org/file23695/issue2979_xmlrpc_server_v2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2979>
_______________________________________

From report at bugs.python.org  Tue Nov 15 21:40:07 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Tue, 15 Nov 2011 20:40:07 +0000
Subject: [issue13215] multiprocessing Manager.connect() aggressively retries
	refused connections
In-Reply-To: <1318965417.81.0.122561387998.issue13215@psf.upfronthosting.co.za>
Message-ID: <1321389607.75.0.392326544058.issue13215@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

Here's a patch removing the automatic retry on ECONNREFUSED: I tested it on Linux and other Unices, and it seems to work just fine without this hammering.
Note that there's a similar mechanism for Windows (ERROR_PIPE_BUSY), but it seems to be necessary there (test_multiprocessing blows up without this). Note that I'd rather only apply this to default (not 2.7 and 3.2), since this is more of a behavior change than a bug fix.

----------
keywords: +needs review, patch
stage:  -> patch review
versions: +Python 3.3 -Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13215>
_______________________________________

From report at bugs.python.org  Tue Nov 15 21:47:35 2011
From: report at bugs.python.org (Eric Snow)
Date: Tue, 15 Nov 2011 20:47:35 +0000
Subject: [issue13386] Document documentation conventions for optional args
In-Reply-To: <1321078121.18.0.541430257552.issue13386@psf.upfronthosting.co.za>
Message-ID: <1321390055.73.0.345969557376.issue13386@psf.upfronthosting.co.za>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

> Me too.  (Can you give the #ids of these other issues?)

#13012 is the one that I was thinking of (msg144328 specifically).  However, I'm sure there was one more recently (which I can't find now).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13386>
_______________________________________

From report at bugs.python.org  Tue Nov 15 21:48:02 2011
From: report at bugs.python.org (Eric Snow)
Date: Tue, 15 Nov 2011 20:48:02 +0000
Subject: [issue13386] Document documentation conventions for optional args
In-Reply-To: <1321078121.18.0.541430257552.issue13386@psf.upfronthosting.co.za>
Message-ID: <1321390082.33.0.539243911132.issue13386@psf.upfronthosting.co.za>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

@msg147671

+1

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13386>
_______________________________________

From report at bugs.python.org  Tue Nov 15 21:52:07 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Tue, 15 Nov 2011 20:52:07 +0000
Subject: [issue13405] Add DTrace probes
In-Reply-To: <1321299726.66.0.343368151185.issue13405@psf.upfronthosting.co.za>
Message-ID: <1321390327.35.0.320565968262.issue13405@psf.upfronthosting.co.za>


Changes by Jes?s Cea Avi?n <jcea at jcea.es>:


Added file: http://bugs.python.org/file23696/9fcca74ff413.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13405>
_______________________________________

From report at bugs.python.org  Tue Nov 15 21:56:14 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Tue, 15 Nov 2011 20:56:14 +0000
Subject: [issue13405] Add DTrace probes
In-Reply-To: <1321299726.66.0.343368151185.issue13405@psf.upfronthosting.co.za>
Message-ID: <1321390574.68.0.519681041723.issue13405@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

New changeset, with testsuite added.

Compile the code adding "--with-dtrace" to your "configure" command. After compiling, test the code with

"""
LD_LIBRARY_PATH=current_path
export LD_LIBRARY_PATH

./python Lib/test/regrtest.py -v test_dtrace.py

"""

It is currently working in Solaris 10, both in 32 and 64 bits.

If you are inside a Solaris/OpenIndiana Zone, the zone *MUST* have dtrace usermode permissions. If not, you can not use dtrace inside the zone and, then, the test will fail.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13405>
_______________________________________

From report at bugs.python.org  Tue Nov 15 22:12:08 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 15 Nov 2011 21:12:08 +0000
Subject: [issue13405] Add DTrace probes
In-Reply-To: <1321390574.68.0.519681041723.issue13405@psf.upfronthosting.co.za>
Message-ID: <1321391237.3272.14.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> LD_LIBRARY_PATH=current_path
> export LD_LIBRARY_PATH

Why do you need LD_LIBRARY_PATH?

> If you are inside a Solaris/OpenIndiana Zone, the zone *MUST* have
> dtrace usermode permissions. If not, you can not use dtrace inside the
> zone and, then, the test will fail.

If there aren't enough permissions, the tests should be skipped rather
than fail.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13405>
_______________________________________

From report at bugs.python.org  Tue Nov 15 22:12:46 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 15 Nov 2011 21:12:46 +0000
Subject: [issue13238] Add shell command helpers to subprocess module
In-Reply-To: <1319176813.33.0.203455355645.issue13238@psf.upfronthosting.co.za>
Message-ID: <1321391566.18.0.165927703284.issue13238@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

I like Nick's original idea for a handful of convenience functions but want to caution against adding a bunch of tools that start guessing at what you want.  Adding automatic wildcard expansion, shell quoting/splitting and whatnot can make the module more arcane and harder to learn and remember.  

Please adopt a conservation approach adding the minimal set that has been shown to be necessary.  We can take these tools away if they turn out to have been a bad idea.  It is much easier to add cruft than to take it away.   In the itertools module, a number of tools started their life as just a recipe in the docs and only became builtin after having proved their worth and having proved their API.

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13238>
_______________________________________

From report at bugs.python.org  Tue Nov 15 22:25:55 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 15 Nov 2011 21:25:55 +0000
Subject: [issue13374] Deprecate usage of the Windows ANSI API in the nt module
In-Reply-To: <1320797406.95.0.49629588961.issue13374@psf.upfronthosting.co.za>
Message-ID: <E1RQQVj-0003Zn-5D@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset d42811b93357 by Victor Stinner in branch 'default':
Issue #13374: The Windows bytes API has been deprecated in the os module. Use
http://hg.python.org/cpython/rev/d42811b93357

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13374>
_______________________________________

From report at bugs.python.org  Tue Nov 15 22:51:00 2011
From: report at bugs.python.org (Florent Xicluna)
Date: Tue, 15 Nov 2011 21:51:00 +0000
Subject: [issue13374] Deprecate usage of the Windows ANSI API in the nt module
In-Reply-To: <1320797406.95.0.49629588961.issue13374@psf.upfronthosting.co.za>
Message-ID: <1321393860.74.0.884118505968.issue13374@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

IIUC, it means that the library/application should not use the bytes API if it intends to be supported on major platforms.

----------
nosy: +flox

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13374>
_______________________________________

From report at bugs.python.org  Tue Nov 15 23:04:50 2011
From: report at bugs.python.org (Jayanth Raman)
Date: Tue, 15 Nov 2011 22:04:50 +0000
Subject: [issue13410] String formatting bug in interactive mode
Message-ID: <1321394690.57.0.254973831289.issue13410@psf.upfronthosting.co.za>


New submission from Jayanth Raman <raman.jayanth at gmail.com>:

With file xx.py:

class Foo(object):
    def __init__(self, x):
        self.x = x
    def __long__(self):
        return long(self.x)
    def __float__(self):
        return float(self.x)
y = Foo(22)
print '%d' % y
print '%d' % y


Interactive mode:

$ python -V
Python 2.6.7
$ python -i xx.py
22
22
>>>
TypeError: int() argument must be a string or a number, not 'Foo'
>>> '%d' % y
'22'
>>> '%d' % y
TypeError: int() argument must be a string or a number, not 'Foo'
>>> '%d' % y
'22'
>>> '%d' % y
TypeError: int() argument must be a string or a number, not 'Foo'

It alternates between printing '22' and print a TypeError message.  Expected it to be consistent.

Also, the first carraige-return (with no input) results in an error message.  Did not expect an error message.  In fact, typing pretty much anything (e.g. an undefined variable or raise(Exception())) results in the same error message.

On Mac OS X Darwin Kernel Version 10.8.0
Python 2.6.7 (r267:88850, Jul  6 2011, 13:57:37) 
[GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin

Thanks.

----------
assignee: ronaldoussoren
components: Macintosh
messages: 147711
nosy: jayanth, ronaldoussoren
priority: normal
severity: normal
status: open
title: String formatting bug in interactive mode
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13410>
_______________________________________

From report at bugs.python.org  Tue Nov 15 23:10:38 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Tue, 15 Nov 2011 22:10:38 +0000
Subject: [issue13391] string.strip Does Not Remove Zero-Width-Space (ZWSP)
In-Reply-To: <1321369664.5.0.609093664254.issue13391@psf.upfronthosting.co.za>
Message-ID: <4EC2E351.8040004@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> Thus strip and isspace are now unusable methods in Python for common use cases.

Please recognize that you haven't demonstrated this at all. U+200B is
*not* a character that is common, not even remotely. It's a rare,
infrequent, unused character. In addition, in the common use case
of string.strip (i.e. get rid of leading an trailing white space for
rendering purposes), keeping it causes no harm since it's zero-width.

If you disagree with the resolution of this issue, you will have to
write a PEP.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13391>
_______________________________________

From report at bugs.python.org  Tue Nov 15 23:14:37 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Tue, 15 Nov 2011 22:14:37 +0000
Subject: [issue13374] Deprecate usage of the Windows ANSI API in the nt module
In-Reply-To: <1321393860.74.0.884118505968.issue13374@psf.upfronthosting.co.za>
Message-ID: <4EC2E441.5080903@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> IIUC, it means that the library/application should not use the bytes API if it intends to be supported on major platforms.

I think you misunderstand; it does not literally mean that. Instead, it
means that the library/application either must not use the bytes API at
all, or else make use of it conditional on non-Windows systems (i.e.
special-case Windows).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13374>
_______________________________________

From report at bugs.python.org  Tue Nov 15 23:17:17 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 15 Nov 2011 22:17:17 +0000
Subject: [issue13248] deprecated in 3.2, should be removed in 3.3
In-Reply-To: <1319392186.66.0.823106983991.issue13248@psf.upfronthosting.co.za>
Message-ID: <1321395437.96.0.427533173555.issue13248@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/issue13248>
_______________________________________

From report at bugs.python.org  Tue Nov 15 23:20:32 2011
From: report at bugs.python.org (Eric V. Smith)
Date: Tue, 15 Nov 2011 22:20:32 +0000
Subject: [issue13410] String formatting bug in interactive mode
In-Reply-To: <1321394690.57.0.254973831289.issue13410@psf.upfronthosting.co.za>
Message-ID: <1321395632.82.0.890840177791.issue13410@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/issue13410>
_______________________________________

From report at bugs.python.org  Tue Nov 15 23:20:43 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 15 Nov 2011 22:20:43 +0000
Subject: [issue13411] Hashable memoryviews
Message-ID: <1321395643.62.0.259606214561.issue13411@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

This patch allows hashing of memoryviews, as discussed on python-dev.

----------
components: Interpreter Core
files: memhash.patch
keywords: patch
messages: 147714
nosy: ncoghlan, pitrou, skrah
priority: normal
severity: normal
stage: patch review
status: open
title: Hashable memoryviews
type: feature request
versions: Python 3.3
Added file: http://bugs.python.org/file23697/memhash.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13411>
_______________________________________

From report at bugs.python.org  Tue Nov 15 23:26:44 2011
From: report at bugs.python.org (Meador Inge)
Date: Tue, 15 Nov 2011 22:26:44 +0000
Subject: [issue13411] Hashable memoryviews
In-Reply-To: <1321395643.62.0.259606214561.issue13411@psf.upfronthosting.co.za>
Message-ID: <1321396004.16.0.282937489788.issue13411@psf.upfronthosting.co.za>


Changes by Meador Inge <meadori at gmail.com>:


----------
nosy: +meador.inge

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13411>
_______________________________________

From report at bugs.python.org  Tue Nov 15 23:36:42 2011
From: report at bugs.python.org (Alex Regueiro)
Date: Tue, 15 Nov 2011 22:36:42 +0000
Subject: [issue13412] No knowledge of symlinks on Windows
Message-ID: <1321396602.6.0.583941827853.issue13412@psf.upfronthosting.co.za>


New submission from Alex Regueiro <alexreg at gmail.com>:

Python 2.7 has no knowledge of directory symlinks on Windows 7. Listing a directory symlink does not work, nor does accessing a file within one. This is quite a notable missing feature on Windows 7, where symlinks are becoming increasingly prevalent.

----------
components: IO
messages: 147715
nosy: alexreg
priority: normal
severity: normal
status: open
title: No knowledge of symlinks on Windows
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13412>
_______________________________________

From report at bugs.python.org  Tue Nov 15 23:37:10 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 15 Nov 2011 22:37:10 +0000
Subject: [issue13412] No knowledge of symlinks on Windows
In-Reply-To: <1321396602.6.0.583941827853.issue13412@psf.upfronthosting.co.za>
Message-ID: <1321396630.45.0.306874704673.issue13412@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +brian.curtin, tim.golden

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13412>
_______________________________________

From report at bugs.python.org  Tue Nov 15 23:38:25 2011
From: report at bugs.python.org (Eric V. Smith)
Date: Tue, 15 Nov 2011 22:38:25 +0000
Subject: [issue13412] No knowledge of symlinks on Windows
In-Reply-To: <1321396602.6.0.583941827853.issue13412@psf.upfronthosting.co.za>
Message-ID: <1321396705.65.0.683344224443.issue13412@psf.upfronthosting.co.za>


Changes by Eric V. Smith <eric at trueblade.com>:


----------
nosy: +eric.smith, jason.coombs

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13412>
_______________________________________

From report at bugs.python.org  Tue Nov 15 23:42:18 2011
From: report at bugs.python.org (Eric V. Smith)
Date: Tue, 15 Nov 2011 22:42:18 +0000
Subject: [issue13410] String formatting bug in interactive mode
In-Reply-To: <1321394690.57.0.254973831289.issue13410@psf.upfronthosting.co.za>
Message-ID: <1321396938.24.0.00319267016354.issue13410@psf.upfronthosting.co.za>


Eric V. Smith <eric at trueblade.com> added the comment:

I think this must be a change between 2.5 and 2.6.

In 2.5.1 non-debug (Linux) I consistently see:
>>> print '%d' % y
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: int argument required

In 2.6.5 (Windows via activestate) I see the alternating errors reported here.

In 2.7.2+ debug (Linux) I consistently see:
>>> print '%d' % y
22
XXX undetected error
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: int() argument must be a string or a number, not 'Foo'
[38749 refs]

Note the "XXX undetected error".

In 2.7.2+ non-debug (Linux), I get the alternating errors reported here.

I don't think anything will be done about the problem in 2.6. For 2.7, the "XXX undetected error" should be investigated, and will likely point to the problem.

----------
assignee: ronaldoussoren -> 
components: +Interpreter Core -Macintosh
versions: +Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13410>
_______________________________________

From report at bugs.python.org  Tue Nov 15 23:42:25 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Tue, 15 Nov 2011 22:42:25 +0000
Subject: [issue11836] multiprocessing.queues.SimpleQueue is undocumented
In-Reply-To: <1302623785.46.0.16009713021.issue11836@psf.upfronthosting.co.za>
Message-ID: <1321396945.6.0.169252235058.issue11836@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

Then it appears to me that Sandro's patch is good and can be committed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11836>
_______________________________________

From report at bugs.python.org  Tue Nov 15 23:44:49 2011
From: report at bugs.python.org (Florent Xicluna)
Date: Tue, 15 Nov 2011 22:44:49 +0000
Subject: [issue13412] No knowledge of symlinks on Windows
In-Reply-To: <1321396602.6.0.583941827853.issue13412@psf.upfronthosting.co.za>
Message-ID: <1321397089.44.0.919768561089.issue13412@psf.upfronthosting.co.za>


Changes by Florent Xicluna <florent.xicluna at gmail.com>:


----------
components: +Windows
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13412>
_______________________________________

From report at bugs.python.org  Tue Nov 15 23:48:42 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 15 Nov 2011 22:48:42 +0000
Subject: [issue13388] document hg commit hooks in the devguide
In-Reply-To: <1321123590.65.0.736191202752.issue13388@psf.upfronthosting.co.za>
Message-ID: <E1RQRnq-0002mH-3j@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 21758f27f98f by Eli Bendersky in branch 'default':
document existing hooks for commit messages mentioning issues. Closes issue 13388
http://hg.python.org/devguide/rev/21758f27f98f

----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13388>
_______________________________________

From report at bugs.python.org  Tue Nov 15 23:49:21 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Tue, 15 Nov 2011 22:49:21 +0000
Subject: [issue13388] document hg commit hooks in the devguide
In-Reply-To: <1321123590.65.0.736191202752.issue13388@psf.upfronthosting.co.za>
Message-ID: <1321397361.54.0.846064871596.issue13388@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

Committed, with the fix suggested by ?ric

----------
resolution: fixed -> 
stage: committed/rejected -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13388>
_______________________________________

From report at bugs.python.org  Tue Nov 15 23:51:10 2011
From: report at bugs.python.org (Florent Xicluna)
Date: Tue, 15 Nov 2011 22:51:10 +0000
Subject: [issue13410] String formatting bug in interactive mode
In-Reply-To: <1321394690.57.0.254973831289.issue13410@psf.upfronthosting.co.za>
Message-ID: <1321397470.89.0.659738019839.issue13410@psf.upfronthosting.co.za>


Changes by Florent Xicluna <florent.xicluna at gmail.com>:


----------
nosy: +flox, mark.dickinson
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13410>
_______________________________________

From report at bugs.python.org  Tue Nov 15 23:52:53 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 15 Nov 2011 22:52:53 +0000
Subject: [issue11836] multiprocessing.queues.SimpleQueue is undocumented
In-Reply-To: <1321396945.6.0.169252235058.issue11836@psf.upfronthosting.co.za>
Message-ID: <1321397281.3272.15.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Then it appears to me that Sandro's patch is good and can be committed.

The doc patch is good. However, if you start exposing SimpleQueue at the
top package level, you have to do it in 3.3 only (since that's a new
API), and also mention it somehow in the doc.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11836>
_______________________________________

From report at bugs.python.org  Tue Nov 15 23:54:24 2011
From: report at bugs.python.org (Jason R. Coombs)
Date: Tue, 15 Nov 2011 22:54:24 +0000
Subject: [issue13412] No knowledge of symlinks on Windows
In-Reply-To: <1321396602.6.0.583941827853.issue13412@psf.upfronthosting.co.za>
Message-ID: <1321397664.08.0.984828489835.issue13412@psf.upfronthosting.co.za>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

Python 2.7 is not aware of symlinks and treats them like their targets, so it should be able to list a symlink directory or access a file within one. For example:

PS C:\Users\jaraco> cmd /c dir
 Volume in drive C is system
 Volume Serial Number is 2455-92A0

 Directory of C:\Users\jaraco

11-Nov-2011  06:50    <DIR>          .
11-Nov-2011  06:50    <DIR>          ..
..
11-Aug-2011  10:11    <SYMLINKD>     bin [Dropbox\bin\x64]
10-Aug-2011  21:00    <SYMLINKD>     bin-x86 [Dropbox\bin\x86]
..
              11 File(s)          6,632 bytes
              27 Dir(s)  301,972,422,656 bytes free
PS C:\Users\jaraco> python
Python 2.7.2 (default, Jun 12 2011, 14:24:46) [MSC v.1500 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import os
>>> os.listdir('bin')
['curl.exe', 'devcon.exe', 'HotSwap!.EXE', 'Notepad2.exe', 'utorrent.exe', 'vncviewer.exe']
>>> with open('bin/curl.exe', 'rb') as f:
...   f.read()[:10]
...
'MZ\x90\x00\x03\x00\x00\x00\x04\x00'
>>> ^Z

Because Python 2.7 is feature-frozen, symlink support will not be available in Python before 3.2.

If you are experiencing errors, please reopen this ticket and describe what you are doing, what you expect, and what you get instead.

----------
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13412>
_______________________________________

From report at bugs.python.org  Tue Nov 15 23:55:08 2011
From: report at bugs.python.org (Florent Xicluna)
Date: Tue, 15 Nov 2011 22:55:08 +0000
Subject: [issue13410] String formatting bug in interactive mode
In-Reply-To: <1321394690.57.0.254973831289.issue13410@psf.upfronthosting.co.za>
Message-ID: <1321397708.18.0.334536266422.issue13410@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

With Darwin 10.8.0 x86_64, I confirm the behavior described in first message.


$ python2.7 -V
Python 2.7.2
$ python2.7 -i xx.py
22
22
>>> 
TypeError: int() argument must be a string or a number, not 'Foo'
>>> '%d' % y
'22'
>>> '%d' % y
TypeError: int() argument must be a string or a number, not 'Foo'
>>> '%d' % y
'22'
>>> '%d' % y
TypeError: int() argument must be a string or a number, not 'Foo'
>>>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13410>
_______________________________________

From report at bugs.python.org  Wed Nov 16 00:02:08 2011
From: report at bugs.python.org (Alex Regueiro)
Date: Tue, 15 Nov 2011 23:02:08 +0000
Subject: [issue13412] No knowledge of symlinks on Windows
In-Reply-To: <1321396602.6.0.583941827853.issue13412@psf.upfronthosting.co.za>
Message-ID: <1321398128.39.0.275812146134.issue13412@psf.upfronthosting.co.za>


Alex Regueiro <alexreg at gmail.com> added the comment:

What are you running? This is not what I get on Win7 x64, and I have had several other users in ##python on FreeNode confirm this inability. As far as Python is concerned, these dir sym links do not even exist.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13412>
_______________________________________

From report at bugs.python.org  Wed Nov 16 00:02:50 2011
From: report at bugs.python.org (Brian Curtin)
Date: Tue, 15 Nov 2011 23:02:50 +0000
Subject: [issue13412] No knowledge of symlinks on Windows
In-Reply-To: <1321396602.6.0.583941827853.issue13412@psf.upfronthosting.co.za>
Message-ID: <1321398170.94.0.591491868515.issue13412@psf.upfronthosting.co.za>


Brian Curtin <brian at python.org> added the comment:

I think we could still make os.listdir work properly. I'll look into a patch for this.

One "problem" here is the testability, since we'd need to rely on the mklink CLI app to create the symlinks, which requires that the calling application (python.exe) has elevated privileges. It wont be exercised by any of the buildbots.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13412>
_______________________________________

From report at bugs.python.org  Wed Nov 16 00:06:26 2011
From: report at bugs.python.org (Jason R. Coombs)
Date: Tue, 15 Nov 2011 23:06:26 +0000
Subject: [issue13412] No knowledge of symlinks on Windows
In-Reply-To: <1321396602.6.0.583941827853.issue13412@psf.upfronthosting.co.za>
Message-ID: <1321398386.95.0.911954227418.issue13412@psf.upfronthosting.co.za>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

I should mention that there is third-party symlink support in jaraco.windows (http://pypi.python.org/pypi/jaraco.windows). Just easy_install it, and then use jaraco.windows.filesystem.symlink.

If there are features you need for symlink support in jaraco.windows, request them via https://bitbucket.org/jaraco/jaraco.windows and they should be implemented quickly.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13412>
_______________________________________

From report at bugs.python.org  Wed Nov 16 00:07:06 2011
From: report at bugs.python.org (Alex Regueiro)
Date: Tue, 15 Nov 2011 23:07:06 +0000
Subject: [issue13412] No knowledge of symlinks on Windows
In-Reply-To: <1321396602.6.0.583941827853.issue13412@psf.upfronthosting.co.za>
Message-ID: <1321398426.53.0.382449948679.issue13412@psf.upfronthosting.co.za>


Alex Regueiro <alexreg at gmail.com> added the comment:

Thanks Bryan, that would be great.

The elevated privs problem could potentially be avoided by creating symlinks using the Win32 API directly. As long as the appropiate group policy is set, one does not require admin privs to create symlinks. Perhaps symlink creation/deletion on Windows could even be integrated into the Python class library?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13412>
_______________________________________

From report at bugs.python.org  Wed Nov 16 00:07:44 2011
From: report at bugs.python.org (Jason R. Coombs)
Date: Tue, 15 Nov 2011 23:07:44 +0000
Subject: [issue13412] No knowledge of symlinks on Windows
In-Reply-To: <1321396602.6.0.583941827853.issue13412@psf.upfronthosting.co.za>
Message-ID: <1321398464.02.0.896827845056.issue13412@psf.upfronthosting.co.za>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

Brian, I'm still not sure I see the problem with os.listdir. It includes symlinks when listing a dir and traverses them naturally when referencing them as part of a path to listdir. Under what conditions does it fail?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13412>
_______________________________________

From report at bugs.python.org  Wed Nov 16 00:10:09 2011
From: report at bugs.python.org (Alex Regueiro)
Date: Tue, 15 Nov 2011 23:10:09 +0000
Subject: [issue13412] No knowledge of symlinks on Windows
In-Reply-To: <1321396602.6.0.583941827853.issue13412@psf.upfronthosting.co.za>
Message-ID: <1321398609.71.0.545579434906.issue13412@psf.upfronthosting.co.za>


Alex Regueiro <alexreg at gmail.com> added the comment:

Well, at the very least it's a system-dependent issue, since I've tried out listdir and also file access on my system and some other Windows users'.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13412>
_______________________________________

From report at bugs.python.org  Wed Nov 16 00:18:48 2011
From: report at bugs.python.org (Jason R. Coombs)
Date: Tue, 15 Nov 2011 23:18:48 +0000
Subject: [issue13412] No knowledge of symlinks on Windows
In-Reply-To: <1321396602.6.0.583941827853.issue13412@psf.upfronthosting.co.za>
Message-ID: <1321399128.03.0.989089608302.issue13412@psf.upfronthosting.co.za>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

Some variables could be a missing privilege or role, or perhaps a UAC restriction. What error do you get when you attempt to invoke os.listdir on a symlink directory?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13412>
_______________________________________

From report at bugs.python.org  Wed Nov 16 00:19:23 2011
From: report at bugs.python.org (Alex Regueiro)
Date: Tue, 15 Nov 2011 23:19:23 +0000
Subject: [issue13412] No knowledge of symlinks on Windows
In-Reply-To: <1321396602.6.0.583941827853.issue13412@psf.upfronthosting.co.za>
Message-ID: <1321399163.56.0.0177077233948.issue13412@psf.upfronthosting.co.za>


Alex Regueiro <alexreg at gmail.com> added the comment:

No error whatsoever. Python just thinks it doesn't exist unfortunately. Same report from other users...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13412>
_______________________________________

From report at bugs.python.org  Wed Nov 16 00:23:39 2011
From: report at bugs.python.org (Roger Serwy)
Date: Tue, 15 Nov 2011 23:23:39 +0000
Subject: [issue12988] IDLE on Win7 crashes when saving to Documents Library
In-Reply-To: <1316123106.02.0.189929579788.issue12988@psf.upfronthosting.co.za>
Message-ID: <1321399419.09.0.478781776335.issue12988@psf.upfronthosting.co.za>


Changes by Roger Serwy <roger.serwy at gmail.com>:


----------
nosy: +serwy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12988>
_______________________________________

From report at bugs.python.org  Wed Nov 16 00:33:02 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 15 Nov 2011 23:33:02 +0000
Subject: [issue13374] Deprecate usage of the Windows ANSI API in the nt module
In-Reply-To: <1320797406.95.0.49629588961.issue13374@psf.upfronthosting.co.za>
Message-ID: <E1RQSUk-0006UI-9b@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset afc716e463a1 by Victor Stinner in branch 'default':
Issue #13374: Skip deprecation tests for os.symlink() on Windows XP
http://hg.python.org/cpython/rev/afc716e463a1

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13374>
_______________________________________

From report at bugs.python.org  Wed Nov 16 00:35:24 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 15 Nov 2011 23:35:24 +0000
Subject: [issue13410] String formatting bug in interactive mode
In-Reply-To: <1321394690.57.0.254973831289.issue13410@psf.upfronthosting.co.za>
Message-ID: <1321400124.57.0.475568502102.issue13410@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

A debug build displays "XXX undetected error".  An error condition was not correctly cleared, see attached patch.

----------
keywords: +patch
nosy: +amaury.forgeotdarc
Added file: http://bugs.python.org/file23698/issue13410.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13410>
_______________________________________

From report at bugs.python.org  Wed Nov 16 00:41:15 2011
From: report at bugs.python.org (Brian Curtin)
Date: Tue, 15 Nov 2011 23:41:15 +0000
Subject: [issue13412] No knowledge of symlinks on Windows
In-Reply-To: <1321398464.02.0.896827845056.issue13412@psf.upfronthosting.co.za>
Message-ID: <CAD+XWwp9SKUArwEy+AST16ugMxaJ5b0myDA9dr1jw+UV1TAjgA@mail.gmail.com>


Brian Curtin <brian at python.org> added the comment:

symlinks when listing a dir and traverses them naturally when referencing
them as part of a path to listdir. Under what conditions does it fail?
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue13412>
> _______________________________________

Jason - I'm responding on a phone - I haven't confirmed anything yet (and
hadn't yet seen your examples when I was typing).

Alex - the Windows API also requires elevation - that's what we have to do
in 3.2+ as well. The symlink calls require a specific privilege which is
only granted when elevated, even for the mklink program.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13412>
_______________________________________

From report at bugs.python.org  Wed Nov 16 00:42:07 2011
From: report at bugs.python.org (Alex Regueiro)
Date: Tue, 15 Nov 2011 23:42:07 +0000
Subject: [issue13412] No knowledge of symlinks on Windows
In-Reply-To: <1321396602.6.0.583941827853.issue13412@psf.upfronthosting.co.za>
Message-ID: <1321400527.36.0.562122944177.issue13412@psf.upfronthosting.co.za>


Alex Regueiro <alexreg at gmail.com> added the comment:

When listing the parent dir in which a dir symlink resides, the dir symlink doesn't show up. That's the one I noticed most.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13412>
_______________________________________

From report at bugs.python.org  Wed Nov 16 00:46:49 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 15 Nov 2011 23:46:49 +0000
Subject: [issue13410] String formatting bug in interactive mode
In-Reply-To: <1321394690.57.0.254973831289.issue13410@psf.upfronthosting.co.za>
Message-ID: <1321400809.67.0.176951010281.issue13410@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

New patch with a unit test.

----------
Added file: http://bugs.python.org/file23699/issue13410_2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13410>
_______________________________________

From report at bugs.python.org  Wed Nov 16 00:48:40 2011
From: report at bugs.python.org (Jason R. Coombs)
Date: Tue, 15 Nov 2011 23:48:40 +0000
Subject: [issue13412] No knowledge of symlinks on Windows
In-Reply-To: <1321396602.6.0.583941827853.issue13412@psf.upfronthosting.co.za>
Message-ID: <1321400920.56.0.519236169913.issue13412@psf.upfronthosting.co.za>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

On Windows Vista and Windows 7, there should be a symlink directory:

C:\Documents and Settings -> .\Users

Perhaps a good test would be:

assert 'Documents and Settings' in os.listdir('C:\\')

As long as there aren't any i18n issues, and the system is a standard install, that test should only fail if os.listdir fails to return symlinks.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13412>
_______________________________________

From report at bugs.python.org  Wed Nov 16 00:49:44 2011
From: report at bugs.python.org (Jason R. Coombs)
Date: Tue, 15 Nov 2011 23:49:44 +0000
Subject: [issue13412] Symbolic links omitted by os.listdir on some systems
In-Reply-To: <1321396602.6.0.583941827853.issue13412@psf.upfronthosting.co.za>
Message-ID: <1321400984.3.0.302302157668.issue13412@psf.upfronthosting.co.za>


Changes by Jason R. Coombs <jaraco at jaraco.com>:


----------
status: closed -> 
title: No knowledge of symlinks on Windows -> Symbolic links omitted by os.listdir on some systems

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13412>
_______________________________________

From report at bugs.python.org  Wed Nov 16 00:50:17 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 15 Nov 2011 23:50:17 +0000
Subject: [issue13410] String formatting bug in interactive mode
In-Reply-To: <1321394690.57.0.254973831289.issue13410@psf.upfronthosting.co.za>
Message-ID: <1321401017.3.0.900280408985.issue13410@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Sorry I found that u'%d' is equally affected, here is a new version.

----------
Added file: http://bugs.python.org/file23700/issue13410_3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13410>
_______________________________________

From report at bugs.python.org  Wed Nov 16 00:51:20 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Tue, 15 Nov 2011 23:51:20 +0000
Subject: [issue13405] Add DTrace probes
In-Reply-To: <1321299726.66.0.343368151185.issue13405@psf.upfronthosting.co.za>
Message-ID: <1321401080.61.0.0628758477577.issue13405@psf.upfronthosting.co.za>


Changes by Jes?s Cea Avi?n <jcea at jcea.es>:


Added file: http://bugs.python.org/file23701/7a2465f6a56a.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13405>
_______________________________________

From report at bugs.python.org  Wed Nov 16 00:56:59 2011
From: report at bugs.python.org (Eric V. Smith)
Date: Tue, 15 Nov 2011 23:56:59 +0000
Subject: [issue13410] String formatting bug in interactive mode
In-Reply-To: <1321394690.57.0.254973831289.issue13410@psf.upfronthosting.co.za>
Message-ID: <1321401419.9.0.650648062298.issue13410@psf.upfronthosting.co.za>


Eric V. Smith <eric at trueblade.com> added the comment:

I don't think you're going to want those print statements in a test. You could just evaluate '%d' % y.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13410>
_______________________________________

From report at bugs.python.org  Wed Nov 16 01:01:14 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 16 Nov 2011 00:01:14 +0000
Subject: [issue13238] Add shell command helpers to subprocess module
In-Reply-To: <1319176813.33.0.203455355645.issue13238@psf.upfronthosting.co.za>
Message-ID: <1321401674.45.0.171428545364.issue13238@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Similar to what I did with walkdir, I plan to publish a shellcommand module on PyPI to give people a chance to look at the API and experiment with it without having to patch shutil in the standard library.

The only aspect I'm 100% sold on at the moment for the stdlib version is the use of a custom formatter to implement automatic invocation of shlex.quote(). It makes doing the right thing to avoid shell injection attacks (and whitespace problems in filenames) the path of least resistance: if you use shell_call/shell_check_call/shell_output and let them do the interpolation, then your call will be safe by default and the only thing you have to avoid is using an explicit conversion specifier that will bypass the quoting (i.e. '!a', '!r', '!s' or the custom '!u'). Since fear of encouraging shell injection vulnerabilities has historically been a big issue when it comes to shell invocation from the subprocess module, I think this part is mandatory. Once you do that, then '!u' is needed as a consequence, since sometimes you *will* want to pass unquoted values through in order to use standard numeric formatting options, or just to allow metacharacters to be interpreted by the shell, etc.

Interface wise, I'm still leaning towards just the _ShellFormatter class being private (due to its thread safety limitations), with ShellCommand and the three module level helpers making up the initial public API.

This isn't just speculation - by making the choice to use the *args and **kwds slots of the helper functions for string interpolation, it means they're no longer available for arguments to the Popen constructor.

In my own use case, one of the big things I want to do is invoke shell_call() with stdout and stderr redirected to a log file. Without ShellCommand exposed to let you customise the arguments to Popen, you end up having to essentially reimplement everything the helpers otherwise provide. With ShellCommand, you're able to still handle those less common use cases *without* having to reinvent the wheel on the formatting front:

    cmd = ShellCommand("cat {}", stdout=logfile, stderr=STDOUT)
    cmd.shell_call(cmd_arg)

For simple use cases where you *don't* want to tinker with the Popen args, though, the module level helpers will be the preferred option:

    data = shell_output("cat {}", cmd_arg).decode("utf-8")

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13238>
_______________________________________

From report at bugs.python.org  Wed Nov 16 01:02:39 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 16 Nov 2011 00:02:39 +0000
Subject: [issue13393] Improve BufferedReader.read1()
In-Reply-To: <1321157701.74.0.443809978111.issue13393@psf.upfronthosting.co.za>
Message-ID: <E1RQSxO-0000RK-Ki@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 27bf3d0b8e5f by Antoine Pitrou in branch 'default':
Issue #13393: BufferedReader.read1() now asks the full requested size to
http://hg.python.org/cpython/rev/27bf3d0b8e5f

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13393>
_______________________________________

From report at bugs.python.org  Wed Nov 16 01:04:18 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 16 Nov 2011 00:04:18 +0000
Subject: [issue13410] String formatting bug in interactive mode
In-Reply-To: <1321394690.57.0.254973831289.issue13410@psf.upfronthosting.co.za>
Message-ID: <1321401858.18.0.531869051258.issue13410@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Unfortunately without the "print" the test does not fail.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13410>
_______________________________________

From report at bugs.python.org  Wed Nov 16 01:10:59 2011
From: report at bugs.python.org (Eric V. Smith)
Date: Wed, 16 Nov 2011 00:10:59 +0000
Subject: [issue13410] String formatting bug in interactive mode
In-Reply-To: <1321394690.57.0.254973831289.issue13410@psf.upfronthosting.co.za>
Message-ID: <1321402259.96.0.643211671085.issue13410@psf.upfronthosting.co.za>


Eric V. Smith <eric at trueblade.com> added the comment:

With an unpatched 2.7, this fails for me:

diff --git a/Lib/test/test_format.py b/Lib/test/test_format.py
--- a/Lib/test/test_format.py
+++ b/Lib/test/test_format.py
@@ -289,6 +289,17 @@
             else:
                 raise TestFailed, '"%*d"%(maxsize, -127) should fail'
 
+    def test_issue13410(self):
+        class Foo(object):
+            def __init__(self, x):
+                self.x = x
+            def __long__(self):
+                return long(self.x)
+            def __float__(self):
+                return float(self.x)
+        '%d' % Foo(22)
+
 def test_main():
     test_support.run_unittest(FormatTest)
 

$ ./python Lib/test/regrtest.py test_format
test_format
test test_format crashed -- <type 'exceptions.TypeError'>: int() argument must be a string or a number, not 'Foo'
1 test failed:
    test_format

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13410>
_______________________________________

From report at bugs.python.org  Wed Nov 16 01:46:44 2011
From: report at bugs.python.org (Florent Xicluna)
Date: Wed, 16 Nov 2011 00:46:44 +0000
Subject: [issue13378] Change the variable "nsmap" from global to instance
	(xml.etree.ElementTree)
In-Reply-To: <1320877071.09.0.895123668254.issue13378@psf.upfronthosting.co.za>
Message-ID: <1321404404.74.0.411305183739.issue13378@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

Thank you Stefan for the comments.
I've added the prefix collision detection, and removed the **kw argument.
(+ tests)

----------
Added file: http://bugs.python.org/file23702/issue13378_non_global_namespaces_v2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13378>
_______________________________________

From report at bugs.python.org  Wed Nov 16 02:16:24 2011
From: report at bugs.python.org (Alex Regueiro)
Date: Wed, 16 Nov 2011 01:16:24 +0000
Subject: [issue13412] Symbolic links omitted by os.listdir on some systems
In-Reply-To: <1321396602.6.0.583941827853.issue13412@psf.upfronthosting.co.za>
Message-ID: <1321406184.85.0.223728035953.issue13412@psf.upfronthosting.co.za>


Alex Regueiro <alexreg at gmail.com> added the comment:

Okay, so I figured out where I was originally seeing this issue. (It does indeed work normally as you said; I'm not sure how I tested otherwise.)

Well, the problem is when you load a module that is a SYMLINKD. If the module folder is a normal directory, all works fine, otherwise it can't be found. Hopefully you can verify this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13412>
_______________________________________

From report at bugs.python.org  Wed Nov 16 02:23:40 2011
From: report at bugs.python.org (Roger Serwy)
Date: Wed, 16 Nov 2011 01:23:40 +0000
Subject: [issue8793] IDLE crashes on opening invalid file
In-Reply-To: <1274607720.78.0.880248664053.issue8793@psf.upfronthosting.co.za>
Message-ID: <1321406620.96.0.793661535931.issue8793@psf.upfronthosting.co.za>


Roger Serwy <roger.serwy at gmail.com> added the comment:

With IDLE 3.2 on Ubuntu 11.04, this is not a problem. An error box pops up:

SyntaxError
(unicode error) 'unicodeescape' codec can't decode bytes in position 0-3: truncated \xXX escape

With IDLE 2.7.1 on Ubuntu 11.04, the console gives the error described by Amaury.

A quick fix would be to add "ValueError" to the except clause in "checksyntax" in ScriptBinding for the 2.7 branch.

----------
nosy: +serwy
versions: +Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8793>
_______________________________________

From report at bugs.python.org  Wed Nov 16 03:30:29 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 16 Nov 2011 02:30:29 +0000
Subject: [issue8793] IDLE crashes on opening invalid file
In-Reply-To: <1274607720.78.0.880248664053.issue8793@psf.upfronthosting.co.za>
Message-ID: <E1RQVGS-0003CL-LL@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset e277fe8380e0 by Ned Deily in branch '2.7':
Issue #8793: Prevent IDLE crash in 2.7 when given strings with
http://hg.python.org/cpython/rev/e277fe8380e0

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8793>
_______________________________________

From report at bugs.python.org  Wed Nov 16 03:33:42 2011
From: report at bugs.python.org (Ned Deily)
Date: Wed, 16 Nov 2011 02:33:42 +0000
Subject: [issue8793] IDLE crashes on opening invalid file
In-Reply-To: <1274607720.78.0.880248664053.issue8793@psf.upfronthosting.co.za>
Message-ID: <1321410822.18.0.0841136799532.issue8793@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Thank for the suggestion!  BTW, a similar change had been recently made to Python 3 for Issue9871 for invalid byte strings.

----------
assignee:  -> ned.deily
nosy: +ned.deily
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
versions:  -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8793>
_______________________________________

From report at bugs.python.org  Wed Nov 16 04:05:25 2011
From: report at bugs.python.org (James C. McPherson)
Date: Wed, 16 Nov 2011 03:05:25 +0000
Subject: [issue13405] Add DTrace probes
In-Reply-To: <1321299726.66.0.343368151185.issue13405@psf.upfronthosting.co.za>
Message-ID: <1321412725.95.0.215578363837.issue13405@psf.upfronthosting.co.za>


James C. McPherson <jmcp at opensolaris.org> added the comment:

While using LD_LIBRARY_PATH might be ok for a quick run by hand,
it's preferable to use an RPATH when linking for more long term
usages.

----------
nosy: +jmcp

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13405>
_______________________________________

From report at bugs.python.org  Wed Nov 16 04:34:33 2011
From: report at bugs.python.org (Roy Smith)
Date: Wed, 16 Nov 2011 03:34:33 +0000
Subject: [issue13249] argparse.ArgumentParser() lists arguments in the wrong
	order
In-Reply-To: <1319394759.74.0.692830705102.issue13249@psf.upfronthosting.co.za>
Message-ID: <1321414473.03.0.135896633263.issue13249@psf.upfronthosting.co.za>


Roy Smith <roy at panix.com> added the comment:

Another patch, with the most recent review suggestions incorporated.

----------
Added file: http://bugs.python.org/file23703/Issue13249-3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13249>
_______________________________________

From report at bugs.python.org  Wed Nov 16 04:36:45 2011
From: report at bugs.python.org (Eric Snow)
Date: Wed, 16 Nov 2011 03:36:45 +0000
Subject: [issue13411] Hashable memoryviews
In-Reply-To: <1321395643.62.0.259606214561.issue13411@psf.upfronthosting.co.za>
Message-ID: <1321414605.27.0.965969658658.issue13411@psf.upfronthosting.co.za>


Changes by Eric Snow <ericsnowcurrently at gmail.com>:


----------
nosy: +eric.snow

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13411>
_______________________________________

From report at bugs.python.org  Wed Nov 16 07:56:31 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 16 Nov 2011 06:56:31 +0000
Subject: [issue13388] document hg commit hooks in the devguide
In-Reply-To: <1321123590.65.0.736191202752.issue13388@psf.upfronthosting.co.za>
Message-ID: <1321426591.27.0.82722255188.issue13388@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13388>
_______________________________________

From report at bugs.python.org  Wed Nov 16 08:16:03 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 16 Nov 2011 07:16:03 +0000
Subject: [issue13410] String formatting bug in interactive mode
In-Reply-To: <1321394690.57.0.254973831289.issue13410@psf.upfronthosting.co.za>
Message-ID: <1321427763.64.0.790542962716.issue13410@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

$ ./python Lib/test/regrtest.py test_format
shows the error, but
$ ./python Lib/test/regrtest.py -v test_format
does not fail!
The "print" is needed, can something else have the same effect?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13410>
_______________________________________

From report at bugs.python.org  Wed Nov 16 08:17:30 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 16 Nov 2011 07:17:30 +0000
Subject: [issue13410] String formatting bug in interactive mode
In-Reply-To: <1321394690.57.0.254973831289.issue13410@psf.upfronthosting.co.za>
Message-ID: <1321427850.66.0.565545128865.issue13410@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti
stage: needs patch -> patch review
versions:  -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13410>
_______________________________________

From report at bugs.python.org  Wed Nov 16 08:39:46 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 16 Nov 2011 07:39:46 +0000
Subject: [issue13406] Deprecation warnings when running the test suite
In-Reply-To: <1321312320.0.0.525763918067.issue13406@psf.upfronthosting.co.za>
Message-ID: <E1RQa5l-0002uW-P1@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 4f534cd40f54 by Ezio Melotti in branch 'default':
#13406: silence deprecation warnings in test_codecs.
http://hg.python.org/cpython/rev/4f534cd40f54

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13406>
_______________________________________

From report at bugs.python.org  Wed Nov 16 08:49:24 2011
From: report at bugs.python.org (Dmitry Balabanov)
Date: Wed, 16 Nov 2011 07:49:24 +0000
Subject: [issue13413] time.daylight incorrect behavior in linux glibc
Message-ID: <1321429764.54.0.0162746927464.issue13413@psf.upfronthosting.co.za>


New submission from Dmitry Balabanov <dimonb at gmail.com>:

In Europe/Moscow timezone:
>> import time
>> time.daylight
1
>>> time.timezone
-10800

But if compile and run attached program result would be:
timezone: -14400, daylight: 0

Daylight is not applicable in Europe/Moscow timezone from this winter. But python detect daylight flag as differences between January and July localtime. 

Why not tzset()?

----------
files: daylight.c
messages: 147752
nosy: dimonb
priority: normal
severity: normal
status: open
title: time.daylight incorrect behavior in linux glibc
type: behavior
Added file: http://bugs.python.org/file23704/daylight.c

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13413>
_______________________________________

From report at bugs.python.org  Wed Nov 16 08:55:04 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 16 Nov 2011 07:55:04 +0000
Subject: [issue13406] Deprecation warnings when running the test suite
In-Reply-To: <1321312320.0.0.525763918067.issue13406@psf.upfronthosting.co.za>
Message-ID: <E1RQaKa-00042M-75@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 028b61c4f926 by Ezio Melotti in branch 'default':
#13406: correct the error message in check_warnings too.
http://hg.python.org/cpython/rev/028b61c4f926

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13406>
_______________________________________

From report at bugs.python.org  Wed Nov 16 09:17:41 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 16 Nov 2011 08:17:41 +0000
Subject: [issue13406] Deprecation warnings when running the test suite
In-Reply-To: <1321312320.0.0.525763918067.issue13406@psf.upfronthosting.co.za>
Message-ID: <1321431461.53.0.0247674466664.issue13406@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Should be fixed now.

----------
assignee:  -> ezio.melotti
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13406>
_______________________________________

From report at bugs.python.org  Wed Nov 16 09:18:34 2011
From: report at bugs.python.org (kxroberto)
Date: Wed, 16 Nov 2011 08:18:34 +0000
Subject: [issue1486713] HTMLParser : A auto-tolerant parsing mode
Message-ID: <1321431514.81.0.612464392354.issue1486713@psf.upfronthosting.co.za>


kxroberto <kxroberto at users.sourceforge.net> added the comment:

Well in many browsers for example there is a internal warning and error log (window). Which yet does not (need to) claim to be a official W3C checker. It has positive effect on web stabilization. 
For example just looking now I see the many HTML and CSS warnings and errors about the sourceforge site and this bug tracker in the Browsers log - not believing that the log covers the bugs 100% ;-)

The events of warnings are easily available here, and calling self.warning, as it was, costs quite nothing. I don't see a problem for non-users of this feature. And most code using HTMLParser also emits warnings on the next higher syntax level, so to not have a black box...
 
As I used a tolerant version of HTMLParser for about a decade, I can say the warnings are of the same value in many apps and use case, as to be able to have look into a Browsers syntax log. 
The style of stretching a argument to black<->white is not reasonable here in the world of human edited HTML ;-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1486713>
_______________________________________

From report at bugs.python.org  Wed Nov 16 09:28:56 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 16 Nov 2011 08:28:56 +0000
Subject: [issue1486713] HTMLParser : A auto-tolerant parsing mode
Message-ID: <1321432136.8.0.865869582555.issue1486713@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

The strict/tolerant mode mainly works by using either a strict or a tolerant regex.  If the markup is invalid, the strict regex doesn't match and it gives an error.  The tolerant regex will match both valid and invalid markup at the same time, without distinctions, and that's why there's no way to emit a warning for these cases.  I think there are a couple of places where a warning could be emitted, but that would just cover a small percentage of the errors.  Even if we find a way to emit a warning for everything allowed by the tolerant mode that fails on strict, it won't still cover all the possible errors, that's why I think tools like validators and conformance checkers (or even the warning/error logs) should be used instead.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1486713>
_______________________________________

From report at bugs.python.org  Wed Nov 16 09:48:51 2011
From: report at bugs.python.org (cedre.m)
Date: Wed, 16 Nov 2011 08:48:51 +0000
Subject: [issue7983] The encoding map from Unicode to CP932 is different from
	that of Windows'
In-Reply-To: <1266844323.37.0.847298507631.issue7983@psf.upfronthosting.co.za>
Message-ID: <1321433331.28.0.521224757605.issue7983@psf.upfronthosting.co.za>


Changes by cedre.m <cedre.m at gmail.com>:


----------
nosy: +cedrem

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7983>
_______________________________________

From report at bugs.python.org  Wed Nov 16 09:54:48 2011
From: report at bugs.python.org (cedre.m)
Date: Wed, 16 Nov 2011 08:54:48 +0000
Subject: [issue7983] The encoding map from Unicode to CP932 is different from
	that of Windows'
In-Reply-To: <1266844323.37.0.847298507631.issue7983@psf.upfronthosting.co.za>
Message-ID: <1321433688.38.0.281129784352.issue7983@psf.upfronthosting.co.za>


cedre.m <cedre.m at gmail.com> added the comment:

http://support.microsoft.com/kb/170559/EN-US
http://msdn.microsoft.com/en-us/goglobal/cc305152.aspx

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7983>
_______________________________________

From report at bugs.python.org  Wed Nov 16 10:45:11 2011
From: report at bugs.python.org (Remi Pointel)
Date: Wed, 16 Nov 2011 09:45:11 +0000
Subject: [issue13414] test_strftime failed on OpenBSD
Message-ID: <1321436711.11.0.148655032298.issue13414@psf.upfronthosting.co.za>


New submission from Remi Pointel <python at xiri.fr>:

Hello,

I was running test_datetime.py and it failed on OpenBSD.
I have tested with Python 2.7, Python 3.2 and Python 3.3.

Python 2.7:
test_datetime.py: ok
test_srtftime.py: failed (see attached file: test_strftime_python27.log)

Have a lot of:
Conflict for nonstandard '%3y' format (year without century rendered using fieldwidth):
  Expected 011, but got 3y
Strftime test, platform: openbsd5, Python version: 2.7.1
strftime test for Sat Jul 24 21:56:24 2010
Supports nonstandard '%c' format (near-asctime() format)
Supports nonstandard '%x' format (%m/%d/%y %H:%M:%S)
Supports nonstandard '%Z' format (time zone name)
Supports nonstandard '%D' format (mm/dd/yy)
Supports nonstandard '%e' format (day of month as number, blank padded ( 0-31))
Supports nonstandard '%h' format (abbreviated month name)
Supports nonstandard '%k' format (hour, blank padded ( 0-23))
Supports nonstandard '%n' format (newline character)
Supports nonstandard '%r' format (%I:%M:%S %p)
Supports nonstandard '%R' format (%H:%M)
Supports nonstandard '%s' format (seconds since the Epoch in UCT)
Supports nonstandard '%t' format (tab character)
Supports nonstandard '%T' format (%H:%M:%S)


Python 3.2:
test_datetime.py: failed (see attached file: test_datetime_python32.log)
======================================================================
FAIL: test_zones (test.datetimetester.TestTimeTZ_Fast)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/ports/pobj/Python-3.2.2/Python-3.2.2/Lib/test/datetimetester.py", line 2506, in test_zones
    "07:47:00 %Z=EST %z=-0500")
AssertionError: '07:47:00 Z=EST z=-0500' != '07:47:00 %Z=EST %z=-0500'
- 07:47:00 Z=EST z=-0500
+ 07:47:00 %Z=EST %z=-0500
?          +      +


======================================================================
FAIL: test_zones (test.datetimetester.TestTimeTZ_Pure)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/ports/pobj/Python-3.2.2/Python-3.2.2/Lib/test/datetimetester.py", line 2506, in test_zones
    "07:47:00 %Z=EST %z=-0500")
AssertionError: '07:47:00 Z=EST z=-0500' != '07:47:00 %Z=EST %z=-0500'
- 07:47:00 Z=EST z=-0500
+ 07:47:00 %Z=EST %z=-0500
?          +      +

test_strftime.py: failed (see attached file: test_strftime_python32.log)

======================================================================
FAIL: test_strftime (__main__.StrftimeTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "Lib/test/test_strftime.py", line 67, in test_strftime
    self.strftest1(now)
  File "Lib/test/test_strftime.py", line 124, in strftest1
    % (e[0], e[2]))
AssertionError: strftime does not support standard '%%' format (single percent sign)

----------------------------------------------------------------------


Python 3.3:
test_datetime.py: failed (see attached file: test_datetime_python33.log)
Same output than Python 3.2.

test_strftime.py: failed (see attached file: test_strftime_python33.log)
Same output than Python 3.2.


I write a small program in C to verify strftime, and it seems to correcly works:
source:
(void)strftime(buf, sizeof(buf) - 1, "%H:%M:%S %%Z=%Z %%z=%z", localtime(&startt));
printf("%s\n", buf);
buf[0] = '\0';
(void)strftime(buf, sizeof(buf) - 1, "07:47:00 %Z=EST %z=-0500", localtime(&startt));
printf("%s\n", buf);

run:
01:00:00 %Z=CET %z=+0100
07:47:00 CET=EST +0100=-0500



Is my test correct ? Don't hesitate if you need more informations.

Thanks for your help, 

Remi.

----------
files: test_datetime_python32.log
messages: 147758
nosy: rpointel
priority: normal
severity: normal
status: open
title: test_strftime failed on OpenBSD
versions: Python 2.7, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file23705/test_datetime_python32.log

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13414>
_______________________________________

From report at bugs.python.org  Wed Nov 16 10:45:21 2011
From: report at bugs.python.org (Remi Pointel)
Date: Wed, 16 Nov 2011 09:45:21 +0000
Subject: [issue13414] test_strftime failed on OpenBSD
In-Reply-To: <1321436711.11.0.148655032298.issue13414@psf.upfronthosting.co.za>
Message-ID: <1321436721.3.0.193933581824.issue13414@psf.upfronthosting.co.za>


Changes by Remi Pointel <python at xiri.fr>:


Added file: http://bugs.python.org/file23706/test_datetime_python33.log

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13414>
_______________________________________

From report at bugs.python.org  Wed Nov 16 10:45:29 2011
From: report at bugs.python.org (Remi Pointel)
Date: Wed, 16 Nov 2011 09:45:29 +0000
Subject: [issue13414] test_strftime failed on OpenBSD
In-Reply-To: <1321436711.11.0.148655032298.issue13414@psf.upfronthosting.co.za>
Message-ID: <1321436729.73.0.728599618893.issue13414@psf.upfronthosting.co.za>


Changes by Remi Pointel <python at xiri.fr>:


Added file: http://bugs.python.org/file23707/test_strftime_python27.log

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13414>
_______________________________________

From report at bugs.python.org  Wed Nov 16 10:45:36 2011
From: report at bugs.python.org (Remi Pointel)
Date: Wed, 16 Nov 2011 09:45:36 +0000
Subject: [issue13414] test_strftime failed on OpenBSD
In-Reply-To: <1321436711.11.0.148655032298.issue13414@psf.upfronthosting.co.za>
Message-ID: <1321436736.58.0.975420708858.issue13414@psf.upfronthosting.co.za>


Changes by Remi Pointel <python at xiri.fr>:


Added file: http://bugs.python.org/file23708/test_strftime_python32.log

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13414>
_______________________________________

From report at bugs.python.org  Wed Nov 16 10:45:44 2011
From: report at bugs.python.org (Remi Pointel)
Date: Wed, 16 Nov 2011 09:45:44 +0000
Subject: [issue13414] test_strftime failed on OpenBSD
In-Reply-To: <1321436711.11.0.148655032298.issue13414@psf.upfronthosting.co.za>
Message-ID: <1321436744.06.0.782401777379.issue13414@psf.upfronthosting.co.za>


Changes by Remi Pointel <python at xiri.fr>:


Added file: http://bugs.python.org/file23709/test_strftime_python33.log

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13414>
_______________________________________

From report at bugs.python.org  Wed Nov 16 10:47:21 2011
From: report at bugs.python.org (Eric V. Smith)
Date: Wed, 16 Nov 2011 09:47:21 +0000
Subject: [issue13410] String formatting bug in interactive mode
In-Reply-To: <1321394690.57.0.254973831289.issue13410@psf.upfronthosting.co.za>
Message-ID: <1321436841.52.0.0412794847407.issue13410@psf.upfronthosting.co.za>


Eric V. Smith <eric at trueblade.com> added the comment:

Interesting! Same here.

Using eval() fails with or without -v:

--- a/Lib/test/test_format.py
+++ b/Lib/test/test_format.py
@@ -289,6 +289,18 @@
             else:
                 raise TestFailed, '"%*d"%(maxsize, -127) should fail'
 
+    def test_issue13410(self):
+        class Foo(object):
+            def __init__(self, x):
+                self.x = x
+            def __long__(self):
+                return long(self.x)
+            def __float__(self):
+                return float(self.x)
+        eval(u'%d' % Foo(22))
+        eval('%d' % Foo(22))
+
+
 def test_main():
     test_support.run_unittest(FormatTest)
 
I've put both '%d' and u'%d' here, but it also fails with just one of them.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13410>
_______________________________________

From report at bugs.python.org  Wed Nov 16 10:52:06 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 16 Nov 2011 09:52:06 +0000
Subject: [issue13414] test_strftime failed on OpenBSD
In-Reply-To: <1321436711.11.0.148655032298.issue13414@psf.upfronthosting.co.za>
Message-ID: <1321437126.88.0.377138640596.issue13414@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Can you also please attach your C test program?

----------
nosy: +belopolsky, haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13414>
_______________________________________

From report at bugs.python.org  Wed Nov 16 10:54:29 2011
From: report at bugs.python.org (Remi Pointel)
Date: Wed, 16 Nov 2011 09:54:29 +0000
Subject: [issue13414] test_strftime failed on OpenBSD
In-Reply-To: <1321436711.11.0.148655032298.issue13414@psf.upfronthosting.co.za>
Message-ID: <1321437269.48.0.102082331357.issue13414@psf.upfronthosting.co.za>


Remi Pointel <python at xiri.fr> added the comment:

Sure.

----------
Added file: http://bugs.python.org/file23710/strftime.c

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13414>
_______________________________________

From report at bugs.python.org  Wed Nov 16 11:08:42 2011
From: report at bugs.python.org (=?utf-8?q?Maciej_Blizi=C5=84ski?=)
Date: Wed, 16 Nov 2011 10:08:42 +0000
Subject: [issue13398] _cursesmodule does not build,
	doesn't find Python.h on Solaris
In-Reply-To: <1321226216.89.0.228790993845.issue13398@psf.upfronthosting.co.za>
Message-ID: <1321438122.8.0.762188320868.issue13398@psf.upfronthosting.co.za>


Maciej Blizi?ski <maciej.blizinski at gmail.com> added the comment:

It's not only the curses module, other two modules are failing as well, the same way - not finding Python.h.

maciej at unstable9s :~/src/opencsw/pkg/lang-python/python/branches/python-3.2 > grep ^PY_CPPFLAGS work/solaris9-sparc/build-isa-sparcv8/Python-3.2.2/Makefile
PY_CPPFLAGS=    -I. -IInclude -I$(srcdir)/Include $(CONFIGURE_CPPFLAGS) $(CPPFLAGS)

Perhaps PY_CPPFLAGS does not get included in the compiler invocation? Poking around the Makefile, I find:

Modules/_cursesmodule.o: $(srcdir)/Modules/_cursesmodule.c; $(CC)  $(CCSHARED) $(CFLAGS) $(CPPFLAGS)  -c $(srcdir)/Modules/_cursesmodule.c -o Modules/_cursesmodule.o

This line doesn't contain a reference to PY_CPPFLAGS.

Perhaps the answer is around line 220 in Modules/makesetup?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13398>
_______________________________________

From report at bugs.python.org  Wed Nov 16 11:16:52 2011
From: report at bugs.python.org (kxroberto)
Date: Wed, 16 Nov 2011 10:16:52 +0000
Subject: [issue1486713] HTMLParser : A auto-tolerant parsing mode
Message-ID: <1321438612.03.0.65576791437.issue1486713@psf.upfronthosting.co.za>


kxroberto <kxroberto at users.sourceforge.net> added the comment:

The old patch warned already the majority of real cases  - except the missing white space between attributes.

"The tolerant regex will match both": 
locatestarttagend_tolerant: The main and frequent issue on the web here is the missing white space between attributes (with enclosed values). And there is the new tolerant comma between attributes, which however I have not seen so far anywhere (the old warning machanism and attrfind.match would have already raised it at "junk chars ..." event.
Both issues can be easily warned (also/already) at quite no cost by the slightly extended regex below (when the 2 new non-pseudo regex groups are check against <>None in check_for_whole_start_tag). 
Or missing whitespace could be warned (multiple times) at attrfind time.

attrfind_tolerant : I see no point in the old/"strict" attrfind. (and the difference is guessed 0.000% of real cases). attrfind_tolerant  could become the only attrfind.


--

locatestarttagend_tolerant = re.compile(r"""
  <[a-zA-Z][-.a-zA-Z0-9:_]*          # tag name
  (?:(?:\s+|(\s*))                   # optional whitespace before attribute name
    (?:[a-zA-Z_][-.:a-zA-Z0-9_]*     # attribute name
      (?:\s*=\s*                     # value indicator
        (?:'[^']*'                   # LITA-enclosed value
          |\"[^\"]*\"                # LIT-enclosed value
          |[^'\">\s]+                # bare value
         )
         (?:\s*(,))*                   # possibly followed by a comma
       )?
     )
   )*
  \s*                                # trailing whitespace
""", re.VERBOSE)
attrfind_tolerant = re.compile(
    r'\s*([a-zA-Z_][-.:a-zA-Z_0-9]*)(\s*=\s*'
    r'(\'[^\']*\'|"[^"]*"|[^>\s]*))?')


#s='<abc a="b,+"c="d"e=f>text'
#s='<abc a="b,+" c="d"e=f>text'
s='<abc a="b,+",c="d" e=f>text'

m = locatestarttagend_tolerant.search(s)
print m.group()
print m.groups()
#if m.group(1) is not None: self.warning('space missing ...
#if m.group(2) is not None: self.warning('comma between attr...

m = attrfind_tolerant.search(s, 5)
print m.group()
print m.groups()

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1486713>
_______________________________________

From report at bugs.python.org  Wed Nov 16 11:25:59 2011
From: report at bugs.python.org (=?utf-8?q?Michele_Orr=C3=B9?=)
Date: Wed, 16 Nov 2011 10:25:59 +0000
Subject: [issue13294] http.server: HEAD request should not return a body
In-Reply-To: <1319985642.06.0.787750282348.issue13294@psf.upfronthosting.co.za>
Message-ID: <1321439159.35.0.462682753814.issue13294@psf.upfronthosting.co.za>


Michele Orr? <maker.py at gmail.com> added the comment:

Well, actually SimpleHTTPRequesthandler extends BaseHTTPHandler with basic do_GET and do_HEAD methods.

Unittests for http.server shows that this behavior is intended, since: 
Traceback (most recent call last):
  File "Lib/test/test_httpservers.py", line 639, in <module>
    test_main()
  File "Lib/test/test_httpservers.py", line 633, in test_main
    SimpleHTTPRequestHandlerTestCase,
  File "/Users/maker/dev/cpython/Lib/test/support.py", line 1274, in run_unittest
    _run_suite(suite)
  File "/Users/maker/dev/cpython/Lib/test/support.py", line 1249, in _run_suite
    raise TestFailed(err)
test.support.TestFailed: Traceback (most recent call last):
  File "Lib/test/test_httpservers.py", line 273, in test_head
    self.check_status_and_reason(response, 200)
  File "Lib/test/test_httpservers.py", line 242, in check_status_and_reason
    self.assertEqual(response.status, status)
AssertionError: 501 != 200

So, imho this is not a bug. Anyway, I would propose a trivial patch to make http.server a little more elegant.

----------
keywords: +patch
nosy: +maker
Added file: http://bugs.python.org/file23711/issue13294.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13294>
_______________________________________

From report at bugs.python.org  Wed Nov 16 11:50:06 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 16 Nov 2011 10:50:06 +0000
Subject: [issue1486713] HTMLParser : A auto-tolerant parsing mode
Message-ID: <1321440606.95.0.494074313189.issue1486713@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Note that the regex and the way the parser considers the commas changed in 16ed15ff0d7c (it now considers them as the name of a value-less attribute), so adding a group for the comma is no longer doable.

In theory, the approach you suggest might work, but if we want some warning mechanism it should be generic enough to work with all kind of invalid markup.  In addition this adds complexity to already complex regular expressions, so there should be a valid use case for this.
Also keep in mind that HTMLParser won't do any check about the validity of the elements' names or attributes' names/values, or even if they are nested/closed correctly, so even with a comprehensive set of warnings, you won't still be able to use HTMLParser to validate your pages.

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1486713>
_______________________________________

From report at bugs.python.org  Wed Nov 16 12:29:49 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 16 Nov 2011 11:29:49 +0000
Subject: [issue9102] pybench: Cannot compare 2.x and 3.x benchmarks
In-Reply-To: <1277739722.07.0.677340784013.issue9102@psf.upfronthosting.co.za>
Message-ID: <1321442989.15.0.392613538036.issue9102@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti
versions: +Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9102>
_______________________________________

From report at bugs.python.org  Wed Nov 16 12:30:49 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 16 Nov 2011 11:30:49 +0000
Subject: [issue3693] Obscure array.array error message
In-Reply-To: <1219801896.33.0.491668230509.issue3693@psf.upfronthosting.co.za>
Message-ID: <1321443049.15.0.125217167454.issue3693@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti
versions: +Python 3.3 -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3693>
_______________________________________

From report at bugs.python.org  Wed Nov 16 12:38:02 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 16 Nov 2011 11:38:02 +0000
Subject: [issue13413] time.daylight incorrect behavior in linux glibc
In-Reply-To: <1321429764.54.0.0162746927464.issue13413@psf.upfronthosting.co.za>
Message-ID: <1321443482.88.0.81172501816.issue13413@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +belopolsky, lemburg

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13413>
_______________________________________

From report at bugs.python.org  Wed Nov 16 12:45:26 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 16 Nov 2011 11:45:26 +0000
Subject: [issue4246] execution model - clear and complete example in
	documentation
In-Reply-To: <1225551571.75.0.81232740458.issue4246@psf.upfronthosting.co.za>
Message-ID: <1321443926.1.0.609792070599.issue4246@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti
stage:  -> needs patch
versions: +Python 2.7, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4246>
_______________________________________

From report at bugs.python.org  Wed Nov 16 12:47:17 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 16 Nov 2011 11:47:17 +0000
Subject: [issue6304] Confusing error message when passing bytes to print with
	file pointing to a binary file
In-Reply-To: <1245293505.96.0.175038220478.issue6304@psf.upfronthosting.co.za>
Message-ID: <1321444037.66.0.467339129477.issue6304@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +pitrou
versions: +Python 3.3 -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6304>
_______________________________________

From report at bugs.python.org  Wed Nov 16 13:16:26 2011
From: report at bugs.python.org (kxroberto)
Date: Wed, 16 Nov 2011 12:16:26 +0000
Subject: [issue1486713] HTMLParser : A auto-tolerant parsing mode
Message-ID: <1321445786.44.0.978807070872.issue1486713@psf.upfronthosting.co.za>


kxroberto <kxroberto at users.sourceforge.net> added the comment:

16ed15ff0d7c was not in current stable py3.2 so I missed it..

When the comma is now raised as attribute name, then the problem is anyway moved to the higher level anyway - and is/can be handled easily there by usual methods.
(still I guess locatestarttagend_tolerant matches a free standing comma extra after an attribute)

"should be generic enough to work with all kind of invalid markup": I think we would be rather complete then (->missing space issue)- at least regarding %age of real cases. And it could be improved with few touches over time if something missing. 100% is not the point unless it shall drive the official W3C checker. The call of self.warning, as in old patch, doesn't cost otherwise and I see no real increase of complexity/cpu-time.

"HTMLParser won't do any check about the validity of the elements' names or attributes' names/values": yes thats of course up to the next level handler (BTDT)- thus the possibilty of error handling is not killed. Its about what HTMLParser _hides_ irrecoverably.

"there should be a valid use case for this": Almost any app which parses HTML (self authored or remote) can have (should have?) a no-fuzz/collateral warn log option. (->no need to make a expensive W3C checker session). I mostly have this in use as said, as it was anyway there.

Well, as for me, I use anyway a private backport to Python2 of this. I try to avoid Python3 as far as possible. (No real plus, too much problems) So for me its just about joining Python4 in the future perhaps - which can do true CPython multithreading, stackless, psyco/static typing ... and print statement again without typing so many extra braces ;-)
I considered extra libs like the HTML tidy binding, but this is all too much fuzz for most cases. And HTMLParser has already quite everything, with the few calls inserted ..

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1486713>
_______________________________________

From report at bugs.python.org  Wed Nov 16 14:17:03 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 16 Nov 2011 13:17:03 +0000
Subject: [issue1486713] HTMLParser : A auto-tolerant parsing mode
Message-ID: <1321449423.33.0.194209888399.issue1486713@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

> 16ed15ff0d7c was not in current stable py3.2 so I missed it..

It's also in 3.2 and 2.7 (but it's quite recent, so if you didn't pull recently you might have missed it).

> When the comma is now raised as attribute name, then the problem is 
> anyway moved to the higher level anyway - and is/can be handled easily 
> there by usual methods.

The next level could/should validate the name of the attribute and determine that ',' is not a valid attribute name, so in this case there's no warning to raise here (actually you could detect that it's not a-zA-Z (or whatever the specs say) and raise a more general warning even at this level, but no information is lost here about this).

> 100% is not the point unless it shall drive the official W3C checker.

I'm still not sure that having 70-80% is useful (unless we can achieve 100% on this level and leave the rest to an upper layer).  If you think this is doable you could try to first identify what errors should be detected by this layer, see if they are all detectable and then propose a patch.

> The call of self.warning, as in old patch, doesn't cost otherwise and
> I see no real increase of complexity/cpu-time.

The extra complexity is mainly in the already complex regular expressions, and also in the list of 'if' that will have to check the content of the groups to report the warnings.  These changes are indeed not too invasive, but they still make the code more complicated.

> Almost any app which parses HTML (self authored or remote) can have 
> (should have?) a no-fuzz/collateral warn log option. (->no need to 
> make a expensive W3C checker session).

I think the original goal of HTMLParser was parsing mostly-valid HTML.  People started reporting issues with less-valid HTML, and these issues got fixed to make it able to parse non-valid HTML.  AFAIK it never followed strictly any HTML standard, and it just provided a best-effort way to get data out of an HTML page.  So, I would consider doing validation or even being a building block for a conforming parser out of the scope of the module.

> I mostly have this in use as said, as it was anyway there.

If 'this' refers to some kind of warning system, what do you do with these warnings?   Do you fix them, avoid using the w3c validator (or any other conforming validator) and consider a mostly-valid page good enough?  Or do you fix them, and then you also check with the w3c validator?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1486713>
_______________________________________

From report at bugs.python.org  Wed Nov 16 14:27:39 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 16 Nov 2011 13:27:39 +0000
Subject: [issue1481032] patch smtplib:when SMTPDataError,
	rset crashes with sslerror
Message-ID: <1321450059.33.0.317979905359.issue1481032@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +barry, r.david.murray -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1481032>
_______________________________________

From report at bugs.python.org  Wed Nov 16 15:02:30 2011
From: report at bugs.python.org (ipatrol)
Date: Wed, 16 Nov 2011 14:02:30 +0000
Subject: [issue4508] distutils compiler not handling spaces in path to
	output/src files
In-Reply-To: <1228341537.43.0.522254260997.issue4508@psf.upfronthosting.co.za>
Message-ID: <1321452150.17.0.140995704061.issue4508@psf.upfronthosting.co.za>


ipatrol <ipatrol6010 at yahoo.com> added the comment:

Ok, I found a similar problem with MMTK. I am currently altering my distutils package to add a function called nt_quote_dir that adds quotes to paths with spaces and then applies it to each path if the platform is win32. When I'm done I will submit a diff after confirming that it works.

----------
components: +Extension Modules, Windows
nosy: +ipatrol

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4508>
_______________________________________

From report at bugs.python.org  Wed Nov 16 16:03:34 2011
From: report at bugs.python.org (Florent Xicluna)
Date: Wed, 16 Nov 2011 15:03:34 +0000
Subject: [issue9102] pybench: Cannot compare 2.x and 3.x benchmarks
In-Reply-To: <1277739722.07.0.677340784013.issue9102@psf.upfronthosting.co.za>
Message-ID: <1321455814.56.0.96905811245.issue9102@psf.upfronthosting.co.za>


Changes by Florent Xicluna <florent.xicluna at gmail.com>:


----------
nosy: +flox

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9102>
_______________________________________

From report at bugs.python.org  Wed Nov 16 17:35:20 2011
From: report at bugs.python.org (Florent Xicluna)
Date: Wed, 16 Nov 2011 16:35:20 +0000
Subject: [issue13309] test_time fails: time data 'LMT' does not match format
	'%Z'
In-Reply-To: <1320156304.27.0.1872899991.issue13309@psf.upfronthosting.co.za>
Message-ID: <1321461320.37.0.95075628172.issue13309@psf.upfronthosting.co.za>


Changes by Florent Xicluna <florent.xicluna at gmail.com>:


----------
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13309>
_______________________________________

From report at bugs.python.org  Wed Nov 16 17:41:28 2011
From: report at bugs.python.org (Florent Xicluna)
Date: Wed, 16 Nov 2011 16:41:28 +0000
Subject: [issue13126] find() slower than rfind()
In-Reply-To: <1318016796.03.0.16031959225.issue13126@psf.upfronthosting.co.za>
Message-ID: <1321461688.66.0.797700468706.issue13126@psf.upfronthosting.co.za>


Changes by Florent Xicluna <florent.xicluna at gmail.com>:


----------
priority: low -> normal
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13126>
_______________________________________

From report at bugs.python.org  Wed Nov 16 17:45:41 2011
From: report at bugs.python.org (Florent Xicluna)
Date: Wed, 16 Nov 2011 16:45:41 +0000
Subject: [issue8913] Document that datetime.__format__ is datetime.strftime
In-Reply-To: <1275794779.99.0.00462382173098.issue8913@psf.upfronthosting.co.za>
Message-ID: <1321461941.18.0.0450981613989.issue8913@psf.upfronthosting.co.za>


Changes by Florent Xicluna <florent.xicluna at gmail.com>:


----------
type:  -> behavior
versions: +Python 3.3 -Python 2.6, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8913>
_______________________________________

From report at bugs.python.org  Wed Nov 16 19:02:30 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 16 Nov 2011 18:02:30 +0000
Subject: [issue6715] xz compressor support
In-Reply-To: <1250502444.31.0.107447392137.issue6715@psf.upfronthosting.co.za>
Message-ID: <1321466550.75.0.918970858746.issue6715@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

What is the status on this, Nadeem? It would be lovely to get the feature in the stdlib.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6715>
_______________________________________

From report at bugs.python.org  Wed Nov 16 19:43:53 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 16 Nov 2011 18:43:53 +0000
Subject: [issue6715] xz compressor support
In-Reply-To: <1250502444.31.0.107447392137.issue6715@psf.upfronthosting.co.za>
Message-ID: <1321469033.2.0.758580801639.issue6715@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

I just added the missing files liblzma.a to the "externals" repository.
If someone can quickly check that it works on win32, I don't have anything else to add to this change.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6715>
_______________________________________

From report at bugs.python.org  Wed Nov 16 20:10:01 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Wed, 16 Nov 2011 19:10:01 +0000
Subject: [issue6715] xz compressor support
In-Reply-To: <1250502444.31.0.107447392137.issue6715@psf.upfronthosting.co.za>
Message-ID: <1321470601.09.0.55425807664.issue6715@psf.upfronthosting.co.za>


Nadeem Vawda <nadeem.vawda at gmail.com> added the comment:

Everything is ready to go, as far as I'm concerned. Once I've tested the
Windows build using the binary from the externals repository, I'll be ready
to commit it to the main repository.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6715>
_______________________________________

From report at bugs.python.org  Wed Nov 16 22:18:22 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Wed, 16 Nov 2011 21:18:22 +0000
Subject: [issue6715] xz compressor support
In-Reply-To: <1250502444.31.0.107447392137.issue6715@psf.upfronthosting.co.za>
Message-ID: <1321478302.15.0.731374515781.issue6715@psf.upfronthosting.co.za>


Nadeem Vawda <nadeem.vawda at gmail.com> added the comment:

I've tested the Windows build, and it works fine. If there are no objections,
I'll commit on Saturday.

Btw, what is the preferred channel for communicating with buildbot owners?
I'll want to send out an email asking that all the *nix bots have
liblzma-dev installed, so that they can actually run the tests...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6715>
_______________________________________

From report at bugs.python.org  Wed Nov 16 23:14:48 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 16 Nov 2011 22:14:48 +0000
Subject: [issue13415] os.unsetenv() on Windows should not use UTF-8
Message-ID: <1321481687.96.0.070295281604.issue13415@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

os.unsetenv(name) encodes name to UTF-8. I think that the ANSI code page (or another code page?) should be used.

----------
components: Unicode, Windows
messages: 147773
nosy: ezio.melotti, haypo
priority: normal
severity: normal
status: open
title: os.unsetenv() on Windows should not use UTF-8
versions: Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13415>
_______________________________________

From report at bugs.python.org  Wed Nov 16 23:23:34 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 16 Nov 2011 22:23:34 +0000
Subject: [issue13064] Port codecs and error handlers to the new Unicode API
In-Reply-To: <1317330548.17.0.268887391547.issue13064@psf.upfronthosting.co.za>
Message-ID: <1321482214.06.0.430692798613.issue13064@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Martin von Loewis implemented this issue, thanks Martin!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13064>
_______________________________________

From report at bugs.python.org  Wed Nov 16 23:23:56 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 16 Nov 2011 22:23:56 +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: <1321482236.41.0.482813962683.issue7732@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/issue7732>
_______________________________________

From report at bugs.python.org  Wed Nov 16 23:42:48 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 16 Nov 2011 22:42:48 +0000
Subject: [issue13374] Deprecate usage of the Windows ANSI API in the nt module
In-Reply-To: <1320797406.95.0.49629588961.issue13374@psf.upfronthosting.co.za>
Message-ID: <E1RQoBa-0004Ml-Sw@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 5f239b0ba819 by Victor Stinner in branch 'default':
Issue #13374: Deprecate os.getcwdb() on Windows
http://hg.python.org/cpython/rev/5f239b0ba819

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13374>
_______________________________________

From report at bugs.python.org  Wed Nov 16 23:44:04 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 16 Nov 2011 22:44:04 +0000
Subject: [issue12729] Python lib re cannot handle Unicode properly due to
	narrow/wide bug
In-Reply-To: <1313089435.8.0.838915767835.issue12729@psf.upfronthosting.co.za>
Message-ID: <1321483444.16.0.385595491934.issue12729@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Closing this bug as PEP 393 is now implemented and makes so-called "narrow builds" obsolete. Python now has an adaptative internal representation that is able to fit all unicode characters.

----------
resolution:  -> out of date
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12729>
_______________________________________

From report at bugs.python.org  Wed Nov 16 23:44:16 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 16 Nov 2011 22:44:16 +0000
Subject: [issue13374] Deprecate usage of the Windows ANSI API in the nt module
In-Reply-To: <1320797406.95.0.49629588961.issue13374@psf.upfronthosting.co.za>
Message-ID: <1321483456.82.0.889559184992.issue13374@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/issue13374>
_______________________________________

From report at bugs.python.org  Wed Nov 16 23:48:13 2011
From: report at bugs.python.org (Nebelhom)
Date: Wed, 16 Nov 2011 22:48:13 +0000
Subject: [issue13416] Python Tutorial, Section 3, Minor PEP 8 adjustment
Message-ID: <1321483693.18.0.17340985314.issue13416@psf.upfronthosting.co.za>


New submission from Nebelhom <nebelhom at googlemail.com>:

Python Tutorial 3.3a

3. An informal introduction to python

example:

-------------------------------------------------------------
# this is the first comment
SPAM = 1                 # and this is the second comment
                         # ... and now a third!
STRING = "# This is not a comment."
-------------------------------------------------------------

Comment: It is probably best to use PEP 8 straight from the start.
Therefore variable names should be all lowercase with connecting underscores (if necessary)

i.e. spam = 1 and string = "#This is not a comment." instead of all uppercase.

----------
assignee: docs at python
components: Documentation
messages: 147777
nosy: Nebelhom, docs at python, ncoghlan
priority: normal
severity: normal
status: open
title: Python Tutorial, Section 3, Minor PEP 8 adjustment
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13416>
_______________________________________

From report at bugs.python.org  Wed Nov 16 23:49:42 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 16 Nov 2011 22:49:42 +0000
Subject: [issue13417] faster utf-8 decoding
Message-ID: <1321483781.85.0.24668666063.issue13417@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

PEP 393 and the need for a two-pass decoding process has made utf-8 decoding much slower, especially with the current generic implementation. Attached patch makes utf-8 more than twice faster, which means we're around 10-20% slower than 3.2 on non-trivial cases.

----------
components: Interpreter Core
files: utf8lib2.patch
keywords: patch
messages: 147778
nosy: haypo, pitrou
priority: normal
severity: normal
stage: patch review
status: open
title: faster utf-8 decoding
type: performance
versions: Python 3.3
Added file: http://bugs.python.org/file23712/utf8lib2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13417>
_______________________________________

From report at bugs.python.org  Thu Nov 17 00:12:10 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 16 Nov 2011 23:12:10 +0000
Subject: [issue13416] Python Tutorial, Section 3, Minor PEP 8 adjustment
In-Reply-To: <1321483693.18.0.17340985314.issue13416@psf.upfronthosting.co.za>
Message-ID: <1321485130.69.0.143817018959.issue13416@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

It's fine as it is; constants are often denoted with capital letters.

----------
nosy: +benjamin.peterson
resolution:  -> rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13416>
_______________________________________

From report at bugs.python.org  Thu Nov 17 00:53:08 2011
From: report at bugs.python.org (Marc Sibson)
Date: Wed, 16 Nov 2011 23:53:08 +0000
Subject: [issue10772] Several actions for argparse arguments missing from docs
In-Reply-To: <1293327184.11.0.454888760887.issue10772@psf.upfronthosting.co.za>
Message-ID: <1321487588.94.0.6761316265.issue10772@psf.upfronthosting.co.za>


Marc Sibson <sibson at gmail.com> added the comment:

changes as per the review,

----------
Added file: http://bugs.python.org/file23713/issue10772.patch3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10772>
_______________________________________

From report at bugs.python.org  Thu Nov 17 01:06:56 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 17 Nov 2011 00:06:56 +0000
Subject: [issue13415] os.unsetenv() on Windows should not use UTF-8
In-Reply-To: <1321481687.96.0.070295281604.issue13415@psf.upfronthosting.co.za>
Message-ID: <1321488416.03.0.939163164524.issue13415@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

But... there is no os.unsetenv on Windows!
2.7 used to have one, which called os.putenv(key, "")
3.2 has a os._unsetenv, which is a lambda key: _putenv(key, "")

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13415>
_______________________________________

From report at bugs.python.org  Thu Nov 17 01:32:56 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 17 Nov 2011 00:32:56 +0000
Subject: [issue13215] multiprocessing Manager.connect() aggressively retries
	refused connections
In-Reply-To: <1318965417.81.0.122561387998.issue13215@psf.upfronthosting.co.za>
Message-ID: <1321489976.2.0.945436657104.issue13215@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Apparently you forgot to upload the patch...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13215>
_______________________________________

From report at bugs.python.org  Thu Nov 17 01:45:42 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 17 Nov 2011 00:45:42 +0000
Subject: [issue13415] del os.environ[key] ignores errors
In-Reply-To: <1321481687.96.0.070295281604.issue13415@psf.upfronthosting.co.za>
Message-ID: <1321490742.62.0.303878841436.issue13415@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> But... there is no os.unsetenv on Windows!

Correct, even unsetenv() doesn't exist on Windows: putenv() can be used to unset a variable using an empty value. And it's exactly what Python does.

It is confusing because posix_unsetenv() is not build on Windows, but it contains code specific for Windows.

While testing del os.environ[key], I found another bug: del os.environ['x'*50000] does crash Python on Windows.

Attached patch (for Python 3.3) does:

 - Remove the Windows specific code from posix_unsetenv()
 - Check if unsetenv() failed on UNIX
 - Check environment variable length on Windows

The Windows bug does affect Python 2.7 too. "Check if unsetenv() failed on UNIX" change may be skipped on Python 2.7 and 3.2.

----------
keywords: +patch
title: os.unsetenv() on Windows should not use UTF-8 -> del os.environ[key] ignores errors
versions: +Python 2.7
Added file: http://bugs.python.org/file23714/unsetenv.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13415>
_______________________________________

From report at bugs.python.org  Thu Nov 17 01:49:53 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 17 Nov 2011 00:49:53 +0000
Subject: [issue6715] xz compressor support
In-Reply-To: <1250502444.31.0.107447392137.issue6715@psf.upfronthosting.co.za>
Message-ID: <1321490993.02.0.474758705024.issue6715@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I've tested under 64-bit Windows and it worked fine.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6715>
_______________________________________

From report at bugs.python.org  Thu Nov 17 01:57:33 2011
From: report at bugs.python.org (Asesh)
Date: Thu, 17 Nov 2011 00:57:33 +0000
Subject: [issue13418] Embedded Python memory leak
Message-ID: <1321491453.86.0.929770076277.issue13418@psf.upfronthosting.co.za>


New submission from Asesh <aseshshres at gmail.com>:

Well I just finished embedding Python in my application but even after calling Py_Finalize the debugger shows tons of memory leak. I just called Py_Initialize and then Py_Finalize then after exiting the application, the Visual C++ debugger shows tons of memory leaks and Python is to be blamed:

Detected memory leaks!
Dumping objects ->
{3478} normal block at 0x00000000026343E0, 912 bytes long.
 Data: <       po       > 00 00 00 00 00 00 03 70 6F FB FB FB FB FB FB FB 
{3476} normal block at 0x0000000002633DA0, 912 bytes long.
 Data: <       po       > 00 00 00 00 00 00 03 70 6F FB FB FB FB FB FB FB 
{3474} normal block at 0x000000000261AC70, 912 bytes long.
 Data: <       po       > 00 00 00 00 00 00 03 70 6F FB FB FB FB FB FB FB 
{3472} normal block at 0x000000000261A620, 912 bytes long.
 Data: <       po       > 00 00 00 00 00 00 03 70 6F FB FB FB FB FB FB FB 
{3471} normal block at 0x000000000261B540, 912 bytes long.
 Data: <       po       > 00 00 00 00 00 00 03 70 6F FB FB FB FB FB FB FB 
{3470} normal block at 0x00000000025C66B0, 800 bytes long.
 Data: <        m       > 00 00 00 00 00 00 03 00 6D FB FB FB FB FB FB FB 
... // Skipped posting more memory leaks
...

{63} normal block at 0x0000000001D927D0, 108 bytes long.
 Data: <C : \ U s e r s > 43 00 3A 00 5C 00 55 00 73 00 65 00 72 00 73 00 
Object dump complete.
The program '[6696] cScripting.exe: Native' has exited with code 0 (0x0).

Upon Googling, seems like am not the only one. I have attached a small project that demonstrates it. It's a x64 build and you'll have to adjust the path of the lib folder

----------
files: cScripting.zip
messages: 147785
nosy: Asesh
priority: normal
severity: normal
status: open
title: Embedded Python memory leak
type: behavior
versions: Python 3.2
Added file: http://bugs.python.org/file23715/cScripting.zip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13418>
_______________________________________

From report at bugs.python.org  Thu Nov 17 02:00:30 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 17 Nov 2011 01:00:30 +0000
Subject: [issue13418] Embedded Python memory leak
In-Reply-To: <1321491453.86.0.929770076277.issue13418@psf.upfronthosting.co.za>
Message-ID: <1321491630.84.0.0790445854557.issue13418@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

(The project example uses _CrtSetDbgFlag(_CRTDBG_LEAK_CHECK_DF | _CRTDBG_ALLOC_MEM_DF) to perform memory leak check.)

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13418>
_______________________________________

From report at bugs.python.org  Thu Nov 17 02:39:04 2011
From: report at bugs.python.org (Joshua Bleecher Snyder)
Date: Thu, 17 Nov 2011 01:39:04 +0000
Subject: [issue706546] u''.translate not documented
Message-ID: <1321493944.08.0.118618481362.issue706546@psf.upfronthosting.co.za>


Joshua Bleecher Snyder <josharian at gmail.com> added the comment:

This documentation change didn't make it into the docs for translate in the string module -- see http://docs.python.org/library/string.html. It'd be great to add it there as well, as I just got bitten by this. :)

----------
nosy: +josharian

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue706546>
_______________________________________

From report at bugs.python.org  Thu Nov 17 02:42:00 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 17 Nov 2011 01:42:00 +0000
Subject: [issue12627] Implement PEP 394: The "python" Command on Unix-Like
	Systems
In-Reply-To: <1311474695.62.0.740113282168.issue12627@psf.upfronthosting.co.za>
Message-ID: <1321494120.72.0.410690393346.issue12627@psf.upfronthosting.co.za>


Changes by Nick Coghlan <ncoghlan at gmail.com>:


----------
nosy: +ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12627>
_______________________________________

From report at bugs.python.org  Thu Nov 17 02:45:29 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Thu, 17 Nov 2011 01:45:29 +0000
Subject: [issue13418] Embedded Python memory leak
In-Reply-To: <1321491453.86.0.929770076277.issue13418@psf.upfronthosting.co.za>
Message-ID: <1321494329.05.0.907740173864.issue13418@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/issue13418>
_______________________________________

From report at bugs.python.org  Thu Nov 17 02:48:24 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 17 Nov 2011 01:48:24 +0000
Subject: [issue6715] xz compressor support
In-Reply-To: <1250502444.31.0.107447392137.issue6715@psf.upfronthosting.co.za>
Message-ID: <1321494504.52.0.549448930108.issue6715@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

I wrote a short review on http://bugs.python.org/review/6715/show

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6715>
_______________________________________

From report at bugs.python.org  Thu Nov 17 03:32:59 2011
From: report at bugs.python.org (Alex Regueiro)
Date: Thu, 17 Nov 2011 02:32:59 +0000
Subject: [issue13419] import does not recognise SYMLINKDs on Windows 7
Message-ID: <1321497179.79.0.443731710828.issue13419@psf.upfronthosting.co.za>


New submission from Alex Regueiro <alexreg at gmail.com>:

Python 2.7 normally inputs directory-modules fine on Windows 7. The notable exception however is symbolically-linked directories on the filesystem, which are ignored (not thought to exist) by the Python `import` statement. (Note that the Python interpreter normally has no problem with symlinks on Win7 with its file I/O features.)

----------
messages: 147789
nosy: alexreg
priority: normal
severity: normal
status: open
title: import does not recognise SYMLINKDs on Windows 7
type: feature request
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13419>
_______________________________________

From report at bugs.python.org  Thu Nov 17 05:41:49 2011
From: report at bugs.python.org (Per Rosengren)
Date: Thu, 17 Nov 2011 04:41:49 +0000
Subject: [issue12013] file
	/usr/local/lib/python3.1/lib-dynload/_socket.so:	symbol
	inet_aton: referenced symbol not found
In-Reply-To: <1304644585.52.0.347221630935.issue12013@psf.upfronthosting.co.za>
Message-ID: <1321504909.81.0.681310521069.issue12013@psf.upfronthosting.co.za>


Per Rosengren <per.rosengren at gmail.com> added the comment:

On Linux:
>nm -C /lib/libc.so.6 |grep ' inet_aton'
00000000000cbce0 W inet_aton

This means that when Python is build with GCC (like on linux), inet_aton
is in system libc. 

If you build with GCC in solaris, inet_aton will be taken from the GCC lib dir. You need to put that GCC lib dir in your LD_LIBRARY_PATH when you run Python.

----------
nosy: +Per.Rosengren

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12013>
_______________________________________

From report at bugs.python.org  Thu Nov 17 09:05:16 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 17 Nov 2011 08:05:16 +0000
Subject: [issue13418] Embedded Python memory leak
In-Reply-To: <1321491453.86.0.929770076277.issue13418@psf.upfronthosting.co.za>
Message-ID: <1321517116.72.0.897748028258.issue13418@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

These are not memory leaks, but global state that the Python interpreter does not bother to free on exit. The amount of memory there is limited.

Yes, I agree that this makes the basic memory checker built in Visual Studio completely useless.

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13418>
_______________________________________

From report at bugs.python.org  Thu Nov 17 09:44:40 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 17 Nov 2011 08:44:40 +0000
Subject: [issue13416] Python Tutorial, Section 3, Minor PEP 8 adjustment
In-Reply-To: <1321483693.18.0.17340985314.issue13416@psf.upfronthosting.co.za>
Message-ID: <1321519480.32.0.555385971911.issue13416@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
stage:  -> committed/rejected

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13416>
_______________________________________

From report at bugs.python.org  Thu Nov 17 10:00:24 2011
From: report at bugs.python.org (Tim Golden)
Date: Thu, 17 Nov 2011 09:00:24 +0000
Subject: [issue13419] import does not recognise SYMLINKDs on Windows 7
In-Reply-To: <1321497179.79.0.443731710828.issue13419@psf.upfronthosting.co.za>
Message-ID: <1321520424.82.0.28717597425.issue13419@psf.upfronthosting.co.za>


Changes by Tim Golden <mail at timgolden.me.uk>:


----------
nosy: +brian.curtin, jason.coombs, tim.golden

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13419>
_______________________________________

From report at bugs.python.org  Thu Nov 17 11:23:54 2011
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 17 Nov 2011 10:23:54 +0000
Subject: [issue13406] Deprecation warnings when running the test suite
In-Reply-To: <1321312320.0.0.525763918067.issue13406@psf.upfronthosting.co.za>
Message-ID: <E1RQz89-00088v-Ug@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset fe2be7d35660 by Ezio Melotti in branch 'default':
#13406: fix more deprecation warnings and move the deprecation of unicode-internal earlier in the code.
http://hg.python.org/cpython/rev/fe2be7d35660

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13406>
_______________________________________

From report at bugs.python.org  Thu Nov 17 11:37:34 2011
From: report at bugs.python.org (Asesh)
Date: Thu, 17 Nov 2011 10:37:34 +0000
Subject: [issue13418] Embedded Python memory leak
In-Reply-To: <1321491453.86.0.929770076277.issue13418@psf.upfronthosting.co.za>
Message-ID: <1321526254.9.0.533127647708.issue13418@psf.upfronthosting.co.za>


Asesh <aseshshres at gmail.com> added the comment:

ok thanks for the replies. Actually I have python embedded in my game but now the real problem now is how do I differentiate from the real memory leak caused either by Python or by my application? Disabling memory leak check is not an option since it's been very helpful when debugging my C++ apps

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13418>
_______________________________________

From report at bugs.python.org  Thu Nov 17 12:23:59 2011
From: report at bugs.python.org (David Amian)
Date: Thu, 17 Nov 2011 11:23:59 +0000
Subject: [issue13420] newer() function in dep_util.py discard changes in the
	same second
Message-ID: <1321529038.98.0.0841934486822.issue13420@psf.upfronthosting.co.za>


New submission from David Amian <damian at emergya.com>:

Hi, I had a problem making deb packages with distutils and cdbs. Looking for any solution, I found Issue 11933 and saw that the newer() method has been changed, using [ST_MTIME] instead of st_mtime. This commit is to solve Issue 10148 that describes a bug when copying files with python, it depends on the filesystem.

In these changes, modification time of files are checked as a integer, discarding the millisec. It makes the issue.

For example, I've a file that is modified with an installation prefix. CDBS runs the build step and after the install step. In build step, the prefix is '/usr/local' because the prefix argument isn't supported, immediately the install step runs with prefix='/usr', so the file that contains a variable with project path modified with the prefix is not copied by distutils, it runs in a different millisec but in the same second.

Then when install my app, it crashes because the variable with project path is '/usr/local' instead of '/usr' and this variable is used in the source.

To solve this problem I made ??some modifications on file_util.py and dep_util.py files, I revert the changes of the issue 11933, but rounding all times returned by stat() with two decimals. With that changes, distutils is not affected by the Issue 10148 and if any file is modified in the same second, but in different millisec, distutils will compare it and it wil copy the file.

----------
assignee: tarek
components: Distutils
files: fix_mtime.diff
keywords: patch
messages: 147794
nosy: d.amian, eric.araujo, tarek
priority: normal
severity: normal
status: open
title: newer() function in dep_util.py discard changes in the same second
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file23716/fix_mtime.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13420>
_______________________________________

From report at bugs.python.org  Thu Nov 17 13:11:29 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Thu, 17 Nov 2011 12:11:29 +0000
Subject: [issue13349] Uninformal error message in index() and remove()
	functions
In-Reply-To: <1320526177.89.0.678573577515.issue13349@psf.upfronthosting.co.za>
Message-ID: <1321531889.76.0.823248939752.issue13349@psf.upfronthosting.co.za>


Petri Lehtinen <petri at digip.org> added the comment:

?ric Araujo wrote:
> > On the other hand, the repr of a value might be very long:
> You can restrict the length with % formats.

Seems you can't with %R. I'd also like to somehow indicate that
the output is truncated.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13349>
_______________________________________

From report at bugs.python.org  Thu Nov 17 15:38:29 2011
From: report at bugs.python.org (Brian Curtin)
Date: Thu, 17 Nov 2011 14:38:29 +0000
Subject: [issue13419] import does not recognise SYMLINKDs on Windows 7
In-Reply-To: <1321497179.79.0.443731710828.issue13419@psf.upfronthosting.co.za>
Message-ID: <1321540709.5.0.24763604444.issue13419@psf.upfronthosting.co.za>


Brian Curtin <brian at python.org> added the comment:

Duplicate of #6727

----------
resolution:  -> duplicate
stage:  -> committed/rejected
status: open -> closed
superseder:  -> ImportError when package is symlinked on Windows

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13419>
_______________________________________

From report at bugs.python.org  Thu Nov 17 15:45:23 2011
From: report at bugs.python.org (Jason R. Coombs)
Date: Thu, 17 Nov 2011 14:45:23 +0000
Subject: [issue6727] ImportError when package is symlinked on Windows
In-Reply-To: <1250608383.93.0.471187637916.issue6727@psf.upfronthosting.co.za>
Message-ID: <1321541123.97.0.233518153598.issue6727@psf.upfronthosting.co.za>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

If this issue is important to you, please follow the link above to the Microsoft Connect site and vote for the issue. More votes should mean it will get more attention. Thanks.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6727>
_______________________________________

From report at bugs.python.org  Thu Nov 17 15:45:47 2011
From: report at bugs.python.org (Alex Regueiro)
Date: Thu, 17 Nov 2011 14:45:47 +0000
Subject: [issue6727] ImportError when package is symlinked on Windows
In-Reply-To: <1250608383.93.0.471187637916.issue6727@psf.upfronthosting.co.za>
Message-ID: <1321541147.26.0.110252438588.issue6727@psf.upfronthosting.co.za>


Alex Regueiro <alexreg at gmail.com> added the comment:

Is this bug going to be fixed? I've been experiencing this for some time now, and it seems the Python team has known about it for a while too... seems like an easy fix!

----------
nosy: +alexreg

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6727>
_______________________________________

From report at bugs.python.org  Thu Nov 17 15:50:43 2011
From: report at bugs.python.org (Brian Curtin)
Date: Thu, 17 Nov 2011 14:50:43 +0000
Subject: [issue6727] ImportError when package is symlinked on Windows
In-Reply-To: <1250608383.93.0.471187637916.issue6727@psf.upfronthosting.co.za>
Message-ID: <1321541443.7.0.510231527757.issue6727@psf.upfronthosting.co.za>


Brian Curtin <brian at python.org> added the comment:

Not fixed, but if it's easy, you're welcome to fix it before we get around to it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6727>
_______________________________________

From report at bugs.python.org  Thu Nov 17 15:52:20 2011
From: report at bugs.python.org (Alex Regueiro)
Date: Thu, 17 Nov 2011 14:52:20 +0000
Subject: [issue6727] ImportError when package is symlinked on Windows
In-Reply-To: <1250608383.93.0.471187637916.issue6727@psf.upfronthosting.co.za>
Message-ID: <1321541540.56.0.0237152343955.issue6727@psf.upfronthosting.co.za>


Alex Regueiro <alexreg at gmail.com> added the comment:

Well, I am making an assumption here. :-)

Might have a look at a patch. Never looked at the Python runtime before. If it's all written in C, then it's possible. I'm guessing most of the Python programmers don't know much/anything about Win32 programming, so that probably explains the delay.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6727>
_______________________________________

From report at bugs.python.org  Thu Nov 17 15:58:06 2011
From: report at bugs.python.org (Brian Curtin)
Date: Thu, 17 Nov 2011 14:58:06 +0000
Subject: [issue6727] ImportError when package is symlinked on Windows
In-Reply-To: <1250608383.93.0.471187637916.issue6727@psf.upfronthosting.co.za>
Message-ID: <1321541886.76.0.315379756151.issue6727@psf.upfronthosting.co.za>


Brian Curtin <brian at python.org> added the comment:

There are a few of us, and Jason and myself have done most of the Windows symlink related work. We'll certainly get to this and have it fixed, but with no releases on the immediate horizon, there isn't a rush. This and your other symlink issue are on my radar for things to make sure we cover.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6727>
_______________________________________

From report at bugs.python.org  Thu Nov 17 15:59:29 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Thu, 17 Nov 2011 14:59:29 +0000
Subject: [issue13405] Add DTrace probes
In-Reply-To: <1321299726.66.0.343368151185.issue13405@psf.upfronthosting.co.za>
Message-ID: <1321541969.02.0.751269683599.issue13405@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

The LD_LIBRARY_PATH is because I am compiling Python as a shared lib and, of course, I am not installing the development version in the usual system path.

That is, it is not a requirement for this project, but an easy to follow procedure for unexperienced betatesters.

About the permissions, the situation is messy because under Solaris a regular user can not run dtrace unless special permissions be assigned to her. The situation is something like this: (talking about Solaris 10):

* Global Zone:
 - root: dtrace works.
 - Regular user: dtrace is going to show a "permission denied" error, unless an admin had set dtrace user/proc permissions to him. If that is the case, it works.

* Non Global Zone:
 - root: dtrace seems to work, but no probes can be found unless special dtrace user/proc permissions are assigned to the zone.
 - regular user: dtrace is going to show a "permission denied" error, unless an admin had set dtrace user/proc permissions to him. In that case, it will behave like "root". That is, no probes found unles the zone have the right capabilities.

The permission denied error can be easily detected and managed, but the "silent" error is not distinguible of this project not working. I am thinking about trying first an "always present" well known probe, to detect when the kernel is activelly ignoring dtrace instead of giving a clear permission error.

I have requested to the sysadmins of my OpenIndiana buildbots to activate dtrace (of user code) in my zone, so I can evaluate the behaviour under OpenIndiana/Illumos.

A couple of details I want to document here, to remember then and to ask for advice:

- I have added a "sys.trace_capabilities", so a program can know if any system-trace functionality is compiled in. Current values are "None" and "("dtrace", "Sun")". Maybe create a new "dtrace" module could be appropiate, instead, with "dtrace.supported=True/False", but I am thinking about future MacOS probes, Linux "systemtap" probes, etc.

- Current code only traces function calls *TO* Python code. If the function calls is to C code (os.getpid(), for instance), the call is not visible. I think this is a major deficience, apparently shared by all the previous attempts I have seen (including official Sun probes).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13405>
_______________________________________

From report at bugs.python.org  Thu Nov 17 16:00:13 2011
From: report at bugs.python.org (Alex Regueiro)
Date: Thu, 17 Nov 2011 15:00:13 +0000
Subject: [issue6727] ImportError when package is symlinked on Windows
In-Reply-To: <1250608383.93.0.471187637916.issue6727@psf.upfronthosting.co.za>
Message-ID: <1321542013.85.0.846886714291.issue6727@psf.upfronthosting.co.za>


Alex Regueiro <alexreg at gmail.com> added the comment:

Thanks Brian; that's good to know. If we could get it in the next release (Python 2.8?) that would be awesome.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6727>
_______________________________________

From report at bugs.python.org  Thu Nov 17 16:05:35 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 17 Nov 2011 15:05:35 +0000
Subject: [issue13405] Add DTrace probes
In-Reply-To: <1321299726.66.0.343368151185.issue13405@psf.upfronthosting.co.za>
Message-ID: <1321542335.14.0.927993458263.issue13405@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13405>
_______________________________________

From report at bugs.python.org  Thu Nov 17 16:25:11 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 17 Nov 2011 15:25:11 +0000
Subject: [issue13357] HTMLParser parses attributes incorrectly.
In-Reply-To: <1320606546.64.0.752508532419.issue13357@psf.upfronthosting.co.za>
Message-ID: <1321543511.43.0.795623491706.issue13357@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

I verified with the red_test.html you provided and now HTMLParser seems to parse everything correctly, so I'm closing this.

----------
resolution:  -> fixed
stage: test needed -> committed/rejected
status: open -> closed
versions: +Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13357>
_______________________________________

From report at bugs.python.org  Thu Nov 17 16:31:38 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 17 Nov 2011 15:31:38 +0000
Subject: [issue6727] ImportError when package is symlinked on Windows
In-Reply-To: <1250608383.93.0.471187637916.issue6727@psf.upfronthosting.co.za>
Message-ID: <1321543898.19.0.193540426261.issue6727@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

> If we could get it in the next release (Python 2.8?) that would be awesome.
I doubt it will (see PEP 404) but 3.3 is a good target.

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6727>
_______________________________________

From report at bugs.python.org  Thu Nov 17 16:36:58 2011
From: report at bugs.python.org (Michael Brooks)
Date: Thu, 17 Nov 2011 15:36:58 +0000
Subject: [issue13358] HTMLParser incorrectly handles cdata elements.
In-Reply-To: <CACDSwD=tCRJGbSXFtpnWdxsTZG4mAMDCrnnq2h3X=dvGUX9AYA@mail.gmail.com>
Message-ID: <CACDSwDkJQpg7XXQMtKyTzCP5zcfCkmigY1v15JTiosB+xG92OA@mail.gmail.com>


Michael Brooks <firealwaysworks at gmail.com> added the comment:

Has anyone else been able to verify this?

On Mon, Nov 7, 2011 at 7:46 AM, Michael Brooks <report at bugs.python.org>wrote:

>
> Michael Brooks <firealwaysworks at gmail.com> added the comment:
>
> This one should also have a priority change. Tested python 2.7.3
>
> --MIke
>
> On Sun, Nov 6, 2011 at 12:54 PM, Michael Brooks <report at bugs.python.org
> >wrote:
>
> >
> > Michael Brooks <firealwaysworks at gmail.com> added the comment:
> >
> > Yes I am running python 2.7.2.
> >
> > On Sun, Nov 6, 2011 at 12:52 PM, Ezio Melotti <report at bugs.python.org
> > >wrote:
> >
> > >
> > > Ezio Melotti <ezio.melotti at gmail.com> added the comment:
> > >
> > > Have you tried with the latest 2.7? (see msg147170)
> > >
> > > ----------
> > > nosy: +ezio.melotti
> > > stage:  -> test needed
> > >
> > > _______________________________________
> > > Python tracker <report at bugs.python.org>
> > > <http://bugs.python.org/issue13358>
> > > _______________________________________
> > >
> >
> > ----------
> >
> > _______________________________________
> > Python tracker <report at bugs.python.org>
> > <http://bugs.python.org/issue13358>
> > _______________________________________
> >
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue13358>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13358>
_______________________________________

From report at bugs.python.org  Thu Nov 17 16:41:11 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 17 Nov 2011 15:41:11 +0000
Subject: [issue13358] HTMLParser incorrectly handles cdata elements.
In-Reply-To: <1320608905.33.0.994524216308.issue13358@psf.upfronthosting.co.za>
Message-ID: <1321544471.01.0.177823064928.issue13358@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

I'm working on it, but a minimal example seems to work fine.

(P.S. there's no need to quote the previous message(s) while replying)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13358>
_______________________________________

From report at bugs.python.org  Thu Nov 17 17:02:18 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Thu, 17 Nov 2011 16:02:18 +0000
Subject: [issue13405] Add DTrace probes
In-Reply-To: <1321299726.66.0.343368151185.issue13405@psf.upfronthosting.co.za>
Message-ID: <1321545738.77.0.264350416124.issue13405@psf.upfronthosting.co.za>


Changes by Jes?s Cea Avi?n <jcea at jcea.es>:


Removed file: http://bugs.python.org/file23690/05fde8943685.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13405>
_______________________________________

From report at bugs.python.org  Thu Nov 17 17:02:36 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Thu, 17 Nov 2011 16:02:36 +0000
Subject: [issue13405] Add DTrace probes
In-Reply-To: <1321299726.66.0.343368151185.issue13405@psf.upfronthosting.co.za>
Message-ID: <1321545757.0.0.0126387281121.issue13405@psf.upfronthosting.co.za>


Changes by Jes?s Cea Avi?n <jcea at jcea.es>:


Removed file: http://bugs.python.org/file23691/1563b5a70362.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13405>
_______________________________________

From report at bugs.python.org  Thu Nov 17 17:02:48 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Thu, 17 Nov 2011 16:02:48 +0000
Subject: [issue13405] Add DTrace probes
In-Reply-To: <1321299726.66.0.343368151185.issue13405@psf.upfronthosting.co.za>
Message-ID: <1321545768.86.0.284155048424.issue13405@psf.upfronthosting.co.za>


Changes by Jes?s Cea Avi?n <jcea at jcea.es>:


Removed file: http://bugs.python.org/file23696/9fcca74ff413.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13405>
_______________________________________

From report at bugs.python.org  Thu Nov 17 17:03:00 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Thu, 17 Nov 2011 16:03:00 +0000
Subject: [issue13405] Add DTrace probes
In-Reply-To: <1321299726.66.0.343368151185.issue13405@psf.upfronthosting.co.za>
Message-ID: <1321545780.51.0.397262492282.issue13405@psf.upfronthosting.co.za>


Changes by Jes?s Cea Avi?n <jcea at jcea.es>:


Removed file: http://bugs.python.org/file23701/7a2465f6a56a.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13405>
_______________________________________

From report at bugs.python.org  Thu Nov 17 17:03:42 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Thu, 17 Nov 2011 16:03:42 +0000
Subject: [issue13405] Add DTrace probes
In-Reply-To: <1321299726.66.0.343368151185.issue13405@psf.upfronthosting.co.za>
Message-ID: <1321545822.34.0.506585052244.issue13405@psf.upfronthosting.co.za>


Changes by Jes?s Cea Avi?n <jcea at jcea.es>:


Added file: http://bugs.python.org/file23717/7c1b63f949e7.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13405>
_______________________________________

From report at bugs.python.org  Thu Nov 17 17:12:52 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Thu, 17 Nov 2011 16:12:52 +0000
Subject: [issue13405] Add DTrace probes
In-Reply-To: <1321299726.66.0.343368151185.issue13405@psf.upfronthosting.co.za>
Message-ID: <1321546372.06.0.853177599216.issue13405@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

New changeset: 7c1b63f949e7.diff

Now I detect lacking of dtrace privileges, both in the global zone and in a non-global zone.

For that, I verify that the process can actually insert a C-entry point probe in a well known function: PyEval_EvalCode. This should work ALWAYS, even if the dtrace instrumentation provided by this fails miserably.

We have to remember if we change that function name, someday...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13405>
_______________________________________

From report at bugs.python.org  Thu Nov 17 17:24:24 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 17 Nov 2011 16:24:24 +0000
Subject: [issue13358] HTMLParser incorrectly handles cdata elements.
In-Reply-To: <1320608905.33.0.994524216308.issue13358@psf.upfronthosting.co.za>
Message-ID: <1321547064.58.0.040646161577.issue13358@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

It seems to me that the arguments are parsed correctly, but handle_data is called multiple time between handle_starttag and handle_endtag.
This might happen, e.g. in case the source lines are fed one by one to the parser, but in this case seems to happen whenever </ is found.
(The tests didn't detect this because they join the data to avoid buffer artifacts.)
I'm not sure if this can be considered a bug, but the situation can indeed be improved.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13358>
_______________________________________

From report at bugs.python.org  Thu Nov 17 17:45:34 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 17 Nov 2011 16:45:34 +0000
Subject: [issue13064] Port codecs and error handlers to the new Unicode API
In-Reply-To: <1317330548.17.0.268887391547.issue13064@psf.upfronthosting.co.za>
Message-ID: <1321548334.38.0.420545196853.issue13064@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
resolution:  -> duplicate
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13064>
_______________________________________

From report at bugs.python.org  Thu Nov 17 17:47:27 2011
From: report at bugs.python.org (Danek Duvall)
Date: Thu, 17 Nov 2011 16:47:27 +0000
Subject: [issue13405] Add DTrace probes
In-Reply-To: <1321299726.66.0.343368151185.issue13405@psf.upfronthosting.co.za>
Message-ID: <1321548447.94.0.571610406885.issue13405@psf.upfronthosting.co.za>


Danek Duvall <duvall at comfychair.org> added the comment:

> - I have added a "sys.trace_capabilities", so a program can know if any
> system-trace functionality is compiled in. Current values are "None"
> and "("dtrace", "Sun")".

I'm not sure "Sun" is the right name here.  I'd say either "SunOS" or "Solaris" (or the lowercase of either).  "Sun" typically refers to Sun hardware, which isn't relevant here, and the company, which doesn't exist anymore, also isn't particularly relevant.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13405>
_______________________________________

From report at bugs.python.org  Thu Nov 17 17:51:00 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 17 Nov 2011 16:51:00 +0000
Subject: [issue13411] Hashable memoryviews
In-Reply-To: <1321395643.62.0.259606214561.issue13411@psf.upfronthosting.co.za>
Message-ID: <1321548660.12.0.370183685761.issue13411@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Does memory_hash() reject non-contiguous memory?

_Py_HashBytes() might be reused by unicode_hash() for PyUnicode_1BYTE_KIND.

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13411>
_______________________________________

From report at bugs.python.org  Thu Nov 17 17:51:21 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 17 Nov 2011 16:51:21 +0000
Subject: [issue13411] Hashable memoryviews
In-Reply-To: <1321395643.62.0.259606214561.issue13411@psf.upfronthosting.co.za>
Message-ID: <1321548681.24.0.745491017887.issue13411@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Except these two minor nits, the patch looks good to me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13411>
_______________________________________

From report at bugs.python.org  Thu Nov 17 17:57:49 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 17 Nov 2011 16:57:49 +0000
Subject: [issue13411] Hashable memoryviews
In-Reply-To: <1321548660.12.0.370183685761.issue13411@psf.upfronthosting.co.za>
Message-ID: <1321548772.3362.2.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Does memory_hash() reject non-contiguous memory?

It should, since it checks the strides array.

> _Py_HashBytes() might be reused by unicode_hash() for PyUnicode_1BYTE_KIND.

I don't really see how unicode hashing should be related to bytes
hashing (even though apparently an (outdated?) test checks for that).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13411>
_______________________________________

From report at bugs.python.org  Thu Nov 17 18:55:56 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Thu, 17 Nov 2011 17:55:56 +0000
Subject: [issue13411] Hashable memoryviews
In-Reply-To: <1321395643.62.0.259606214561.issue13411@psf.upfronthosting.co.za>
Message-ID: <1321552556.73.0.454519182969.issue13411@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

I'm not sure that the "register" storage class specifier is still relevant with modern compilers: I'm pretty sure gcc ignores it unless -O0, and I think I've read somewhere Microsoft's compiler ignores it too.

----------
nosy: +neologix

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13411>
_______________________________________

From report at bugs.python.org  Thu Nov 17 19:00:57 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 17 Nov 2011 18:00:57 +0000
Subject: [issue13411] Hashable memoryviews
In-Reply-To: <1321552556.73.0.454519182969.issue13411@psf.upfronthosting.co.za>
Message-ID: <1321552563.3362.3.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> I'm not sure that the "register" storage class specifier is still
> relevant with modern compilers: I'm pretty sure gcc ignores it unless
> -O0, and I think I've read somewhere Microsoft's compiler ignores it
> too.

I don't think so either. I was lazily moving the original code, but I
could remove those bits.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13411>
_______________________________________

From report at bugs.python.org  Thu Nov 17 19:01:07 2011
From: report at bugs.python.org (Michael Brooks)
Date: Thu, 17 Nov 2011 18:01:07 +0000
Subject: [issue13358] HTMLParser incorrectly handles cdata elements.
In-Reply-To: <1321547064.58.0.040646161577.issue13358@psf.upfronthosting.co.za>
Message-ID: <CACDSwDm1p09B_sBpqgT_LmKw7+oHwQDmFK6ZnZ=7ZYF_8v_9MQ@mail.gmail.com>


Michael Brooks <firealwaysworks at gmail.com> added the comment:

Ok so until you fix this bug,  i'll be overriding HTMLParser with my fix,
becuase this is a blocking issue for my project.  My HTMLParser must behave
like a browser,  period end of story.

Thanks.

On Thu, Nov 17, 2011 at 9:24 AM, Ezio Melotti <report at bugs.python.org>wrote:

>
> Ezio Melotti <ezio.melotti at gmail.com> added the comment:
>
> It seems to me that the arguments are parsed correctly, but handle_data is
> called multiple time between handle_starttag and handle_endtag.
> This might happen, e.g. in case the source lines are fed one by one to the
> parser, but in this case seems to happen whenever </ is found.
> (The tests didn't detect this because they join the data to avoid buffer
> artifacts.)
> I'm not sure if this can be considered a bug, but the situation can indeed
> be improved.
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue13358>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13358>
_______________________________________

From report at bugs.python.org  Thu Nov 17 19:14:43 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Thu, 17 Nov 2011 18:14:43 +0000
Subject: [issue13421] PyCFunction_* are not documented anywhere
Message-ID: <1321553683.63.0.825049607384.issue13421@psf.upfronthosting.co.za>


New submission from Jes?s Cea Avi?n <jcea at jcea.es>:

Functions PyCFunction_* are not documented. Searching online I found http://www.gossamer-threads.com/lists/python/dev/738662 , so I am actually opening the issue and assigning to Georg :).

----------
assignee: georg.brandl
components: Documentation
messages: 147817
nosy: georg.brandl, jcea
priority: normal
severity: normal
status: open
title: PyCFunction_* are not documented anywhere

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13421>
_______________________________________

From report at bugs.python.org  Thu Nov 17 19:17:55 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 17 Nov 2011 18:17:55 +0000
Subject: [issue13358] HTMLParser incorrectly handles cdata elements.
In-Reply-To: <1320608905.33.0.994524216308.issue13358@psf.upfronthosting.co.za>
Message-ID: <1321553875.95.0.876633555871.issue13358@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

It already behaves like a browser, it just gives you data in chunks instead of calling handle_data() only once at the end.  The documentation is not clear about this though.  It says that feed() can be called several times, but it doesn't say that handle_data() (and possibly other methods) might get called more than once.  This seems to always be the case while calling feed() several times.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13358>
_______________________________________

From report at bugs.python.org  Thu Nov 17 19:28:35 2011
From: report at bugs.python.org (Michael Brooks)
Date: Thu, 17 Nov 2011 18:28:35 +0000
Subject: [issue13358] HTMLParser incorrectly handles cdata elements.
In-Reply-To: <1321553875.95.0.876633555871.issue13358@psf.upfronthosting.co.za>
Message-ID: <CACDSwD=hyC+qAA+XQYcHrUE-uG7wmhzQs4qV6xDTzA1rZr01_g@mail.gmail.com>


Michael Brooks <firealwaysworks at gmail.com> added the comment:

Oah,  then there is a misunderstanding.  No browser will parse the html
that is declared within a javascript variable,  it must be treated as a
continues data segment (with cdata properties) until the exit
</\s*script\s*> is encountered (and if this tag found anywhere,  even in a
quoted string it will still terminate this data segment,  because its a
cdata element).   The snip of html provided must only be a single data
segment. </ alone is not a proper terminator.

Thu, Nov 17, 2011 at 11:17 AM, Ezio Melotti <report at bugs.python.org> wrote:

>
> Ezio Melotti <ezio.melotti at gmail.com> added the comment:
>
> It already behaves like a browser, it just gives you data in chunks
> instead of calling handle_data() only once at the end.  The documentation
> is not clear about this though.  It says that feed() can be called several
> times, but it doesn't say that handle_data() (and possibly other methods)
> might get called more than once.  This seems to always be the case while
> calling feed() several times.
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue13358>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13358>
_______________________________________

From report at bugs.python.org  Thu Nov 17 19:54:51 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Thu, 17 Nov 2011 18:54:51 +0000
Subject: [issue13405] Add DTrace probes
In-Reply-To: <1321299726.66.0.343368151185.issue13405@psf.upfronthosting.co.za>
Message-ID: <1321556091.53.0.577447431015.issue13405@psf.upfronthosting.co.za>


Changes by Jes?s Cea Avi?n <jcea at jcea.es>:


Added file: http://bugs.python.org/file23718/62e7091812bc.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13405>
_______________________________________

From report at bugs.python.org  Thu Nov 17 20:02:05 2011
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 17 Nov 2011 19:02:05 +0000
Subject: [issue13421] PyCFunction_* are not documented anywhere
In-Reply-To: <1321553683.63.0.825049607384.issue13421@psf.upfronthosting.co.za>
Message-ID: <1321556525.35.0.209297715337.issue13421@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
assignee: georg.brandl -> docs at python
nosy: +docs at python

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13421>
_______________________________________

From report at bugs.python.org  Thu Nov 17 21:35:44 2011
From: report at bugs.python.org (Felix Steffenhagen)
Date: Thu, 17 Nov 2011 20:35:44 +0000
Subject: [issue13422] Subprocess: children hang due to open pipes
Message-ID: <1321562143.65.0.570707046808.issue13422@psf.upfronthosting.co.za>


New submission from Felix Steffenhagen <felix at sutus.com>:

subprocess.Popen.communicate() hangs for daemonized subprocesses that leave a pipe open. The python caller, invoking the daemon subprocess, runs as long as the daemon process. This happens on POSIX platforms with python 2.7 as well as 3.2. 

Please find attached a simple python daemon, which leaves stderr pipe open. It runs for 10 sec and then exits.

To reproduce the problem run the following start script:
##################
# startpydaemon.py
import subprocess

cmd = 'python pydaemon.py'
print("Starting daemon that runs for 10 sec")
daemon = subprocess.Popen(cmd, 
                          stdout=subprocess.PIPE,
                          stderr=subprocess.PIPE,
                          shell=True)
stdout, stderr = daemon.communicate()
print("Stdout:")
print(stdout)
print("Stderr:")
print(stderr)
##################

Expected Behavior:
------------------
Daemon starter should exit immediately after the daemon process is initialized.

Actual Behavior:
----------------
Daemon starter waits for daemon process to be finished due to left open error pipe. 

Workaround:
-----------
One workaround is to not capture output from the left-open pipe. This way.

----------
components: Library (Lib)
files: pydaemon.py
messages: 147820
nosy: fsteffenhagen
priority: normal
severity: normal
status: open
title: Subprocess: children hang due to open pipes
versions: Python 2.6, Python 3.2
Added file: http://bugs.python.org/file23719/pydaemon.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13422>
_______________________________________

From report at bugs.python.org  Thu Nov 17 21:37:07 2011
From: report at bugs.python.org (Felix Steffenhagen)
Date: Thu, 17 Nov 2011 20:37:07 +0000
Subject: [issue13422] Subprocess: children hang due to open pipes
In-Reply-To: <1321562143.65.0.570707046808.issue13422@psf.upfronthosting.co.za>
Message-ID: <1321562227.76.0.944196198985.issue13422@psf.upfronthosting.co.za>


Changes by Felix Steffenhagen <felix at sutus.com>:


----------
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13422>
_______________________________________

From report at bugs.python.org  Thu Nov 17 22:00:30 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Thu, 17 Nov 2011 21:00:30 +0000
Subject: [issue13422] Subprocess: children hang due to open pipes
In-Reply-To: <1321562143.65.0.570707046808.issue13422@psf.upfronthosting.co.za>
Message-ID: <1321563630.1.0.104903323858.issue13422@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

> subprocess.Popen.communicate() hangs for daemonized subprocesses that 
> leave a pipe open. [...] which leaves stderr pipe open.

Of course: the daemon process (spawned by the second fork()) inherits the subprocess's stderr (since file descriptors are inherited upon fork), and communicate waits until the subprocess's stderr and stdout are closed (EOF returned).
And it's of course documented, see http://docs.python.org/dev/library/subprocess.html#subprocess.Popen.communicate :
"""
Popen.communicate(input=None, timeout=None) 
Interact with process: Send data to stdin. Read data from stdout and stderr, until end-of-file is reached. Wait for process to terminate.
"""

----------
nosy: +neologix

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13422>
_______________________________________

From report at bugs.python.org  Thu Nov 17 22:16:59 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Thu, 17 Nov 2011 21:16:59 +0000
Subject: [issue13215] multiprocessing Manager.connect() aggressively retries
	refused connections
In-Reply-To: <1318965417.81.0.122561387998.issue13215@psf.upfronthosting.co.za>
Message-ID: <1321564619.22.0.760564616571.issue13215@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

> Apparently you forgot to upload the patch...

Told you I couldn't think straight :-)

----------
Added file: http://bugs.python.org/file23720/connection_retry.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13215>
_______________________________________

From report at bugs.python.org  Thu Nov 17 22:43:02 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 17 Nov 2011 21:43:02 +0000
Subject: [issue13215] multiprocessing Manager.connect() aggressively retries
	refused connections
In-Reply-To: <1318965417.81.0.122561387998.issue13215@psf.upfronthosting.co.za>
Message-ID: <1321566182.58.0.164417433246.issue13215@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Ok for me. Nice to see that piece of ugliness removed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13215>
_______________________________________

From report at bugs.python.org  Thu Nov 17 22:53:44 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 17 Nov 2011 21:53:44 +0000
Subject: [issue13349] Uninformal error message in index() and remove()
	functions
In-Reply-To: <1320526177.89.0.678573577515.issue13349@psf.upfronthosting.co.za>
Message-ID: <1321566824.49.0.366812870551.issue13349@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

The test suite has code (functions) that restrict the length on AssertEqual (and other) failure messages. (I do not know the location though.) Perhaps that can be reused. This almost seems like something that should be more easily available.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13349>
_______________________________________

From report at bugs.python.org  Thu Nov 17 22:55:23 2011
From: report at bugs.python.org (Gregory P. Smith)
Date: Thu, 17 Nov 2011 21:55:23 +0000
Subject: [issue13422] Subprocess: children hang due to open pipes
In-Reply-To: <1321562143.65.0.570707046808.issue13422@psf.upfronthosting.co.za>
Message-ID: <1321566923.32.0.0920600216129.issue13422@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

This looks like a bug in your daemon not in subprocess.  Your daemon is intentionally not closing its inherited stderr fd.

----------
nosy: +gregory.p.smith
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13422>
_______________________________________

From report at bugs.python.org  Thu Nov 17 23:12:17 2011
From: report at bugs.python.org (Felix Steffenhagen)
Date: Thu, 17 Nov 2011 22:12:17 +0000
Subject: [issue13422] Subprocess: children hang due to open pipes
In-Reply-To: <1321562143.65.0.570707046808.issue13422@psf.upfronthosting.co.za>
Message-ID: <1321567937.26.0.374155566813.issue13422@psf.upfronthosting.co.za>


Felix Steffenhagen <felix at sutus.com> added the comment:

The behavior that the daemon is not closing stderr is intentional to reproduce the issue. This problem occured to me when I was invoking the samba init script on a Gentoo system.
Invoked from a bash, the initscript was terminating fine. But when I invoked it using the subprocess module, my python script hang.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13422>
_______________________________________

From report at bugs.python.org  Thu Nov 17 23:15:35 2011
From: report at bugs.python.org (Eric V. Smith)
Date: Thu, 17 Nov 2011 22:15:35 +0000
Subject: [issue13386] Document documentation conventions for optional args
In-Reply-To: <1321078121.18.0.541430257552.issue13386@psf.upfronthosting.co.za>
Message-ID: <1321568135.54.0.373452698441.issue13386@psf.upfronthosting.co.za>


Eric V. Smith <eric at trueblade.com> added the comment:

I just ran across the other reason that having the actual default values documented is important. Sometimes I want to do this:

some_func(param if some_condition else <use the default value>)

If some_condition is False, I want the default behavior, if not, I want to pass in a parameter. If I don't know the real default value, I have to write:

if some_condition:
   some_func(param)
else:
   some_func()

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13386>
_______________________________________

From report at bugs.python.org  Thu Nov 17 23:29:05 2011
From: report at bugs.python.org (Nu Kvar)
Date: Thu, 17 Nov 2011 22:29:05 +0000
Subject: [issue7750] IOError when launching script under pdb with backslash in
	script path
In-Reply-To: <1264112305.65.0.888456425139.issue7750@psf.upfronthosting.co.za>
Message-ID: <1321568945.24.0.591015110174.issue7750@psf.upfronthosting.co.za>


Nu Kvar <asafgreenberg at gmail.com> added the comment:

this bug exist also in python 2.5 (of course)

and the same patch as above fixes it (of course).

----------
nosy: +nukvar

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7750>
_______________________________________

From report at bugs.python.org  Fri Nov 18 00:53:21 2011
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 17 Nov 2011 23:53:21 +0000
Subject: [issue7750] IOError when launching script under pdb with backslash in
	script path
In-Reply-To: <1264112305.65.0.888456425139.issue7750@psf.upfronthosting.co.za>
Message-ID: <E1RRBlU-0003ds-AC@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset f7dd5178f36a by Jason R. Coombs in branch '2.7':
PDB now will properly escape backslashes in the names of modules it executes. Fixes #7750
http://hg.python.org/cpython/rev/f7dd5178f36a

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7750>
_______________________________________

From report at bugs.python.org  Fri Nov 18 00:59:22 2011
From: report at bugs.python.org (Jason R. Coombs)
Date: Thu, 17 Nov 2011 23:59:22 +0000
Subject: [issue7750] IOError when launching script under pdb with backslash in
	script path
In-Reply-To: <1264112305.65.0.888456425139.issue7750@psf.upfronthosting.co.za>
Message-ID: <1321574362.85.0.323219071267.issue7750@psf.upfronthosting.co.za>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

This bug doesn't appear to be present in 3.1, so the 2.7 patch is all that applies at this time.

----------
resolution:  -> fixed
status: open -> closed
versions:  -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7750>
_______________________________________

From report at bugs.python.org  Fri Nov 18 03:06:32 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Fri, 18 Nov 2011 02:06:32 +0000
Subject: [issue13386] Document documentation conventions for optional args
In-Reply-To: <1321078121.18.0.541430257552.issue13386@psf.upfronthosting.co.za>
Message-ID: <1321581992.46.0.111064082765.issue13386@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

Eric,

Spot on :-) 
This is *exactly* the reason that led me to open issue 12875, which eventually led to this one.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13386>
_______________________________________

From report at bugs.python.org  Fri Nov 18 05:29:32 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 18 Nov 2011 04:29:32 +0000
Subject: [issue13386] Document documentation conventions for optional args
In-Reply-To: <1321078121.18.0.541430257552.issue13386@psf.upfronthosting.co.za>
Message-ID: <1321590572.06.0.541036897626.issue13386@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

>From Ezio's original post: '''
If a function has optional arguments but it doesn't accept keyword arguments, the "func([arg1])" notation is used instead. ... The notation "func([arg=default])" should never be used, and "func([arg])" should be used only when keyword args are not accepted.
'''

In the following, I give objections to this PO (position only) rule and suggest an alternative ND (no default) rule: use 'name=default' when there is a default and '[name]' when there is not'.

The issue of whether an argument is required or optional is orthogonal to whether it can be passed by both position and name, only by name, or only by position. All combinations are possible. Optional arguments may or may not have a definition-time (or even run-time) default value, regardless of how passed. (In Python, use of *args and **kwds allows args to be optional without default.)

In the CPython stdlib, I think position-only arguments only occur with some, but only some, C functions. One can emulate such C functions in Python by doing the equivalent of what is going on with such C functions. Use a collective *varargs in the definition while naming the required and optional components of varargs in the doc as if they were the actual parameters. But I think we agree that emulating a limitation of C in Python is a bad idea.

So by using [] to mean both 'argument is optional' and 'function only take parameters by position' (or at least 'this parameter can only be passed to this function by position'), we are simultaneously documenting an intended and permanent feature of the Python function and a possibly temporary and unwanted side-effect of the current CPython implementation of that function. I think a separate PO indication might be better.

1: The PO rule goes against the effort to separate the Python language from the CPython implementation. With it, the doc for a function does not apply to other implementations that do not have the PO limitation for that function.

2: The PO rule is incomplete. It only marks an arg as position-only if it is optional, but not if it is required. And even if marking one arg as PO means that other args of the function might be, so 'watch out', there is still no special marking for a function with only required PO args. 

A separate sentence like "For CPython, all args must be passed by position." would solve both of the above problems.

3: The PO rule does not account for the possibility that an argument can be passed by keyword, perhaps only by keyword, but have no default. This is possibly in Python with **kwds in the def and recognized optional names in the doc. With 'name=default' and '[name]' not allowed, how should such an argument be documented is a signature?

4: The PO rule omits useful information on defaults from the place of prominence - the signature header for the entry. Sometimes the information, needed by some users and all implementers, gets omitted altogether. For example, the doc string and manual entry give the signature for str.startwith as
  str.startswith(prefix[, start[, end]])
The unmentioned defaults are None, None.

In summary, the PO rule primarily indicates, but only for optional args, whether the arg can be passed by keyword or not. It secondarily indicates, but only if it can be passed by keyword, what its default is. But if fails if the arg can be passed by keyword but does not have a default. It also fails, in its primary role, for required args.

To me, this is all mixed up. Method of passing is not related to optionality. What is special about optional args, regardless of how passed, is the default value, if it has one. The ND rule is to give exactly this information. With an implementation-independent signature and a separate note on passing method, when needed, it solves all the problems listed above. For .startswith, I would like to see something like
   str.startswith(prefix, start=None, end=None) ...
   CPython: pass args by position only.

---
#13355 illustrates Eric's point with a twist.
"random.triangular(low, high, mode) 
Return a random floating point number N such that low <= N <= high and with the specified mode between those bounds. The low and high bounds default to zero and one. The mode argument defaults to the midpoint between the bounds, giving a symmetric distribution."

The *actual* default for mode is None. The function *usually* acts if the default were as described. Twist 1 is that it does not actually calculate the midpoint, as it is not actually needed. Twist 2 is that there is currently a bug (easily fixed) such that triangular does not work if low>=high and mode is not specified, whereas it does work if the true default None is passed ;-). So one needs to know the real default to avoid the bug.

Of course, as I said on the issue, all defaults should be given in the signature (by either PO or ND rule):
"random.triangular(low=0.0, high=1.0, mode=None) ..."

And yes, +1 to documenting visible document conventions both in the documenting howto *and* in the docs themselves.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13386>
_______________________________________

From report at bugs.python.org  Fri Nov 18 08:11:43 2011
From: report at bugs.python.org (Baptiste Carvello)
Date: Fri, 18 Nov 2011 07:11:43 +0000
Subject: [issue13386] Document documentation conventions for optional args
In-Reply-To: <1321590572.06.0.541036897626.issue13386@psf.upfronthosting.co.za>
Message-ID: <4EC60527.5080409@baptiste-carvello.net>


Baptiste Carvello <devel at baptiste-carvello.net> added the comment:

Le 18/11/2011 05:29, Terry J. Reedy a ?crit :
> 
> In the following, I give objections to this PO (position only) rule and suggest an alternative ND (no default) rule: use 'name=default' when there is a default and '[name]' when there is not'.
> 
> The issue of whether an argument is required or optional is orthogonal to whether it can be passed by both position and name, only by name, or only by position.

With this logic, you would need to use '[name=default]' when an argument
is optional *and* can be passed by name.

Sure, this notation is inherently redundant, but is has the advantage of
conveying both informations immediately to the user. It is also more
coherent with '[name]'.

But this is a big change from the current philosophy...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13386>
_______________________________________

From report at bugs.python.org  Fri Nov 18 08:26:16 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Fri, 18 Nov 2011 07:26:16 +0000
Subject: [issue13349] Uninformal error message in index() and remove()
	functions
In-Reply-To: <1320526177.89.0.678573577515.issue13349@psf.upfronthosting.co.za>
Message-ID: <1321601176.15.0.2955419846.issue13349@psf.upfronthosting.co.za>


Petri Lehtinen <petri at digip.org> added the comment:

I found safe_repr() from Lib/unittest/util.py. We would require a similar function, just implemented in C.

What is a good place to define such C helpers that could be used everywhere?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13349>
_______________________________________

From report at bugs.python.org  Fri Nov 18 10:17:28 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 18 Nov 2011 09:17:28 +0000
Subject: [issue13386] Document documentation conventions for optional args
In-Reply-To: <1321078121.18.0.541430257552.issue13386@psf.upfronthosting.co.za>
Message-ID: <1321607848.87.0.0232920222185.issue13386@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

> From Ezio's original post: '''
> If a function has optional arguments but it doesn't accept keyword 
> arguments, the "func([arg1])" notation is used instead. ... The 
> notation "func([arg=default])" should never be used, and "func([arg])" 
> should be used only when keyword args are not accepted.
> '''
>
> In the following, I give objections to this PO (position only) rule and > suggest an alternative ND (no default) rule: use 'name=default' when
> there is a default and '[name]' when there is not'.

Maybe we should try to keep it simple and just document the signature of the function.
Everything that can not be described in the signature can be explained by words.

I tried to write down all the combinations of optional/non optional, with/without default, works/doesn't work with keywords to see how to represent them, but it started being a bit messy.  The "problematic" combinations (for example a function that accepts an optional arguments with no default but that doesn't work with keywords) seem quite rare, and for them we could just write down what's special about them.

There are two more cases that could be solved with a specific notation though:
1) optional arg, with default, doesn't work with keywords (e.g. range, startswith):
   func(arg1)
   func(arg1, arg2)
   *arg2* defaults to <default>.
2) optional arg, with no default, that works only with keywords:
   func(arg1, *, arg2)

The keyword-only *, and the multiple signatures "tricks" can also be used for other similar cases.

func(arg1, **kwargs) can be used for functions that accept kwargs without expecting any specific value; if the values are known and have defaults they could be included in the signature (even if the default is like foo = kwargs.get('foo', default)).

This should cover most of the cases, it only uses valid Python syntax and avoids potentially confusing [].

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13386>
_______________________________________

From report at bugs.python.org  Fri Nov 18 10:22:12 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 18 Nov 2011 09:22:12 +0000
Subject: [issue13349] Uninformal error message in index() and remove()
	functions
In-Reply-To: <1320526177.89.0.678573577515.issue13349@psf.upfronthosting.co.za>
Message-ID: <1321608132.66.0.912949562322.issue13349@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

> I found safe_repr() from Lib/unittest/util.py.

The functions in Lib/unittest/util.py shouldn't be used outside unittest.

> We would require a similar function, just implemented in C.
> What is a good place to define such C helpers that could be used everywhere?

You could start by adding it in the file where you need it.  If it starts becoming useful elsewhere too, it can then be moved somewhere else.  I would expect such function to be private, so we are free to move it whenever we need it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13349>
_______________________________________

From report at bugs.python.org  Fri Nov 18 10:26:41 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Fri, 18 Nov 2011 09:26:41 +0000
Subject: [issue13349] Uninformal error message in index() and remove()
	functions
In-Reply-To: <1321608132.66.0.912949562322.issue13349@psf.upfronthosting.co.za>
Message-ID: <20111118092626.GB3148@p16>


Petri Lehtinen <petri at digip.org> added the comment:

Ezio Melotti wrote:
> You could start by adding it in the file where you need it. If it
> starts becoming useful elsewhere too, it can then be moved somewhere
> else. I would expect such function to be private, so we are free to
> move it whenever we need it.

Well, msg147109 already lists 6 files that would use this function.
Some of them are under Objects&, some are under Modules/.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13349>
_______________________________________

From report at bugs.python.org  Fri Nov 18 10:36:58 2011
From: report at bugs.python.org (Chase Albert)
Date: Fri, 18 Nov 2011 09:36:58 +0000
Subject: [issue13423] Ranges cannot be meaningfully compared for equality or
	hashed
Message-ID: <1321609018.8.0.880546307397.issue13423@psf.upfronthosting.co.za>


New submission from Chase Albert <thaoeuns at gmail.com>:

My expectation was that range(2,5) == range(2,5), and that they should hash the same. This is not the case.

----------
messages: 147838
nosy: rob.anyone
priority: normal
severity: normal
status: open
title: Ranges cannot be meaningfully compared for equality or hashed
type: behavior
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13423>
_______________________________________

From report at bugs.python.org  Fri Nov 18 10:42:18 2011
From: report at bugs.python.org (Florent Xicluna)
Date: Fri, 18 Nov 2011 09:42:18 +0000
Subject: [issue13423] Ranges cannot be meaningfully compared for equality or
	hashed
In-Reply-To: <1321609018.8.0.880546307397.issue13423@psf.upfronthosting.co.za>
Message-ID: <1321609338.97.0.539279959051.issue13423@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

this was implemented with ticket #13201.
It will be available in version 3.3.

----------
nosy: +flox
resolution:  -> out of date
stage:  -> committed/rejected
status: open -> closed
superseder:  -> Implement comparison operators for range objects
type: behavior -> feature request

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13423>
_______________________________________

From report at bugs.python.org  Fri Nov 18 10:52:13 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 18 Nov 2011 09:52:13 +0000
Subject: =?utf-8?q?=5Bissue13424=5D_Add_examples_for_open=E2=80=99s_new_opener_arg?=
	=?utf-8?q?ument?=
Message-ID: <1321609933.89.0.531165464334.issue13424@psf.upfronthosting.co.za>


New submission from ?ric Araujo <merwok at netwok.org>:

The new opener argument to open and TextIOWrapper closed two bugs on this tracker: using O_CLOEXEC and replacing the unofficial 'c' mode (O_CREATE).  I think it?d be nice to have these as examples (maybe not in the docs of TextIOWrapper which are already huge, but for example in the os docs after the O_* constants).

----------
assignee: docs at python
components: Documentation
messages: 147840
nosy: docs at python, eric.araujo
priority: normal
severity: normal
status: open
title: Add examples for open?s new opener argument
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13424>
_______________________________________

From report at bugs.python.org  Fri Nov 18 10:55:29 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 18 Nov 2011 09:55:29 +0000
Subject: [issue12760] Add create mode to open()
In-Reply-To: <1313502559.06.0.415498401391.issue12760@psf.upfronthosting.co.za>
Message-ID: <1321610129.16.0.414444179943.issue12760@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

See #13424 for a doc request about this.

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12760>
_______________________________________

From report at bugs.python.org  Fri Nov 18 10:55:53 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 18 Nov 2011 09:55:53 +0000
Subject: =?utf-8?q?=5Bissue13424=5D_Add_examples_for_open=E2=80=99s_new_opener_arg?=
	=?utf-8?q?ument?=
In-Reply-To: <1321609933.89.0.531165464334.issue13424@psf.upfronthosting.co.za>
Message-ID: <1321610153.05.0.11321467341.issue13424@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

s/TextIOWrapper/FileIO/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13424>
_______________________________________

From report at bugs.python.org  Fri Nov 18 10:56:00 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 18 Nov 2011 09:56:00 +0000
Subject: [issue12797] io.FileIO and io.open should support openat
In-Reply-To: <1313874003.0.0.755289779326.issue12797@psf.upfronthosting.co.za>
Message-ID: <1321610160.85.0.728777861287.issue12797@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

See #13424 for a doc request about this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12797>
_______________________________________

From report at bugs.python.org  Fri Nov 18 11:15:22 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 18 Nov 2011 10:15:22 +0000
Subject: [issue12780] Clean up tests for pyc/pyo in __file__
In-Reply-To: <1313687680.79.0.253573735588.issue12780@psf.upfronthosting.co.za>
Message-ID: <1321611322.54.0.861783318127.issue12780@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> Seems reasonable to me.  When did/does unicodedata ever have a __file__ attribute?
No idea.  Maybe it has to do with static vs. dynamic linking?  Or alternate VMs?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12780>
_______________________________________

From report at bugs.python.org  Fri Nov 18 11:17:33 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 18 Nov 2011 10:17:33 +0000
Subject: [issue2979] use_builtin_types in xmlrpc.server
In-Reply-To: <1211846989.94.0.031553096454.issue2979@psf.upfronthosting.co.za>
Message-ID: <1321611453.63.0.440098431508.issue2979@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Looks good.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2979>
_______________________________________

From report at bugs.python.org  Fri Nov 18 11:19:15 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 18 Nov 2011 10:19:15 +0000
Subject: [issue13358] HTMLParser incorrectly handles cdata elements.
In-Reply-To: <1320608905.33.0.994524216308.issue13358@psf.upfronthosting.co.za>
Message-ID: <1321611555.02.0.683731745425.issue13358@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Attached patch should solve the issue.

----------
assignee:  -> ezio.melotti
keywords: +patch
stage: test needed -> commit review
versions: +Python 3.2, Python 3.3
Added file: http://bugs.python.org/file23721/issue13358.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13358>
_______________________________________

From report at bugs.python.org  Fri Nov 18 11:23:55 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 18 Nov 2011 10:23:55 +0000
Subject: [issue13294] http.server: HEAD request should not return a body
In-Reply-To: <1319985642.06.0.787750282348.issue13294@psf.upfronthosting.co.za>
Message-ID: <1321611835.59.0.354392628298.issue13294@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Hi Michele, long time no see :)

> Well, actually SimpleHTTPRequesthandler extends BaseHTTPHandler with basic do_GET and
> do_HEAD methods.
> Unittests for http.server shows that this behavior is intended, since: [snip] 
Not sure what this test shows (maybe because I need coffee :)

> Anyway, I would propose a trivial patch to make http.server a little more elegant.
The first change may do more that you want it to: rstrip without argument will remove all whitespace, but there the code wants to remove only CRLF or LF.  Anyway, changes for the sake of elegance or cleanliness are not done for the sake of it, but usually as a part of a greater refactoring or fix.  We prefer to minimize chances of compatibility breakage by avoiding gratuitous changes.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13294>
_______________________________________

From report at bugs.python.org  Fri Nov 18 11:47:05 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 18 Nov 2011 10:47:05 +0000
Subject: [issue4147] xml.dom.minidom toprettyxml: omit whitespace for
	text-only elements
In-Reply-To: <1224430404.43.0.0672391440841.issue4147@psf.upfronthosting.co.za>
Message-ID: <1321613225.68.0.126620127451.issue4147@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

I did some tests, creating an element ('elem') that contains two adjacent text nodes ('text').  With my latest patch the prettyprint is:
<?xml version="1.0" ?>
<elem>
        text
        text
</elem>

Here both the text nodes are printed on a newline and they are indented.

With your patch it should be:
<?xml version="1.0" ?>
<elem>texttext</elem>

I'm not sure there's any reason to prefer the second option though.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4147>
_______________________________________

From report at bugs.python.org  Fri Nov 18 12:03:50 2011
From: report at bugs.python.org (=?utf-8?q?Stanis=C5=82aw_Jankowski?=)
Date: Fri, 18 Nov 2011 11:03:50 +0000
Subject: [issue13425] http.client.HTTPMessage.getallmatchingheaders() always
	returns []
Message-ID: <1321614230.59.0.764469605478.issue13425@psf.upfronthosting.co.za>


New submission from Stanis?aw Jankowski <stach.jankowski at gmail.com>:

http.client.HTTPMessage.getallmatchingheaders() always returns []

Python 3.2.2:
Calling the code below does not give the expected result.

sjankowski at sjankowski:~$ python3
Python 3.2.2rc1 (default, Aug 14 2011, 18:43:44) 
[GCC 4.6.1] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from urllib.request import urlopen
>>> fp = urlopen('http://www.python.org/')
>>> fp.headers.getallmatchingheaders('Content-Type')
[]

At Python 2.7.2 returns the result.

sjankowski at sjankowski:~$ python
Python 2.7.2+ (default, Aug 16 2011, 09:23:59) 
[GCC 4.6.1] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from urllib import urlopen
>>> fp = urlopen('http://www.python.org/')
>>> fp.headers.getallmatchingheaders('Content-Type')
['Content-Type: text/html\r\n']

----------
components: Library (Lib)
messages: 147849
nosy: stachjankowski
priority: normal
severity: normal
status: open
title: http.client.HTTPMessage.getallmatchingheaders() always returns []
type: behavior
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13425>
_______________________________________

From report at bugs.python.org  Fri Nov 18 12:16:54 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 18 Nov 2011 11:16:54 +0000
Subject: [issue13425] http.client.HTTPMessage.getallmatchingheaders() always
	returns []
In-Reply-To: <1321614230.59.0.764469605478.issue13425@psf.upfronthosting.co.za>
Message-ID: <1321615014.29.0.923729984104.issue13425@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

The problem seems to be in Lib/http/client.py:227.
The code adds a ':' that is not found in the list of headers returned by self.keys().

----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13425>
_______________________________________

From report at bugs.python.org  Fri Nov 18 12:25:49 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Fri, 18 Nov 2011 11:25:49 +0000
Subject: [issue13425] http.client.HTTPMessage.getallmatchingheaders() always
	returns []
In-Reply-To: <1321614230.59.0.764469605478.issue13425@psf.upfronthosting.co.za>
Message-ID: <1321615549.19.0.359452551009.issue13425@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/issue13425>
_______________________________________

From report at bugs.python.org  Fri Nov 18 12:29:59 2011
From: report at bugs.python.org (Nebelhom)
Date: Fri, 18 Nov 2011 11:29:59 +0000
Subject: [issue13426] The Python Standard Library >> 11. Data Persistence
Message-ID: <1321615799.02.0.0403291741181.issue13426@psf.upfronthosting.co.za>


New submission from Nebelhom <nebelhom at googlemail.com>:

------------------------------
Python v3.3a0 documentation >> The Python Standard Library >> 11. Data
Persistence

Section 11.1 pickle module

#1
11.1.3. Module Interface

exception pickle.UnpicklingError

   Error raised when there a problem unpickling an object, such as a data corruption or a security violation.
   It inherits PickleError.

TYPO: Error raised when there IS a problem unpickling an object

------------------------------
#2
11.1.3. Module Interface

persistent_load(pid)

   Raise an UnpickingError by default.

TYPO: Should be "Unpick"l"ingError" as wrtten earlier in the section

--------------------------------
#3
11.1.4 What can be pickled and unpickled

Note that functions (built-in and user-defined) are pickled by >>fully
qualified<< name reference, not by value.
This means that only the function name is pickled, along with the name of module the function is defined in.

TYPO: along with the name of "THE" module the function is defined in.

--------------------------------
#4
11.1.5.1. Persistence of External Objects

In Windows XP SP3, example does not work out of the box as sqlite3 is not included when compiling python3.3a following the Getting Set Up directions in the Developer's Guide

Is this an issue?

Code works in Ubuntu 10.04 lucid.

When run from Terminal, it gives the following output:

Pickled records:
[MemoRecord(key=1, task='give food to fish'),
 MemoRecord(key=2, task='prepare group meeting'),
 MemoRecord(key=3, task='fight with a zebra')]
Unpickled records:
[MemoRecord(key=1, task='learn italian'),
 MemoRecord(key=2, task='prepare group meeting'),
 MemoRecord(key=3, task='fight with a zebra')]


 Should that not be given afterwards as a reference to the user, so that
(s)he knows, that the code is right?

--------------------------------
#5
11.1.6 Restricting Globals

Thus it is possible to either forbid completely globals

NOTE: should be "either completely forbid globals"

--------------------------------

----------
assignee: docs at python
components: Documentation
messages: 147851
nosy: Nebelhom, docs at python
priority: normal
severity: normal
status: open
title: The Python Standard Library >> 11. Data Persistence
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13426>
_______________________________________

From report at bugs.python.org  Fri Nov 18 12:36:11 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 18 Nov 2011 11:36:11 +0000
Subject: [issue13425] http.client.HTTPMessage.getallmatchingheaders() always
	returns []
In-Reply-To: <1321614230.59.0.764469605478.issue13425@psf.upfronthosting.co.za>
Message-ID: <1321616171.58.0.91933829479.issue13425@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Actually the headers are already parsed, so the code should use self.items() instead of self.keys(), check if the key (without ':') matches, and append the key-value pair to the list.
Having a list of key-value pairs seems more useful than having a bare string, but this would be incompatible with 2.7.
This function also doesn't seem to be tested and documented, and it's used only once in the stdlib.

----------
keywords: +easy
stage:  -> test needed
versions: +Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13425>
_______________________________________

From report at bugs.python.org  Fri Nov 18 12:41:21 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 18 Nov 2011 11:41:21 +0000
Subject: [issue13349] Uninformal error message in index() and remove()
	functions
In-Reply-To: <1320526177.89.0.678573577515.issue13349@psf.upfronthosting.co.za>
Message-ID: <1321616481.6.0.785282234232.issue13349@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Please don't stress too much about providing an indication that the repr has been truncated - it's an error message, not part of the normal program output. Besides, the lack of a closing ')', ']', '}' or '>' will usually indicate something is amiss in long reprs.

More useful would be to raise a separate feature request about the lack of width and precision handling for string formatting in PyUnicode_FromFormatV - the common format code handling means it *accepts* the width and precision information for string codes, but then proceeds to completely ignore it. It should be using them to pad short strings (width) and truncate long ones (precision), just like printf() (only in terms of code points rather than bytes, since those codes work with Unicode text).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13349>
_______________________________________

From report at bugs.python.org  Fri Nov 18 12:43:55 2011
From: report at bugs.python.org (Alan Beccati)
Date: Fri, 18 Nov 2011 11:43:55 +0000
Subject: [issue13427] string comparison with ==
Message-ID: <1321616635.73.0.844704371256.issue13427@psf.upfronthosting.co.za>


New submission from Alan Beccati <alan.beccati at gmail.com>:

Hello,
did I discover a python string comparison bug or is this behaviour expected and I am doing something wrong?

This is the code I run:
for line in lines[4:]:
	currColl=line.split(":")[1].strip()
	print "'",currColl,"'","==","'",collName,"'"
	if currColl == collName :
		return True
	else:
		print "not equal"

where currColl is a method parameter and lines is built from subprocess Popen like:
p = subprocess.Popen(cmd, shell=True, stdout=subprocess.PIPE, stderr=subprocess.STDOUT)
lines=[]
for line in p.stdout.readlines():
	lines.append(line)
	
The output of the abovementioned code is:
' utm ' == ' utm10 '
not equal
' utm1000 ' == ' utm10 '
not equal
' utm100 ' == ' utm10 '
not equal
' utm10 ' == ' utm10 '
not equal
' utm1 ' == ' utm10 '
not equal

as you can see the fourth comparison should return True while it gives a "not equal" as the others.

Python info:
Python 2.7.1+ (r271:86832, Apr 11 2011, 18:05:24) 
[GCC 4.5.2] on linux2

----------
messages: 147854
nosy: Alan.Beccati
priority: normal
severity: normal
status: open
title: string comparison with ==
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13427>
_______________________________________

From report at bugs.python.org  Fri Nov 18 12:50:14 2011
From: report at bugs.python.org (Florent Xicluna)
Date: Fri, 18 Nov 2011 11:50:14 +0000
Subject: [issue13427] string comparison with ==
In-Reply-To: <1321616635.73.0.844704371256.issue13427@psf.upfronthosting.co.za>
Message-ID: <1321617014.03.0.636721221052.issue13427@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

collName is probably not what you expect.
You can print repr(collName), repr(currColl) to verify this.

It is not a bug on Python side.

----------
nosy: +flox
resolution:  -> works for me
stage:  -> committed/rejected
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13427>
_______________________________________

From report at bugs.python.org  Fri Nov 18 12:53:06 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 18 Nov 2011 11:53:06 +0000
Subject: [issue13426] The Python Standard Library >> 11. Data Persistence
In-Reply-To: <1321615799.02.0.0403291741181.issue13426@psf.upfronthosting.co.za>
Message-ID: <E1RRN01-00015T-H1@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset ce34e9223450 by Ezio Melotti in branch '2.7':
#13426: fix typo in pickle doc.
http://hg.python.org/cpython/rev/ce34e9223450

New changeset 1f31061afdaf by Ezio Melotti in branch '3.2':
#13426: fix typos in pickle doc.
http://hg.python.org/cpython/rev/1f31061afdaf

New changeset 7992f3247447 by Ezio Melotti in branch 'default':
#13426: merge with 3.2.
http://hg.python.org/cpython/rev/7992f3247447

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13426>
_______________________________________

From report at bugs.python.org  Fri Nov 18 12:58:54 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 18 Nov 2011 11:58:54 +0000
Subject: [issue13426] The Python Standard Library >> 11. Data Persistence
In-Reply-To: <1321615799.02.0.0403291741181.issue13426@psf.upfronthosting.co.za>
Message-ID: <1321617534.73.0.127194901162.issue13426@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

This is fixed now, thanks for the report!
Regarding #4, sqlite3 is included in the official installer provided for Windows, so that shouldn't be a problem.
Regarding the output, I don't think is necessary to add it.
The example is fairly complex, so people that need it will probably have to try it and experiment a bit anyway, rather than just reading 100 lines of code and trying to understand how they work without actually trying it.

----------
assignee: docs at python -> ezio.melotti
nosy: +ezio.melotti
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
versions: +Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13426>
_______________________________________

From report at bugs.python.org  Fri Nov 18 12:58:55 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Fri, 18 Nov 2011 11:58:55 +0000
Subject: [issue13428] PyUnicode_FromFormatV: support width and precision for
	string codes, e.g %S and %R
Message-ID: <1321617535.12.0.0988297561958.issue13428@psf.upfronthosting.co.za>


New submission from Petri Lehtinen <petri at digip.org>:

Currently, the width and precision information for string codes are accepted but ignored. They should be used to pad short strings (width) and truncate long ones (precision), just like printf() (only in terms of code points rather than bytes, since those codes work with Unicode text).

----------
components: Interpreter Core
messages: 147858
nosy: petri.lehtinen
priority: normal
severity: normal
status: open
title: PyUnicode_FromFormatV: support width and precision for string codes, e.g %S and %R
type: feature request
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13428>
_______________________________________

From report at bugs.python.org  Fri Nov 18 13:01:47 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Fri, 18 Nov 2011 12:01:47 +0000
Subject: [issue13349] Uninformal error message in index() and remove()
	functions
In-Reply-To: <1321616481.6.0.785282234232.issue13349@psf.upfronthosting.co.za>
Message-ID: <20111118120133.GF3148@p16>


Petri Lehtinen <petri at digip.org> added the comment:

Nick Coghlan wrote:
> Please don't stress too much about providing an indication that the
> repr has been truncated - it's an error message, not part of the
> normal program output. Besides, the lack of a closing ')', ']', '}'
> or '>' will usually indicate something is amiss in long reprs.

Ok. This makes things easier.

> More useful would be to raise a separate feature request about the
> lack of width and precision handling for string formatting in
> PyUnicode_FromFormatV - the common format code handling means it
> *accepts* the width and precision information for string codes, but
> then proceeds to completely ignore it. It should be using them to
> pad short strings (width) and truncate long ones (precision), just
> like printf() (only in terms of code points rather than bytes, since
> those codes work with Unicode text).

Created #13428.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13349>
_______________________________________

From report at bugs.python.org  Fri Nov 18 13:03:21 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 18 Nov 2011 12:03:21 +0000
Subject: [issue13428] PyUnicode_FromFormatV: support width and precision for
	string codes, e.g %S and %R
In-Reply-To: <1321617535.12.0.0988297561958.issue13428@psf.upfronthosting.co.za>
Message-ID: <1321617801.7.0.733719368029.issue13428@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Duplicate of #7330.

----------
nosy: +haypo
resolution:  -> duplicate
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13428>
_______________________________________

From report at bugs.python.org  Fri Nov 18 13:03:43 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 18 Nov 2011 12:03:43 +0000
Subject: [issue7330] PyUnicode_FromFormat: implement width and precision for
	%s, %S, %R, %V, %U, %A
In-Reply-To: <1258314153.95.0.978747695294.issue7330@psf.upfronthosting.co.za>
Message-ID: <1321617823.88.0.792018016199.issue7330@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Issue #13428 has been marked as a duplicate of this issue.

----------
nosy: +petri.lehtinen

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7330>
_______________________________________

From report at bugs.python.org  Fri Nov 18 13:06:44 2011
From: report at bugs.python.org (Florent Xicluna)
Date: Fri, 18 Nov 2011 12:06:44 +0000
Subject: [issue13427] string comparison with ==
In-Reply-To: <1321616635.73.0.844704371256.issue13427@psf.upfronthosting.co.za>
Message-ID: <1321618004.71.0.342606792207.issue13427@psf.upfronthosting.co.za>


Changes by Florent Xicluna <florent.xicluna at gmail.com>:


----------
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13427>
_______________________________________

From report at bugs.python.org  Fri Nov 18 13:23:59 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 18 Nov 2011 12:23:59 +0000
Subject: [issue13426] Typos in pickle docs
In-Reply-To: <1321615799.02.0.0403291741181.issue13426@psf.upfronthosting.co.za>
Message-ID: <1321619039.82.0.909179191015.issue13426@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +eric.araujo
title: The Python Standard Library >> 11. Data Persistence -> Typos in pickle docs

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13426>
_______________________________________

From report at bugs.python.org  Fri Nov 18 13:25:02 2011
From: report at bugs.python.org (Nebelhom)
Date: Fri, 18 Nov 2011 12:25:02 +0000
Subject: [issue13426] The Python Standard Library >> 11. Data Persistence
In-Reply-To: <1321617534.73.0.127194901162.issue13426@psf.upfronthosting.co.za>
Message-ID: <CAHw0e=vWryZei6ru4=_y-3=fOd8AsgVFWfhFhzFQhFxQYs_HHg@mail.gmail.com>


Nebelhom <nebelhom at googlemail.com> added the comment:

Hi Ezio,

"Regarding the output, I don't think is necessary to add it."

I left it in because of a discussion in core-mentorship, where they
mentioned that it would be beneficial to have it in. I pasted the exchange
below if you are interested.

Thanks for looking at it,

Johannes

-------------------------------------
Pasted content:

Message: 2
Date: Fri, 18 Nov 2011 04:15:03 +0200
From: Eli Bendersky <eliben at gmail.com>
To: Python Core Development Mentorship <core-mentorship at python.org>
Subject: Re: [Core-mentorship] What classes as an issue in
       documentation?
Message-ID:
       <CAF-Rda-U5Jya999K=FW6Xe8VGrSpj1pHq0EtcMZ277x2JDtv0Q at mail.gmail.com>
Content-Type: text/plain; charset=windows-1252

trying
> to gauge what is relevant and what is just a little overly picky.
>
> I applied the standard, I use when proofreading scientific texts of fellow
> researchers (which raises the bar into infinity as you may always
encounter
> someone who is willing to split hairs over a comma in the wrong position
> just to be right). I would be grateful, if you could just quickly scan
over
> the list and say in each case (I numbered them) if it is relevant or not.
>
> thanks a bundle.
>
> Johannes
>
> P.S. Also, one issue for all issues in one section (like Nick Coghlan
> suggested)
>
> ------------------------------
> Python v3.3a0 documentation ? The Python Standard Library ? 11. Data
> Persistence ?
>
> Section 11.1 pickle module
>
> #1
> 11.1.3. Module Interface
>
> exception pickle.UnpicklingError
>
> ??? Error raised when there a problem unpickling an object, such as a data
> corruption or a security violation.
> ??? It inherits PickleError.
>
> TYPO: Error raised when there IS a problem unpickling an object
>
> ------------------------------
> #2
> 11.1.3. Module Interface
>
> persistent_load(pid)
>
> ??? Raise an UnpickingError by default.
>
> TYPO: Should be "Unpick"l"ingError" as wrtten earlier in the section
>
> ------------------------------
--
> #3
> 11.1.4 What can be pickled and unpickled
>
> Note that functions (built-in and user-defined) are pickled by ?fully
> qualified? name reference, not by value.
> This means that only the function name is pickled, along with the name of
> module the function is defined in.
>
> TYPO: along with the name of "THE" module the function is defined in.
>
> --------------------------------
> #4
> 11.1.5.1. Persistence of External Objects
>
> In Windows XP SP3, example does not work out of the box as sqlite3 is not
> included when compiling python3.3a
> following the Getting Set Up directions in the Developer's Guide
>
> Is this an issue?
>
> Code works in Ubuntu 10.04 lucid.
>
> When run from Terminal, it gives the following output:
>
> Pickled records:
> [MemoRecord(key=1, task='give food to fish'),
> ?MemoRecord(key=2, task='prepare group meeting'),
> ?MemoRecord(key=3, task='fight with a zebra')]
> Unpickled records:
> [MemoRecord(key=1, task='learn italian'),
> ?MemoRecord(key=2, task='prepare group meeting'),
> ?MemoRecord(key=3, task='fight with a zebra')]
>
>
> ?Should that not be given afterwards as a reference to the user, so that
> (s)he knows, that the code is right?
>
> --------------------------------
> #5
> 11.1.6 Restricting Globals
>
> Thus it is possible to either forbid completely globals
>
> NOTE: should be "either completely forbid globals"
>

Johannes,

These look perfectly valid to me. Even the smallest typos mentioned
here are worth fixing. The next step is opening an issue in the
tracker (http://bugs.python.org/) and submitting a patch.

Eli

------------------------------

Message: 3
Date: Fri, 18 Nov 2011 13:17:11 +1000
From: Nick Coghlan <ncoghlan at gmail.com>
To: Python Core Development Mentorship <core-mentorship at python.org>
Subject: Re: [Core-mentorship] What classes as an issue in
       documentation?
Message-ID:
       <CADiSq7cH_inw_3MUM8huro4GFT=uT7XOF04DE-cSb+BnjKRumg at mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1

On Fri, Nov 18, 2011 at 12:15 PM, Eli Bendersky <eliben at gmail.com> wrote:
> Johannes,
>
> These look perfectly valid to me. Even the smallest typos mentioned
> here are worth fixing. The next step is opening an issue in the
> tracker (http://bugs.python.org/) and submitting a patch.

Although I'll note that even if you're not yet ready to make the patch
yourself, a detailed report like this one makes it very easy for
someone *else* to produce a patch, so the tracker issue is the most
important next step.

Lots of things have to happen for a change to get into the source
tree, and the reason we have tools like the tracker around is so that
the work can be coordinated amongst multiple people.

Even as core devs, we'll still often post changes we design, code and
commit ourselves as tracker issues for a while, just so we have a
venue to coordinate reviews and gather feedback.

Cheers,
Nick.

----------
title: Typos in pickle docs -> The Python Standard Library >> 11. Data Persistence

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13426>
_______________________________________

From report at bugs.python.org  Fri Nov 18 13:26:40 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 18 Nov 2011 12:26:40 +0000
Subject: [issue6570] Tutorial clarity: section 4.7.2, parameters and arguments
In-Reply-To: <1248510940.46.0.953855607394.issue6570@psf.upfronthosting.co.za>
Message-ID: <1321619200.48.0.427490877735.issue6570@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Here is a new patch.

----------
Added file: http://bugs.python.org/file23722/issue6570-2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6570>
_______________________________________

From report at bugs.python.org  Fri Nov 18 13:28:37 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 18 Nov 2011 12:28:37 +0000
Subject: [issue13125] test_all_project_files() expected failure
In-Reply-To: <1318012693.65.0.29583104397.issue13125@psf.upfronthosting.co.za>
Message-ID: <1321619317.64.0.200554013296.issue13125@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/issue13125>
_______________________________________

From report at bugs.python.org  Fri Nov 18 13:31:12 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 18 Nov 2011 12:31:12 +0000
Subject: [issue10772] Several actions for argparse arguments missing from docs
In-Reply-To: <1293327184.11.0.454888760887.issue10772@psf.upfronthosting.co.za>
Message-ID: <1321619472.98.0.185795513224.issue10772@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Looks good to me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10772>
_______________________________________

From report at bugs.python.org  Fri Nov 18 13:35:10 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 18 Nov 2011 12:35:10 +0000
Subject: [issue10772] Several actions for argparse arguments missing from docs
In-Reply-To: <1293327184.11.0.454888760887.issue10772@psf.upfronthosting.co.za>
Message-ID: <1321619710.5.0.48999781935.issue10772@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
stage: patch review -> commit review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10772>
_______________________________________

From report at bugs.python.org  Fri Nov 18 13:41:11 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 18 Nov 2011 12:41:11 +0000
Subject: [issue4508] distutils compiler not handling spaces in path to
	output/src files
In-Reply-To: <1228341537.43.0.522254260997.issue4508@psf.upfronthosting.co.za>
Message-ID: <1321620071.04.0.394099794724.issue4508@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> Ok, I found a similar problem with MMTK.
I don?t know what that is.

> I am currently altering my distutils package to add a function called nt_quote_dir
> that adds quotes to paths with spaces and then applies it to each path if the platform
> is win32.
You shouldn?t have to do that; there?s already a similar function in distutils.spawn.

> When I'm done I will submit a diff after confirming that it works.
What is needed is a diff for distutils 2.7 or 3.2 adding a test with a file containing a space.  I can?t do anything with diffs for other projects.

----------
versions: +Python 3.3 -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4508>
_______________________________________

From report at bugs.python.org  Fri Nov 18 13:54:47 2011
From: report at bugs.python.org (=?utf-8?q?Michele_Orr=C3=B9?=)
Date: Fri, 18 Nov 2011 12:54:47 +0000
Subject: [issue13294] http.server: HEAD request should not return a body
In-Reply-To: <1321611835.59.0.354392628298.issue13294@psf.upfronthosting.co.za>
Message-ID: <CAMfKjGX7-C5rXB8WmVbnzA5-RmoEWq9pfS_DhgeW4KFqKE1V9g@mail.gmail.com>


Michele Orr? <maker.py at gmail.com> added the comment:

These tests shows how SimpleHTTPRequestHandler behaves: if the class
contains a do_FOO method, it is called, otherwise error501 is raised.
That's what Karl said with ?Or to modify the library code that for any
resources not yet defined.?.
Since SimpleHTTPRequestHandler.do_HEAD exists, and this is reflected
in the correspondent unittest, I belive that this is not a bug.

Patch attached. No problem if it's not committed now. I hope that
someone in the noisy list will make a little cleanup one day :)

>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue13294>
> _______________________________________
>

----------
Added file: http://bugs.python.org/file23723/issue13294.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13294>
_______________________________________
-------------- next part --------------
diff -r a00bb30cf775 Lib/http/server.py
--- a/Lib/http/server.py	Tue Nov 15 16:12:49 2011 +0100
+++ b/Lib/http/server.py	Wed Nov 16 11:15:45 2011 +0100
@@ -271,14 +271,11 @@
         self.request_version = version = self.default_request_version
         self.close_connection = 1
         requestline = str(self.raw_requestline, 'iso-8859-1')
-        if requestline[-2:] == '\r\n':
-            requestline = requestline[:-2]
-        elif requestline[-1:] == '\n':
-            requestline = requestline[:-1]
+        requestline = requestline.rstrip('\r\n')
         self.requestline = requestline
         words = requestline.split()
         if len(words) == 3:
-            [command, path, version] = words
+            command, path, version = words
             if version[:5] != 'HTTP/':
                 self.send_error(400, "Bad request version (%r)" % version)
                 return False
@@ -304,7 +301,7 @@
                           "Invalid HTTP Version (%s)" % base_version_number)
                 return False
         elif len(words) == 2:
-            [command, path] = words
+            command, path = words
             self.close_connection = 1
             if command != 'GET':
                 self.send_error(400,


From report at bugs.python.org  Fri Nov 18 13:57:17 2011
From: report at bugs.python.org (Alan)
Date: Fri, 18 Nov 2011 12:57:17 +0000
Subject: [issue13427] string comparison with ==
In-Reply-To: <1321616635.73.0.844704371256.issue13427@psf.upfronthosting.co.za>
Message-ID: <1321621037.87.0.241345185958.issue13427@psf.upfronthosting.co.za>


Alan <alan.beccati at gmail.com> added the comment:

Using repr highlights the issue which lies in the behaviour of str.strip() which does not strip away null spaces as I would have expected:

' 'utm10\x00' ' == ' 'utm10' '
not equal

Changing the code to:
currColl=line.split(":")[1].strip().strip("\0")

works but I think strip() should already do that by default, shouldn't it?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13427>
_______________________________________

From report at bugs.python.org  Fri Nov 18 13:57:49 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 18 Nov 2011 12:57:49 +0000
Subject: [issue13420] newer() function in dep_util.py discard changes in the
	same second
In-Reply-To: <1321529038.98.0.0841934486822.issue13420@psf.upfronthosting.co.za>
Message-ID: <1321621069.01.0.452196461304.issue13420@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Hi David.  Thanks for reporting the issue.  I have to warn you that there is a high bar for distutils changes; due to the mass of code out there that relies on undocumented internal behavior or works around old bugs, a feature freeze is in effect and we try to be very careful with the changes we make to fix bugs.  Some things clearly qualify as bugs and can be fixed, some things are clearly new features and are redirected to the distutils2 project, some bugs can?t be fixed because everyone and every tool is used to the buggy behavior.  Here we are in a gray area between bug and feature; one can argue that the behavior is not what is expected (bug), but one can reply that the documentation just doesn?t say that filesystems with millisecond precision are supported (so it would be a new feature).

> For example, I've a file that is modified with an installation prefix.
Modified by what when?

> CDBS runs the build step and after the install step. In build step, the prefix is
> '/usr/local' because the prefix argument isn't supported, immediately the install step
> runs with prefix='/usr', so the file that contains a variable with project path
> modified with the prefix is not copied by distutils, it runs in a different millisec
> but in the same second.
I don?t understand when the file is changed.  (BTW, I read some Debian mailing lists and I had the impression that CDBS was deprecated.)

----------
nosy: +jsjgruber

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13420>
_______________________________________

From report at bugs.python.org  Fri Nov 18 13:59:31 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 18 Nov 2011 12:59:31 +0000
Subject: [issue13427] string comparison with ==
In-Reply-To: <1321616635.73.0.844704371256.issue13427@psf.upfronthosting.co.za>
Message-ID: <1321621171.72.0.551241952711.issue13427@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Nope, str.strip only strips whitespace, and \x00 is not considered whitespace:
>>> '\x00'.isspace()
False

----------
nosy: +ezio.melotti
resolution: works for me -> invalid

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13427>
_______________________________________

From report at bugs.python.org  Fri Nov 18 14:03:06 2011
From: report at bugs.python.org (=?utf-8?q?Michele_Orr=C3=B9?=)
Date: Fri, 18 Nov 2011 13:03:06 +0000
Subject: [issue13294] http.server: HEAD request should not return a body
In-Reply-To: <1319985642.06.0.787750282348.issue13294@psf.upfronthosting.co.za>
Message-ID: <1321621386.63.0.472930961208.issue13294@psf.upfronthosting.co.za>


Michele Orr? <maker.py at gmail.com> added the comment:

As Ezio just pointed out, strip('\r\n') is still behaves differently from the previous code. Sorry for that.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13294>
_______________________________________

From report at bugs.python.org  Fri Nov 18 14:53:55 2011
From: report at bugs.python.org (David Amian)
Date: Fri, 18 Nov 2011 13:53:55 +0000
Subject: [issue13420] newer() function in dep_util.py discard changes in the
	same second
In-Reply-To: <1321529038.98.0.0841934486822.issue13420@psf.upfronthosting.co.za>
Message-ID: <1321624435.48.0.733557367041.issue13420@psf.upfronthosting.co.za>


David Amian <damian at emergya.com> added the comment:

sorry, I didn't explain well.
I've a project, in the setup.py file, I've a function called update_prefix, that updates the 'path_project' variable with prefix arguments from setup.py
If you runs setup.py with --prefix=/usr, then the file in 'projectname/projectnameconfig.py' is modified changing the 'path_project' variable from @PREFIX at +"share/projectname" to '/usr/share/projectname'.
If you runs setup.py without prefix arguments, the prefix is '/usr/local'.

Debuild which is the tool used to build debian package, in this case using CDBS, gives this output:
it first runs:
...
python setup.py build \
--build-base="/tmp/buildd/pdal2-0.3.1/./build"
running build
running build_py
creating /tmp/buildd/pdal2-0.3.1/build
creating /tmp/buildd/pdal2-0.3.1/build/lib.linux-i686-2.7
creating /tmp/buildd/pdal2-0.3.1/build/lib.linux-i686-2.7/pdal
copying pdal/utils.py -> /tmp/buildd/pdal2-0.3.1/./build/lib.linux-i686-2.7/pdal
copying pdal/pdalconfig.py -> /tmp/buildd/pdal2-0.3.1/./build/lib.linux-i686-2.7/pdal
...
then it runs:
...
cd . && \
		python setup.py install \
		--root="/tmp/buildd/pdal2-0.3.1/debian/pdal2/" \
		--install-purelib=/usr/lib/python2.7/site-packages/ \
		--prefix=/usr --no-compile -O0 --install-layout=deb 
running install
running build
running build_py
running build_scripts

It doesn't copy pdal/pdalconfig.py becouse the file in /tmp/buildd/pdal2-0.3.1/./build/lib.linux-i686-2.7/pdal have the same st_mtime in seconds than pdal/pdalconfig.py, but if you see de st_mtime, both are different in millisec and the file is different.

 File: ?pdal/pdalconfig.py?
Modify: 2011-11-16 11:55:52.665727826 +0100

File: ?/tmp/buildd/pdal2-0.3.1/./build/lib.linux-i686-2.7/pdal/pdalconfig.py?
Modify: 2011-11-16 11:55:52.000000000 +0100

but if you print the st_mtime of both files within newer() function you can check the file's timestamp are the same when they are really not:
ST_MTIME-source-target-1321440952-1321440952

That is cause of the issue, that I explain in the early comment, I fixed it rounding to two decimals instead of rounding to integer.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13420>
_______________________________________

From report at bugs.python.org  Fri Nov 18 15:11:23 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 18 Nov 2011 14:11:23 +0000
Subject: [issue13426] Typos in pickle docs
In-Reply-To: <1321615799.02.0.0403291741181.issue13426@psf.upfronthosting.co.za>
Message-ID: <1321625483.49.0.576253354666.issue13426@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

>> Regarding the output, I don't think is necessary to add it.
> I left it in because of a discussion in core-mentorship, where they
> mentioned that it would be beneficial to have it in.

Well, people can have diverging opinions.  Terry?s was that ?having the output, perhaps in a separate box, will also help to analyze the code to understand it?, but Ezio judged that ?the example is fairly complex, so people that need it will probably have to try it and experiment a bit anyway?.  I think I agree with Ezio.

----------
nosy: +terry.reedy
title: The Python Standard Library >> 11. Data Persistence -> Typos in pickle docs

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13426>
_______________________________________

From report at bugs.python.org  Fri Nov 18 15:19:08 2011
From: report at bugs.python.org (Ross Lagerwall)
Date: Fri, 18 Nov 2011 14:19:08 +0000
Subject: =?utf-8?q?=5Bissue13424=5D_Add_examples_for_open=E2=80=99s_new_opener_arg?=
	=?utf-8?q?ument?=
In-Reply-To: <1321609933.89.0.531165464334.issue13424@psf.upfronthosting.co.za>
Message-ID: <1321625948.44.0.573244045847.issue13424@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/issue13424>
_______________________________________

From report at bugs.python.org  Fri Nov 18 15:19:20 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 18 Nov 2011 14:19:20 +0000
Subject: [issue12779] Update packaging documentation
In-Reply-To: <1313686169.0.0.406072932055.issue12779@psf.upfronthosting.co.za>
Message-ID: <1321625960.72.0.185563787327.issue12779@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I worked on this a bit more and the current boring diff has more than 1000 deleted lines and more than 1000 added lines.  After thinking about it, maybe I should not make a mega-patch with markup/boring changes first but rather fix markup as part of more consistent wording and reorganization changes.  The series of changesets could look like this:

- Update and improve Doc/install (the end-user guide, a few files)
- Update and improve the commands reference in Doc/packaging
- Improve introduction material in Doc/packaging
- Fix X in Doc/library/packaging.foo
- Add missing doc for packaging.spam in Doc/library
- etc.

I think that will make more sense to review.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12779>
_______________________________________

From report at bugs.python.org  Fri Nov 18 15:30:27 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 18 Nov 2011 14:30:27 +0000
Subject: [issue13420] newer() function in dep_util.py discard changes in the
	same second
In-Reply-To: <1321529038.98.0.0841934486822.issue13420@psf.upfronthosting.co.za>
Message-ID: <1321626627.03.0.197752380943.issue13420@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> I've a project, in the setup.py file, I've a function called update_prefix, that updates the
> 'path_project' variable with prefix arguments from setup.py
> If you runs setup.py with --prefix=/usr, then the file in 'projectname/projectnameconfig.py' is
> modified changing the 'path_project' variable from @PREFIX at +"share/projectname" to
> '/usr/share/projectname'. If you runs setup.py without prefix arguments, the prefix is '/usr/local'.

Did you write a custom 'install' class or are you for example looking at sys.argv to decide whether to run your function?  If it?s not implemented as a distutils command, it?s not surprising that it does not integrate well.

> [...]
> That is cause of the issue, that I explain in the early comment, I fixed it rounding to two decimals
> instead of rounding to integer.

Okay.  Can you make sure that this is the source of the problem, for example by adding time.sleep(1) between build and install?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13420>
_______________________________________

From report at bugs.python.org  Fri Nov 18 15:31:46 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 18 Nov 2011 14:31:46 +0000
Subject: [issue4442] document immutable type subclassing via __new__
In-Reply-To: <1227719282.37.0.890069433685.issue4442@psf.upfronthosting.co.za>
Message-ID: <1321626706.44.0.888407292093.issue4442@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/issue4442>
_______________________________________

From report at bugs.python.org  Fri Nov 18 15:32:50 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 18 Nov 2011 14:32:50 +0000
Subject: [issue4395] Document auto __ne__ generation;
	provide a use case for non-trivial __ne__
In-Reply-To: <1227464493.77.0.130820783094.issue4395@psf.upfronthosting.co.za>
Message-ID: <1321626770.99.0.55093838803.issue4395@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/issue4395>
_______________________________________

From report at bugs.python.org  Fri Nov 18 15:35:46 2011
From: report at bugs.python.org (sbt)
Date: Fri, 18 Nov 2011 14:35:46 +0000
Subject: [issue13322] buffered read() and write() does not raise
	BlockingIOError
In-Reply-To: <1320246535.71.0.465783773129.issue13322@psf.upfronthosting.co.za>
Message-ID: <1321626946.05.0.871339002739.issue13322@psf.upfronthosting.co.za>


sbt <shibturn at gmail.com> added the comment:

> Thanks again. Just a nit: the tests should be in MiscIOTest, since 
> they don't directly instantiate the individual classes. Also, perhaps 
> it would be nice to check that the exception's "errno" attribute is 
> EAGAIN.


Done.

----------
Added file: http://bugs.python.org/file23724/write_blockingioerror.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13322>
_______________________________________

From report at bugs.python.org  Fri Nov 18 15:48:32 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 18 Nov 2011 14:48:32 +0000
Subject: [issue13388] document hg commit hooks in the devguide
In-Reply-To: <1321123590.65.0.736191202752.issue13388@psf.upfronthosting.co.za>
Message-ID: <1321627712.14.0.173633477224.issue13388@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> The commit details (including its changeset, branch and commit message)

In Mercurial terminology, a changeset *is* a commit (or if you really want to make a distinction, a commit is the action that creates a changeset).  I think you meant ?diff?.  Moreover, only the first line of the commit message is added, which is IMO worth mentioning.  Finally, I think we should recommend the ?#12345? style: For one thing, it makes our hgweb application create links.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13388>
_______________________________________

From report at bugs.python.org  Fri Nov 18 15:52:21 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 18 Nov 2011 14:52:21 +0000
Subject: [issue13343] Lambda keyword-only argument not updating co_freevars
In-Reply-To: <1320435452.65.0.656040815575.issue13343@psf.upfronthosting.co.za>
Message-ID: <1321627941.43.0.500275702987.issue13343@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> It's made my day. I get to boast at school now!
You could do more of that if you got a patch committed!  See http://docs.python.org/devguide and http://mail.python.org/mailman/listinfo/core-mentorship for more info if you?re interested.

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13343>
_______________________________________

From report at bugs.python.org  Fri Nov 18 15:53:48 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 18 Nov 2011 14:53:48 +0000
Subject: [issue13292] missing versionadded for bytearray
In-Reply-To: <1319975533.88.0.431386848219.issue13292@psf.upfronthosting.co.za>
Message-ID: <1321628028.93.0.308870551699.issue13292@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Thanks for cleaning up the reports.  I?m not a numbers person :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13292>
_______________________________________

From report at bugs.python.org  Fri Nov 18 16:36:33 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 18 Nov 2011 15:36:33 +0000
Subject: [issue4147] xml.dom.minidom toprettyxml: omit whitespace for
	text-only elements
In-Reply-To: <1224430404.43.0.0672391440841.issue4147@psf.upfronthosting.co.za>
Message-ID: <E1RRQUF-0005b6-3T@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 7262f8f276ff by Ezio Melotti in branch '2.7':
#4147: minidom's toprettyxml no longer adds whitespace around a text node when it is the only child of an element.  Initial patch by Dan Kenigsberg.
http://hg.python.org/cpython/rev/7262f8f276ff

New changeset 5401daa96a21 by Ezio Melotti in branch '3.2':
#4147: minidom's toprettyxml no longer adds whitespace around a text node when it is the only child of an element.  Initial patch by Dan Kenigsberg.
http://hg.python.org/cpython/rev/5401daa96a21

New changeset cb6614e3438b by Ezio Melotti in branch 'default':
#4147: merge with 3.2.
http://hg.python.org/cpython/rev/cb6614e3438b

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4147>
_______________________________________

From report at bugs.python.org  Fri Nov 18 16:39:14 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 18 Nov 2011 15:39:14 +0000
Subject: [issue4147] xml.dom.minidom toprettyxml: omit whitespace for
	text-only elements
In-Reply-To: <1224430404.43.0.0672391440841.issue4147@psf.upfronthosting.co.za>
Message-ID: <1321630754.27.0.284399251654.issue4147@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

I committed my patch with a few more tests.  This should be fixed now.
Thanks for the report and the patch!

----------
resolution:  -> fixed
stage: commit review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4147>
_______________________________________

From report at bugs.python.org  Fri Nov 18 16:46:58 2011
From: report at bugs.python.org (Stefan Behnel)
Date: Fri, 18 Nov 2011 15:46:58 +0000
Subject: [issue13429] provide __file__ to extension init function
Message-ID: <1321631218.51.0.537222078649.issue13429@psf.upfronthosting.co.za>


New submission from Stefan Behnel <scoder at users.sourceforge.net>:

In Python modules, the top-level module code sees the __file__ variable and can use it to refer to resources in package subdirectories, for example. This is not currently possible in extension modules, because __file__ is only set after running the module init function, and the module has no way to find out its runtime location.

CPython should set __file__ directly in PyModule_Create2(), based on information provided by the shared library loader. This would let PyModule_GetFilenameObject() work immediately with the newly created module object.

The relevant python-dev thread is here:

http://mail.python.org/pipermail/python-dev/2011-November/114476.html

A patch will follow soon.

----------
components: Extension Modules, Interpreter Core
messages: 147881
nosy: scoder
priority: normal
severity: normal
status: open
title: provide __file__ to extension init function
type: feature request
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13429>
_______________________________________

From report at bugs.python.org  Fri Nov 18 17:01:34 2011
From: report at bugs.python.org (Marko Nervo)
Date: Fri, 18 Nov 2011 16:01:34 +0000
Subject: [issue13430] Add a curry function to the functools module
Message-ID: <1321632094.44.0.291753245781.issue13430@psf.upfronthosting.co.za>


New submission from Marko Nervo <marko at python.it>:

I think it would be very usefull to add a curry function to the functools module. It should be like this.


def curry(func, *args, **kwargs):

    if (len(args) + len(kwargs)) >= func.__code__.co_argcount:

        return func(*args, **kwargs)

    return (lambda *x, **y: curry(func, *(args + x), **dict(kwargs, **y)))


This function allows you to create curried functions or methods in two main ways:


(1)


>>> def adder(x, y, z):
...     return (x + y + z)
>>> adder = curry(adder)


(2)


>>> @curry
... def adder(x, y, z):
...     return (x + y + z)


Curried functions could be used as follow.


>>> adder(2, 3, 4)
>>> adder(2, 3)(4)
>>> adder(2)(3)(4)
>>> adder(z = 4)(2, 3)  # etc, etc, etc...


Best regards,
Marco.

----------
components: Library (Lib)
messages: 147882
nosy: collinwinter, eric.araujo, gregory_p, markonervo, rhettinger, serprex
priority: normal
severity: normal
status: open
title: Add a curry function to the functools module
type: feature request
versions: Python 2.7, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13430>
_______________________________________

From report at bugs.python.org  Fri Nov 18 17:03:24 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 18 Nov 2011 16:03:24 +0000
Subject: [issue13358] HTMLParser incorrectly handles cdata elements.
In-Reply-To: <1320608905.33.0.994524216308.issue13358@psf.upfronthosting.co.za>
Message-ID: <E1RRQuE-0008VT-Eo@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 91163aa3d5b4 by Ezio Melotti in branch '2.7':
#13358: HTMLParser now calls handle_data only once for each CDATA.
http://hg.python.org/cpython/rev/91163aa3d5b4

New changeset 0a32e7e3aa1f by Ezio Melotti in branch '3.2':
#13358: HTMLParser now calls handle_data only once for each CDATA.
http://hg.python.org/cpython/rev/0a32e7e3aa1f

New changeset e12d2b9c88ef by Ezio Melotti in branch 'default':
#13358: merge with 3.2.
http://hg.python.org/cpython/rev/e12d2b9c88ef

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13358>
_______________________________________

From report at bugs.python.org  Fri Nov 18 17:05:19 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 18 Nov 2011 16:05:19 +0000
Subject: [issue13358] HTMLParser incorrectly handles cdata elements.
In-Reply-To: <1320608905.33.0.994524216308.issue13358@psf.upfronthosting.co.za>
Message-ID: <1321632319.46.0.441035838006.issue13358@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

This should be fixed now, let me know if you find other problems with the parser.

----------
resolution:  -> fixed
stage: commit review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13358>
_______________________________________

From report at bugs.python.org  Fri Nov 18 17:14:01 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 18 Nov 2011 16:14:01 +0000
Subject: [issue13430] Add a curry function to the functools module
In-Reply-To: <1321632094.44.0.291753245781.issue13430@psf.upfronthosting.co.za>
Message-ID: <1321632841.89.0.748277984429.issue13430@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

This sounds similar to http://wiki.python.org/moin/PythonDecoratorLibrary#Pseudo-currying

Do you have a concrete use case for this?

----------
nosy: +ezio.melotti
versions: +Python 3.3 -Python 2.7, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13430>
_______________________________________

From report at bugs.python.org  Fri Nov 18 17:15:37 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 18 Nov 2011 16:15:37 +0000
Subject: [issue13430] Add a curry function to the functools module
In-Reply-To: <1321632094.44.0.291753245781.issue13430@psf.upfronthosting.co.za>
Message-ID: <1321632937.05.0.438490641582.issue13430@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

You can use functools.partial for similar effect. Not sure what a dedicated curry() primitive would improve.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13430>
_______________________________________

From report at bugs.python.org  Fri Nov 18 17:16:18 2011
From: report at bugs.python.org (Alex Gaynor)
Date: Fri, 18 Nov 2011 16:16:18 +0000
Subject: [issue13430] Add a curry function to the functools module
In-Reply-To: <1321632094.44.0.291753245781.issue13430@psf.upfronthosting.co.za>
Message-ID: <1321632978.26.0.978968616497.issue13430@psf.upfronthosting.co.za>


Alex Gaynor <alex.gaynor at gmail.com> added the comment:

This already exists, as functools.partial: http://docs.python.org/library/functools.html#functools.partial

----------
nosy: +alex
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13430>
_______________________________________

From report at bugs.python.org  Fri Nov 18 17:17:40 2011
From: report at bugs.python.org (Stefan Behnel)
Date: Fri, 18 Nov 2011 16:17:40 +0000
Subject: [issue13429] provide __file__ to extension init function
In-Reply-To: <1321631218.51.0.537222078649.issue13429@psf.upfronthosting.co.za>
Message-ID: <1321633060.85.0.549466730256.issue13429@psf.upfronthosting.co.za>


Changes by Stefan Behnel <scoder at users.sourceforge.net>:


----------
keywords: +patch
nosy: +loewis
Added file: http://bugs.python.org/file23725/ext_module_init_file_path.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13429>
_______________________________________

From report at bugs.python.org  Fri Nov 18 17:22:22 2011
From: report at bugs.python.org (Stefan Behnel)
Date: Fri, 18 Nov 2011 16:22:22 +0000
Subject: [issue13429] provide __file__ to extension init function
In-Reply-To: <1321631218.51.0.537222078649.issue13429@psf.upfronthosting.co.za>
Message-ID: <1321633342.68.0.077756112582.issue13429@psf.upfronthosting.co.za>


Stefan Behnel <scoder at users.sourceforge.net> added the comment:

Here is an extension to the patch that implements the protocol also for extension module reinitialisation, so that the module creation can also set __file__ and the proper package in that case. Currently without tests (and users, I guess).

----------
Added file: http://bugs.python.org/file23726/ext_module_reinit_context.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13429>
_______________________________________

From report at bugs.python.org  Fri Nov 18 17:23:34 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 18 Nov 2011 16:23:34 +0000
Subject: [issue9614] _pickle is not entirely 64-bit safe
In-Reply-To: <1281895982.89.0.760453311109.issue9614@psf.upfronthosting.co.za>
Message-ID: <1321633414.75.0.731202884442.issue9614@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +brian.curtin
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9614>
_______________________________________

From report at bugs.python.org  Fri Nov 18 17:27:17 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 18 Nov 2011 16:27:17 +0000
Subject: [issue3430] httplib.HTTPResponse documentations inconsistent
In-Reply-To: <1216747880.73.0.0581734704537.issue3430@psf.upfronthosting.co.za>
Message-ID: <1321633637.75.0.129771955243.issue3430@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti
resolution: accepted -> 
versions: +Python 3.3 -Python 2.6, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3430>
_______________________________________

From report at bugs.python.org  Fri Nov 18 17:32:15 2011
From: report at bugs.python.org (=?utf-8?b?U8OpYmFzdGllbiBTYWJsw6k=?=)
Date: Fri, 18 Nov 2011 16:32:15 +0000
Subject: [issue10469] test_socket fails using Visual Studio 2010
In-Reply-To: <1290263082.19.0.540702085336.issue10469@psf.upfronthosting.co.za>
Message-ID: <1321633935.64.0.308959187018.issue10469@psf.upfronthosting.co.za>


S?bastien Sabl? <sable at users.sourceforge.net> added the comment:

I can also confirm that this patch corrects the problem with test_asyncore for Python 2.7 built with VS2010.

----------
nosy: +sable

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10469>
_______________________________________

From report at bugs.python.org  Fri Nov 18 17:36:19 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 18 Nov 2011 16:36:19 +0000
Subject: [issue11112] UDPTimeoutTest derives from SocketTCPTest
In-Reply-To: <1296788763.68.0.867412797858.issue11112@psf.upfronthosting.co.za>
Message-ID: <E1RRRQ5-0003Yr-RX@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 0fdf7f7c353d by Ezio Melotti in branch '2.7':
#11112: Fix typo in a base class in test_socket.
http://hg.python.org/cpython/rev/0fdf7f7c353d

New changeset b410bcd300a1 by Ezio Melotti in branch '3.2':
#11112: Fix typo in a base class in test_socket.
http://hg.python.org/cpython/rev/b410bcd300a1

New changeset 116ed0ce5756 by Ezio Melotti in branch 'default':
#11112: merge with 3.2.
http://hg.python.org/cpython/rev/116ed0ce5756

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11112>
_______________________________________

From report at bugs.python.org  Fri Nov 18 17:36:46 2011
From: report at bugs.python.org (Brian Curtin)
Date: Fri, 18 Nov 2011 16:36:46 +0000
Subject: [issue10469] test_socket fails using Visual Studio 2010
In-Reply-To: <1290263082.19.0.540702085336.issue10469@psf.upfronthosting.co.za>
Message-ID: <1321634206.98.0.286720352147.issue10469@psf.upfronthosting.co.za>


Brian Curtin <brian at python.org> added the comment:

FYI: this would likely be handled through #13210. I have a conversion sandbox started at http://hg.python.org/sandbox/vs2010port/ and am working through fixing test failures after the initial conversion.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10469>
_______________________________________

From report at bugs.python.org  Fri Nov 18 17:37:32 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 18 Nov 2011 16:37:32 +0000
Subject: [issue11112] UDPTimeoutTest derives from SocketTCPTest
In-Reply-To: <1296788763.68.0.867412797858.issue11112@psf.upfronthosting.co.za>
Message-ID: <1321634252.24.0.198573818758.issue11112@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Fixed, thanks for the report!

----------
assignee:  -> ezio.melotti
nosy: +ezio.melotti
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed
versions:  -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11112>
_______________________________________

From report at bugs.python.org  Fri Nov 18 17:39:24 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 18 Nov 2011 16:39:24 +0000
Subject: [issue11107] Cache constant "slice" instances
In-Reply-To: <1296761121.69.0.66743926851.issue11107@psf.upfronthosting.co.za>
Message-ID: <1321634364.61.0.117094303281.issue11107@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11107>
_______________________________________

From report at bugs.python.org  Fri Nov 18 17:40:14 2011
From: report at bugs.python.org (Brian Curtin)
Date: Fri, 18 Nov 2011 16:40:14 +0000
Subject: [issue13210] Support Visual Studio 2010
In-Reply-To: <1318942521.44.0.961979099616.issue13210@psf.upfronthosting.co.za>
Message-ID: <1321634414.12.0.781854200932.issue13210@psf.upfronthosting.co.za>


Brian Curtin <brian at python.org> added the comment:

I mentioned this on another issue, but I created a clone at http://hg.python.org/sandbox/vs2010port/. I've already gone through the port in the past but wasn't able to release the code at the time. As I work through it, I'll occasionally announce large milestones here.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13210>
_______________________________________

From report at bugs.python.org  Fri Nov 18 17:41:03 2011
From: report at bugs.python.org (Tim Golden)
Date: Fri, 18 Nov 2011 16:41:03 +0000
Subject: [issue13210] Support Visual Studio 2010
In-Reply-To: <1321634414.12.0.781854200932.issue13210@psf.upfronthosting.co.za>
Message-ID: <4EC68A8E.7020506@timgolden.me.uk>


Tim Golden <mail at timgolden.me.uk> added the comment:

Thanks. I was going to ask about this to see if anyone had already done 
the legwork.

----------
nosy: +tim.golden

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13210>
_______________________________________

From report at bugs.python.org  Fri Nov 18 17:47:49 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 18 Nov 2011 16:47:49 +0000
Subject: [issue10980] http.server Header Unicode Bug
In-Reply-To: <1295700354.03.0.333269896981.issue10980@psf.upfronthosting.co.za>
Message-ID: <1321634869.0.0.643730114976.issue10980@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Now it's too late for 3.1, should this still go to 2.7?

----------
nosy: +ezio.melotti
versions:  -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10980>
_______________________________________

From report at bugs.python.org  Fri Nov 18 17:51:57 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 18 Nov 2011 16:51:57 +0000
Subject: [issue10980] http.server Header Unicode Bug
In-Reply-To: <1295700354.03.0.333269896981.issue10980@psf.upfronthosting.co.za>
Message-ID: <1321635117.82.0.406602742872.issue10980@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Please.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10980>
_______________________________________

From report at bugs.python.org  Fri Nov 18 17:59:42 2011
From: report at bugs.python.org (Marko Nervo)
Date: Fri, 18 Nov 2011 16:59:42 +0000
Subject: [issue13430] Add a curry function to the functools module
In-Reply-To: <1321632094.44.0.291753245781.issue13430@psf.upfronthosting.co.za>
Message-ID: <1321635582.0.0.34243385897.issue13430@psf.upfronthosting.co.za>


Marko Nervo <marko at python.it> added the comment:

In [1]: import functools

In [2]: def adder(x, y, z):
   ...:     return (x + y + z)
   ...: 

In [3]: adder = functools.partial(adder)

In [4]: adder(2)(3)(4)
---------------------------------------------------------------------------
TypeError                                 Traceback (most recent call last)

/home/marko/<ipython console> in <module>()

TypeError: adder() takes exactly 3 arguments (1 given)


No, it can't be replaced using functools.partial.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13430>
_______________________________________

From report at bugs.python.org  Fri Nov 18 18:01:23 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 18 Nov 2011 17:01:23 +0000
Subject: [issue13387] suggest assertIs(type(obj), cls) for exact type checking
In-Reply-To: <1321101802.89.0.94542095022.issue13387@psf.upfronthosting.co.za>
Message-ID: <E1RRRoL-0005vX-KC@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset fd9d7a8e45bc by Ezio Melotti in branch '2.7':
#13387: add note about checking the exact type in assertIsInstance doc.
http://hg.python.org/cpython/rev/fd9d7a8e45bc

New changeset 583aff635ce1 by Ezio Melotti in branch '3.2':
#13387: add note about checking the exact type in assertIsInstance doc.
http://hg.python.org/cpython/rev/583aff635ce1

New changeset 196d485ed26d by Ezio Melotti in branch 'default':
#13387: merge with 3.2.
http://hg.python.org/cpython/rev/196d485ed26d

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13387>
_______________________________________

From report at bugs.python.org  Fri Nov 18 18:01:52 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 18 Nov 2011 17:01:52 +0000
Subject: [issue13387] suggest assertIs(type(obj), cls) for exact type checking
In-Reply-To: <1321101802.89.0.94542095022.issue13387@psf.upfronthosting.co.za>
Message-ID: <1321635712.51.0.887553979946.issue13387@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Fixed.

----------
assignee: docs at python -> ezio.melotti
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed
versions: +Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13387>
_______________________________________

From report at bugs.python.org  Fri Nov 18 18:02:24 2011
From: report at bugs.python.org (=?utf-8?b?U8OpYmFzdGllbiBTYWJsw6k=?=)
Date: Fri, 18 Nov 2011 17:02:24 +0000
Subject: [issue2286] Stack overflow exception caused by test_marshal on
	Windows x64
In-Reply-To: <1205499475.78.0.0465561571315.issue2286@psf.upfronthosting.co.za>
Message-ID: <1321635744.04.0.19844701269.issue2286@psf.upfronthosting.co.za>


S?bastien Sabl? <sable at users.sourceforge.net> added the comment:

I had the exact same problem when compiling the Python 2.7 branch with Visual Studio 2010.

In debug mode and 64 bits, python will crash on test_loads_recursion in test_marshal and on the code provided in msg63536.

Could you please reopen this issue?

----------
nosy: +sable
versions: +Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2286>
_______________________________________

From report at bugs.python.org  Fri Nov 18 18:03:05 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 18 Nov 2011 17:03:05 +0000
Subject: [issue13430] Add a curry function to the functools module
In-Reply-To: <1321632094.44.0.291753245781.issue13430@psf.upfronthosting.co.za>
Message-ID: <1321635785.16.0.616079076639.issue13430@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

To go back to your original message:

> I think it would be very usefull to add a curry function to the functools module.

For what use cases?

> Curried functions could be used as follow.
>>> adder(2, 3, 4)
>>> adder(2, 3)(4)
>>> adder(2)(3)(4)
>>> adder(z = 4)(2, 3)  # etc, etc, etc...

I don?t know the curry concept from other languages, but I?m experienced with Python and don?t like this idea at all.  A function returns something; the returned value being callable or not is a property of that value, not of the function.  The examples above look confusing to me.

I think you should discuss your use cases on the python-ideas mailing list.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13430>
_______________________________________

From report at bugs.python.org  Fri Nov 18 18:05:09 2011
From: report at bugs.python.org (Stefan Behnel)
Date: Fri, 18 Nov 2011 17:05:09 +0000
Subject: [issue10227] Improve performance of MemoryView slicing
In-Reply-To: <1288342228.97.0.170566139041.issue10227@psf.upfronthosting.co.za>
Message-ID: <1321635909.98.0.246561563137.issue10227@psf.upfronthosting.co.za>


Stefan Behnel <scoder at users.sourceforge.net> added the comment:

Updated single slice caching patch for latest Py3.3 hg tip.

----------
Added file: http://bugs.python.org/file23727/slice-object-cache.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10227>
_______________________________________

From report at bugs.python.org  Fri Nov 18 18:06:25 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 18 Nov 2011 17:06:25 +0000
Subject: [issue13387] suggest assertIs(type(obj), cls) for exact type checking
In-Reply-To: <1321101802.89.0.94542095022.issue13387@psf.upfronthosting.co.za>
Message-ID: <1321635985.63.0.832356331352.issue13387@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

+ To check for a specific type (without including superclasses) use
+ :func:`assertIs(type(obj), cls) <assertIs>`.

Don?t you mean ?without accepting subclasses?, not superclasses?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13387>
_______________________________________

From report at bugs.python.org  Fri Nov 18 18:08:05 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 18 Nov 2011 17:08:05 +0000
Subject: [issue13430] Add a curry function to the functools module
In-Reply-To: <1321632094.44.0.291753245781.issue13430@psf.upfronthosting.co.za>
Message-ID: <1321636085.21.0.272634648244.issue13430@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

FWIW there is a somewhat related thread that proposed a new syntax for curried functions: http://mail.python.org/pipermail/python-ideas/2009-March/003220.html

----------
stage:  -> committed/rejected

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13430>
_______________________________________

From report at bugs.python.org  Fri Nov 18 18:12:40 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 18 Nov 2011 17:12:40 +0000
Subject: [issue13429] provide __file__ to extension init function
In-Reply-To: <1321631218.51.0.537222078649.issue13429@psf.upfronthosting.co.za>
Message-ID: <1321636360.95.0.943852345394.issue13429@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

I suppose that the value of _Py_ModuleImportContext is protected by the import lock?

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13429>
_______________________________________

From report at bugs.python.org  Fri Nov 18 18:15:33 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 18 Nov 2011 17:15:33 +0000
Subject: [issue13387] suggest assertIs(type(obj), cls) for exact type checking
In-Reply-To: <1321101802.89.0.94542095022.issue13387@psf.upfronthosting.co.za>
Message-ID: <1321636533.62.0.452991276521.issue13387@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

> + To check for a specific type (without including superclasses) use
> + :func:`assertIs(type(obj), cls) <assertIs>`.
>
> Don?t you mean ?without accepting subclasses?, not superclasses?

I mean:
>>> class MyInt(int): pass     # my specific type
...
>>> isinstance(MyInt(5), int)  # int superclass included
True
>>> type(MyInt(5)) is int      # int superclass not included
False
>>> type(MyInt(5)) is MyInt    # check for specific type
True

Do you think I should rephrase it (or maybe just remove the (...))?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13387>
_______________________________________

From report at bugs.python.org  Fri Nov 18 18:18:37 2011
From: report at bugs.python.org (=?utf-8?b?U8OpYmFzdGllbiBTYWJsw6k=?=)
Date: Fri, 18 Nov 2011 17:18:37 +0000
Subject: [issue2286] Stack overflow exception caused by test_marshal on
	Windows x64
In-Reply-To: <1205499475.78.0.0465561571315.issue2286@psf.upfronthosting.co.za>
Message-ID: <1321636717.79.0.224537870062.issue2286@psf.upfronthosting.co.za>


S?bastien Sabl? <sable at users.sourceforge.net> added the comment:

I don't have the issue anymore when bumping the stack size to 2300000.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2286>
_______________________________________

From report at bugs.python.org  Fri Nov 18 18:19:30 2011
From: report at bugs.python.org (Armin Ronacher)
Date: Fri, 18 Nov 2011 17:19:30 +0000
Subject: [issue10980] http.server Header Unicode Bug
In-Reply-To: <1295700354.03.0.333269896981.issue10980@psf.upfronthosting.co.za>
Message-ID: <1321636770.05.0.733046994736.issue10980@psf.upfronthosting.co.za>


Armin Ronacher <armin.ronacher at active-4.com> added the comment:

2.7 does not suffer from this since 2.7 does not support unicode in headers.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10980>
_______________________________________

From report at bugs.python.org  Fri Nov 18 18:20:13 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 18 Nov 2011 17:20:13 +0000
Subject: [issue13397] Option for XMLRPC clients to automatically transform
	Fault exceptions into standard exceptions
In-Reply-To: <1321218030.66.0.0560016220773.issue13397@psf.upfronthosting.co.za>
Message-ID: <1321636813.2.0.299853276993.issue13397@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/issue13397>
_______________________________________

From report at bugs.python.org  Fri Nov 18 18:20:26 2011
From: report at bugs.python.org (Brian Curtin)
Date: Fri, 18 Nov 2011 17:20:26 +0000
Subject: [issue2286] Stack overflow exception caused by test_marshal on
	Windows x64
In-Reply-To: <1205499475.78.0.0465561571315.issue2286@psf.upfronthosting.co.za>
Message-ID: <1321636826.18.0.00399277333486.issue2286@psf.upfronthosting.co.za>


Changes by Brian Curtin <brian at python.org>:


----------
components: +Windows
nosy: +brian.curtin
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2286>
_______________________________________

From report at bugs.python.org  Fri Nov 18 18:21:07 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 18 Nov 2011 17:21:07 +0000
Subject: [issue13404] Add support for system.methodSignature() to XMLRPC Server
In-Reply-To: <1321292022.85.0.26720578121.issue13404@psf.upfronthosting.co.za>
Message-ID: <1321636867.47.0.899304713577.issue13404@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/issue13404>
_______________________________________

From report at bugs.python.org  Fri Nov 18 18:23:20 2011
From: report at bugs.python.org (Stefan Behnel)
Date: Fri, 18 Nov 2011 17:23:20 +0000
Subject: [issue13429] provide __file__ to extension init function
In-Reply-To: <1321631218.51.0.537222078649.issue13429@psf.upfronthosting.co.za>
Message-ID: <1321637000.84.0.559908320272.issue13429@psf.upfronthosting.co.za>


Stefan Behnel <scoder at users.sourceforge.net> added the comment:

I don't know how the import lock applies here. Would it have to be protected by it? The lifetime is restricted to the call of the extension module init function, and its value is saved recursively if the init function triggers further imports.

It works exactly like the existing _Py_PackageContext variable.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13429>
_______________________________________

From report at bugs.python.org  Fri Nov 18 18:29:21 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 18 Nov 2011 17:29:21 +0000
Subject: [issue13429] provide __file__ to extension init function
In-Reply-To: <1321631218.51.0.537222078649.issue13429@psf.upfronthosting.co.za>
Message-ID: <1321637361.67.0.139322731473.issue13429@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

But the GIL can be released in many places (e.g. a Py_DECREF), and another thread can enter the same function and update the same static variable.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13429>
_______________________________________

From report at bugs.python.org  Fri Nov 18 19:02:55 2011
From: report at bugs.python.org (Marko Nervo)
Date: Fri, 18 Nov 2011 18:02:55 +0000
Subject: [issue13430] Add a curry function to the functools module
In-Reply-To: <1321632094.44.0.291753245781.issue13430@psf.upfronthosting.co.za>
Message-ID: <1321639375.46.0.108686675289.issue13430@psf.upfronthosting.co.za>


Marko Nervo <marko at python.it> added the comment:

I totally disagree with the syntax for curried function, but I think a curry function is perfect for the functools module and I also think it could be useful at least as functools.partial. In addition, a lot of languages support currying, such as Haskell, Scala, Javascript...

However, here an example less confusional

>>> adder = curry(lambda (x, y): (x + y))
>>> adder3 = adder(3)
>>> adder3(4)
7
>>> adder3(5)
8

Currying let you defining new functions on other functions. This is a common practice in functional programming (point-free style). So, why not?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13430>
_______________________________________

From report at bugs.python.org  Fri Nov 18 19:07:40 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 18 Nov 2011 18:07:40 +0000
Subject: [issue13430] Add a curry function to the functools module
In-Reply-To: <1321639375.46.0.108686675289.issue13430@psf.upfronthosting.co.za>
Message-ID: <1321639363.3352.0.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> However, here an example less confusional
> 
> >>> adder = curry(lambda (x, y): (x + y))
> >>> adder3 = adder(3)
> >>> adder3(4)
> 7
> >>> adder3(5)
> 8
> 
> Currying let you defining new functions on other functions.

But so does functools.partial. So the question is, what use case does it
help that functools.partial doesn't?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13430>
_______________________________________

From report at bugs.python.org  Fri Nov 18 19:09:22 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 18 Nov 2011 18:09:22 +0000
Subject: [issue13430] Add a curry function to the functools module
In-Reply-To: <1321632094.44.0.291753245781.issue13430@psf.upfronthosting.co.za>
Message-ID: <1321639762.42.0.779851663893.issue13430@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

In that thread Guido said:
"""
Haskell has this too, perhaps even more extreme: there's not really
such a thing in Haskell as a function of N arguments (N > 1). "f a b =
..." defines a function f of one argument a which returns another
function ("f a") of one argument b. And so on.

That doesn't mean we need to copy this idea in Python.
"""

New features require a valid use case before being included, and I'm afraid "why not?" is not valid :)
(Also nothing prevents you to define your own curry function/decorator and use it where you need it.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13430>
_______________________________________

From report at bugs.python.org  Fri Nov 18 20:23:02 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 18 Nov 2011 19:23:02 +0000
Subject: [issue10227] Improve performance of MemoryView slicing
In-Reply-To: <1288342228.97.0.170566139041.issue10227@psf.upfronthosting.co.za>
Message-ID: <E1RRU1R-0002Ar-4R@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset fa2f8dd077e0 by Antoine Pitrou in branch 'default':
Issue #10227: Add an allocation cache for a single slice object.
http://hg.python.org/cpython/rev/fa2f8dd077e0

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10227>
_______________________________________

From report at bugs.python.org  Fri Nov 18 20:24:27 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 18 Nov 2011 19:24:27 +0000
Subject: [issue10227] Improve performance of MemoryView slicing
In-Reply-To: <1288342228.97.0.170566139041.issue10227@psf.upfronthosting.co.za>
Message-ID: <1321644267.8.0.326296656513.issue10227@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Thanks Stefan. I'm leaving the issue open since the original topic is a bit different.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10227>
_______________________________________

From report at bugs.python.org  Fri Nov 18 20:26:16 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 18 Nov 2011 19:26:16 +0000
Subject: [issue13322] buffered read() and write() does not raise
	BlockingIOError
In-Reply-To: <1320246535.71.0.465783773129.issue13322@psf.upfronthosting.co.za>
Message-ID: <1321644376.61.0.809666807871.issue13322@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Thanks. Who should I credit? "sbt"?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13322>
_______________________________________

From report at bugs.python.org  Fri Nov 18 20:29:04 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 18 Nov 2011 19:29:04 +0000
Subject: [issue9614] _pickle is not entirely 64-bit safe
In-Reply-To: <1281895982.89.0.760453311109.issue9614@psf.upfronthosting.co.za>
Message-ID: <1321644544.25.0.432560336178.issue9614@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

This issue is obsolete, there are no 64-bit warnings in _pickle.c anymore.
See issue 11564.

----------
resolution:  -> out of date
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9614>
_______________________________________

From report at bugs.python.org  Fri Nov 18 20:38:15 2011
From: report at bugs.python.org (Marko Nervo)
Date: Fri, 18 Nov 2011 19:38:15 +0000
Subject: [issue13430] Add a curry function to the functools module
In-Reply-To: <1321632094.44.0.291753245781.issue13430@psf.upfronthosting.co.za>
Message-ID: <1321645095.52.0.587027963.issue13430@psf.upfronthosting.co.za>


Marko Nervo <marko at python.it> added the comment:

> But so does functools.partial. So the question is, what use case does it
> help that functools.partial doesn't?

Sure, it's common `defining new functions on other functions`... more times. Here a stupid example with fold (our reduce).


@curry
def fold(function, start, sequence):
    if len(sequence) == 0:
        return start
    else:
        return fold(function, function(start, sequence[0]), sequence[1:])


Now, someone could be define a generic summer function by fold.


import operator as op

summer = fold(op.add)


Now, an other programmer could be use summer for defining listsummer (a function which sum only list), as follow.


listsummer = summer([])


In addition, curry is cleaver than functools.partial. 


summer = functools.partial(fold, op.add)
listsummer = functools.partial(summer, [])


However, it is an additional feature. Nobody forces you to use it, but if you need it... Yeah, you could rewrite it each time, but why? It is perfect in functools (:

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13430>
_______________________________________

From report at bugs.python.org  Fri Nov 18 20:43:34 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 18 Nov 2011 19:43:34 +0000
Subject: [issue13430] Add a curry function to the functools module
In-Reply-To: <1321645095.52.0.587027963.issue13430@psf.upfronthosting.co.za>
Message-ID: <1321645117.3352.4.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Sure, it's common `defining new functions on other functions`... more
> times. Here a stupid example with fold (our reduce).
> 
> @curry
> def fold(function, start, sequence):
>     if len(sequence) == 0:
>         return start
>     else:
>         return fold(function, function(start, sequence[0]), sequence[1:])
> 
> Now, someone could be define a generic summer function by fold.
> 
> import operator as op
> 
> summer = fold(op.add)

Right... so you defined these helper functions (curry, fold) just to...
define a generic summer function? Really?

I understand that fold() and curry() may look pretty to functional
languages people, but they don't solve any real-world problems that
Python doesn't already solve in a neater way. You will have to try a bit
harder and showcase examples of *useful* code that are made
significantly easier through the use of curry().

(no, generic summer functions are *not* real-world use cases. They are
homework exercises for CS students, at best)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13430>
_______________________________________

From report at bugs.python.org  Fri Nov 18 21:00:10 2011
From: report at bugs.python.org (Stefan Behnel)
Date: Fri, 18 Nov 2011 20:00:10 +0000
Subject: [issue13429] provide __file__ to extension init function
In-Reply-To: <1321631218.51.0.537222078649.issue13429@psf.upfronthosting.co.za>
Message-ID: <1321646410.57.0.567479702204.issue13429@psf.upfronthosting.co.za>


Stefan Behnel <scoder at users.sourceforge.net> added the comment:

... and the module init function could create and register a different module first, and ...

Well, yes, it's a best effort thing. It's rather unlikely that the GIL would get released in between the call to the init function and the creation of the module within that function, but sure, I don't see a reason why it could not happen.

However, it can't happen in moduleobject.c between the NULL check and the setting of the __file__ attribute, so that is safe enough to not trigger crashes.

And even if the wrong __file__ value is set during the run of the init function, it will still get overwritten (and thus fixed) afterwards. So my intuition is that code that relies on this new feature will simply have to make sure the module object creation is the first thing it does, and code that does not rely on it, well, does not rely on it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13429>
_______________________________________

From report at bugs.python.org  Fri Nov 18 21:20:21 2011
From: report at bugs.python.org (Marko Nervo)
Date: Fri, 18 Nov 2011 20:20:21 +0000
Subject: [issue13430] Add a curry function to the functools module
In-Reply-To: <1321632094.44.0.291753245781.issue13430@psf.upfronthosting.co.za>
Message-ID: <1321647621.99.0.615892758238.issue13430@psf.upfronthosting.co.za>


Marko Nervo <marko at python.it> added the comment:

> You will have to try a bit
> harder and showcase examples of *useful* code that are made
> significantly easier through the use of curry().

Curry is a more advanced functools.partial. So, it could be used *at least* as partial, but it is more powerfull, usable and readable. I think it's a valid reason; if it isn't, I haven't anything else to say.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13430>
_______________________________________

From report at bugs.python.org  Fri Nov 18 21:31:12 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 18 Nov 2011 20:31:12 +0000
Subject: [issue13429] provide __file__ to extension init function
In-Reply-To: <1321631218.51.0.537222078649.issue13429@psf.upfronthosting.co.za>
Message-ID: <1321648272.1.0.312472544137.issue13429@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

> ... and the module init function could create and register a
> different module first, and ...
Actually, this *does* happen, the PIL module is written this way.
And I don't agree with the "best effort" argument.  If there is a slight chance that this does not work, we'll have to fix it sooner or later.

But please check this import lock thing: if _PyImport_AcquireLock and _PyImport_ReleaseLock are always called around extension module initialization, then we don't have to worry about other threads; and nested calls are already handled by the "oldimportcontext" variable in your patch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13429>
_______________________________________

From report at bugs.python.org  Fri Nov 18 21:55:30 2011
From: report at bugs.python.org (Eric Snow)
Date: Fri, 18 Nov 2011 20:55:30 +0000
Subject: [issue13429] provide __file__ to extension init function
In-Reply-To: <1321631218.51.0.537222078649.issue13429@psf.upfronthosting.co.za>
Message-ID: <1321649730.42.0.482818279069.issue13429@psf.upfronthosting.co.za>


Changes by Eric Snow <ericsnowcurrently at gmail.com>:


----------
nosy: +eric.snow

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13429>
_______________________________________

From report at bugs.python.org  Fri Nov 18 22:22:36 2011
From: report at bugs.python.org (sbt)
Date: Fri, 18 Nov 2011 21:22:36 +0000
Subject: [issue13322] buffered read() and write() does not raise
	BlockingIOError
In-Reply-To: <1320246535.71.0.465783773129.issue13322@psf.upfronthosting.co.za>
Message-ID: <1321651356.56.0.641669636283.issue13322@psf.upfronthosting.co.za>


sbt <shibturn at gmail.com> added the comment:

> Thanks. Who should I credit? "sbt"?

Yeah, thanks.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13322>
_______________________________________

From report at bugs.python.org  Fri Nov 18 22:59:05 2011
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Fri, 18 Nov 2011 21:59:05 +0000
Subject: [issue13429] provide __file__ to extension init function
In-Reply-To: <1321631218.51.0.537222078649.issue13429@psf.upfronthosting.co.za>
Message-ID: <1321653545.4.0.759042202452.issue13429@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/issue13429>
_______________________________________

From report at bugs.python.org  Sat Nov 19 00:44:01 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 18 Nov 2011 23:44:01 +0000
Subject: [issue13393] Improve BufferedReader.read1()
In-Reply-To: <1321157701.74.0.443809978111.issue13393@psf.upfronthosting.co.za>
Message-ID: <E1RRY60-0008Oj-FS@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 76d414cc3e38 by Antoine Pitrou in branch 'default':
Issue #13393: In TextIOWrapper.read(n), try to read `n` characters as
http://hg.python.org/cpython/rev/76d414cc3e38

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13393>
_______________________________________

From report at bugs.python.org  Sat Nov 19 00:58:11 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 18 Nov 2011 23:58:11 +0000
Subject: [issue13393] Improve BufferedReader.read1()
In-Reply-To: <1321157701.74.0.443809978111.issue13393@psf.upfronthosting.co.za>
Message-ID: <1321660691.35.0.931395839693.issue13393@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I've committed a slightly modified patch. Not a huge improvement, but makes sense nevertheless (and it's really short).

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13393>
_______________________________________

From report at bugs.python.org  Sat Nov 19 03:35:53 2011
From: report at bugs.python.org (Gregory P. Smith)
Date: Sat, 19 Nov 2011 02:35:53 +0000
Subject: [issue13417] faster utf-8 decoding
In-Reply-To: <1321483781.85.0.24668666063.issue13417@psf.upfronthosting.co.za>
Message-ID: <1321670153.01.0.311164297054.issue13417@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

+1 nice!  A couple minor comments on the code review.

----------
nosy: +gregory.p.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13417>
_______________________________________

From report at bugs.python.org  Sat Nov 19 07:12:50 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Sat, 19 Nov 2011 06:12:50 +0000
Subject: [issue13388] document hg commit hooks in the devguide
In-Reply-To: <1321123590.65.0.736191202752.issue13388@psf.upfronthosting.co.za>
Message-ID: <1321683170.88.0.8913742634.issue13388@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

?ric, feel free to fix it to your heart's desire ;-) I think that having it documented is far more important than nuances in nomenclature, so I'm -0 on this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13388>
_______________________________________

From report at bugs.python.org  Sat Nov 19 09:23:07 2011
From: report at bugs.python.org (Stefan Behnel)
Date: Sat, 19 Nov 2011 08:23:07 +0000
Subject: [issue13429] provide __file__ to extension init function
In-Reply-To: <1321631218.51.0.537222078649.issue13429@psf.upfronthosting.co.za>
Message-ID: <1321690987.0.0.984903978025.issue13429@psf.upfronthosting.co.za>


Stefan Behnel <scoder at users.sourceforge.net> added the comment:

I'm aware that these things happen, that's why I said it. Actually, wouldn't it rather be *correct* for __file__ to be set to the same file path for all modules that an extension module creates in its init function? That would suggest that _Py_ModuleImportContext shouldn't be set to NULL after the first assignment, but instead stay alive until it gets reset by the dynlib loader. If the loader gets invoked recursively later on, it will do the right thing by storing away the old value during the import and restoring it afterwards. So _Py_ModuleImportContext would always point to the path that contains the init function that is currently being executed.

Regarding the lock (which, I assume, is simply reentrant), it's being acquired far up when the import mechanism starts, so the dynlib loader and the init function call are protected.

Note that this does not apply to the reinit case. _PyImport_FindExtensionObject() does not acquire the lock itself (which seems correct), and it can be called directly from imp.init_builtin(), i.e. from user code. Maybe that's why the _Py_PackageContext protocol was not implemented there. That's rather unfortunate, though. I guess the reasoning is that new code that uses this new feature is expected to actually be reentrant, also in parallel, because the module it creates and works on is local to the current thread until the init function terminates. So the import lock is not strictly required here. This does complicate the __file__ feature, though, so the second ("reinit") patch won't work as is. I think the right fix for Python 4 would be to simply pass a context struct into the module init function.

On a related note, I just stumbled over this code in _PyImport_FindExtensionObject():

    else {
        if (def->m_base.m_init == NULL)
            return NULL;
        mod = def->m_base.m_init();
        if (mod == NULL)
            return NULL;
        PyDict_SetItem(PyImport_GetModuleDict(), name, mod);
        Py_DECREF(mod);
    }
    if (_PyState_AddModule(mod, def) < 0) {
        PyDict_DelItem(PyImport_GetModuleDict(), name);
        Py_DECREF(mod);
        return NULL;
    }

If PyDict_SetItem() fails, this is bound to crash. I think it would be worth looking into this mechanism a bit more.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13429>
_______________________________________

From report at bugs.python.org  Sat Nov 19 09:29:40 2011
From: report at bugs.python.org (Stefan Behnel)
Date: Sat, 19 Nov 2011 08:29:40 +0000
Subject: [issue13429] provide __file__ to extension init function
In-Reply-To: <1321631218.51.0.537222078649.issue13429@psf.upfronthosting.co.za>
Message-ID: <1321691380.35.0.814037536557.issue13429@psf.upfronthosting.co.za>


Stefan Behnel <scoder at users.sourceforge.net> added the comment:

Updated patch that does not reset _Py_ModuleImportContext after use.

----------
Added file: http://bugs.python.org/file23728/ext_module_init_file_path_2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13429>
_______________________________________

From report at bugs.python.org  Sat Nov 19 10:00:28 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 19 Nov 2011 09:00:28 +0000
Subject: [issue13215] multiprocessing Manager.connect() aggressively retries
	refused connections
In-Reply-To: <1318965417.81.0.122561387998.issue13215@psf.upfronthosting.co.za>
Message-ID: <E1RRgmU-0002IL-Cn@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 34fcc0d5c3c5 by Charles-Fran?ois Natali in branch 'default':
Issue #13215: multiprocessing.Connection: don't hammer the remote end with
http://hg.python.org/cpython/rev/34fcc0d5c3c5

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13215>
_______________________________________

From report at bugs.python.org  Sat Nov 19 10:16:48 2011
From: report at bugs.python.org (Stefan Behnel)
Date: Sat, 19 Nov 2011 09:16:48 +0000
Subject: [issue13431] Pass context information into the extension module init
	function
Message-ID: <1321694208.82.0.599594610804.issue13431@psf.upfronthosting.co.za>


New submission from Stefan Behnel <scoder at users.sourceforge.net>:

This is a follow-up to issue 13429, which deals with setting __file__ on newly created extension modules earlier than it is currently the case.

Currently, the module init function of extension modules lacks a way to find out the context in which it is being imported, e.g. its package path or its location in the file system. This makes it tricky for extension modules to do things like loading package resources or using relative imports at init time.

This can be fixed by allowing the init function to take a context struct as argument, which would contain object pointers to the FQ package name and file path, and potentially other information.

I think this would be backwards compatible to existing code, because C should allow the caller of the init function to pack additional arguments on the stack that the called function simply doesn't care about. From CPython 3.3 on, however, new and updated code could benefit from this feature.

----------
components: Extension Modules, Interpreter Core
messages: 147931
nosy: scoder
priority: normal
severity: normal
status: open
title: Pass context information into the extension module init function
type: feature request
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13431>
_______________________________________

From report at bugs.python.org  Sat Nov 19 10:18:32 2011
From: report at bugs.python.org (Stefan Behnel)
Date: Sat, 19 Nov 2011 09:18:32 +0000
Subject: [issue13429] provide __file__ to extension init function
In-Reply-To: <1321631218.51.0.537222078649.issue13429@psf.upfronthosting.co.za>
Message-ID: <1321694312.68.0.727372594077.issue13429@psf.upfronthosting.co.za>


Stefan Behnel <scoder at users.sourceforge.net> added the comment:

Replying to myself:
> I think the right fix for Python 4 would be to simply pass
> a context struct into the module init function.

Actually, this doesn't have to wait for Python 4. Changing the module init function to take a parameter should be backwards compatible in C. Existing code simply wouldn't read the value from the stack, and new (or updated) code could benefit from the feature, Cython code in particular.

Here is a follow-up ticket for this more general feature:

http://bugs.python.org/issue13431

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13429>
_______________________________________

From report at bugs.python.org  Sat Nov 19 11:16:08 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sat, 19 Nov 2011 10:16:08 +0000
Subject: [issue13431] Pass context information into the extension module init
	function
In-Reply-To: <1321694208.82.0.599594610804.issue13431@psf.upfronthosting.co.za>
Message-ID: <1321697768.9.0.232234793461.issue13431@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

This approach is not correct C. You may pass an "incorrect" number of arguments only if the function is declared with an ellipsis, else the behavior is undefined (6.5.5.2p6). Your proposed approach works with most implementations of C, but Python shouldn't deliberately rely on undefined behavior.

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13431>
_______________________________________

From report at bugs.python.org  Sat Nov 19 11:17:50 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sat, 19 Nov 2011 10:17:50 +0000
Subject: [issue13431] Pass context information into the extension module init
	function
In-Reply-To: <1321694208.82.0.599594610804.issue13431@psf.upfronthosting.co.za>
Message-ID: <1321697870.43.0.100666778151.issue13431@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

FWIW, I think that a PEP will be needed to redesign the module initialization for Python 4. Hopefully, this time people will then identify all requirements before the PEP is accepted (which unfortunately didn't happen for PEP 3121).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13431>
_______________________________________

From report at bugs.python.org  Sat Nov 19 11:47:21 2011
From: report at bugs.python.org (Stefan Behnel)
Date: Sat, 19 Nov 2011 10:47:21 +0000
Subject: [issue13431] Pass context information into the extension module init
	function
In-Reply-To: <1321694208.82.0.599594610804.issue13431@psf.upfronthosting.co.za>
Message-ID: <1321699641.67.0.59164254566.issue13431@psf.upfronthosting.co.za>


Stefan Behnel <scoder at users.sourceforge.net> added the comment:

Yes, that's unfortunate. I found the same paragraph in section 6.5.2.2p6 of the C99 standard now, so it seems that this idea isn't suitable for the Py3.x series.

There's no Python 4 target version in the bug tracker, BTW. :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13431>
_______________________________________

From report at bugs.python.org  Sat Nov 19 11:50:21 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Sat, 19 Nov 2011 10:50:21 +0000
Subject: [issue13402] Document absoluteness of sys.executable
In-Reply-To: <1321289437.84.0.982753479785.issue13402@psf.upfronthosting.co.za>
Message-ID: <1321699821.54.0.545376046977.issue13402@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/issue13402>
_______________________________________

From report at bugs.python.org  Sat Nov 19 11:51:43 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Sat, 19 Nov 2011 10:51:43 +0000
Subject: [issue13403] Option for XMLPRC Server to support HTTPS
In-Reply-To: <1321291767.37.0.486686259371.issue13403@psf.upfronthosting.co.za>
Message-ID: <1321699903.04.0.244142387053.issue13403@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/issue13403>
_______________________________________

From report at bugs.python.org  Sat Nov 19 11:56:59 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Sat, 19 Nov 2011 10:56:59 +0000
Subject: [issue13407] tarfile.getnames misses members again
In-Reply-To: <1321352961.33.0.0944615995053.issue13407@psf.upfronthosting.co.za>
Message-ID: <1321700219.29.0.756398587949.issue13407@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/issue13407>
_______________________________________

From report at bugs.python.org  Sat Nov 19 12:35:12 2011
From: report at bugs.python.org (kxroberto)
Date: Sat, 19 Nov 2011 11:35:12 +0000
Subject: [issue13432] Encoding alias "unicode"
Message-ID: <1321702512.61.0.807104309131.issue13432@psf.upfronthosting.co.za>


New submission from kxroberto <kxroberto at users.sourceforge.net>:

"unicode" seems not to be an official unicode encoding name alias.
Yet it is quite frequent on the web - and obviously means UTF-8. 
(search '"text/html; charset=unicode"' in Google)
Chrome and IE display it as UTF-8.  (Mozilla as ASCII, thus mixed up chars).

Should it be added in to aliases.py ?

--- ./aliases.py
+++ ./aliases.py
@@ -511,6 +511,7 @@
     'utf8'               : 'utf_8',
     'utf8_ucs2'          : 'utf_8',
     'utf8_ucs4'          : 'utf_8',
+    'unicode'            : 'utf_8',
 
     # uu_codec codec
     'uu'                 : 'uu_codec',

----------
messages: 147936
nosy: kxroberto
priority: normal
severity: normal
status: open
title: Encoding alias "unicode"

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13432>
_______________________________________

From report at bugs.python.org  Sat Nov 19 12:36:16 2011
From: report at bugs.python.org (kxroberto)
Date: Sat, 19 Nov 2011 11:36:16 +0000
Subject: [issue13432] Encoding alias "unicode"
In-Reply-To: <1321702512.61.0.807104309131.issue13432@psf.upfronthosting.co.za>
Message-ID: <1321702576.56.0.490405313225.issue13432@psf.upfronthosting.co.za>


Changes by kxroberto <kxroberto at users.sourceforge.net>:


----------
components: +Unicode
nosy: +ezio.melotti
type:  -> feature request
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/issue13432>
_______________________________________

From report at bugs.python.org  Sat Nov 19 12:49:48 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 19 Nov 2011 11:49:48 +0000
Subject: [issue13432] Encoding alias "unicode"
In-Reply-To: <1321702512.61.0.807104309131.issue13432@psf.upfronthosting.co.za>
Message-ID: <1321703388.55.0.252520461578.issue13432@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Sorry, but it's not obviously that Unicode means UTF-8.

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13432>
_______________________________________

From report at bugs.python.org  Sat Nov 19 13:03:32 2011
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 19 Nov 2011 12:03:32 +0000
Subject: [issue13432] Encoding alias "unicode"
In-Reply-To: <1321702512.61.0.807104309131.issue13432@psf.upfronthosting.co.za>
Message-ID: <1321704212.99.0.207922863571.issue13432@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Definitely; this will just serve to create more confusion for beginners over what a Unicode string is:

unicodestring.encode('unicode')   <- WTF?

----------
nosy: +georg.brandl
resolution:  -> rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13432>
_______________________________________

From report at bugs.python.org  Sat Nov 19 13:25:15 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Sat, 19 Nov 2011 12:25:15 +0000
Subject: [issue13430] Add a curry function to the functools module
In-Reply-To: <1321632094.44.0.291753245781.issue13430@psf.upfronthosting.co.za>
Message-ID: <1321705515.83.0.481256436409.issue13430@psf.upfronthosting.co.za>


Petri Lehtinen <petri at digip.org> added the comment:

@markonervo: Have you tried the pointfree library: http://pypi.python.org/pypi/pointfree/ ? I think it's exactly what you're asking for.

The only case I've ever needed currying was managing callback soup in async code. And even then, functools.partial() was perfectly enough.

I don't think this would be useful in Python stdlib, so -1 from me.

----------
nosy: +petri.lehtinen

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13430>
_______________________________________

From report at bugs.python.org  Sat Nov 19 14:01:32 2011
From: report at bugs.python.org (Christian Iversen)
Date: Sat, 19 Nov 2011 13:01:32 +0000
Subject: [issue13433] String format documentation contains error regarding %g
Message-ID: <1321707692.58.0.601543510069.issue13433@psf.upfronthosting.co.za>


New submission from Christian Iversen <ci at sikkerhed.org>:

The documentation for string format options state that both %f, %g and %e default to 6 digits after the decimal point. In fact, %g always seems to use 5 digits by default:

>>> "%g" % 2.1234567
'2.12346'
>>> "%f" % 2.1234567
'2.123457'
>>> "%e" % 2.1234567
'2.123457e+00'

But something much more insidious is wrong, because even when explicitly told how many digits to have, %g is one off:

>>> "%.6g" % 2.1234567
'2.12346'
>>> "%.6f" % 2.1234567
'2.123457'
>>> "%.6e" % 2.1234567
'2.123457e+00'

This can't be right?

----------
assignee: docs at python
components: Documentation
messages: 147940
nosy: Christian.Iversen, docs at python
priority: normal
severity: normal
status: open
title: String format documentation contains error regarding %g
type: behavior
versions: Python 2.6, Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13433>
_______________________________________

From report at bugs.python.org  Sat Nov 19 14:24:52 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sat, 19 Nov 2011 13:24:52 +0000
Subject: [issue12156] test_multiprocessing.test_notify_all() timeout (1 hour)
	on FreeBSD 7.2
In-Reply-To: <1306147254.92.0.286085135906.issue12156@psf.upfronthosting.co.za>
Message-ID: <1321709092.26.0.776753011793.issue12156@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

Alright, I got tired of seeing the FreeBSD buildbots consistently choke on test_multiprocessing, so here's a simple patch that skips the test if the OS doesn't support a reasonable number (30) of semaphores.

----------
keywords: +patch
Added file: http://bugs.python.org/file23729/test_multi_sem.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12156>
_______________________________________

From report at bugs.python.org  Sat Nov 19 14:26:24 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 19 Nov 2011 13:26:24 +0000
Subject: [issue13433] String format documentation contains error regarding %g
In-Reply-To: <1321707692.58.0.601543510069.issue13433@psf.upfronthosting.co.za>
Message-ID: <1321709184.04.0.466428984851.issue13433@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Yep, there's an oddity here that's directly inherited from C's sprintf family of functions, namely that in %e-style formatting you give the number of digits after the point (= one less than the total number of significant digits), and in %g-style formatting you give the total number of significant digits instead.

Can you give a pointer, or link, to the documentation section you were looking at?

The description at:

http://docs.python.org/library/stdtypes.html#string-formatting-operations

looks fine to me.  Note 3, which relates to the '%e' and '%f'-style formatting, talks about number of places after the point.  Note 4, which relates to '%g' formatting, talks about the total number of significant digits.

----------
nosy: +mark.dickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13433>
_______________________________________

From report at bugs.python.org  Sat Nov 19 14:31:17 2011
From: report at bugs.python.org (Christian Iversen)
Date: Sat, 19 Nov 2011 13:31:17 +0000
Subject: [issue13433] String format documentation contains error regarding %g
In-Reply-To: <1321707692.58.0.601543510069.issue13433@psf.upfronthosting.co.za>
Message-ID: <1321709477.1.0.888531920721.issue13433@psf.upfronthosting.co.za>


Christian Iversen <ci at sikkerhed.org> added the comment:

That was exactly the page I was looking at, and after some discussion on #python, I can see how they differ.

Perhaps this could be clarified in the documentation? It's very easy to miss as it is now. Maybe a note describing that %g is different from the others in this regard?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13433>
_______________________________________

From report at bugs.python.org  Sat Nov 19 14:32:04 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 19 Nov 2011 13:32:04 +0000
Subject: [issue13397] Option for XMLRPC clients to automatically transform
	Fault exceptions into standard exceptions
In-Reply-To: <1321218030.66.0.0560016220773.issue13397@psf.upfronthosting.co.za>
Message-ID: <1321709524.57.0.97528318151.issue13397@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13397>
_______________________________________

From report at bugs.python.org  Sat Nov 19 14:35:37 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 19 Nov 2011 13:35:37 +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: <1321709737.33.0.822624572055.issue12258@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12258>
_______________________________________

From report at bugs.python.org  Sat Nov 19 14:38:38 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 19 Nov 2011 13:38:38 +0000
Subject: [issue11908] Weird `slice.stop or sys.maxint`
In-Reply-To: <1303493846.17.0.214651551769.issue11908@psf.upfronthosting.co.za>
Message-ID: <1321709918.78.0.164781467951.issue11908@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
keywords: +easy
nosy: +ezio.melotti
stage:  -> needs patch
versions:  -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11908>
_______________________________________

From report at bugs.python.org  Sat Nov 19 14:54:03 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 19 Nov 2011 13:54:03 +0000
Subject: [issue1047540] Turtle.py hangs Idle
Message-ID: <1321710843.57.0.460507495487.issue1047540@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Can you still reproduce this?
I tried on winxp with Python 3.2 and following the steps in msg82419 (or even if I open IDLE from cmd as msg82553 suggests) I get a popup error that says "IDLE's subprocess didn't make connection".  If I open IDLE, do File->Open->turtle.py I can run the demo and do Ctrl+Q with no tracebacks.

----------
nosy: +ezio.melotti, kbk, ned.deily, terry.reedy
versions: +Python 3.3 -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1047540>
_______________________________________

From report at bugs.python.org  Sat Nov 19 14:56:41 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 19 Nov 2011 13:56:41 +0000
Subject: [issue10318] "make altinstall" installs many files with incorrect
	shebangs
In-Reply-To: <1288926610.35.0.932494150274.issue10318@psf.upfronthosting.co.za>
Message-ID: <1321711001.43.0.759141700543.issue10318@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

?ric, what's the status of this?

----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10318>
_______________________________________

From report at bugs.python.org  Sat Nov 19 14:58:18 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 19 Nov 2011 13:58:18 +0000
Subject: [issue9750] sqlite3 iterdump fails on column with reserved name
In-Reply-To: <1283494526.84.0.467033818097.issue9750@psf.upfronthosting.co.za>
Message-ID: <1321711098.23.0.318679607606.issue9750@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9750>
_______________________________________

From report at bugs.python.org  Sat Nov 19 15:00:44 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 19 Nov 2011 14:00:44 +0000
Subject: [issue1047397] cgitb failures
Message-ID: <1321711244.5.0.0718685697381.issue1047397@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy:  -BreamoreBoy
versions: +Python 3.3 -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1047397>
_______________________________________

From report at bugs.python.org  Sat Nov 19 15:03:05 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 19 Nov 2011 14:03:05 +0000
Subject: [issue7267] format method: c presentation type broken
In-Reply-To: <1257438168.68.0.774312526176.issue7267@psf.upfronthosting.co.za>
Message-ID: <1321711385.46.0.105157743129.issue7267@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
versions:  -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7267>
_______________________________________

From report at bugs.python.org  Sat Nov 19 15:05:23 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 19 Nov 2011 14:05:23 +0000
Subject: [issue13433] String format documentation contains error regarding %g
In-Reply-To: <1321707692.58.0.601543510069.issue13433@psf.upfronthosting.co.za>
Message-ID: <1321711523.56.0.58943237409.issue13433@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> Maybe a note describing that %g is different from the others in this regard?

-1 from me;  I don't really see that that would improve the documentation.  Maybe that's just me, but I expect reference documentation to be clean, and uncluttered with too many warnings.  All the necessary information is already there, and adding extra notes like this just increases the total number of words to be read without adding new information.

In a tutorial, that would be different ... :-)

Leaving this open---others may have different takes on this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13433>
_______________________________________

From report at bugs.python.org  Sat Nov 19 15:05:36 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 19 Nov 2011 14:05:36 +0000
Subject: [issue5066] IDLE documentation for Unix obsolete/incorrect
In-Reply-To: <1232942217.99.0.191249551049.issue5066@psf.upfronthosting.co.za>
Message-ID: <1321711536.06.0.150187844389.issue5066@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti
stage: needs patch -> patch review
versions: +Python 3.3 -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5066>
_______________________________________

From report at bugs.python.org  Sat Nov 19 15:06:56 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 19 Nov 2011 14:06:56 +0000
Subject: [issue7695] missing termios constants
In-Reply-To: <1263412950.84.0.252347161386.issue7695@psf.upfronthosting.co.za>
Message-ID: <1321711616.0.0.627267229523.issue7695@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
stage: needs patch -> patch review
versions: +Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7695>
_______________________________________

From report at bugs.python.org  Sat Nov 19 15:08:36 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 19 Nov 2011 14:08:36 +0000
Subject: [issue11842] slice.indices with negative step and default stop
In-Reply-To: <1302727853.06.0.703796407001.issue11842@psf.upfronthosting.co.za>
Message-ID: <1321711716.79.0.303228655278.issue11842@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
keywords: +easy
stage:  -> needs patch
versions: +Python 2.7, Python 3.3 -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11842>
_______________________________________

From report at bugs.python.org  Sat Nov 19 15:09:03 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 19 Nov 2011 14:09:03 +0000
Subject: =?utf-8?q?=5Bissue13424=5D_Add_examples_for_open=E2=80=99s_new_opener_arg?=
	=?utf-8?q?ument?=
In-Reply-To: <1321609933.89.0.531165464334.issue13424@psf.upfronthosting.co.za>
Message-ID: <1321711743.11.0.0465279744563.issue13424@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
keywords: +easy
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13424>
_______________________________________

From report at bugs.python.org  Sat Nov 19 15:10:01 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 19 Nov 2011 14:10:01 +0000
Subject: [issue7695] missing termios constants
In-Reply-To: <1263412950.84.0.252347161386.issue7695@psf.upfronthosting.co.za>
Message-ID: <1321711801.5.0.399594943326.issue7695@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +haypo
versions:  -Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7695>
_______________________________________

From report at bugs.python.org  Sat Nov 19 15:10:26 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 19 Nov 2011 14:10:26 +0000
Subject: [issue12907] Update test coverage devguide page
In-Reply-To: <1315284413.51.0.757189280849.issue12907@psf.upfronthosting.co.za>
Message-ID: <1321711826.25.0.107047131954.issue12907@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +eli.bendersky, eric.araujo, terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12907>
_______________________________________

From report at bugs.python.org  Sat Nov 19 15:11:06 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 19 Nov 2011 14:11:06 +0000
Subject: [issue12908] Update dev-in-a-box for new coverage steps
In-Reply-To: <1315284663.33.0.542797190768.issue12908@psf.upfronthosting.co.za>
Message-ID: <1321711866.68.0.850547776206.issue12908@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +eli.bendersky, eric.araujo, ezio.melotti, terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12908>
_______________________________________

From report at bugs.python.org  Sat Nov 19 15:11:16 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 19 Nov 2011 14:11:16 +0000
Subject: [issue12907] Update test coverage devguide page
In-Reply-To: <1315284413.51.0.757189280849.issue12907@psf.upfronthosting.co.za>
Message-ID: <1321711876.47.0.534091032547.issue12907@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/issue12907>
_______________________________________

From report at bugs.python.org  Sat Nov 19 15:12:04 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 19 Nov 2011 14:12:04 +0000
Subject: [issue6733] curses line wrap broken when mixing full- and half-width
	unicode characters
In-Reply-To: <1250642602.2.0.807698027943.issue6733@psf.upfronthosting.co.za>
Message-ID: <1321711924.78.0.755905580277.issue6733@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
versions: +Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6733>
_______________________________________

From report at bugs.python.org  Sat Nov 19 15:12:50 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 19 Nov 2011 14:12:50 +0000
Subject: [issue2527] Pass a namespace to timeit
In-Reply-To: <1207052027.28.0.27225375953.issue2527@psf.upfronthosting.co.za>
Message-ID: <1321711970.31.0.216120544275.issue2527@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
versions: +Python 3.3 -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2527>
_______________________________________

From report at bugs.python.org  Sat Nov 19 15:27:09 2011
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sat, 19 Nov 2011 14:27:09 +0000
Subject: [issue13431] Pass context information into the extension module init
	function
In-Reply-To: <1321694208.82.0.599594610804.issue13431@psf.upfronthosting.co.za>
Message-ID: <1321712829.15.0.348992563475.issue13431@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/issue13431>
_______________________________________

From report at bugs.python.org  Sat Nov 19 15:58:11 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sat, 19 Nov 2011 14:58:11 +0000
Subject: [issue13215] multiprocessing Manager.connect() aggressively retries
	refused connections
In-Reply-To: <1318965417.81.0.122561387998.issue13215@psf.upfronthosting.co.za>
Message-ID: <1321714691.88.0.868044520413.issue13215@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

Benjamin, thanks for the report.

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13215>
_______________________________________

From report at bugs.python.org  Sat Nov 19 16:44:46 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 19 Nov 2011 15:44:46 +0000
Subject: [issue13434] time.xmlrpc.com dead
Message-ID: <1321717486.33.0.411354256352.issue13434@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

time.xmlrpc.com seems dead (no DNS entry), which leads to failures on one of the stable buildbots (redirecting DNS catchall?):

======================================================================
ERROR: test_current_time (test.test_xmlrpc_net.CurrentTimeTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/buildbot/buildarea/3.x.ochtman-gentoo-amd64/build/Lib/test/test_xmlrpc_net.py", line 19, in test_current_time
    t0 = server.currentTime.getCurrentTime()
  File "/home/buildbot/buildarea/3.x.ochtman-gentoo-amd64/build/Lib/xmlrpc/client.py", line 1089, in __call__
    return self.__send(self.__name, args)
  File "/home/buildbot/buildarea/3.x.ochtman-gentoo-amd64/build/Lib/xmlrpc/client.py", line 1420, in __request
    verbose=self.__verbose
  File "/home/buildbot/buildarea/3.x.ochtman-gentoo-amd64/build/Lib/xmlrpc/client.py", line 1131, in request
    return self.single_request(host, handler, request_body, verbose)
  File "/home/buildbot/buildarea/3.x.ochtman-gentoo-amd64/build/Lib/xmlrpc/client.py", line 1163, in single_request
    dict(resp.getheaders())
xmlrpc.client.ProtocolError: <ProtocolError for time.xmlrpc.com/RPC2: 303 See Other>

----------
components: Tests
messages: 147948
nosy: flox, loewis, pitrou
priority: high
severity: normal
stage: needs patch
status: open
title: time.xmlrpc.com dead
type: behavior
versions: Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13434>
_______________________________________

From report at bugs.python.org  Sat Nov 19 17:27:51 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 19 Nov 2011 16:27:51 +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: <E1RRnlR-0005nv-Io@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset de1ecda2afa2 by Mark Dickinson in branch '2.7':
Issue #12245: Document sys.float_info.rounds better.
http://hg.python.org/cpython/rev/de1ecda2afa2

New changeset 795c184b0282 by Mark Dickinson in branch '3.2':
Issue #12245: Document sys.float_info.rounds better.
http://hg.python.org/cpython/rev/795c184b0282

New changeset 5e45dfc421e4 by Mark Dickinson in branch 'default':
Issue #12245 merge.
http://hg.python.org/cpython/rev/5e45dfc421e4

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12245>
_______________________________________

From report at bugs.python.org  Sat Nov 19 17:28:16 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 19 Nov 2011 16:28:16 +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: <1321720096.58.0.884891784287.issue12245@psf.upfronthosting.co.za>


Changes by Mark Dickinson <dickinsm at gmail.com>:


----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12245>
_______________________________________

From report at bugs.python.org  Sat Nov 19 17:30:27 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 19 Nov 2011 16:30:27 +0000
Subject: [issue7433] MemoryView memory_getbuf causes segfaults,
	double call to tp_releasebuffer
In-Reply-To: <1259880029.03.0.2026580728.issue7433@psf.upfronthosting.co.za>
Message-ID: <1321720227.92.0.742036667065.issue7433@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/issue7433>
_______________________________________

From report at bugs.python.org  Sat Nov 19 17:32:07 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sat, 19 Nov 2011 16:32:07 +0000
Subject: [issue13434] time.xmlrpc.com dead
In-Reply-To: <1321717486.33.0.411354256352.issue13434@psf.upfronthosting.co.za>
Message-ID: <1321720327.78.0.363928469336.issue13434@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Not sure whether this is actually new, but it may be that Dave Winer is migrating all this stuff to Amazon S3, and that he just didn't get to restoring the time service yet.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13434>
_______________________________________

From report at bugs.python.org  Sat Nov 19 17:33:34 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 19 Nov 2011 16:33:34 +0000
Subject: [issue7049] decimal.py: Three argument power issues
In-Reply-To: <1254578364.09.0.56728742883.issue7049@psf.upfronthosting.co.za>
Message-ID: <1321720414.84.0.12401380785.issue7049@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Closing as won't fix.  Even deprecation doesn't seem worth the effort here.

----------
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7049>
_______________________________________

From report at bugs.python.org  Sat Nov 19 17:35:46 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 19 Nov 2011 16:35:46 +0000
Subject: [issue2813] No float formatting in PyString_FromFormat
In-Reply-To: <1210453747.33.0.971608840544.issue2813@psf.upfronthosting.co.za>
Message-ID: <1321720546.05.0.877584257725.issue2813@psf.upfronthosting.co.za>


Changes by Mark Dickinson <dickinsm at gmail.com>:


----------
versions: +Python 3.3 -Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2813>
_______________________________________

From report at bugs.python.org  Sat Nov 19 17:37:45 2011
From: report at bugs.python.org (R. David Murray)
Date: Sat, 19 Nov 2011 16:37:45 +0000
Subject: [issue13434] time.xmlrpc.com dead
In-Reply-To: <1321717486.33.0.411354256352.issue13434@psf.upfronthosting.co.za>
Message-ID: <1321720665.95.0.123080440957.issue13434@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

We've had problems with this service going away for a while before.  I think the test was marked skip for at least a year before someone (it might have been me) noticed that it was back and reactivated it.  There's a ticket in here somewhere for it.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13434>
_______________________________________

From report at bugs.python.org  Sat Nov 19 17:46:26 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 19 Nov 2011 16:46:26 +0000
Subject: [issue12156] test_multiprocessing.test_notify_all() timeout (1 hour)
	on FreeBSD 7.2
In-Reply-To: <1306147254.92.0.286085135906.issue12156@psf.upfronthosting.co.za>
Message-ID: <1321721186.73.0.828428478109.issue12156@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Testing os.sysconf("SC_SEM_NSEMS_MAX") value is maybe better than creating 30 semaphores. See the function added by the changeset 746143ec1f60 (fixing #10798) is maybe faster than creating 30 semaphores.

Value on the FreeBSD 7.2 buildbot:

>>> import os
>>> os.sysconf("SC_SEM_NSEMS_MAX")
30

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12156>
_______________________________________

From report at bugs.python.org  Sat Nov 19 17:58:36 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 19 Nov 2011 16:58:36 +0000
Subject: [issue9530] integer undefined behaviors
In-Reply-To: <1281075386.13.0.164742828093.issue9530@psf.upfronthosting.co.za>
Message-ID: <1321721916.37.0.942971429563.issue9530@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Status update:  all the reported errors from the Objects/ directory have been fixed in the default branch (many of these were fixed recently as part of making sure that the test-suite runs under Clang's -ftrapv option), or are out of date.  I haven't checked the reports for the extension Modules.

----------
versions: +Python 3.3 -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9530>
_______________________________________

From report at bugs.python.org  Sat Nov 19 18:00:09 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 19 Nov 2011 17:00:09 +0000
Subject: [issue9530] integer undefined behaviors
In-Reply-To: <1281075386.13.0.164742828093.issue9530@psf.upfronthosting.co.za>
Message-ID: <1321722009.91.0.479806222058.issue9530@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

See also issue #1621.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9530>
_______________________________________

From report at bugs.python.org  Sat Nov 19 18:07:40 2011
From: report at bugs.python.org (Jeff McNeil)
Date: Sat, 19 Nov 2011 17:07:40 +0000
Subject: [issue12890] cgitb displays <p> tags when executed in text mode
In-Reply-To: <1315016521.13.0.175763253408.issue12890@psf.upfronthosting.co.za>
Message-ID: <1321722460.63.0.844634413569.issue12890@psf.upfronthosting.co.za>


Jeff McNeil <jeff at jmcneil.net> added the comment:

Is there anything else needed here?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12890>
_______________________________________

From report at bugs.python.org  Sat Nov 19 18:08:34 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 19 Nov 2011 17:08:34 +0000
Subject: [issue9530] integer undefined behaviors
In-Reply-To: <1281075386.13.0.164742828093.issue9530@psf.upfronthosting.co.za>
Message-ID: <1321722514.59.0.672880756513.issue9530@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

The issues reported for the datetime, array, itertools and math modules are also already fixed.  That just leaves the following two of the reported issues outstanding:

</home/regehr/z/python/Modules/_ctypes/cfield.c, (590:5)> : Op: <<=, Reason : Signed Left Shift Error: Right operand is negative or is greater than or equal to the width of the promoted left operand, BINARY OPERATION: left (int32): 0 right (int32): -2 

and

</home/regehr/z/python/Modules/testcapi_long.h, (37:47)> : Op: -, Reason : Signed Subtraction Overflow, UNARY OPERATION: left (int32): 0 right (int32): -2147483648

I'm using r63764 as the revision that the line numbers relate to; not sure whether this exactly right, but it seems to be close enough.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9530>
_______________________________________

From report at bugs.python.org  Sat Nov 19 18:10:39 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 19 Nov 2011 17:10:39 +0000
Subject: [issue1621] Do not assume signed integer overflow behavior
In-Reply-To: <1197593027.35.0.00314874350765.issue1621@psf.upfronthosting.co.za>
Message-ID: <1321722639.77.0.424012068631.issue1621@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

See also issue #9530.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1621>
_______________________________________

From report at bugs.python.org  Sat Nov 19 18:14:59 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sat, 19 Nov 2011 17:14:59 +0000
Subject: [issue12156] test_multiprocessing.test_notify_all() timeout (1 hour)
	on FreeBSD 7.2
In-Reply-To: <1306147254.92.0.286085135906.issue12156@psf.upfronthosting.co.za>
Message-ID: <1321722899.91.0.706768491287.issue12156@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

> Testing os.sysconf("SC_SEM_NSEMS_MAX") value is maybe better than
> creating 30 semaphores.

Yeah, I thought about that, but the problem is that it doesn't take into account the number of semaphores already allocated: so, for example, if sysconf() returns 50 but you already have 30 allocated semaphores, the test will fail with ENOFILE.
But if we consider that most buildbots don't have many semaphores allocated (and in particular no dangling semaphores), and that FreeBSD 8 has a limit substentially higher than 30 (ideally above 256), then I guess we could use this.
Patch attached.

----------
Added file: http://bugs.python.org/file23730/test_multi_sem-1.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12156>
_______________________________________

From report at bugs.python.org  Sat Nov 19 18:27:51 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 19 Nov 2011 17:27:51 +0000
Subject: [issue12890] cgitb displays <p> tags when executed in text mode
In-Reply-To: <1315016521.13.0.175763253408.issue12890@psf.upfronthosting.co.za>
Message-ID: <1321723671.79.0.0628779099566.issue12890@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

A test?

----------
stage:  -> test needed
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12890>
_______________________________________

From report at bugs.python.org  Sat Nov 19 18:28:27 2011
From: report at bugs.python.org (John Regehr)
Date: Sat, 19 Nov 2011 17:28:27 +0000
Subject: [issue9530] integer undefined behaviors
In-Reply-To: <1281075386.13.0.164742828093.issue9530@psf.upfronthosting.co.za>
Message-ID: <1321723707.47.0.545561076837.issue9530@psf.upfronthosting.co.za>


John Regehr <regehr at cs.utah.edu> added the comment:

This is great.  I'd be happy to re-run the tests sometime, and also we're talking with the LLVM folks about getting our patches into the main LLMM tree.  Basically it'll act as a more powerful -ftrapv, and the error message will be much better than "aborted".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9530>
_______________________________________

From report at bugs.python.org  Sat Nov 19 18:42:23 2011
From: report at bugs.python.org (Robert Lehmann)
Date: Sat, 19 Nov 2011 17:42:23 +0000
Subject: [issue13435] Copybutton does not hide tracebacks
Message-ID: <1321724543.66.0.854276029391.issue13435@psf.upfronthosting.co.za>


New submission from Robert Lehmann <lehmannro at gmail.com>:

The recently added copybutton.js (r18bbfed9aafa) does not work with the 2.7 docs since they are deployed with JQuery 1.2 (which is shipped with Sphinx 0.6).

Copybutton is an unobtrusive Javascript feature which adds a little button to all doctests that removes the interactive prompts in order to copy the code as-is into Python scripts.  I think that feature could well be ported to Sphinx itself.

In line 44 and 51 of Doc/tools/sphinxext/static/copybutton.js the code uses jQuery.nextUntil(), which is new in JQuery 1.4.  That results in tracebacks being only partially hidden.  Reproduce the error at http://docs.python.org/tutorial/errors.html#exceptions for example.

The Python 3.2+ documentation is not affected as it is built with Sphinx 1.0, which ships with JQuery 1.4.  JQuery Untils are available as a separate plugin (http://benalman.com/projects/jquery-untils-plugin/).

----------
assignee: docs at python
components: Documentation
messages: 147962
nosy: docs at python, ezio.melotti, lehmannro
priority: normal
severity: normal
status: open
title: Copybutton does not hide tracebacks
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13435>
_______________________________________

From report at bugs.python.org  Sat Nov 19 18:57:09 2011
From: report at bugs.python.org (Jeff McNeil)
Date: Sat, 19 Nov 2011 17:57:09 +0000
Subject: [issue12890] cgitb displays <p> tags when executed in text mode
In-Reply-To: <1315016521.13.0.175763253408.issue12890@psf.upfronthosting.co.za>
Message-ID: <1321725429.57.0.506275990081.issue12890@psf.upfronthosting.co.za>


Jeff McNeil <jeff at jmcneil.net> added the comment:

I didn't add one initially as I was just changing output format and not actual behavior.  I guess I could add something to ensure it doesn't regress? I'll make sure there's coverage to begin with.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12890>
_______________________________________

From report at bugs.python.org  Sat Nov 19 18:58:59 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 19 Nov 2011 17:58:59 +0000
Subject: [issue9530] integer undefined behaviors
In-Reply-To: <1281075386.13.0.164742828093.issue9530@psf.upfronthosting.co.za>
Message-ID: <E1RRpBe-0003nj-FF@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 71100ef4f7a2 by Mark Dickinson in branch 'default':
Issue #9530: Fix undefined behaviour due to signed overflow in testcapi_long.h.
http://hg.python.org/cpython/rev/71100ef4f7a2

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9530>
_______________________________________

From report at bugs.python.org  Sat Nov 19 19:20:41 2011
From: report at bugs.python.org (Jeff McNeil)
Date: Sat, 19 Nov 2011 18:20:41 +0000
Subject: [issue12890] cgitb displays <p> tags when executed in text mode
In-Reply-To: <1315016521.13.0.175763253408.issue12890@psf.upfronthosting.co.za>
Message-ID: <1321726841.83.0.340809905255.issue12890@psf.upfronthosting.co.za>


Jeff McNeil <jeff at jmcneil.net> added the comment:

Test to ensure html isn't included when the formatting is text.  I don't seem to be able to update the stage.

----------
Added file: http://bugs.python.org/file23731/head-cgitb-display-tests.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12890>
_______________________________________

From report at bugs.python.org  Sat Nov 19 19:21:32 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 19 Nov 2011 18:21:32 +0000
Subject: [issue12890] cgitb displays <p> tags when executed in text mode
In-Reply-To: <1315016521.13.0.175763253408.issue12890@psf.upfronthosting.co.za>
Message-ID: <1321726892.74.0.0770818527699.issue12890@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
stage: test needed -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12890>
_______________________________________

From report at bugs.python.org  Sat Nov 19 19:24:51 2011
From: report at bugs.python.org (Eric V. Smith)
Date: Sat, 19 Nov 2011 18:24:51 +0000
Subject: [issue13433] String format documentation contains error regarding %g
In-Reply-To: <1321707692.58.0.601543510069.issue13433@psf.upfronthosting.co.za>
Message-ID: <1321727091.04.0.747783767739.issue13433@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/issue13433>
_______________________________________

From report at bugs.python.org  Sat Nov 19 19:35:09 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 19 Nov 2011 18:35:09 +0000
Subject: [issue13433] String format documentation contains error regarding %g
In-Reply-To: <1321707692.58.0.601543510069.issue13433@psf.upfronthosting.co.za>
Message-ID: <1321727709.2.0.696103184531.issue13433@psf.upfronthosting.co.za>


Changes by Mark Dickinson <dickinsm at gmail.com>:


----------
versions: +Python 3.2, Python 3.3 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13433>
_______________________________________

From report at bugs.python.org  Sat Nov 19 19:48:41 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 19 Nov 2011 18:48:41 +0000
Subject: [issue13435] Copybutton does not hide tracebacks
In-Reply-To: <1321724543.66.0.854276029391.issue13435@psf.upfronthosting.co.za>
Message-ID: <1321728521.57.0.449265508828.issue13435@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
assignee: docs at python -> ezio.melotti
nosy: +georg.brandl
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13435>
_______________________________________

From report at bugs.python.org  Sat Nov 19 20:07:46 2011
From: report at bugs.python.org (Nebelhom)
Date: Sat, 19 Nov 2011 19:07:46 +0000
Subject: [issue12779] Update packaging documentation
In-Reply-To: <1313686169.0.0.406072932055.issue12779@psf.upfronthosting.co.za>
Message-ID: <1321729666.86.0.636544951563.issue12779@psf.upfronthosting.co.za>


Changes by Nebelhom <nebelhom at googlemail.com>:


----------
nosy: +Nebelhom

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12779>
_______________________________________

From report at bugs.python.org  Sat Nov 19 20:30:37 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Sat, 19 Nov 2011 19:30:37 +0000
Subject: [issue7330] PyUnicode_FromFormat: implement width and precision for
	%s, %S, %R, %V, %U, %A
In-Reply-To: <1258314153.95.0.978747695294.issue7330@psf.upfronthosting.co.za>
Message-ID: <1321731037.11.0.804993812878.issue7330@psf.upfronthosting.co.za>


Petri Lehtinen <petri at digip.org> added the comment:

Hi!

I'd like to have this committed to be able to fix #13349. So here's a review.

- In Doc/c-api/unicode.rst, the two "versionchanged:: 3.3" directives can be merged

- In tests, I'd use 'abcde' rather than 'xxxxx' to make sure that correct characters are copied to the output (hope you understand what I mean)

- No test checks that width and precision work on characters rather than bytes

- The changes to unicodeobject.c don't apply on top of current default branch.

----------
keywords: +needs review
stage:  -> patch review
versions: +Python 3.3 -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7330>
_______________________________________

From report at bugs.python.org  Sat Nov 19 21:02:52 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Sat, 19 Nov 2011 20:02:52 +0000
Subject: [issue13089] parsetok.c: memory leak
In-Reply-To: <1317545416.55.0.717898890924.issue13089@psf.upfronthosting.co.za>
Message-ID: <1321732972.5.0.651136242337.issue13089@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/issue13089>
_______________________________________

From report at bugs.python.org  Sat Nov 19 21:11:10 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 19 Nov 2011 20:11:10 +0000
Subject: [issue13338] Not all enumerations used in _Py_ANNOTATE_MEMORY_ORDER
In-Reply-To: <1320366284.3.0.0625863072508.issue13338@psf.upfronthosting.co.za>
Message-ID: <E1RRrFY-0004Qt-Pj@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset f855f929bc48 by Petri Lehtinen in branch '3.2':
Issue #13338: Handle all enumerations in _Py_ANNOTATE_MEMORY_ORDER
http://hg.python.org/cpython/rev/f855f929bc48

New changeset c2e588a5237a by Petri Lehtinen in branch 'default':
Merge branch 3.2 (closes #13338)
http://hg.python.org/cpython/rev/c2e588a5237a

----------
nosy: +python-dev
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13338>
_______________________________________

From report at bugs.python.org  Sat Nov 19 21:12:56 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Sat, 19 Nov 2011 20:12:56 +0000
Subject: [issue13338] Not all enumerations used in _Py_ANNOTATE_MEMORY_ORDER
In-Reply-To: <1320366284.3.0.0625863072508.issue13338@psf.upfronthosting.co.za>
Message-ID: <1321733576.39.0.842458709096.issue13338@psf.upfronthosting.co.za>


Petri Lehtinen <petri at digip.org> added the comment:

Your patch was applied with the default: case removed. Thanks!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13338>
_______________________________________

From report at bugs.python.org  Sat Nov 19 21:28:46 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sat, 19 Nov 2011 20:28:46 +0000
Subject: [issue13432] Encoding alias "unicode"
In-Reply-To: <1321702512.61.0.807104309131.issue13432@psf.upfronthosting.co.za>
Message-ID: <1321734526.76.0.0242197147212.issue13432@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Joining the chorus: people who need it in their application will have to add it themselves (monkeypatching the aliases dictionary as appropriate).

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13432>
_______________________________________

From report at bugs.python.org  Sat Nov 19 21:31:13 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sat, 19 Nov 2011 20:31:13 +0000
Subject: [issue13431] Pass context information into the extension module init
	function
In-Reply-To: <1321694208.82.0.599594610804.issue13431@psf.upfronthosting.co.za>
Message-ID: <1321734673.7.0.783527305405.issue13431@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

I really do propose to close this issue as "won't fix". By the time Python 4 comes along, things will have changed a lot; it's not clear that the value of keeping it open will outweigh the cost of keeping it open.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13431>
_______________________________________

From report at bugs.python.org  Sat Nov 19 21:57:25 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 19 Nov 2011 20:57:25 +0000
Subject: [issue13432] Encoding alias "unicode"
In-Reply-To: <1321702512.61.0.807104309131.issue13432@psf.upfronthosting.co.za>
Message-ID: <1321736245.64.0.676834556048.issue13432@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
stage:  -> committed/rejected
versions:  -Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13432>
_______________________________________

From report at bugs.python.org  Sat Nov 19 22:10:38 2011
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 19 Nov 2011 21:10:38 +0000
Subject: [issue7433] MemoryView memory_getbuf causes segfaults,
	double call to tp_releasebuffer
In-Reply-To: <1259880029.03.0.2026580728.issue7433@psf.upfronthosting.co.za>
Message-ID: <1321737038.22.0.386463434113.issue7433@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

My last comment could be misinterpreted: This *is* actually
already fixed in features/pep-3118.

----------
versions: +Python 3.3 -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7433>
_______________________________________

From report at bugs.python.org  Sat Nov 19 23:07:17 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Sat, 19 Nov 2011 22:07:17 +0000
Subject: [issue6715] xz compressor support
In-Reply-To: <1250502444.31.0.107447392137.issue6715@psf.upfronthosting.co.za>
Message-ID: <1321740437.84.0.480498570082.issue6715@psf.upfronthosting.co.za>


Changes by Nadeem Vawda <nadeem.vawda at gmail.com>:


Added file: http://bugs.python.org/file23732/9276fc685c05.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6715>
_______________________________________

From report at bugs.python.org  Sat Nov 19 23:12:48 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Sat, 19 Nov 2011 22:12:48 +0000
Subject: [issue6715] xz compressor support
In-Reply-To: <1250502444.31.0.107447392137.issue6715@psf.upfronthosting.co.za>
Message-ID: <1321740768.74.0.175963425009.issue6715@psf.upfronthosting.co.za>


Changes by Nadeem Vawda <nadeem.vawda at gmail.com>:


Removed file: http://bugs.python.org/file23466/371a133b770a.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6715>
_______________________________________

From report at bugs.python.org  Sun Nov 20 01:04:39 2011
From: report at bugs.python.org (=?utf-8?q?Janosch_Gr=C3=A4f?=)
Date: Sun, 20 Nov 2011 00:04:39 +0000
Subject: [issue13436] compile() doesn't work on ImportFrom with level=None
Message-ID: <1321747479.31.0.688458511993.issue13436@psf.upfronthosting.co.za>


New submission from Janosch Gr?f <janosch.graef at gmx.net>:

The documentation for ast says that arguments that are marked with a '?' in the abstract grammar are optional and can therefore be None.
When I try to compile a Module node which contains an ImportFrom node with attribute level=None compile() throws an exception:

Module(body=[ImportFrom(module='time', names=[alias(name='sleep', asname=None), alias(name='time', asname=None)], level=None, lineno=0, col_offset=0)])

Traceback (most recent call last):
  File "g0.py", line 423, in <module>
    p.main()
  File "g0.py", line 65, in main
    self.reproduce("g1.pyc")
  File "g0.py", line 85, in reproduce
    co = self.generate_bytecode(st, genome)
  File "g0.py", line 243, in generate_bytecode
    co = compile(st, id, "exec")
ValueError: invalid integer value: ????????

So, I tried to set level=0:
Module(body=[ImportFrom(module='time', names=[alias(name='sleep', asname=None), alias(name='time', asname=None)], level=0, lineno=0, col_offset=0)])

and everything worked fine.

BTW: The unprintable bytes in the error message are:
ef bf bd ef bf bd ef bf bd ef bf bd ef bf bd ef bf bd ef bf bd ef bf bd

----------
assignee: docs at python
components: Documentation, Interpreter Core
messages: 147972
nosy: Janosch.Gr?f, docs at python
priority: normal
severity: normal
status: open
title: compile() doesn't work on ImportFrom with level=None
type: behavior
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13436>
_______________________________________

From report at bugs.python.org  Sun Nov 20 01:29:31 2011
From: report at bugs.python.org (Julian Berman)
Date: Sun, 20 Nov 2011 00:29:31 +0000
Subject: [issue13437] Provide links to the source code for every module in the
	documentation
Message-ID: <1321748971.83.0.182041155467.issue13437@psf.upfronthosting.co.za>


New submission from Julian Berman <Julian+Python.org at GrayVines.com>:

The documentation occasionally contains a link to the source code for a module in the stdlib. See for instance http://docs.python.org/library/urlparse.html and http://docs.python.org/library/collections.html , or many others.

With a quick perusal, I couldn't immediately guess as to which ones managed to have one and which ones don't, but it'd be convenient to have a link in as many places as possible, which is certainly more than we have now. (See e.g. http://docs.python.org/library/json.html and http://docs.python.org/library/itertools.html and many others for examples of pages that lack a link).

Perhaps putting it in a more conspicuous but still consistent location would be reasonable (the sidebar?).

----------
assignee: docs at python
components: Documentation
messages: 147973
nosy: Julian, docs at python
priority: normal
severity: normal
status: open
title: Provide links to the source code for every module in the documentation
type: feature request
versions: Python 2.7, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13437>
_______________________________________

From report at bugs.python.org  Sun Nov 20 01:57:27 2011
From: report at bugs.python.org (Michael Foord)
Date: Sun, 20 Nov 2011 00:57:27 +0000
Subject: [issue13241] llvm-gcc-4.2 miscompiles Python (XCode 4.1 on Mac OS
	10.7)
In-Reply-To: <1319226560.18.0.474501275115.issue13241@psf.upfronthosting.co.za>
Message-ID: <1321750647.07.0.163430898848.issue13241@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

Note that this works for me on a Macbook Air that has never had Snow Leopard, nor XCode 3 installed. 

As far as I can tell non-llvm gcc *is* installed by XCode 4.2: /usr/bin/gcc-4.2

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13241>
_______________________________________

From report at bugs.python.org  Sun Nov 20 04:43:34 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Sun, 20 Nov 2011 03:43:34 +0000
Subject: [issue9530] integer undefined behaviors
In-Reply-To: <1281075386.13.0.164742828093.issue9530@psf.upfronthosting.co.za>
Message-ID: <1321760614.52.0.546493886796.issue9530@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/issue9530>
_______________________________________

From report at bugs.python.org  Sun Nov 20 04:56:21 2011
From: report at bugs.python.org (Collin Winter)
Date: Sun, 20 Nov 2011 03:56:21 +0000
Subject: [issue13430] Add a curry function to the functools module
In-Reply-To: <1321632094.44.0.291753245781.issue13430@psf.upfronthosting.co.za>
Message-ID: <1321761381.12.0.638962852778.issue13430@psf.upfronthosting.co.za>


Collin Winter <collinw at gmail.com> added the comment:

I assume I was added to this thread since I wrote the functional module, so I'll give my take in that capacity. IMO Python doesn't need a more general version of partial(); indeed, I question the need for partial() as it is today. Querying Google Code Search for code using partial, I haven't found any usages in the wild where partial() makes code more readable than simply defining a new function. partial() is almost always a loss for readability.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13430>
_______________________________________

From report at bugs.python.org  Sun Nov 20 06:38:38 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Sun, 20 Nov 2011 05:38:38 +0000
Subject: [issue13431] Pass context information into the extension module init
	function
In-Reply-To: <1321694208.82.0.599594610804.issue13431@psf.upfronthosting.co.za>
Message-ID: <1321767518.34.0.205506641551.issue13431@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

What about providing a function that "init" would call to get this information, instead of a "hidden" parameter?.

----------
nosy: +jcea

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13431>
_______________________________________

From report at bugs.python.org  Sun Nov 20 06:45:08 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Sun, 20 Nov 2011 05:45:08 +0000
Subject: [issue13429] provide __file__ to extension init function
In-Reply-To: <1321631218.51.0.537222078649.issue13429@psf.upfronthosting.co.za>
Message-ID: <1321767908.32.0.565741735872.issue13429@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/issue13429>
_______________________________________

From report at bugs.python.org  Sun Nov 20 10:13:38 2011
From: report at bugs.python.org (Armin Rigo)
Date: Sun, 20 Nov 2011 09:13:38 +0000
Subject: [issue13410] String formatting bug in interactive mode
In-Reply-To: <1321394690.57.0.254973831289.issue13410@psf.upfronthosting.co.za>
Message-ID: <1321780418.35.0.778470277686.issue13410@psf.upfronthosting.co.za>


Armin Rigo <arigo at users.sourceforge.net> added the comment:

Fwiw, a class with methods __long__ and __float__ but no method __int__ behaves strangely in many other places; the canonical example is that calling "int(Foo(42))" will not work.  In light of this, does it make sense for "'%d' % Foo(42)" to work?  Shouldn't the fix instead be to cleanly raise the TypeError instead?

----------
nosy: +arigo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13410>
_______________________________________

From report at bugs.python.org  Sun Nov 20 10:24:09 2011
From: report at bugs.python.org (Armin Rigo)
Date: Sun, 20 Nov 2011 09:24:09 +0000
Subject: [issue13412] Symbolic links omitted by os.listdir on some systems
In-Reply-To: <1321396602.6.0.583941827853.issue13412@psf.upfronthosting.co.za>
Message-ID: <1321781049.3.0.264430058087.issue13412@psf.upfronthosting.co.za>


Armin Rigo <arigo at users.sourceforge.net> added the comment:

I think this can then be considered a duplicate of issue #6727.

----------
nosy: +arigo
resolution: wont fix -> duplicate
status:  -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13412>
_______________________________________

From report at bugs.python.org  Sun Nov 20 10:40:33 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 20 Nov 2011 09:40:33 +0000
Subject: [issue13431] Pass context information into the extension module
	init	function
In-Reply-To: <1321767518.34.0.205506641551.issue13431@psf.upfronthosting.co.za>
Message-ID: <4EC8CB03.9020103@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> What about providing a function that "init" would call to get this information, instead of a "hidden" parameter?.

How would the function that init calls itself get the information,
without a hidden parameter?

----------
title: Pass context information into the extension module init function -> Pass context information into the extension module init	function

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13431>
_______________________________________

From report at bugs.python.org  Sun Nov 20 11:02:05 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 20 Nov 2011 10:02:05 +0000
Subject: [issue13416] Python Tutorial, Section 3, Minor PEP 8 adjustment
In-Reply-To: <1321483693.18.0.17340985314.issue13416@psf.upfronthosting.co.za>
Message-ID: <1321783325.26.0.532618097896.issue13416@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Indeed, PEP 8 mandates that constants be written in all uppercase, so changing it would actually make it deviate from PEP 8. Also, using a lower-case variable name "string" would be a bad choice because it collides with a module name.

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13416>
_______________________________________

From report at bugs.python.org  Sun Nov 20 11:11:12 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 20 Nov 2011 10:11:12 +0000
Subject: [issue13418] Embedded Python memory leak
In-Reply-To: <1321491453.86.0.929770076277.issue13418@psf.upfronthosting.co.za>
Message-ID: <1321783872.53.0.472024532012.issue13418@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

If you *really* want to solve this problem, you could start working on making Python release all memory at interpreter shutdown. Please understand that this project may well take several years to complete, but it would help not only your project, but also many people in a similar situation.

Meanwhile, you should use a better memory checker, one where you can declare that it shall ignore certain allocations.

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13418>
_______________________________________

From report at bugs.python.org  Sun Nov 20 11:11:19 2011
From: report at bugs.python.org (Oleg Plakhotnyuk)
Date: Sun, 20 Nov 2011 10:11:19 +0000
Subject: [issue13394] Patch to increase aifc lib test coverage with couple of
	minor fixes
In-Reply-To: <1321169659.12.0.870815067565.issue13394@psf.upfronthosting.co.za>
Message-ID: <1321783879.76.0.911176874577.issue13394@psf.upfronthosting.co.za>


Changes by Oleg Plakhotnyuk <olegus8 at gmail.com>:


Removed file: http://bugs.python.org/file23678/test_aifc2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13394>
_______________________________________

From report at bugs.python.org  Sun Nov 20 11:35:40 2011
From: report at bugs.python.org (Oleg Plakhotnyuk)
Date: Sun, 20 Nov 2011 10:35:40 +0000
Subject: [issue13394] Patch to increase aifc lib test coverage with couple of
	minor fixes
In-Reply-To: <1321169659.12.0.870815067565.issue13394@psf.upfronthosting.co.za>
Message-ID: <1321785340.93.0.744613416011.issue13394@psf.upfronthosting.co.za>


Oleg Plakhotnyuk <olegus8 at gmail.com> added the comment:

1. Test coverage increased to 95%.
2. G722 compressed files reading in aifc.py fixed (it used to use 0 bytes frame size).
3. audioop's ulaw2lin, alaw2lin and adpcm2lin length checks fixed (width should be used for output only, because input sequence frame length is always 1 byte).
4. aifc.py _write_float infinity and NaN proper checking.
5. Other minor aifc.py clean ups.

----------
nosy: +haypo
Added file: http://bugs.python.org/file23733/test_aifc.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13394>
_______________________________________

From report at bugs.python.org  Sun Nov 20 11:37:29 2011
From: report at bugs.python.org (Oleg Plakhotnyuk)
Date: Sun, 20 Nov 2011 10:37:29 +0000
Subject: [issue13394] Patch to increase aifc lib test coverage with couple of
	minor fixes
In-Reply-To: <1321169659.12.0.870815067565.issue13394@psf.upfronthosting.co.za>
Message-ID: <1321785449.35.0.698809088047.issue13394@psf.upfronthosting.co.za>


Changes by Oleg Plakhotnyuk <olegus8 at gmail.com>:


Removed file: http://bugs.python.org/file23677/test_aifc.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13394>
_______________________________________

From report at bugs.python.org  Sun Nov 20 13:00:17 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 20 Nov 2011 12:00:17 +0000
Subject: [issue3430] httplib.HTTPResponse documentations inconsistent
In-Reply-To: <1216747880.73.0.0581734704537.issue3430@psf.upfronthosting.co.za>
Message-ID: <1321790417.56.0.714616865775.issue3430@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/issue3430>
_______________________________________

From report at bugs.python.org  Sun Nov 20 13:02:07 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 20 Nov 2011 12:02:07 +0000
Subject: [issue12707] Deprecate addinfourl getters
In-Reply-To: <1312760770.57.0.2285900636.issue12707@psf.upfronthosting.co.za>
Message-ID: <1321790527.76.0.0278988016133.issue12707@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> I thought about having another class, but I couldn't come up with a
> decent name for it (ResponseWithCloseHook?).

If it?s used together with the base Response class (I don?t have the details in memory anymore), you could try ClosingMixin or FileLikeMixin.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12707>
_______________________________________

From report at bugs.python.org  Sun Nov 20 13:08:31 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 20 Nov 2011 12:08:31 +0000
Subject: [issue13434] time.xmlrpc.com dead
In-Reply-To: <1321717486.33.0.411354256352.issue13434@psf.upfronthosting.co.za>
Message-ID: <1321790911.92.0.762953171907.issue13434@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

#6533: Make test_xmlrpc_net functional in the absence of time.xmlrpc.com
#6027: test_xmlrpc_net fails when the ISP returns "302 Found"

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13434>
_______________________________________

From report at bugs.python.org  Sun Nov 20 13:12:54 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 20 Nov 2011 12:12:54 +0000
Subject: [issue13433] String format documentation contains error regarding %g
In-Reply-To: <1321707692.58.0.601543510069.issue13433@psf.upfronthosting.co.za>
Message-ID: <1321791174.41.0.127587448869.issue13433@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I agree with Mark.  The Documenting Python docs were recently updated by Raymond Hettinger to recommend not abusing notes and warnings, and the doc maintainer Georg Brandl approved it: d5d91b14b238 (#12047).

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13433>
_______________________________________

From report at bugs.python.org  Sun Nov 20 13:20:32 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 20 Nov 2011 12:20:32 +0000
Subject: [issue12890] cgitb displays <p> tags when executed in text mode
In-Reply-To: <1315016521.13.0.175763253408.issue12890@psf.upfronthosting.co.za>
Message-ID: <1321791632.74.0.0562780233827.issue12890@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Thanks for the updated patch.  I made a review, you should have received an email.  When you make a new patch, it would be most helpful if you could make one patch with code and tests changes, and then we?ll remove the old versions.

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12890>
_______________________________________

From report at bugs.python.org  Sun Nov 20 13:21:55 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 20 Nov 2011 12:21:55 +0000
Subject: [issue13435] Copybutton does not hide tracebacks
In-Reply-To: <1321724543.66.0.854276029391.issue13435@psf.upfronthosting.co.za>
Message-ID: <1321791715.59.0.00482393588175.issue13435@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Another way to fix this would be to use Sphinx 1.0 for Python 2.7, but I don?t know what?s the status of that, given the amount of changes needed.

----------
nosy: +eric.araujo, sandro.tosi

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13435>
_______________________________________

From report at bugs.python.org  Sun Nov 20 13:26:20 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 20 Nov 2011 12:26:20 +0000
Subject: [issue13437] Provide links to the source code for every module in the
	documentation
In-Reply-To: <1321748971.83.0.182041155467.issue13437@psf.upfronthosting.co.za>
Message-ID: <1321791980.58.0.569869427096.issue13437@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Hi Julian, thanks for your interest in improving Python and welcome!  It is Raymond who initially added these links, and I helped porting them between versions.  The criterion can be read in the commit message: ?Provide links to Python source in a handful of cases where the source is a generally helpful adjunct to the docs? (from http://hg.python.org/cpython/rev/fdd3681b1439/).  Not all modules have source code that is easy or helpful to read; not all modules have Python source code (itertools doesn?t).  I think Raymond is not willing to add links for all modules, but if you have a list of specific names which would benefit from source links, I?m sure he will consider them.

----------
assignee: docs at python -> rhettinger
nosy: +eric.araujo, rhettinger
versions: +Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13437>
_______________________________________

From report at bugs.python.org  Sun Nov 20 15:20:19 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 20 Nov 2011 14:20:19 +0000
Subject: [issue10318] "make altinstall" installs many files with incorrect
	shebangs
In-Reply-To: <1288926610.35.0.932494150274.issue10318@psf.upfronthosting.co.za>
Message-ID: <1321798819.2.0.523111456654.issue10318@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

The patches I?ve discussed and committed were actually peripheral.  The original bug reported here is that shebangs shouldn?t use ?/usr/bin/env python? with an altinstall installation, as in that case you?re not creating a python (or python3) binary but a pythonx.y, so the shebangs should refer to that exact x.y versions.

The few scripts from Tools/scripts (idle, pydoc, 2to3, python-config) are installed with an x.y suffix and hard-code the Python version and location at build time, by using distutils.  (That?s why Nick reports the only matches for ?3.2? found by grep are in the build/scripts directory.)

The stdlib modules do use ?/usr/bin/env python[3]?.  I see various ways to handle that:
a) Reject the bug as works for me: these are stdlib modules, not scripts, they can be imported or executed with -m, they?re not symlinked (by us) from anywhere so the bug, while technically valid, has no real effect.

b) Further complicate the build/install machinery to update shebangs in altinstall mode.

c) Remove useless shebangs and execute bit in the stdlib.

My preference is to do c) for 3.3 and nothing for the stable versions.

(About wrongly using python in Python 3 docs: I?ll open another bug for that).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10318>
_______________________________________

From report at bugs.python.org  Sun Nov 20 15:21:12 2011
From: report at bugs.python.org (Oleg Plakhotnyuk)
Date: Sun, 20 Nov 2011 14:21:12 +0000
Subject: [issue13394] Patch to increase aifc lib test coverage with couple of
	minor fixes
In-Reply-To: <1321169659.12.0.870815067565.issue13394@psf.upfronthosting.co.za>
Message-ID: <1321798872.97.0.890020441018.issue13394@psf.upfronthosting.co.za>


Oleg Plakhotnyuk <olegus8 at gmail.com> added the comment:

Minor style fixes

----------
Added file: http://bugs.python.org/file23734/test_aifc.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13394>
_______________________________________

From report at bugs.python.org  Sun Nov 20 15:24:39 2011
From: report at bugs.python.org (Oleg Plakhotnyuk)
Date: Sun, 20 Nov 2011 14:24:39 +0000
Subject: [issue13394] Patch to increase aifc lib test coverage with couple of
	minor fixes
In-Reply-To: <1321169659.12.0.870815067565.issue13394@psf.upfronthosting.co.za>
Message-ID: <1321799079.87.0.0287328686614.issue13394@psf.upfronthosting.co.za>


Changes by Oleg Plakhotnyuk <olegus8 at gmail.com>:


Removed file: http://bugs.python.org/file23733/test_aifc.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13394>
_______________________________________

From report at bugs.python.org  Sun Nov 20 15:28:03 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 20 Nov 2011 14:28:03 +0000
Subject: [issue13387] suggest assertIs(type(obj), cls) for exact type checking
In-Reply-To: <1321101802.89.0.94542095022.issue13387@psf.upfronthosting.co.za>
Message-ID: <1321799283.89.0.184550843994.issue13387@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

No, I?m not talking about a rephrasing, but on a full change of meaning.  I don?t understand your use of ?superclasses? at all; isinstance(x, T) checks if x is an instance of T or any subclass, am I wrong?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13387>
_______________________________________

From report at bugs.python.org  Sun Nov 20 15:32:40 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 20 Nov 2011 14:32:40 +0000
Subject: [issue11045] shutil._make_tarball misses a guard against loggger=None
In-Reply-To: <1296222490.15.0.786706157889.issue11045@psf.upfronthosting.co.za>
Message-ID: <1321799560.65.0.189743082132.issue11045@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

This was fixed in 615a29295d5f.

----------
resolution: accepted -> fixed
stage: needs patch -> committed/rejected
status: open -> closed
title: shutil._make_tarball -> shutil._make_tarball misses a guard against loggger=None

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11045>
_______________________________________

From report at bugs.python.org  Sun Nov 20 15:38:54 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 20 Nov 2011 14:38:54 +0000
Subject: [issue6983] Add specific get_platform() for freebsd
In-Reply-To: <1253751823.43.0.939101436857.issue6983@psf.upfronthosting.co.za>
Message-ID: <1321799934.36.0.700052939026.issue6983@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> This is still a bothersome issue, but we've taken to patching every version of python
> downstream before deploying them. All for a simple three line patch.

Sorry about the unsatisfactory situation.  Could we start anew and define exactly what the problem is, so that distutils2 can be free of it?  (I?m afraid distutils can?t be changed: even undocumented, the platform string used for FreeBSD is certainly used by tools out there that we don?t want to break.  I second the suggestion to bring up the issue to the projects responsible for eggs, i.e. setuptools and distribute, not distutils.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6983>
_______________________________________

From report at bugs.python.org  Sun Nov 20 15:51:30 2011
From: report at bugs.python.org (Oleg Plakhotnyuk)
Date: Sun, 20 Nov 2011 14:51:30 +0000
Subject: [issue13438] "Delete patch set" review action doesn't work
Message-ID: <1321800690.51.0.854492831277.issue13438@psf.upfronthosting.co.za>


New submission from Oleg Plakhotnyuk <olegus8 at gmail.com>:

I got following error when trying to delete outdated patch set:


Environment:

Request Method: POST
Request URL: http://bugs.python.org/review/13394/patchset/3680/delete
Django Version: 1.1.1 SVN-17047
Python Version: 2.5.2
Installed Applications:
['django.contrib.auth',
 'django.contrib.contenttypes',
 'django.contrib.sessions',
 'django.contrib.sites',
 'django.contrib.admin',
 'gae2django',
 'rietveld_helper',
 'codereview']
Installed Middleware:
('django.middleware.common.CommonMiddleware',
 'django.contrib.sessions.middleware.SessionMiddleware',
 'django.contrib.auth.middleware.AuthenticationMiddleware',
 'roundup_helper.middleware.LookupRoundupUser',
 'gae2django.middleware.FixRequestUserMiddleware',
 'rietveld_helper.middleware.AddUserToRequestMiddleware',
 'django.middleware.doc.XViewMiddleware')


Traceback:
File "/home/roundup/trackers/tracker/rietveld/django/core/handlers/base.py" in get_response
  88.                 response = middleware_method(request, callback, callback_args, callback_kwargs)
File "/home/roundup/trackers/tracker/rietveld/rietveld_helper/middleware.py" in process_view
  21.         response = view_func(request, *view_args, **view_kwargs)
File "/home/roundup/trackers/tracker/rietveld/codereview/views.py" in post_wrapper
  557.     return func(request, *args, **kwds)
File "/home/roundup/trackers/tracker/rietveld/codereview/views.py" in login_wrapper
  569.     return func(request, *args, **kwds)
File "/home/roundup/trackers/tracker/rietveld/codereview/views.py" in issue_wrapper
  643.     return func(request, *args, **kwds)
File "/home/roundup/trackers/tracker/rietveld/codereview/views.py" in patchset_wrapper
  706.     return func(request, *args, **kwds)
File "/home/roundup/trackers/tracker/rietveld/codereview/views.py" in patchset_owner_wrapper
  718.     return func(request, *args, **kwds)
File "/home/roundup/trackers/tracker/rietveld/codereview/views.py" in xsrf_wrapper
  597.     return func(request, *args, **kwds)
File "/home/roundup/trackers/tracker/rietveld/codereview/views.py" in delete_patchset
  1669.   for patchset in patchsets_after:
File "/home/roundup/trackers/tracker/rietveld/django/db/models/query.py" in _result_iter
  106.                 self._fill_cache()
File "/home/roundup/trackers/tracker/rietveld/django/db/models/query.py" in _fill_cache
  692.                     self._result_cache.append(self._iter.next())
File "/home/roundup/trackers/tracker/rietveld/django/db/models/query.py" in iterator
  238.         for row in self.query.results_iter():
File "/home/roundup/trackers/tracker/rietveld/django/db/models/sql/query.py" in results_iter
  287.         for rows in self.execute_sql(MULTI):
File "/home/roundup/trackers/tracker/rietveld/django/db/models/sql/query.py" in execute_sql
  2369.         cursor.execute(sql, params)
File "/home/roundup/trackers/tracker/rietveld/django/db/backends/util.py" in execute
  19.             return self.cursor.execute(sql, params)

Exception Type: ProgrammingError at /review/13394/patchset/3680/delete
Exception Value: schema "datetime" does not exist


Last trace frame's local vars exploration revealed this:
'SELECT "codereview_patchset"."id", "codereview_patchset"."gae_key", "codereview_patchset"."gae_parent_ctype_id", "codereview_patchset"."gae_parent_id", "codereview_patchset"."gae_ancestry", "codereview_patchset"."issue_id", "codereview_patchset"."message", "codereview_patchset"."data", "codereview_patchset"."url", "codereview_patchset"."owner_id", "codereview_patchset"."created", "codereview_patchset"."modified", "codereview_patchset"."n_comments" FROM "codereview_patchset" WHERE "codereview_patchset"."issue_id" = 13394 AND created > datetime.datetime(2011, 11, 20, 11, 36, 4, 343046)'

I believe that it should look something like this:
'SELECT ... AND created > %s' % datetime.datetime(2011, 11, 20, 11, 36, 4, 343046)

I'm not sure where should I post this issue. I didn't find "rietveld/django/db/backends/util.py" in sources at rietveld.googlecode.com, therefore I posted it here.

----------
messages: 147994
nosy: Oleg.Plakhotnyuk
priority: normal
severity: normal
status: open
title: "Delete patch set" review action doesn't work
type: behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13438>
_______________________________________

From report at bugs.python.org  Sun Nov 20 16:15:24 2011
From: report at bugs.python.org (Christopher Smith)
Date: Sun, 20 Nov 2011 15:15:24 +0000
Subject: [issue13439] turtle docstring for onkeyrelease references onkey,
	not onkeyrelease
Message-ID: <1321802124.14.0.262913683551.issue13439@psf.upfronthosting.co.za>


New submission from Christopher Smith <smichr at users.sourceforge.net>:

The docstring example is written using onkey instead of onkeyrelease.

----------
components: Library (Lib)
messages: 147995
nosy: smichr
priority: normal
severity: normal
status: open
title: turtle docstring for onkeyrelease references onkey, not onkeyrelease
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13439>
_______________________________________

From report at bugs.python.org  Sun Nov 20 16:19:35 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 20 Nov 2011 15:19:35 +0000
Subject: [issue12703] Improve error reporting for packaging.util.resolve_name
In-Reply-To: <1312626935.87.0.525014153536.issue12703@psf.upfronthosting.co.za>
Message-ID: <1321802375.06.0.929868935103.issue12703@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I?ve found a way to make sure error messages always bubble up *and* clean up the ugly code in resolve_name, but it?s a rather drastic one.  The idea is to restrict the function to work only with names defined at the module level, not arbitrarily nested names.  That way, the code is much easier to write: split on '.', pop the last element and keep it for later, __import__ the rest of the name and look it up in sys.modules.  One consequence is that you can?t use package.module.SomeClass.NestedClass for a command, nor module.SomeClass.staticmethod as setup hook; to be pragmatic, I?m not sure that was really useful, and in any case you just have to do a module-level alias (?x = SomeClass.staticmethod?) to make it work.

To reflect the fact that the function has restrictions, I renamed it from the generic ?resolve_name? to the vague ?find_object?; vague is better because it makes less promises and should cause developers using to look at the docs or docstring.

In short, it?s a clear improvement code-wise that should not impact most of the users, and I like it a lot.

----------
stage: test needed -> patch review
Added file: http://bugs.python.org/file23735/change-resolve-name.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12703>
_______________________________________

From report at bugs.python.org  Sun Nov 20 16:45:18 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 20 Nov 2011 15:45:18 +0000
Subject: [issue11751] Increase distutils.filelist / packaging.manifest test
	coverage
In-Reply-To: <1301857658.21.0.439945432416.issue11751@psf.upfronthosting.co.za>
Message-ID: <1321803918.02.0.320423029432.issue11751@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Advice from Ezio Melotti:
> I would keep the flags even if you don't need them
> someone in the present or in the future might need them, and having them doesn't harm

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11751>
_______________________________________

From report at bugs.python.org  Sun Nov 20 16:55:17 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Sun, 20 Nov 2011 15:55:17 +0000
Subject: [issue13431] Pass context information into the extension module
	init	function
In-Reply-To: <1321694208.82.0.599594610804.issue13431@psf.upfronthosting.co.za>
Message-ID: <1321804517.79.0.173774951493.issue13431@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

Python interpreter already have that information internally. The initial proposal was to pass it to the init as an additional parameter. My suggestion is to export it as a new function that the init can call if VERSION >=3.3.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13431>
_______________________________________

From report at bugs.python.org  Sun Nov 20 17:09:15 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 20 Nov 2011 16:09:15 +0000
Subject: [issue13387] suggest assertIs(type(obj), cls) for exact type checking
In-Reply-To: <1321101802.89.0.94542095022.issue13387@psf.upfronthosting.co.za>
Message-ID: <1321805355.67.0.387635276945.issue13387@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Is "To check for the exact type, use :func:`assertIs(type(obj), cls) <assertIs>`." better?
I think the problem this solves is clear enough even without mentioning sub/superclasses.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13387>
_______________________________________

From report at bugs.python.org  Sun Nov 20 17:29:15 2011
From: report at bugs.python.org (Stefan Behnel)
Date: Sun, 20 Nov 2011 16:29:15 +0000
Subject: [issue13431] Pass context information into the extension module init
	function
In-Reply-To: <1321694208.82.0.599594610804.issue13431@psf.upfronthosting.co.za>
Message-ID: <1321806555.84.0.329842584199.issue13431@psf.upfronthosting.co.za>


Stefan Behnel <scoder at users.sourceforge.net> added the comment:

The problem with having that information "internally" is that it's currently stored in local variables in the call chain from the dynamic library loader. Passing that information on into a callable function, without passing it as an argument into the init function, means, that it needs to get stored away in some global place, with all the drawbacks that this induces. That's what Martin was referring to.

I agree with Martin that the idea of adding a parameter to the module init function is not worth pursuing before Python 4, so I'm closing this bug.

----------
resolution:  -> postponed
status: open -> closed
title: Pass context information into the extension module init	function -> Pass context information into the extension module init function

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13431>
_______________________________________

From report at bugs.python.org  Sun Nov 20 17:37:50 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sun, 20 Nov 2011 16:37:50 +0000
Subject: [issue3824] test_tarfile fails on cygwin (unicode decode error)
In-Reply-To: <1220992929.24.0.0835677599554.issue3824@psf.upfronthosting.co.za>
Message-ID: <1321807070.85.0.342714116613.issue3824@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

grp.getgrgid() now calls .decode('utf8', errors="surrogateescape").
Even if cygwin does not correctly copy strings from the Windows registry, tarinfo.gname should now contain a string that will at least round trip and give the same value on disk.
Ocean-city, can you check whether this error still reproduces?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3824>
_______________________________________

From report at bugs.python.org  Sun Nov 20 17:42:11 2011
From: report at bugs.python.org (Stefan Behnel)
Date: Sun, 20 Nov 2011 16:42:11 +0000
Subject: [issue13429] provide __file__ to extension init function
In-Reply-To: <1321631218.51.0.537222078649.issue13429@psf.upfronthosting.co.za>
Message-ID: <1321807331.16.0.108532014624.issue13429@psf.upfronthosting.co.za>


Stefan Behnel <scoder at users.sourceforge.net> added the comment:

As MvL noted in his response to issue 13431, simply adding a parameter to the module init function cannot safely be done before Python 4. So we are back to the idea of passing the information through to the module creation function, i.e. this very issue.

A variant of the implementation would be to store the context information in thread local storage instead of a global variable. That would work around any threading issues. However, this would not be required in the normal import case, only in the reinit case, as the import case is protected by the import lock, as we have seen. Personally, I do not consider this a good idea for the time being, since I doubt that the number of users for the reinitialisation API is currently worth caring about.

In any case, the semantics of __file__ for extension modules would basically become that __file__ refers to the last library that was loaded before calling the module init function. So all extension modules that this init function creates will inherit the same __file__. My guess is that they currently end up with no __file__ attribute at all, as the loader only sets it on the module that the init function returns. So I consider that an improvement already.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13429>
_______________________________________

From report at bugs.python.org  Sun Nov 20 18:07:29 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Sun, 20 Nov 2011 17:07:29 +0000
Subject: [issue10318] "make altinstall" installs many files with incorrect
	shebangs
In-Reply-To: <1288926610.35.0.932494150274.issue10318@psf.upfronthosting.co.za>
Message-ID: <1321808849.45.0.529352267658.issue10318@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

+1 to "c".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10318>
_______________________________________

From report at bugs.python.org  Sun Nov 20 19:41:05 2011
From: report at bugs.python.org (sbt)
Date: Sun, 20 Nov 2011 18:41:05 +0000
Subject: [issue12328] multiprocessing's overlapped PipeConnection on Windows
In-Reply-To: <1307991196.59.0.849860111943.issue12328@psf.upfronthosting.co.za>
Message-ID: <1321814465.51.0.759877323291.issue12328@psf.upfronthosting.co.za>


sbt <shibturn at gmail.com> added the comment:

Here is an updated patch (pipe_poll_fix.patch) which should be applied on top of sigint_event.patch.

It fixes the problems with PipeConnection.poll() and Queue.empty() and makes PipeListener.accept() use overlapped I/O.  This should make all the pipe releated blocking functions/methods interruptible on Windows.

----------
Added file: http://bugs.python.org/file23736/pipe_poll_fix.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12328>
_______________________________________

From report at bugs.python.org  Sun Nov 20 20:43:43 2011
From: report at bugs.python.org (Jeff McNeil)
Date: Sun, 20 Nov 2011 19:43:43 +0000
Subject: [issue12890] cgitb displays <p> tags when executed in text mode
In-Reply-To: <1315016521.13.0.175763253408.issue12890@psf.upfronthosting.co.za>
Message-ID: <1321818223.82.0.258272873916.issue12890@psf.upfronthosting.co.za>


Jeff McNeil <jeff at jmcneil.net> added the comment:

Added everything to one file. Updated tests to also include a logdir argument as that is required to trigger the original bug.  Weeded out a spurious write that occurred when format was set to text.

----------
Added file: http://bugs.python.org/file23737/head-cgitb-display.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12890>
_______________________________________

From report at bugs.python.org  Sun Nov 20 21:02:48 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 20 Nov 2011 20:02:48 +0000
Subject: [issue13437] Provide links to the source code for every module in the
	documentation
In-Reply-To: <1321748971.83.0.182041155467.issue13437@psf.upfronthosting.co.za>
Message-ID: <1321819368.52.0.30684600384.issue13437@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/issue13437>
_______________________________________

From report at bugs.python.org  Sun Nov 20 21:04:47 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 20 Nov 2011 20:04:47 +0000
Subject: [issue13438] "Delete patch set" review action doesn't work
In-Reply-To: <1321800690.51.0.854492831277.issue13438@psf.upfronthosting.co.za>
Message-ID: <1321819487.24.0.432143516889.issue13438@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13438>
_______________________________________

From report at bugs.python.org  Sun Nov 20 21:09:08 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Sun, 20 Nov 2011 20:09:08 +0000
Subject: [issue13402] Document absoluteness of sys.executable
In-Reply-To: <1321289437.84.0.982753479785.issue13402@psf.upfronthosting.co.za>
Message-ID: <1321819748.3.0.595686705692.issue13402@psf.upfronthosting.co.za>


Petri Lehtinen <petri at digip.org> added the comment:

Attached a patch.

----------
keywords: +patch
Added file: http://bugs.python.org/file23738/issue13402.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13402>
_______________________________________

From report at bugs.python.org  Sun Nov 20 21:41:24 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sun, 20 Nov 2011 20:41:24 +0000
Subject: [issue13436] compile() doesn't work on ImportFrom with level=None
In-Reply-To: <1321747479.31.0.688458511993.issue13436@psf.upfronthosting.co.za>
Message-ID: <1321821684.8.0.380665793442.issue13436@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Here is a patch for the bad error message (PyBytes_AS_BYTES after PyObject_Repr, bah)

----------
keywords: +patch
nosy: +amaury.forgeotdarc
Added file: http://bugs.python.org/file23739/issue13436.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13436>
_______________________________________

From report at bugs.python.org  Sun Nov 20 21:43:09 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sun, 20 Nov 2011 20:43:09 +0000
Subject: [issue13436] compile() doesn't work on ImportFrom with level=None
In-Reply-To: <1321747479.31.0.688458511993.issue13436@psf.upfronthosting.co.za>
Message-ID: <1321821789.24.0.980285454502.issue13436@psf.upfronthosting.co.za>


Changes by Amaury Forgeot d'Arc <amauryfa at gmail.com>:


----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13436>
_______________________________________

From report at bugs.python.org  Sun Nov 20 22:24:19 2011
From: report at bugs.python.org (=?utf-8?q?Bo=C5=A1tjan_Mejak?=)
Date: Sun, 20 Nov 2011 21:24:19 +0000
Subject: [issue12277] Missing comma in os.walk docs
In-Reply-To: <1307439951.32.0.810805209718.issue12277@psf.upfronthosting.co.za>
Message-ID: <1321824259.73.0.145768237856.issue12277@psf.upfronthosting.co.za>


Bo?tjan Mejak <bostjan.mejak at gmail.com> added the comment:

http://docs.python.org/release/2.6.7/library/os.html?highlight=os.walk#os.walk

Please fix Python 2.6 branch of docs as well. Thanks.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12277>
_______________________________________

From report at bugs.python.org  Sun Nov 20 22:25:12 2011
From: report at bugs.python.org (=?utf-8?q?Bo=C5=A1tjan_Mejak?=)
Date: Sun, 20 Nov 2011 21:25:12 +0000
Subject: [issue12277] Missing comma in os.walk docs
In-Reply-To: <1307439951.32.0.810805209718.issue12277@psf.upfronthosting.co.za>
Message-ID: <1321824312.06.0.307017104285.issue12277@psf.upfronthosting.co.za>


Changes by Bo?tjan Mejak <bostjan.mejak at gmail.com>:


----------
status: closed -> open
versions: +Python 2.6 -Python 2.7, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12277>
_______________________________________

From report at bugs.python.org  Sun Nov 20 22:29:18 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 20 Nov 2011 21:29:18 +0000
Subject: [issue13431] Pass context information into the extension module
	init	function
In-Reply-To: <1321804517.79.0.173774951493.issue13431@psf.upfronthosting.co.za>
Message-ID: <4EC97120.4020701@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> Python interpreter already have that information internally. The
> initial proposal was to pass it to the init as an additional
> parameter. My suggestion is to export it as a new function that the
> init can call if VERSION >=3.3.

Jesus: Please try to come up with a patch if you don't see the problem.
Trust Stefan and me that there actually *is* a problem with your
approach.

----------
title: Pass context information into the extension module init function -> Pass context information into the extension module init	function

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13431>
_______________________________________

From report at bugs.python.org  Sun Nov 20 22:33:03 2011
From: report at bugs.python.org (=?utf-8?q?Bo=C5=A1tjan_Mejak?=)
Date: Sun, 20 Nov 2011 21:33:03 +0000
Subject: [issue10562] Change 'j' for imaginary unit into an 'i'
In-Reply-To: <1290957558.0.0.518903978948.issue10562@psf.upfronthosting.co.za>
Message-ID: <1321824783.36.0.936178234849.issue10562@psf.upfronthosting.co.za>


Bo?tjan Mejak <bostjan.mejak at gmail.com> added the comment:

What's up with that now? Any interests in changing the imaginary unit from "j" to "i" ?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10562>
_______________________________________

From report at bugs.python.org  Sun Nov 20 22:34:52 2011
From: report at bugs.python.org (=?utf-8?q?Bo=C5=A1tjan_Mejak?=)
Date: Sun, 20 Nov 2011 21:34:52 +0000
Subject: [issue10621] >>> 1 + 2j --> (1 + 2j) and not (1+2j)
In-Reply-To: <1291454509.87.0.00219292943169.issue10621@psf.upfronthosting.co.za>
Message-ID: <1321824892.29.0.27492364991.issue10621@psf.upfronthosting.co.za>


Changes by Bo?tjan Mejak <bostjan.mejak at gmail.com>:


----------
resolution: wont fix -> remind
status: closed -> open
versions: +Python 3.3 -Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10621>
_______________________________________

From report at bugs.python.org  Sun Nov 20 22:35:54 2011
From: report at bugs.python.org (=?utf-8?q?Bo=C5=A1tjan_Mejak?=)
Date: Sun, 20 Nov 2011 21:35:54 +0000
Subject: [issue10621] >>> 1 + 2j --> (1 + 2j) and not (1+2j)
In-Reply-To: <1291454509.87.0.00219292943169.issue10621@psf.upfronthosting.co.za>
Message-ID: <1321824954.67.0.141309864757.issue10621@psf.upfronthosting.co.za>


Changes by Bo?tjan Mejak <bostjan.mejak at gmail.com>:


----------
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/issue10621>
_______________________________________

From report at bugs.python.org  Sun Nov 20 22:36:20 2011
From: report at bugs.python.org (=?utf-8?q?Bo=C5=A1tjan_Mejak?=)
Date: Sun, 20 Nov 2011 21:36:20 +0000
Subject: [issue10621] >>> 1 + 2j --> (1 + 2j) and not (1+2j)
In-Reply-To: <1291454509.87.0.00219292943169.issue10621@psf.upfronthosting.co.za>
Message-ID: <1321824980.47.0.35374179494.issue10621@psf.upfronthosting.co.za>


Changes by Bo?tjan Mejak <bostjan.mejak at gmail.com>:


----------
versions: +Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10621>
_______________________________________

From report at bugs.python.org  Sun Nov 20 22:37:17 2011
From: report at bugs.python.org (=?utf-8?q?Bo=C5=A1tjan_Mejak?=)
Date: Sun, 20 Nov 2011 21:37:17 +0000
Subject: [issue10562] Change 'j' for imaginary unit into an 'i'
In-Reply-To: <1290957558.0.0.518903978948.issue10562@psf.upfronthosting.co.za>
Message-ID: <1321825037.54.0.664791360648.issue10562@psf.upfronthosting.co.za>


Bo?tjan Mejak <bostjan.mejak at gmail.com> added the comment:

Come on, let's do this.

----------
resolution: wont fix -> remind
status: closed -> open
versions: +Python 3.3 -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10562>
_______________________________________

From report at bugs.python.org  Sun Nov 20 22:48:00 2011
From: report at bugs.python.org (Eric V. Smith)
Date: Sun, 20 Nov 2011 21:48:00 +0000
Subject: [issue10621] >>> 1 + 2j --> (1 + 2j) and not (1+2j)
In-Reply-To: <1291454509.87.0.00219292943169.issue10621@psf.upfronthosting.co.za>
Message-ID: <1321825680.14.0.160027202627.issue10621@psf.upfronthosting.co.za>


Eric V. Smith <eric at trueblade.com> added the comment:

I'm not sure why this is being reopened. Unless there's been a discussion I'm not aware of, the change is still not worth the disruption it would cause.

And in any event, it can only be addressed in new (as yet unreleased) versions of python. It would never be implemented in any release before 3.3.

----------
resolution: remind -> wont fix
status: open -> closed
versions:  -Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10621>
_______________________________________

From report at bugs.python.org  Sun Nov 20 22:55:27 2011
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sun, 20 Nov 2011 21:55:27 +0000
Subject: [issue13431] Pass context information into the extension module init
	function
In-Reply-To: <1321694208.82.0.599594610804.issue13431@psf.upfronthosting.co.za>
Message-ID: <1321826127.41.0.213350315151.issue13431@psf.upfronthosting.co.za>


Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:


----------
title: Pass context information into the extension module init	function -> Pass context information into the extension module init function

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13431>
_______________________________________

From report at bugs.python.org  Sun Nov 20 23:09:53 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 20 Nov 2011 22:09:53 +0000
Subject: [issue13401] test_argparse fails with root permissions
In-Reply-To: <1321284011.15.0.976219743674.issue13401@psf.upfronthosting.co.za>
Message-ID: <E1RSFZz-0007I7-Dl@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset ba3da86d1c5d by Victor Stinner in branch '3.2':
Close #13401: Skip TestFileTypeW of test_argparse if the current user is root
http://hg.python.org/cpython/rev/ba3da86d1c5d

New changeset 50e788691eda by Victor Stinner in branch 'default':
(Merge 3.2) Close #13401: Skip TestFileTypeW of test_argparse if the current user is root
http://hg.python.org/cpython/rev/50e788691eda

New changeset 6e1e1118adca by Victor Stinner in branch '2.7':
Close #13401: Skip TestFileTypeW of test_argparse if the current user is root
http://hg.python.org/cpython/rev/6e1e1118adca

----------
nosy: +python-dev
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13401>
_______________________________________

From report at bugs.python.org  Mon Nov 21 00:24:37 2011
From: report at bugs.python.org (Eli Collins)
Date: Sun, 20 Nov 2011 23:24:37 +0000
Subject: [issue12242] distutils2 environment marker for current compiler
In-Reply-To: <1307028523.76.0.0549970473948.issue12242@psf.upfronthosting.co.za>
Message-ID: <1321831477.27.0.985378175947.issue12242@psf.upfronthosting.co.za>


Changes by Eli Collins <elic at assurancetechnologies.com>:


Added file: http://bugs.python.org/file23740/4e67e7205aba.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12242>
_______________________________________

From report at bugs.python.org  Mon Nov 21 00:26:29 2011
From: report at bugs.python.org (Eli Collins)
Date: Sun, 20 Nov 2011 23:26:29 +0000
Subject: [issue12242] distutils2 environment marker for current compiler
In-Reply-To: <1307028523.76.0.0549970473948.issue12242@psf.upfronthosting.co.za>
Message-ID: <1321831589.68.0.75175682538.issue12242@psf.upfronthosting.co.za>


Eli Collins <elic at assurancetechnologies.com> added the comment:

Attached is a sixth revision (4e67e7205aba.diff) of my patch. This revision makes a couple of minor changes requested by ?ric Araujo.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12242>
_______________________________________

From report at bugs.python.org  Mon Nov 21 00:51:13 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 20 Nov 2011 23:51:13 +0000
Subject: [issue10562] Change 'j' for imaginary unit into an 'i'
In-Reply-To: <1290957558.0.0.518903978948.issue10562@psf.upfronthosting.co.za>
Message-ID: <1321833073.02.0.65325617927.issue10562@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

While this thread was amusing to read, *changing* Python from the engineering notation to mathematical notation for imaginary numbers is not going to happen. 'i' has ambiguity problems relative to '1' and 'l' in too many fonts - 'j', on the other hand, almost always uses a visually distinct glyph. And whether 'i' or 'j' seems more natural to you will depend on whether or not you have an electrical engineering background (as noted earlier in the thread, 'i' refers to current in electrical engineering).

If you care about the precise formatting of a complex number, write your own formatting function rather than relying on the exact format produced by "repr(num)".

Having an alternate constructor for complex objects that was more forgiving about 'i' vs 'j' also doesn't offer a huge benefit over the simple "x = complex(arg.replace('i', 'j')".

So while I have some sympathy for mathematicians that are frustrated by having to train their fingers to hit 'j' instead of 'i', that's not a good enough reason to change the language syntax or the behaviour of the complex() builtin. (See also http://www.boredomandlaziness.org/2011/02/status-quo-wins-stalemate.html)

----------
nosy: +ncoghlan
resolution: remind -> wont fix
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10562>
_______________________________________

From report at bugs.python.org  Mon Nov 21 00:54:44 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 20 Nov 2011 23:54:44 +0000
Subject: [issue13440] Explain the "status quo wins a stalemate" principle in
	the devguide
Message-ID: <1321833284.75.0.438515825131.issue13440@psf.upfronthosting.co.za>


New submission from Nick Coghlan <ncoghlan at gmail.com>:

I've linked http://www.boredomandlaziness.org/2011/02/status-quo-wins-stalemate.html in response to enough tracker issues and python-ideas threads now, that I'm convinced it (or at least something along those lines) belongs in the devguide.

It wouldn't hurt to also include something along the lines of:
http://www.boredomandlaziness.org/2011/02/justifying-python-language-changes.html

----------
components: Devguide
messages: 148016
nosy: ezio.melotti, ncoghlan
priority: normal
severity: normal
stage: needs patch
status: open
title: Explain the "status quo wins a stalemate" principle in the devguide

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13440>
_______________________________________

From report at bugs.python.org  Mon Nov 21 00:58:16 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 20 Nov 2011 23:58:16 +0000
Subject: [issue13441] TestEnUSCollation.test_strxfrm() fails on Solaris
Message-ID: <1321833496.0.0.544021070577.issue13441@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

I added a test in _PyUnicode_CheckConsistency() (in debug mode) to ensure that all characters of a string are in the range U+0000-U+10FFFF. Locale tests are now failing on Solaris:

-----------------------------------
[ 28/361] test__locale
Assertion failed: maxchar <= 0x10FFFF, file Objects/unicodeobject.c, line 408
Fatal Python error: Aborted

Current thread 0x00000001:
  File "/home2/buildbot/slave/3.x.loewis-sun/build/Lib/test/test__locale.py", line 134 in test_float_parsing
  File "/home2/buildbot/slave/3.x.loewis-sun/build/Lib/unittest/case.py", line 385 in _executeTestPart
  File "/home2/buildbot/slave/3.x.loewis-sun/build/Lib/unittest/case.py", line 440 in run
  File "/home2/buildbot/slave/3.x.loewis-sun/build/Lib/unittest/case.py", line 492 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/unittest/runner.py", line 168 in run
  File "/home2/buildbot/slave/3.x.loewis-sun/build/Lib/test/support.py", line 1368 in _run_suite
  File "/home2/buildbot/slave/3.x.loewis-sun/build/Lib/test/support.py", line 1402 in run_unittest
  File "/home2/buildbot/slave/3.x.loewis-sun/build/Lib/test/test__locale.py", line 139 in test_main
  File "/home2/buildbot/slave/3.x.loewis-sun/build/Lib/test/regrtest.py", line 1203 in runtest_inner
  File "/home2/buildbot/slave/3.x.loewis-sun/build/Lib/test/regrtest.py", line 906 in runtest
  File "/home2/buildbot/slave/3.x.loewis-sun/build/Lib/test/regrtest.py", line 709 in main
  File "/home2/buildbot/slave/3.x.loewis-sun/build/Lib/test/__main__.py", line 13 in <module>
  File "/home2/buildbot/slave/3.x.loewis-sun/build/Lib/runpy.py", line 73 in _run_code
  File "/home2/buildbot/slave/3.x.loewis-sun/build/Lib/runpy.py", line 160 in _run_module_as_main
*** Error code 134
-----------------------------------

The problem is that strxfrm() and wcsxfrm() return strange results for the string "a" and the english locale (e.g. en_US.UTF-8).

strxfrm(buffer, "a\0", 100) returns 21 (bytes) but only 2 bytes are written ("\x01\x00"). The next bytes are unchanged.

wcsxfrm(buffer, L"a\0", 100) returns 7 (characters), the 7 characters are written but they are in range U+1010101..U+1010163, whereas the maximum character of Unicode 6.0 is U+10FFFF (U+101xxxx vs U+10xxxx).

Output of the attached program, strxfrm.c, on OpenSolaris:
-----------------------------------
strxfrm: len=21
0x01
0x00
0xff
0xff
0xff
0xff
0xff
0xff
0xff
0xff
0xff
0xff
0xff
0xff
0xff
0xff
0xff
0xff
0xff
0xff
0xff

wcsxfrm: len=7
U+1010163
U+1010101
U+1010103
U+1010101
U+1010103
U+1010101
U+1010101
-----------------------------------

I don't know if it's normal that wcsxfrm() writes characters in the range U+1010101..U+1010163.

Is Python supposed to support characters outside U+0000-U+10FFFF range? chr(0x10FFFF+1) raises a ValueError.

----------
components: Unicode
files: strxfrm.c
messages: 148017
nosy: ezio.melotti, haypo, loewis, pitrou
priority: normal
severity: normal
status: open
title: TestEnUSCollation.test_strxfrm() fails on Solaris
versions: Python 3.3
Added file: http://bugs.python.org/file23741/strxfrm.c

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13441>
_______________________________________

From report at bugs.python.org  Mon Nov 21 01:00:40 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 21 Nov 2011 00:00:40 +0000
Subject: [issue10318] "make altinstall" installs many files with incorrect
	shebangs
In-Reply-To: <1288926610.35.0.932494150274.issue10318@psf.upfronthosting.co.za>
Message-ID: <1321833640.78.0.966514783482.issue10318@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

+1 to 'c', but it should come with an update to PEP 8 to say "don't do that".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10318>
_______________________________________

From report at bugs.python.org  Mon Nov 21 01:11:54 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 21 Nov 2011 00:11:54 +0000
Subject: [issue13441] TestEnUSCollation.test_strxfrm() fails on Solaris
In-Reply-To: <1321833496.0.0.544021070577.issue13441@psf.upfronthosting.co.za>
Message-ID: <E1RSHU4-0007Sn-DX@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 31baf1363ba1 by Victor Stinner in branch 'default':
Issue #13441: Disable temporary strxfrm() tests on Solaris
http://hg.python.org/cpython/rev/31baf1363ba1

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13441>
_______________________________________

From report at bugs.python.org  Mon Nov 21 01:24:28 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 21 Nov 2011 00:24:28 +0000
Subject: [issue13436] compile() doesn't work on ImportFrom with level=None
In-Reply-To: <1321747479.31.0.688458511993.issue13436@psf.upfronthosting.co.za>
Message-ID: <1321835068.84.0.248673059646.issue13436@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

LGTM.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13436>
_______________________________________

From report at bugs.python.org  Mon Nov 21 01:24:36 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 21 Nov 2011 00:24:36 +0000
Subject: [issue13436] compile() doesn't work on ImportFrom with level=None
In-Reply-To: <1321747479.31.0.688458511993.issue13436@psf.upfronthosting.co.za>
Message-ID: <1321835076.46.0.658920626637.issue13436@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <benjamin at python.org>:


----------
assignee: docs at python -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13436>
_______________________________________

From report at bugs.python.org  Mon Nov 21 01:47:20 2011
From: report at bugs.python.org (Julian Berman)
Date: Mon, 21 Nov 2011 00:47:20 +0000
Subject: [issue13437] Provide links to the source code for every module in the
	documentation
In-Reply-To: <1321748971.83.0.182041155467.issue13437@psf.upfronthosting.co.za>
Message-ID: <1321836440.43.0.763426033211.issue13437@psf.upfronthosting.co.za>


Julian Berman <Julian+Python.org at GrayVines.com> added the comment:

Here's first a quick list from one pass over the docs. I've attempted to limit myself to a few like you've suggested, though I'll wait for confirmation that Raymond is not willing to simply add them to everything once we're at it :).

http://docs.python.org/library/difflib.html
http://docs.python.org/library/stringio.html
http://docs.python.org/library/codecs.html
http://docs.python.org/library/stringprep.html
http://docs.python.org/library/datetime.html
http://docs.python.org/library/math.html
http://docs.python.org/library/cmath.html
http://docs.python.org/library/decimal.html
http://docs.python.org/library/itertools.html
http://docs.python.org/library/os.path.html
http://docs.python.org/library/csv.html
http://docs.python.org/library/configparser.html
http://docs.python.org/library/logging.html
http://docs.python.org/library/getpass.html
http://docs.python.org/library/json.html
http://docs.python.org/library/urllib2.html
http://docs.python.org/library/unittest.html
http://docs.python.org/library/code.html

When I hit the docs to diagnose a problem, it's usually to take a quick look, and then to hit the source code to read that too, since most of the stuff that's in general use is common enough for me to know how it works in a general sense, so the source code is typically where I go pretty quickly after reading what the docs have to say.

It's not a huge deal obviously, hg.python.com is not the furthest thing away. Just seems convenient, especially since like I said a lot of the other ones I peek at already have links.


As for non-python modules, I really would like to say that linking to C source sounds just as reasonable to me, a little C never killed anyone :), but I don't want to push my luck, so I'll stick with whatever I can get here I guess (I know I put some non-python modules on the list).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13437>
_______________________________________

From report at bugs.python.org  Mon Nov 21 02:22:49 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 21 Nov 2011 01:22:49 +0000
Subject: [issue13442] Better support for pipe I/O encoding in subprocess
Message-ID: <1321838568.9.0.683093502178.issue13442@psf.upfronthosting.co.za>


New submission from Nick Coghlan <ncoghlan at gmail.com>:

Currently, pipes in the subprocess module work strictly with bytes I/O, *unless* you set "universal newlines=True". In that case, it assumes an output encoding of UTF-8 for stdout and stderr and applies universal newlines process.

When stdin/out/err are remapped to ordinary I/O streams then 'encoding' and 'errors' can be specified as usual, but it is currently challenging to do this for pipes. Since they're created internally by the subprocess module, user code doesn't get the opportunity to wrap them when using the convenience APIs. When using Popen objects, you have to create the object, then wrap each stream individually (rebinding the attributes as you go).

My suggestion is that we add a new option for the stdin/out/err arguments:

    class TextPipe:
        def __init__(self, encoding, errors='strict'):
            self.encoding = encoding
            self.errors = errors

So to read UTF-8 encoded data from a subprocess, you could just do:

    data = check_stdout(cmd, stdout=TextPipe('utf-8'), stderr=STDOUT)

There are at least a couple of other alternatives here:

- separate out the pipe creation logic from the Popen logic so it is possible to create and wrap the pipe objects explicitly and then pass the wrapped pipe object to the subprocess invocation APIs. 'TextPipe' would then actually be such a wrapped pipe, rather than merely instructions to tell Popen what kind of pipe to create.
- instead of adding 'TextPipe', just re-use the PIPE name (with the class itself still being used as a marker constant to request implicit creation of a binary PIPE)

----------
assignee: docs at python
components: Documentation
messages: 148022
nosy: docs at python, ncoghlan
priority: normal
severity: normal
stage: needs patch
status: open
title: Better support for pipe I/O encoding in subprocess
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13442>
_______________________________________

From report at bugs.python.org  Mon Nov 21 02:25:27 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 21 Nov 2011 01:25:27 +0000
Subject: [issue13442] Better support for pipe I/O encoding in subprocess
In-Reply-To: <1321838568.9.0.683093502178.issue13442@psf.upfronthosting.co.za>
Message-ID: <1321838727.23.0.0528033923546.issue13442@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

This issue looks as a duplicate of #6135.

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13442>
_______________________________________

From report at bugs.python.org  Mon Nov 21 02:32:26 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 21 Nov 2011 01:32:26 +0000
Subject: [issue13442] Better support for pipe I/O encoding in subprocess
In-Reply-To: <1321838568.9.0.683093502178.issue13442@psf.upfronthosting.co.za>
Message-ID: <1321839146.49.0.387612326674.issue13442@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Indeed, I'll add my suggestions over there.

----------
assignee: docs at python -> 
resolution:  -> duplicate
stage: needs patch -> committed/rejected
status: open -> closed
superseder:  -> subprocess seems to use local 8-bit encoding and gives no choice

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13442>
_______________________________________

From report at bugs.python.org  Mon Nov 21 02:56:37 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 21 Nov 2011 01:56:37 +0000
Subject: [issue6135] subprocess seems to use local 8-bit encoding and gives no
	choice
In-Reply-To: <1243494524.57.0.870766192683.issue6135@psf.upfronthosting.co.za>
Message-ID: <1321840597.06.0.979705999952.issue6135@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

I discovered this same problem recently when updating the subprocess docs, and also in working on the improved shell invocation support I am proposing for 3.3 (#13238).

I initially posted an earlier variant this suggestion as a new issue (#13442), but Victor redirected me here.

Firstly, I don't think it makes any sense to set encoding information globally for the Popen object. As a simple example, consider using Python to write a test suite for the iconv command line tool: there's only one Popen instance (for the iconv call), but different encodings for stdin and stdout.

Really, we want to be able to make full use of Python 3's layered I/O model, but we want the subprocess pipe instances to be slotted in at the lowest layer rather than creating them ourselves.

The easiest way to do that is to have a separate class that specifies the additional options for pipe creation and does the wrapping:

    class TextPipe:
        def __init__(self, *args, **kwds):
            self.args = args
            self.kwds = kwds
        def wrap_pipe(self, pipe):
            return io.TextIOWrapper(pipe, *self.args, **self.kwds)

The stream creation process would then include a new "wrap = getattr(stream_arg, 'wrap_pipe', None)" check that is similar to the existing check for subprocess.PIPE, but invokes the method to wrap the pipe after creating it.

So to read UTF-8 encoded data from a subprocess, you could just do:

    data = check_stdout(cmd, stdout=TextPipe('utf-8'), stderr=STDOUT)

----------
nosy: +ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6135>
_______________________________________

From report at bugs.python.org  Mon Nov 21 03:05:10 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 21 Nov 2011 02:05:10 +0000
Subject: [issue13441] TestEnUSCollation.test_strxfrm() fails on Solaris
In-Reply-To: <1321833496.0.0.544021070577.issue13441@psf.upfronthosting.co.za>
Message-ID: <1321841110.32.0.025121107234.issue13441@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> Is Python supposed to support characters outside U+0000-U+10FFFF range?

If not, PyUnicode_FromUnicode(), PyUnicode_FromWideChar() and PyUnicode_FromKindAndData() should be patched to raise an error if a bigger character is encountered.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13441>
_______________________________________

From report at bugs.python.org  Mon Nov 21 03:09:17 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 21 Nov 2011 02:09:17 +0000
Subject: [issue13441] TestEnUSCollation.test_strxfrm() fails on Solaris
In-Reply-To: <1321833496.0.0.544021070577.issue13441@psf.upfronthosting.co.za>
Message-ID: <1321841357.14.0.579519553254.issue13441@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> strxfrm(buffer, "a\0", 100) returns 21 (bytes) but only 2 bytes
> are written ("\x01\x00"). The next bytes are unchanged.

Woops, it was a bug in my program. I attached the fixed version. The correct program writes:
----
strxfrm: len=21
0x01
0x01
0x63
0x01
0x01
0x01
0x01
0x01
0x03
0x01
0x01
0x01
0x01
0x01
0x03
0x01
0x01
0x01
0x01
0x01
0x01

wcsxfrm: len=7
U+1010163
U+1010101
U+1010103
U+1010101
U+1010103
U+1010101
U+1010101
----

----------
Added file: http://bugs.python.org/file23742/strxfrm.c

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13441>
_______________________________________

From report at bugs.python.org  Mon Nov 21 03:09:27 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 21 Nov 2011 02:09:27 +0000
Subject: [issue13441] TestEnUSCollation.test_strxfrm() fails on Solaris
In-Reply-To: <1321833496.0.0.544021070577.issue13441@psf.upfronthosting.co.za>
Message-ID: <1321841367.4.0.931103533025.issue13441@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Removed file: http://bugs.python.org/file23741/strxfrm.c

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13441>
_______________________________________

From report at bugs.python.org  Mon Nov 21 03:17:06 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 21 Nov 2011 02:17:06 +0000
Subject: [issue13441] TestEnUSCollation.test_strxfrm() fails on Solaris
In-Reply-To: <1321833496.0.0.544021070577.issue13441@psf.upfronthosting.co.za>
Message-ID: <E1RSJRE-0007ko-Nd@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 78123afb3ea4 by Victor Stinner in branch 'default':
Issue #13441: Disable temporary localeconv() tests on Solaris
http://hg.python.org/cpython/rev/78123afb3ea4

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13441>
_______________________________________

From report at bugs.python.org  Mon Nov 21 05:28:26 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Mon, 21 Nov 2011 04:28:26 +0000
Subject: [issue13402] Document absoluteness of sys.executable
In-Reply-To: <1321289437.84.0.982753479785.issue13402@psf.upfronthosting.co.za>
Message-ID: <1321849706.68.0.534188456735.issue13402@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

LGTM

----------
nosy: +eli.bendersky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13402>
_______________________________________

From report at bugs.python.org  Mon Nov 21 05:40:04 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Mon, 21 Nov 2011 04:40:04 +0000
Subject: [issue13443] wrong links and examples in the functional HOWTO
Message-ID: <1321850404.45.0.767133152656.issue13443@psf.upfronthosting.co.za>


New submission from Eli Bendersky <eliben at gmail.com>:

Micha? Cha?upczak reported in this docs@ list that the links to IBM developerworks articles are wrong.

>From some additional observation, the code samples on the 3.x page use the external `functional` module, which was not ported to Python 3 at all.

I wonder whether it makes sense to use external modules in official Python documentation, since these are not guaranteed to be ported. This issue is a good example of this happening.

The HOWTO should be probably rewritten to use only the stdlib. The links to IBM developerworks should be, IMHO, removed, since they point to articles written in 2001 and have code samples that won't work on Python 3.x

----------
assignee: docs at python
components: Documentation
messages: 148030
nosy: akuchling, docs at python, eli.bendersky
priority: normal
severity: normal
status: open
title: wrong links and examples in the functional HOWTO
versions: Python 2.7, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13443>
_______________________________________

From report at bugs.python.org  Mon Nov 21 06:31:40 2011
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 21 Nov 2011 05:31:40 +0000
Subject: [issue12277] Missing comma in os.walk docs
In-Reply-To: <1307439951.32.0.810805209718.issue12277@psf.upfronthosting.co.za>
Message-ID: <1321853500.4.0.870000015906.issue12277@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/issue12277>
_______________________________________

From report at bugs.python.org  Mon Nov 21 08:00:24 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Mon, 21 Nov 2011 07:00:24 +0000
Subject: [issue12277] Missing comma in os.walk docs
In-Reply-To: <1307439951.32.0.810805209718.issue12277@psf.upfronthosting.co.za>
Message-ID: <1321858824.83.0.376381619213.issue12277@psf.upfronthosting.co.za>


Petri Lehtinen <petri at digip.org> added the comment:

> Please fix Python 2.6 branch of docs as well. Thanks.

2.6 only receives security fixes any more.

----------
versions: +Python 2.7, Python 3.2, Python 3.3 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12277>
_______________________________________

From report at bugs.python.org  Mon Nov 21 11:03:05 2011
From: report at bugs.python.org (Christian Iversen)
Date: Mon, 21 Nov 2011 10:03:05 +0000
Subject: [issue13433] String format documentation contains error regarding %g
In-Reply-To: <1321707692.58.0.601543510069.issue13433@psf.upfronthosting.co.za>
Message-ID: <1321869785.22.0.201160047082.issue13433@psf.upfronthosting.co.za>


Christian Iversen <ci at sikkerhed.org> added the comment:

Certainly, I don't think we should be peppering the docs with warnings and notes, either.

However, the elements in question _already have_ notes. I propose that the note for %g (4) simply be updated for clarity. Something like this, perhaps:

"""Unlike the other floating-point formats, the precision determines the number of significant digits before and after the decimal point and defaults to 6."""

Simply adding "Unlike the other floating-point formats," at the beginning of the second line makes it much clearer that this is a different beast.

If you feel that is not the right solution, then feel free to close this issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13433>
_______________________________________

From report at bugs.python.org  Mon Nov 21 13:06:16 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 21 Nov 2011 12:06:16 +0000
Subject: [issue13437] Provide links to the source code for every module in the
	documentation
In-Reply-To: <1321748971.83.0.182041155467.issue13437@psf.upfronthosting.co.za>
Message-ID: <1321877176.15.0.736980552965.issue13437@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

There are usually two cases that lead me to check the code:
1) The documentation is incomplete, not clear, missing, or plain wrong;
2) I want to check how something is implemented, mostly just out of curiosity;

Regarding the first case, in theory the docs should be informative and correct enough to not require you to go and check the code.  If they aren't you can report issues and we can improve it.
The second case applies to pretty much any module.  Linking to the code might also expose some internal details that should be just ignored by the user.  The code in some modules is also pretty old and might be a "bad" example (because it doesn't use modern conventions).
Some of the modules you listed are actually packages, so that would require to link to several files.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13437>
_______________________________________

From report at bugs.python.org  Mon Nov 21 13:07:31 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 21 Nov 2011 12:07:31 +0000
Subject: [issue13443] wrong links and examples in the functional HOWTO
In-Reply-To: <1321850404.45.0.767133152656.issue13443@psf.upfronthosting.co.za>
Message-ID: <1321877251.29.0.187184535323.issue13443@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
keywords: +easy
nosy: +ezio.melotti
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13443>
_______________________________________

From report at bugs.python.org  Mon Nov 21 13:14:39 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 21 Nov 2011 12:14:39 +0000
Subject: [issue13441] TestEnUSCollation.test_strxfrm() fails on Solaris
In-Reply-To: <1321833496.0.0.544021070577.issue13441@psf.upfronthosting.co.za>
Message-ID: <1321877679.93.0.136442394463.issue13441@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

> Is Python supposed to support characters outside U+0000-U+10FFFF range?

No, they should be rejected.  Allowing them in some specific places might cause them to leak somewhere else and cause problems, so I'd rather stick with that range and reject all the chars >U+10FFFF everywhere.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13441>
_______________________________________

From report at bugs.python.org  Mon Nov 21 13:39:29 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 21 Nov 2011 12:39:29 +0000
Subject: [issue9530] integer undefined behaviors
In-Reply-To: <1281075386.13.0.164742828093.issue9530@psf.upfronthosting.co.za>
Message-ID: <1321879169.31.0.63572482476.issue9530@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> I'd be happy to re-run the tests sometime.

Yes, please!  Alternatively, if there are easy instructions for us to re-run these tests, that would be valuable, too.  Do I understand correctly that you have a publicly available extension to LLVM for this?

> Basically it'll act as a more powerful -ftrapv, and the error message will be much better than "aborted".

Indeed---there were a number of places where tracking down the exact cause of the error using a combination of -ftrapv and gdb was painful. :-)

I'm aware of two current issues: one in Python/formatter_unicode.c, and one in Modules/timemodule.c.  I'll try to fix these shortly.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9530>
_______________________________________

From report at bugs.python.org  Mon Nov 21 14:21:51 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 21 Nov 2011 13:21:51 +0000
Subject: [issue13170] distutils2 test failures
In-Reply-To: <1318523837.27.0.295397321545.issue13170@psf.upfronthosting.co.za>
Message-ID: <E1RSToX-0001C5-In@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset c1b1b537196d by ?ric Araujo in branch 'default':
Remove usage of stdlib shutil.
http://hg.python.org/distutils2/rev/c1b1b537196d

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13170>
_______________________________________

From report at bugs.python.org  Mon Nov 21 14:21:53 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 21 Nov 2011 13:21:53 +0000
Subject: [issue11751] Increase distutils.filelist / packaging.manifest test
	coverage
In-Reply-To: <1301857658.21.0.439945432416.issue11751@psf.upfronthosting.co.za>
Message-ID: <E1RSToX-0001C5-Iu@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 723517bf6708 by ?ric Araujo in branch 'default':
Make test_manifest pass on 2.4 and 2.5 (fixes #11751).
http://hg.python.org/distutils2/rev/723517bf6708

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11751>
_______________________________________

From report at bugs.python.org  Mon Nov 21 14:32:04 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 21 Nov 2011 13:32:04 +0000
Subject: [issue13441] TestEnUSCollation.test_strxfrm() fails on Solaris
In-Reply-To: <1321833496.0.0.544021070577.issue13441@psf.upfronthosting.co.za>
Message-ID: <E1RSTyQ-0002AC-KY@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset a19dad38d4e8 by Victor Stinner in branch 'default':
Issue #13441: _PyUnicode_CheckConsistency() dumps the string if the maximum
http://hg.python.org/cpython/rev/a19dad38d4e8

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13441>
_______________________________________

From report at bugs.python.org  Mon Nov 21 14:32:33 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 21 Nov 2011 13:32:33 +0000
Subject: [issue13441] TestEnUSCollation.test_strxfrm() fails on Solaris
In-Reply-To: <1321833496.0.0.544021070577.issue13441@psf.upfronthosting.co.za>
Message-ID: <1321882353.25.0.546446284533.issue13441@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> No, they should be rejected. Allowing them in some specific
> places might cause them to leak somewhere else and cause problems,
> so I'd rather stick with that range and reject all the chars
> >U+10FFFF everywhere.

That's why I added a (debug) check to reject them. I don't think that your UTF-8 encoder support such character some example. All functions assumes that the maximum character is U+10FFFF.

If they should be rejected, a solution is to modify strxfrm() to return a list of integer (of code points) instead of a string.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13441>
_______________________________________

From report at bugs.python.org  Mon Nov 21 14:46:39 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 21 Nov 2011 13:46:39 +0000
Subject: [issue13387] suggest assertIs(type(obj), cls) for exact type checking
In-Reply-To: <1321101802.89.0.94542095022.issue13387@psf.upfronthosting.co.za>
Message-ID: <1321883199.59.0.0367137961792.issue13387@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Your latest proposal is better.  I would prefer mentioning subclasses, but don?t feel strongly about it.  One markup nit: I?d use ``code`` instead of (ab)using :func:; the doc for assertIs is just a few paragraphs above, it won?t be hard to find.

----------
resolution: fixed -> 
stage: committed/rejected -> commit review
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13387>
_______________________________________

From report at bugs.python.org  Mon Nov 21 14:47:46 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 21 Nov 2011 13:47:46 +0000
Subject: [issue11751] Increase distutils.filelist / packaging.manifest test
	coverage
In-Reply-To: <1301857658.21.0.439945432416.issue11751@psf.upfronthosting.co.za>
Message-ID: <1321883266.06.0.51615021934.issue11751@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Did the second idea as suggested by Ezio.

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11751>
_______________________________________

From report at bugs.python.org  Mon Nov 21 14:50:03 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 21 Nov 2011 13:50:03 +0000
Subject: [issue13402] Document absoluteness of sys.executable
In-Reply-To: <1321289437.84.0.982753479785.issue13402@psf.upfronthosting.co.za>
Message-ID: <1321883403.49.0.00560350977728.issue13402@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Patch looks good, but are you 100% sure that sys.executable is always absolute?  (On all OSes, under multiprocessing, etc?)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13402>
_______________________________________

From report at bugs.python.org  Mon Nov 21 14:50:14 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 21 Nov 2011 13:50:14 +0000
Subject: [issue12890] cgitb displays <p> tags when executed in text mode
In-Reply-To: <1315016521.13.0.175763253408.issue12890@psf.upfronthosting.co.za>
Message-ID: <1321883414.96.0.862851473657.issue12890@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


Removed file: http://bugs.python.org/file23091/head-cgitb-display.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12890>
_______________________________________

From report at bugs.python.org  Mon Nov 21 14:50:17 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 21 Nov 2011 13:50:17 +0000
Subject: [issue12890] cgitb displays <p> tags when executed in text mode
In-Reply-To: <1315016521.13.0.175763253408.issue12890@psf.upfronthosting.co.za>
Message-ID: <1321883417.21.0.00259427481716.issue12890@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


Removed file: http://bugs.python.org/file23731/head-cgitb-display-tests.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12890>
_______________________________________

From report at bugs.python.org  Mon Nov 21 15:20:04 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Mon, 21 Nov 2011 14:20:04 +0000
Subject: [issue13402] Document absoluteness of sys.executable
In-Reply-To: <1321883403.49.0.00560350977728.issue13402@psf.upfronthosting.co.za>
Message-ID: <20111121141949.GD9731@p16>


Petri Lehtinen <petri at digip.org> added the comment:

?ric Araujo wrote:
> Patch looks good, but are you 100% sure that sys.executable is
> always absolute? (On all OSes, under multiprocessing, etc?)

Well, its value is computed by a function named
Py_GetProgramFullPath(), so I'm quite sure. I had a quick look on what
the function is doing, but it was quite complicated. I can check it
better if needed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13402>
_______________________________________

From report at bugs.python.org  Mon Nov 21 15:34:24 2011
From: report at bugs.python.org (Jeff McNeil)
Date: Mon, 21 Nov 2011 14:34:24 +0000
Subject: [issue12890] cgitb displays <p> tags when executed in text mode
In-Reply-To: <1315016521.13.0.175763253408.issue12890@psf.upfronthosting.co.za>
Message-ID: <1321886064.1.0.83550129305.issue12890@psf.upfronthosting.co.za>


Changes by Jeff McNeil <jeff at jmcneil.net>:


Added file: http://bugs.python.org/file23743/head-cgitb-display.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12890>
_______________________________________

From report at bugs.python.org  Mon Nov 21 15:35:24 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 21 Nov 2011 14:35:24 +0000
Subject: [issue13317] building with 2to3 generates wrong import paths because
	build_ext is run after build_py
In-Reply-To: <1320183133.27.0.209500697705.issue13317@psf.upfronthosting.co.za>
Message-ID: <1321886124.77.0.90124841699.issue13317@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Ah, thanks for clarifying, I didn?t understand what you meant with local/global but now I see it?s about absolute imports and explicit relative imports.  (I don?t remember ever reading that terminology before looking at fix_import.)

I?m adding the ?easy? keyword because it should not be too hard to write tests for this, with the examples and helpers we already have in the test suite and given that I?m available for help.

----------
assignee: tarek -> eric.araujo
components: +Distutils2 -2to3 (2.x to 3.x conversion tool)
keywords: +easy
nosy: +alexis
stage:  -> needs patch
type:  -> behavior
versions: +3rd party, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13317>
_______________________________________

From report at bugs.python.org  Mon Nov 21 15:39:45 2011
From: report at bugs.python.org (Asesh)
Date: Mon, 21 Nov 2011 14:39:45 +0000
Subject: [issue13418] Embedded Python memory leak
In-Reply-To: <1321491453.86.0.929770076277.issue13418@psf.upfronthosting.co.za>
Message-ID: <1321886385.53.0.619833471511.issue13418@psf.upfronthosting.co.za>


Asesh <aseshshres at gmail.com> added the comment:

@Martin v. L?wis (loewis): thanks, I will try to do so in my free time

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13418>
_______________________________________

From report at bugs.python.org  Mon Nov 21 15:41:05 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 21 Nov 2011 14:41:05 +0000
Subject: [issue13441] TestEnUSCollation.test_strxfrm() fails on Solaris
In-Reply-To: <1321833496.0.0.544021070577.issue13441@psf.upfronthosting.co.za>
Message-ID: <E1RSV3D-0000uO-7u@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset d1b3b1d00811 by Victor Stinner in branch 'default':
Another temporary hack to debug the issue #13441
http://hg.python.org/cpython/rev/d1b3b1d00811

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13441>
_______________________________________

From report at bugs.python.org  Mon Nov 21 15:41:24 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 21 Nov 2011 14:41:24 +0000
Subject: [issue13316] build_py_2to3 does not convert when there was an error
	in the last run
In-Reply-To: <1320182540.3.0.985799836702.issue13316@psf.upfronthosting.co.za>
Message-ID: <1321886484.67.0.873738765395.issue13316@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> It does stop with an error message.  But when I reinvoke the command, converting is
> skipped (because the file is already copied).
Then that?s the bug: In case of error, the file in the build dir should be removed.

By the way, I think this was not reported before because people probably edit the file when there is a 2to3 error, and so it is detected as modified and then copied again.

----------
assignee: tarek -> eric.araujo
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13316>
_______________________________________

From report at bugs.python.org  Mon Nov 21 15:44:13 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 21 Nov 2011 14:44:13 +0000
Subject: [issue13441] TestEnUSCollation.test_strxfrm() fails on Solaris
In-Reply-To: <1321833496.0.0.544021070577.issue13441@psf.upfronthosting.co.za>
Message-ID: <1321886653.21.0.789122255881.issue13441@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

I dumped some values to try to debug this issue. Last failure in test__locale.test_lc_numeric_basic() on localeconv():
----------------------------
[ 25/361] test_float
Decode localeconv() decimal_point: {0x2c} (len=1)
Decode localeconv() thousands_sep: {0x2e} (len=1)
Decode localeconv() int_curr_symbol: {} (len=0)
Decode localeconv() currency_symbol: {} (len=0)
Decode localeconv() mon_decimal_point: {} (len=0)
Decode localeconv() mon_thousands_sep: {} (len=0)
Decode localeconv() positive_sign: {} (len=0)
Decode localeconv() negative_sign: {} (len=0)
...
[100/361] test__locale
Decode localeconv() decimal_point: {0x2c} (len=1)
Decode localeconv() thousands_sep: {0xa0} (len=1)
Invalid Unicode string! {U+30000020} (len=1)
Fatal Python error: Aborted
----------------------------

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13441>
_______________________________________

From report at bugs.python.org  Mon Nov 21 15:55:40 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 21 Nov 2011 14:55:40 +0000
Subject: [issue12618] py_compile cannot create files in current directory
In-Reply-To: <1311406971.17.0.312082121474.issue12618@psf.upfronthosting.co.za>
Message-ID: <1321887340.07.0.316992070666.issue12618@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Thanks for the patch Meador, I hadn?t realized we had no tests for py_compile (it is however used in test_import and test_compileall).  I think it would be nice to commit the tests first (except for the one that?s the object of this bug report) in order to have a baseline, and then see about fixing this bug.  I?ll do that in a few days if nobody objects.

I?m not sure there would be no negative side-effects to using os.path.abspath; we don?t know what people do with symlinks and relative paths out there, so I?d prefer adding a safe special case* rather than always calling abspath.  What do you think?


* Instead of using len, something like this would be clear IMO:

      if parent:  # empty string means current directory, skip creating the dir
          os.makedirs(parent)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12618>
_______________________________________

From report at bugs.python.org  Mon Nov 21 16:01:01 2011
From: report at bugs.python.org (=?utf-8?q?Bo=C5=A1tjan_Mejak?=)
Date: Mon, 21 Nov 2011 15:01:01 +0000
Subject: [issue12277] Missing comma in os.walk docs
In-Reply-To: <1321858824.83.0.376381619213.issue12277@psf.upfronthosting.co.za>
Message-ID: <CAEt-fFwpLq1Kse_zopStX5cw1Mv=wRb28pRzPt2k3GLXnSZyVQ@mail.gmail.com>


Bo?tjan Mejak <bostjan.mejak at gmail.com> added the comment:

That is simply idiotic. Your way of fixing things is idiotic. When you
clearly see the missing comma and you fix it everywhere else but 2.6
because "2.6 only receives security fixes" as if adding a comma to the
documentation would create a big security hole. That's an act of an idiot.
I am sorry, but that is how I see it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12277>
_______________________________________

From report at bugs.python.org  Mon Nov 21 16:01:16 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 21 Nov 2011 15:01:16 +0000
Subject: [issue13441] TestEnUSCollation.test_strxfrm() fails on Solaris
In-Reply-To: <1321833496.0.0.544021070577.issue13441@psf.upfronthosting.co.za>
Message-ID: <E1RSVMk-0002wL-99@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset acda16de630c by Victor Stinner in branch 'default':
Remove temporary hacks for the issue #13441
http://hg.python.org/cpython/rev/acda16de630c

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13441>
_______________________________________

From report at bugs.python.org  Mon Nov 21 16:01:37 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 21 Nov 2011 15:01:37 +0000
Subject: [issue9321] CGIHTTPServer cleanup htbin
In-Reply-To: <1279701482.44.0.871660375803.issue9321@psf.upfronthosting.co.za>
Message-ID: <1321887697.21.0.561670565772.issue9321@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Google does find matches for ?CGI /htbin?.  Given that CGI is an obsolete technology anyway, I don?t see value in removing that, and propose that we reject this request.

----------
nosy: +eric.araujo
versions: +Python 3.3 -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9321>
_______________________________________

From report at bugs.python.org  Mon Nov 21 16:04:12 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 21 Nov 2011 15:04:12 +0000
Subject: [issue12277] Missing comma in os.walk docs
In-Reply-To: <1307439951.32.0.810805209718.issue12277@psf.upfronthosting.co.za>
Message-ID: <1321887852.36.0.0425221686383.issue12277@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

It's not because of the security risk, but simply because the docs for 2.6 are not rebuilt automatically anymore.  So, even if we fix it on 2.6, no one will see the change unless someone goes and triggers a full doc rebuild manually.  A missing comma is not enough to justify this extra work.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12277>
_______________________________________

From report at bugs.python.org  Mon Nov 21 16:10:16 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 21 Nov 2011 15:10:16 +0000
Subject: [issue13441] TestEnUSCollation.test_strxfrm() fails on Solaris
In-Reply-To: <1321833496.0.0.544021070577.issue13441@psf.upfronthosting.co.za>
Message-ID: <1321888216.28.0.335458856672.issue13441@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Here is a more complete output. localeconv() fails in the hu_HU locale for the "thousands_sep" field: localeconv() returns b'\xa0' which is decoded as the wchar_t* string: {U+30000020} (len=1). This is an invalid character
-----------------------------------
[ 54/361/3] test__locale
Decode wchar_t {U+0043} (len=1)
SET LOCALE "es_UY"
SET LOCALE "fr_FR"
SET LOCALE "fi_FI"
SET LOCALE "es_CO"
SET LOCALE "pt_PT"
SET LOCALE "it_IT"
SET LOCALE "et_EE"
SET LOCALE "es_PY"
SET LOCALE "no_NO"
SET LOCALE "nl_NL"
SET LOCALE "lv_LV"
SET LOCALE "el_GR"
SET LOCALE "be_BY"
SET LOCALE "fr_BE"
SET LOCALE "ro_RO"
SET LOCALE "ru_UA"
SET LOCALE "ru_RU"
SET LOCALE "es_VE"
SET LOCALE "ca_ES"
SET LOCALE "se_NO"
SET LOCALE "es_EC"
SET LOCALE "id_ID"
SET LOCALE "ka_GE"
SET LOCALE "es_CL"
SET LOCALE "hu_HU"
SET LOCALE -> hu_HU
Decode wchar_t {U+0068 U+0075 U+005f U+0048 U+0055} (len=5)
SET LOCALE "hu_HU"
SET LOCALE -> hu_HU
Decode wchar_t {U+0068 U+0075 U+005f U+0048 U+0055} (len=5)
Decode wchar_t {U+002c} (len=1)
Decode localeconv() decimal_point: {0x2c} (len=1)
Decode wchar_t {U+002c} (len=1)
Decode localeconv() thousands_sep: {0xa0} (len=1)
Decode wchar_t {U+30000020} (len=1)
Invalid Unicode string! {U+30000020} (len=1)
Fatal Python error: Aborted

Current thread 0x00000001:
  File "/home2/buildbot/slave/3.x.loewis-sun/build/Lib/test/test__locale.py", line 105 in test_lc_numeric_basic
  File "/home2/buildbot/slave/3.x.loewis-sun/build/Lib/unittest/case.py", line 385 in _executeTestPart
  File "/home2/buildbot/slave/3.x.loewis-sun/build/Lib/unittest/case.py", line 440 in run
  File "/home2/buildbot/slave/3.x.loewis-sun/build/Lib/unittest/case.py", line 492 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/unittest/runner.py", line 168 in run
  File "/home2/buildbot/slave/3.x.loewis-sun/build/Lib/test/support.py", line 1368 in _run_suite
  File "/home2/buildbot/slave/3.x.loewis-sun/build/Lib/test/support.py", line 1402 in run_unittest
  File "/home2/buildbot/slave/3.x.loewis-sun/build/Lib/test/test__locale.py", line 141 in test_main
  File "/home2/buildbot/slave/3.x.loewis-sun/build/Lib/test/regrtest.py", line 1203 in runtest_inner
  File "/home2/buildbot/slave/3.x.loewis-sun/build/Lib/test/regrtest.py", line 906 in runtest
  File "/home2/buildbot/slave/3.x.loewis-sun/build/Lib/test/regrtest.py", line 709 in main
  File "/home2/buildbot/slave/3.x.loewis-sun/build/Lib/test/__main__.py", line 13 in <module>
  File "/home2/buildbot/slave/3.x.loewis-sun/build/Lib/runpy.py", line 73 in _run_code
  File "/home2/buildbot/slave/3.x.loewis-sun/build/Lib/runpy.py", line 160 in _run_module_as_main
*** Error code 134
-----------------------------------

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13441>
_______________________________________

From report at bugs.python.org  Mon Nov 21 16:12:05 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 21 Nov 2011 15:12:05 +0000
Subject: [issue13441] TestEnUSCollation.test_strxfrm() fails on Solaris
In-Reply-To: <1321833496.0.0.544021070577.issue13441@psf.upfronthosting.co.za>
Message-ID: <1321888325.61.0.345582427901.issue13441@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy:  -pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13441>
_______________________________________

From report at bugs.python.org  Mon Nov 21 16:18:20 2011
From: report at bugs.python.org (Ronny Pfannschmidt)
Date: Mon, 21 Nov 2011 15:18:20 +0000
Subject: [issue13444] closed stdout causes error on stderr when the
	interpreter unconditionally flushes on shutdown
Message-ID: <1321888700.56.0.103830046171.issue13444@psf.upfronthosting.co.za>


New submission from Ronny Pfannschmidt <ronny.pfannschmidt at gmail.com>:

not sure if this is to be considered a bug,
but python3.2 tries to flush sys.stdout on shutdown, even if its closed

$ python3.2 -c 'import sys;sys.stdout.close()'
Exception ValueError: 'I/O operation on closed file.' in <_io.TextIOWrapper name='<stdout>' mode='w' encoding='ANSI_X3.4-1968'> ignored

its related to how Issue #5319 was fixed

----------
components: Interpreter Core
messages: 148055
nosy: Ronny.Pfannschmidt, georg.brandl, mkc, pitrou, terry.reedy
priority: normal
severity: normal
status: open
title: closed stdout causes error on stderr when the interpreter unconditionally flushes on shutdown
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13444>
_______________________________________

From report at bugs.python.org  Mon Nov 21 16:23:50 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 21 Nov 2011 15:23:50 +0000
Subject: [issue12890] cgitb displays <p> tags when executed in text mode
In-Reply-To: <1315016521.13.0.175763253408.issue12890@psf.upfronthosting.co.za>
Message-ID: <1321889030.4.0.632229460188.issue12890@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


Removed file: http://bugs.python.org/file23737/head-cgitb-display.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12890>
_______________________________________

From report at bugs.python.org  Mon Nov 21 16:24:56 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 21 Nov 2011 15:24:56 +0000
Subject: [issue12890] cgitb displays <p> tags when executed in text mode
In-Reply-To: <1315016521.13.0.175763253408.issue12890@psf.upfronthosting.co.za>
Message-ID: <1321889096.92.0.201802991811.issue12890@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Latest patch is good to go.

----------
versions: +Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12890>
_______________________________________

From report at bugs.python.org  Mon Nov 21 17:29:55 2011
From: report at bugs.python.org (David Amian)
Date: Mon, 21 Nov 2011 16:29:55 +0000
Subject: [issue13420] newer() function in dep_util.py discard changes in the
	same second
In-Reply-To: <1321626627.03.0.197752380943.issue13420@psf.upfronthosting.co.za>
Message-ID: <CABJvE6JYOzLL5wtG-ipGOWFjzVxuA6+qUSV1KAWGuzEoAxXgow@mail.gmail.com>


David Amian <damian at emergya.com> added the comment:

2011/11/18 ?ric Araujo <report at bugs.python.org>

>
> ?ric Araujo <merwok at netwok.org> added the comment:
>
> > I've a project, in the setup.py file, I've a function called
> update_prefix, that updates the
> > 'path_project' variable with prefix arguments from setup.py
> > If you runs setup.py with --prefix=/usr, then the file in
> 'projectname/projectnameconfig.py' is
> > modified changing the 'path_project' variable from @PREFIX at +"share/projectname"
> to
> > '/usr/share/projectname'. If you runs setup.py without prefix arguments,
> the prefix is '/usr/local'.
>
> Did you write a custom 'install' class or are you for example looking at
> sys.argv to decide whether to run your function?  If it?s not implemented
> as a distutils command, it?s not surprising that it does not integrate well.
>

Really I've a function to update prefix based on sys.argv but i changed
this using a custom class command and the same issue occurs

>
> > [...]
> > That is cause of the issue, that I explain in the early comment, I fixed
> it rounding to two decimals
> > instead of rounding to integer.
>
> Okay.  Can you make sure that this is the source of the problem, for
> example by adding time.sleep(1) between build and install?
>

I puts a time.sleep(1) bewteen 'setup.py build' and 'setup.py install' and
I got these results:

*Without waiting:

$debuild -us -uc
[...]
mkdir -p debian/python-module-stampdir
cd . && \
python setup.py build \
--build-base="/tmp/pdal/pdal2-0.3.1/./build"
running build
running build_py
copying pdal/pdalconfig.py -> build/lib.linux-i686-2.7/pdal
running build_scripts
[...]
python setup.py install \
--root="/tmp/pdal/pdal2-0.3.1/debian/pdal2/" \
--install-purelib=/usr/lib/python2.7/site-packages/ \
-f --prefix=/usr
[...]
running build
running build_py
running build_scripts
[...]

$

The stats of files are:

File: ?pdal/pdalconfig.py?
Modify: 2011-11-21 13:44:52.497971724 +0100

File: ?build/lib.linux-i686-2.7/pdal/pdalconfig.py?
Modify: 2011-11-21 13:44:52.000000000 +0100

It doesn't copy in the install step because st_mtimes in newer() are the
same:
ST_MTIME-source- 1321879492
ST_MTIME-target- 1321879492

*Waiting a second between build and install:

$debuild -us -uc
[...]
mkdir -p debian/python-module-stampdir
cd . && \
python setup.py build \
--build-base="/tmp/pdal/pdal2-0.3.1/./build"
running build
running build_py
copying pdal/pdalconfig.py -> build/lib.linux-i686-2.7/pdal
running build_scripts
[...]
python setup.py install \
--root="/tmp/pdal/pdal2-0.3.1/debian/pdal2/" \
--install-purelib=/usr/lib/python2.7/site-packages/ \
-f --prefix=/usr
[...]
running build
running build_py
copying pdal/pdalconfig.py -> build/lib.linux-i686-2.7/pdal
running build_scripts
[...]

$

Obviously the file has been copied as st_mtimes in newer() differ by a
second
ST_MTIME-source- 1321879603
ST_MTIME-target- 1321879602

>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue13420>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13420>
_______________________________________

From report at bugs.python.org  Mon Nov 21 17:55:15 2011
From: report at bugs.python.org (Lauren Foutz)
Date: Mon, 21 Nov 2011 16:55:15 +0000
Subject: [issue13445] Enable linking the module pysqlite with Berkeley DB SQL
	instead of SQLite
Message-ID: <1321894515.42.0.740720237959.issue13445@psf.upfronthosting.co.za>


New submission from Lauren Foutz <lauren.foutz at gmail.com>:

Before the pysqlite module was made standard it could be edited to link with Berkeley DB SQL instead of SQLite.  I am requesting that the Python build add the ability to link with BDBSQL instead of SQLite.

----------
components: Build
messages: 148058
nosy: Lauren.Foutz
priority: normal
severity: normal
status: open
title: Enable linking the module pysqlite with Berkeley DB SQL instead of SQLite
type: feature request

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13445>
_______________________________________

From report at bugs.python.org  Mon Nov 21 17:58:37 2011
From: report at bugs.python.org (Lauren Foutz)
Date: Mon, 21 Nov 2011 16:58:37 +0000
Subject: [issue13445] Enable linking the module pysqlite with Berkeley DB SQL
	instead of SQLite
In-Reply-To: <1321894515.42.0.740720237959.issue13445@psf.upfronthosting.co.za>
Message-ID: <1321894717.88.0.466767650866.issue13445@psf.upfronthosting.co.za>


Lauren Foutz <lauren.foutz at gmail.com> added the comment:

Before the pysqlite module was made standard it could be edited to link with Berkeley DB SQL instead of SQLite.  I am requesting that the Python build add the ability to link with BDBSQL instead of SQLite.

Below is a description of how to link pysqlite with BDBSQL


Download and unpack the latest version of pysqlite.
Download and unpack the latest release of Berkeley Db (at least db-5.0 or higher).
Build bdb using the following:
cd db/build_unix
../dist/configure --enable-sql-compat --prefix=<bdb install directory>
make
make install

Next change to the top pysqlite directory. There edit the file setup.cfg to the following:
[build_ext]
#define=
include_dirs=<bdb install directory>/include
library_dirs=<bdb install directory>/lib
libraries=sqlite3
define=SQLITE_OMIT_LOAD_EXTENSION

Note, make sure you uncomment the lines with "include_dirs" and "library_dirs"

Next, build and install the python sqlite3 library using:
python setup.py build
python setup.py install

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13445>
_______________________________________

From report at bugs.python.org  Mon Nov 21 17:58:56 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 21 Nov 2011 16:58:56 +0000
Subject: [issue13445] Enable linking the module pysqlite with Berkeley DB SQL
	instead of SQLite
In-Reply-To: <1321894515.42.0.740720237959.issue13445@psf.upfronthosting.co.za>
Message-ID: <1321894736.01.0.702460907057.issue13445@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +ghaering
versions: +Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13445>
_______________________________________

From report at bugs.python.org  Mon Nov 21 18:04:19 2011
From: report at bugs.python.org (Charalampos Nikolaou)
Date: Mon, 21 Nov 2011 17:04:19 +0000
Subject: [issue13446] imaplib,
	fetch: improper behaviour on read-only selected mailboxes
Message-ID: <1321895059.52.0.840142009955.issue13446@psf.upfronthosting.co.za>


New submission from Charalampos Nikolaou <char.nikolaou at gmail.com>:

I would like to report a misbehaviour on the fetch command of imaplib when used with mailboxes that have been opened as read-only. In such cases, when you fetch a message (using for instance RFC822), the mail is not marked as read (i.e., the flag of the respective message is not set to 'seen'). I have only tested with IMAP over SSL with the server of my organization on which I don't have administration permissions and gmail.

System details
----------------
Python: 2.5, 2.6, 2.7.2, 3.0, 3.1, 3.2
Server: Cyrus IMAP4 v2.1.18 and imap.gmail.com

Pseudocode to reproduce the problem:
---------------------------------------
imap = imaplib.IMAP4_SSL(imap_server)
imap.connect(user, pass)
imap.select(mailbox, readonly=True)
imap.search(None, 'Unseen')
imap.fetch(mid, 'RFC822')
imap.close()
imap.logout()

After executing the above code, the message with id mid will not have been marked as read, while it should have been.

Other relevant information:
-----------------------------
Access List for my readonly mailbox: group:1 lrsw group:2 p group:3 lrsp group:4 lrswip group:5 lrswipd group:6 lrswipd group:7 lrsw group:8 lrsw group:9 p group:10 p group:11 lrsp group:12 lrsp group:13 lrswip group:14 lrswip group:15 lrswipd group:16 lrswipd group:17 lrswipd group:18 lrswipd

I have to mention that the above access list is the same with the one of another mailbox which is read/write. I mention this just to make clear that the access list does not play any role in this problem.

Hope I haven't forgotten anything. In any case, ask me.

----------
components: Library (Lib)
messages: 148060
nosy: char.nikolaou
priority: normal
severity: normal
status: open
title: imaplib, fetch: improper behaviour on read-only selected mailboxes
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13446>
_______________________________________

From report at bugs.python.org  Mon Nov 21 18:04:19 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 21 Nov 2011 17:04:19 +0000
Subject: [issue13441] TestEnUSCollation.test_strxfrm() fails on Solaris
In-Reply-To: <1321833496.0.0.544021070577.issue13441@psf.upfronthosting.co.za>
Message-ID: <E1RSXHp-0008LD-HB@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset d6d15fcf5eb6 by Victor Stinner in branch 'default':
Issue #13441: Reenable strxfrm() tests on Solaris
http://hg.python.org/cpython/rev/d6d15fcf5eb6

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13441>
_______________________________________

From report at bugs.python.org  Mon Nov 21 18:08:04 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 21 Nov 2011 17:08:04 +0000
Subject: [issue13447] Add tests for Tools/scripts/reindent.py
Message-ID: <1321895284.05.0.389852057258.issue13447@psf.upfronthosting.co.za>


New submission from ?ric Araujo <merwok at netwok.org>:

When people find bugs in reindent.py (#12930 is a recent one), we have to try to reproduce the bug manually, apply a fix and test manually again.  The alternative is to only read the code and trust that it works.  I find both of these positions unsatisfactory and propose to add unit tests for the script.  I?m opening this report to gather votes, and if they?re positive I?ll proceed with a patch and other bug reports for the other most used scripts (we have a number of reports for pygettext and msgfmt for example; I am not proposing adding tests for all, or even most, scripts).

Even if these scripts are not part of the stdlib and not officially documented or supported, we do ship them and use them (reindent from patchcheck and Mercurial hooks for example), so I really think we need unit tests to know that they work as intended.  Then we?ll be able to commit fixes and other changes serenely.

Implementation idea: The tests would go in Tools/scripts/tests/test_reindent.py and a short file in Lib/test/test_scripts.py would run them as part of the test suite if they exist (so that running tests from an installed Python without Tools dir just skips test_scripts).  For scripts that are in another Tools subdir, like Tools/i18n/pygettext.py, I?d put them in Tools/i18n/tests/test_pygettext.py.

----------
components: Demos and Tools, Tests
messages: 148062
nosy: eric.araujo
priority: normal
severity: normal
status: open
title: Add tests for Tools/scripts/reindent.py
versions: Python 2.7, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13447>
_______________________________________

From report at bugs.python.org  Mon Nov 21 18:10:56 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 21 Nov 2011 17:10:56 +0000
Subject: [issue12930] reindent.py inserts spaces in multiline literals
In-Reply-To: <1315405777.71.0.767109553281.issue12930@psf.upfronthosting.co.za>
Message-ID: <1321895456.39.0.292742911576.issue12930@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Thanks, I?ll make time to review the change this week.

----------
dependencies: +Add tests for Tools/scripts/reindent.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12930>
_______________________________________

From report at bugs.python.org  Mon Nov 21 18:18:21 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 21 Nov 2011 17:18:21 +0000
Subject: [issue13447] Add tests for Tools/scripts/reindent.py
In-Reply-To: <1321895284.05.0.389852057258.issue13447@psf.upfronthosting.co.za>
Message-ID: <1321895901.33.0.714637661187.issue13447@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

+1

What you describe sounds all good to me, except that I would keep all tests in the same dir (i.e. Tools/tests (or Tools/test?)) instead of having different test dirs for each subdir (so test_pygettext.py would go in Tools/tests and not in Tools/i18n/tests).

----------
nosy: +ezio.melotti
stage:  -> test needed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13447>
_______________________________________

From report at bugs.python.org  Mon Nov 21 18:20:55 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 21 Nov 2011 17:20:55 +0000
Subject: [issue12156] test_multiprocessing.test_notify_all() timeout (1 hour)
	on FreeBSD 7.2
In-Reply-To: <1306147254.92.0.286085135906.issue12156@psf.upfronthosting.co.za>
Message-ID: <1321896055.85.0.904535572869.issue12156@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

I tried test_multi_sem-1.diff on "x86 FreeBSD 7.2 3.x" buildbot: the patch works as expected, the test suite is skipped.

A minor nit: can you write the number of semaphore in the skip message? Except of this nit, the patch looks good to me (and I prefer test_multi_sem-1.diff over test_multi_sem.diff).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12156>
_______________________________________

From report at bugs.python.org  Mon Nov 21 18:31:13 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 21 Nov 2011 17:31:13 +0000
Subject: [issue6135] subprocess seems to use local 8-bit encoding and gives no
	choice
In-Reply-To: <1321840597.06.0.979705999952.issue6135@psf.upfronthosting.co.za>
Message-ID: <1321896370.3305.3.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Firstly, I don't think it makes any sense to set encoding information
> globally for the Popen object. As a simple example, consider using
> Python to write a test suite for the iconv command line tool: there's
> only one Popen instance (for the iconv call), but different encodings
> for stdin and stdout.

Isn't that the exception rather than the rule? I think it actually makes
sense, in at least 99.83% of cases ;-), to have a common encoding
setting for all streams.
(I'm not sure about the "errors" setting, though: should we use strict
for stdin/stdout and backslashreplace for stderr, as the interpreter
does?)

Perhaps the common case should be made extra easy.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6135>
_______________________________________

From report at bugs.python.org  Mon Nov 21 19:06:16 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 21 Nov 2011 18:06:16 +0000
Subject: [issue12277] Missing comma in os.walk docs
In-Reply-To: <1307439951.32.0.810805209718.issue12277@psf.upfronthosting.co.za>
Message-ID: <1321898776.4.0.329083493844.issue12277@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

The reason is simply that 2.6 basically unmaintained.

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12277>
_______________________________________

From report at bugs.python.org  Mon Nov 21 19:17:03 2011
From: report at bugs.python.org (John Regehr)
Date: Mon, 21 Nov 2011 18:17:03 +0000
Subject: [issue9530] integer undefined behaviors
In-Reply-To: <1281075386.13.0.164742828093.issue9530@psf.upfronthosting.co.za>
Message-ID: <1321899423.41.0.468409448613.issue9530@psf.upfronthosting.co.za>


John Regehr <regehr at cs.utah.edu> added the comment:

Hi Mark, yes you can run the overflow checker but "easy instructions" depends on whether you feel like building your own LLVM.  It is not at all difficult, but it's certainly not as easy as "apt-get install ...".

Patch and instructions are here:

  http://embed.cs.utah.edu/ioc/

If/when we get this into LLVM (the earliest possible release containing IOC will be 3.1), I'll let you know.  Thanks again.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9530>
_______________________________________

From report at bugs.python.org  Mon Nov 21 19:57:31 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Mon, 21 Nov 2011 18:57:31 +0000
Subject: [issue8270] Should socket.PF_PACKET be removed,
	in favor of socket.AF_PACKET?
In-Reply-To: <1269993998.45.0.142767118704.issue8270@psf.upfronthosting.co.za>
Message-ID: <1321901851.2.0.0131904538585.issue8270@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

There are now more protocol families defined (PF_RDS, PF_CAN), etc.
Since both AF_ and PF_ are valid (see http://en.wikipedia.org/wiki/Berkeley_sockets#Protocol_and_address_families for more information), and there is so much code out there in the wild using either form, let's just keep it that way.

----------
nosy: +neologix
resolution:  -> rejected
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8270>
_______________________________________

From report at bugs.python.org  Mon Nov 21 20:11:05 2011
From: report at bugs.python.org (Masha Katsman)
Date: Mon, 21 Nov 2011 19:11:05 +0000
Subject: [issue12759] "(?P=)" input for Tools/scripts/redemo.py raises
	unnhandled exception
In-Reply-To: <1313495654.73.0.277709437369.issue12759@psf.upfronthosting.co.za>
Message-ID: <1321902665.03.0.848523519438.issue12759@psf.upfronthosting.co.za>


Masha Katsman <mkatsman at yahoo.com> added the comment:

I am working on the patch. The fix is ready. Will be delivered shortly.
It is also broken when I specify (?P<>) pattern

----------
nosy: +mashayk

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12759>
_______________________________________

From report at bugs.python.org  Mon Nov 21 20:14:20 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 21 Nov 2011 19:14:20 +0000
Subject: [issue12759] "(?P=)" input for Tools/scripts/redemo.py raises
	unnhandled exception
In-Reply-To: <1313495654.73.0.277709437369.issue12759@psf.upfronthosting.co.za>
Message-ID: <1321902860.83.0.0819001670528.issue12759@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/issue12759>
_______________________________________

From report at bugs.python.org  Mon Nov 21 20:20:43 2011
From: report at bugs.python.org (=?utf-8?q?Bo=C5=A1tjan_Mejak?=)
Date: Mon, 21 Nov 2011 19:20:43 +0000
Subject: [issue10562] Change 'j' for imaginary unit into an 'i'
In-Reply-To: <1290957558.0.0.518903978948.issue10562@psf.upfronthosting.co.za>
Message-ID: <1321903243.25.0.36897025726.issue10562@psf.upfronthosting.co.za>


Bo?tjan Mejak <bostjan.mejak at gmail.com> added the comment:

It's stupid that the imaginary unit in Python is denoted by a "j" just for ambiguity reasons that "i" can be mistaken with a "1" or an "l". It's true that "1" and "l" can look the same in some fonts, but that is *certainly not true* for the small letter "i".

Just fix the "j" into an "i" already.

----------
resolution: wont fix -> remind
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10562>
_______________________________________

From report at bugs.python.org  Mon Nov 21 20:23:37 2011
From: report at bugs.python.org (Brian Curtin)
Date: Mon, 21 Nov 2011 19:23:37 +0000
Subject: [issue10562] Change 'j' for imaginary unit into an 'i'
In-Reply-To: <1290957558.0.0.518903978948.issue10562@psf.upfronthosting.co.za>
Message-ID: <1321903417.92.0.943164259589.issue10562@psf.upfronthosting.co.za>


Changes by Brian Curtin <brian at python.org>:


----------
resolution: remind -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10562>
_______________________________________

From report at bugs.python.org  Mon Nov 21 20:24:09 2011
From: report at bugs.python.org (=?utf-8?q?Bo=C5=A1tjan_Mejak?=)
Date: Mon, 21 Nov 2011 19:24:09 +0000
Subject: [issue10562] Change 'j' for imaginary unit into an 'i'
In-Reply-To: <1290957558.0.0.518903978948.issue10562@psf.upfronthosting.co.za>
Message-ID: <1321903449.01.0.882628520978.issue10562@psf.upfronthosting.co.za>


Changes by Bo?tjan Mejak <bostjan.mejak at gmail.com>:


----------
resolution: wont fix -> remind
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10562>
_______________________________________

From report at bugs.python.org  Mon Nov 21 20:24:26 2011
From: report at bugs.python.org (=?utf-8?q?Bo=C5=A1tjan_Mejak?=)
Date: Mon, 21 Nov 2011 19:24:26 +0000
Subject: [issue10562] Change 'j' for imaginary unit into an 'i'
In-Reply-To: <1290957558.0.0.518903978948.issue10562@psf.upfronthosting.co.za>
Message-ID: <1321903466.58.0.545405885046.issue10562@psf.upfronthosting.co.za>


Changes by Bo?tjan Mejak <bostjan.mejak at gmail.com>:


----------
nosy: +gvanrossum

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10562>
_______________________________________

From report at bugs.python.org  Mon Nov 21 20:25:42 2011
From: report at bugs.python.org (=?utf-8?q?Bo=C5=A1tjan_Mejak?=)
Date: Mon, 21 Nov 2011 19:25:42 +0000
Subject: [issue10562] Change 'j' for imaginary unit into an 'i'
In-Reply-To: <1290957558.0.0.518903978948.issue10562@psf.upfronthosting.co.za>
Message-ID: <1321903542.24.0.507652006499.issue10562@psf.upfronthosting.co.za>


Bo?tjan Mejak <bostjan.mejak at gmail.com> added the comment:

Please fix this in Python 3.3 and don't forget to fix the complex() function/method as well.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10562>
_______________________________________

From report at bugs.python.org  Mon Nov 21 20:26:59 2011
From: report at bugs.python.org (Brian Curtin)
Date: Mon, 21 Nov 2011 19:26:59 +0000
Subject: [issue10562] Change 'j' for imaginary unit into an 'i'
In-Reply-To: <1290957558.0.0.518903978948.issue10562@psf.upfronthosting.co.za>
Message-ID: <1321903619.87.0.710336065132.issue10562@psf.upfronthosting.co.za>


Brian Curtin <brian at python.org> added the comment:

Please stop re-opening this thread. The reasons it will not be fixed have been laid out.

----------
nosy: +brian.curtin -gvanrossum
resolution: remind -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10562>
_______________________________________

From report at bugs.python.org  Mon Nov 21 20:31:25 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 21 Nov 2011 19:31:25 +0000
Subject: [issue13322] buffered read() and write() does not raise
	BlockingIOError
In-Reply-To: <1320246535.71.0.465783773129.issue13322@psf.upfronthosting.co.za>
Message-ID: <E1RSZaB-0005g0-II@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset ac2c4c62b486 by Antoine Pitrou in branch '3.2':
Issue #13322: Fix BufferedWriter.write() to ensure that BlockingIOError is
http://hg.python.org/cpython/rev/ac2c4c62b486

New changeset 3cd1985ed04f by Antoine Pitrou in branch 'default':
Issue #13322: Fix BufferedWriter.write() to ensure that BlockingIOError is
http://hg.python.org/cpython/rev/3cd1985ed04f

New changeset e84e17643eeb by Antoine Pitrou in branch '2.7':
Issue #13322: Fix BufferedWriter.write() to ensure that BlockingIOError is
http://hg.python.org/cpython/rev/e84e17643eeb

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13322>
_______________________________________

From report at bugs.python.org  Mon Nov 21 20:32:11 2011
From: report at bugs.python.org (=?utf-8?q?Bo=C5=A1tjan_Mejak?=)
Date: Mon, 21 Nov 2011 19:32:11 +0000
Subject: [issue10621] >>> 1 + 2j --> (1 + 2j) and not (1+2j)
In-Reply-To: <1291454509.87.0.00219292943169.issue10621@psf.upfronthosting.co.za>
Message-ID: <1321903931.41.0.514062466999.issue10621@psf.upfronthosting.co.za>


Bo?tjan Mejak <bostjan.mejak at gmail.com> added the comment:

Make the output of a complex expression include spaces around the operator. So, for example, (1+2j) should be outputted as (1 + 2j). Make this happen in Python 3.3.

----------
nosy: +gvanrossum
resolution: wont fix -> remind
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10621>
_______________________________________

From report at bugs.python.org  Mon Nov 21 20:44:20 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 21 Nov 2011 19:44:20 +0000
Subject: [issue13417] faster utf-8 decoding
In-Reply-To: <1321483781.85.0.24668666063.issue13417@psf.upfronthosting.co.za>
Message-ID: <E1RSZmg-0006ik-5B@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 8e6c4acaf530 by Antoine Pitrou in branch 'default':
Issue #13417: speed up utf-8 decoding by around 2x for the non-fully-ASCII case.
http://hg.python.org/cpython/rev/8e6c4acaf530

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13417>
_______________________________________

From report at bugs.python.org  Mon Nov 21 20:44:58 2011
From: report at bugs.python.org (Eric V. Smith)
Date: Mon, 21 Nov 2011 19:44:58 +0000
Subject: [issue10621] >>> 1 + 2j --> (1 + 2j) and not (1+2j)
In-Reply-To: <1291454509.87.0.00219292943169.issue10621@psf.upfronthosting.co.za>
Message-ID: <1321904698.6.0.586213857444.issue10621@psf.upfronthosting.co.za>


Eric V. Smith <eric at trueblade.com> added the comment:

I'm -1 on this change. I think all the core devs who have commented on it here are -1 or -0. If you really want to lobby for this change, I suggest starting a discussion on python-dev.

My position is that I think it would indeed look nicer, but the breakage doesn't justify the small improvement.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10621>
_______________________________________

From report at bugs.python.org  Mon Nov 21 20:48:57 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 21 Nov 2011 19:48:57 +0000
Subject: [issue13417] faster utf-8 decoding
In-Reply-To: <1321483781.85.0.24668666063.issue13417@psf.upfronthosting.co.za>
Message-ID: <1321904937.26.0.673160256505.issue13417@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Thanks for the review, patch committed now (with bogus comments removed).

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13417>
_______________________________________

From report at bugs.python.org  Mon Nov 21 20:53:00 2011
From: report at bugs.python.org (Eric Snow)
Date: Mon, 21 Nov 2011 19:53:00 +0000
Subject: [issue10621] >>> 1 + 2j --> (1 + 2j) and not (1+2j)
In-Reply-To: <1291454509.87.0.00219292943169.issue10621@psf.upfronthosting.co.za>
Message-ID: <1321905180.97.0.465328861855.issue10621@psf.upfronthosting.co.za>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

@eric.smith: +1

@Retro: If you are intent on pushing this, please take it to python-ideas at python.org.  However, judging from the response in this ticket and #10562, you won't get much traction.

----------
nosy: +eric.snow

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10621>
_______________________________________

From report at bugs.python.org  Mon Nov 21 20:54:09 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 21 Nov 2011 19:54:09 +0000
Subject: [issue13411] Hashable memoryviews
In-Reply-To: <1321395643.62.0.259606214561.issue13411@psf.upfronthosting.co.za>
Message-ID: <E1RSZwB-0007fj-9X@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 215690b782f8 by Antoine Pitrou in branch 'default':
Issue #13411: memoryview objects are now hashable when the underlying object is hashable.
http://hg.python.org/cpython/rev/215690b782f8

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13411>
_______________________________________

From report at bugs.python.org  Mon Nov 21 20:54:41 2011
From: report at bugs.python.org (Eric Snow)
Date: Mon, 21 Nov 2011 19:54:41 +0000
Subject: [issue10562] Change 'j' for imaginary unit into an 'i'
In-Reply-To: <1290957558.0.0.518903978948.issue10562@psf.upfronthosting.co.za>
Message-ID: <1321905281.87.0.571239706405.issue10562@psf.upfronthosting.co.za>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

@brian.curtin: +1

@Retro: as noted in #10621, please take this to python-ideas at python.org

----------
nosy: +eric.snow

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10562>
_______________________________________

From report at bugs.python.org  Mon Nov 21 20:57:02 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 21 Nov 2011 19:57:02 +0000
Subject: [issue13411] Hashable memoryviews
In-Reply-To: <1321395643.62.0.259606214561.issue13411@psf.upfronthosting.co.za>
Message-ID: <1321905422.63.0.780235661643.issue13411@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Fixed, thanks.

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13411>
_______________________________________

From report at bugs.python.org  Mon Nov 21 21:08:03 2011
From: report at bugs.python.org (Eric Snow)
Date: Mon, 21 Nov 2011 20:08:03 +0000
Subject: [issue13402] Document absoluteness of sys.executable
In-Reply-To: <1321289437.84.0.982753479785.issue13402@psf.upfronthosting.co.za>
Message-ID: <1321906083.57.0.132081746504.issue13402@psf.upfronthosting.co.za>


Changes by Eric Snow <ericsnowcurrently at gmail.com>:


----------
nosy: +eric.snow

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13402>
_______________________________________

From report at bugs.python.org  Mon Nov 21 21:12:08 2011
From: report at bugs.python.org (Eric Snow)
Date: Mon, 21 Nov 2011 20:12:08 +0000
Subject: [issue13445] Enable linking the module pysqlite with Berkeley DB SQL
	instead of SQLite
In-Reply-To: <1321894515.42.0.740720237959.issue13445@psf.upfronthosting.co.za>
Message-ID: <1321906328.83.0.0759480290692.issue13445@psf.upfronthosting.co.za>


Changes by Eric Snow <ericsnowcurrently at gmail.com>:


----------
nosy: +eric.snow

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13445>
_______________________________________

From report at bugs.python.org  Mon Nov 21 21:12:37 2011
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 21 Nov 2011 20:12:37 +0000
Subject: [issue10562] Change 'j' for imaginary unit into an 'i'
In-Reply-To: <1290957558.0.0.518903978948.issue10562@psf.upfronthosting.co.za>
Message-ID: <1321906357.12.0.837122652971.issue10562@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

This will not be fixed. For one thing, the letter 'i' or upper case 'I' look too much like digits. The way numbers are parsed either by the language parser (in source code) or by the built-in functions (int, float, complex) should not be localizable or configurable in any way; that's asking for huge disappointments down the road. If you want to parse complex numbers using 'i' instead of 'j', you have plenty of solutions available already.

----------
nosy: +gvanrossum

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10562>
_______________________________________

From report at bugs.python.org  Mon Nov 21 21:12:59 2011
From: report at bugs.python.org (Eric Snow)
Date: Mon, 21 Nov 2011 20:12:59 +0000
Subject: [issue12618] py_compile cannot create files in current directory
In-Reply-To: <1311406971.17.0.312082121474.issue12618@psf.upfronthosting.co.za>
Message-ID: <1321906379.17.0.126911829842.issue12618@psf.upfronthosting.co.za>


Changes by Eric Snow <ericsnowcurrently at gmail.com>:


----------
nosy: +eric.snow

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12618>
_______________________________________

From report at bugs.python.org  Mon Nov 21 21:17:02 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 21 Nov 2011 20:17:02 +0000
Subject: [issue10557] Malformed error message from float()
In-Reply-To: <1290914546.61.0.639677577533.issue10557@psf.upfronthosting.co.za>
Message-ID: <1321906622.73.0.23932055055.issue10557@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
versions: +Python 3.3 -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10557>
_______________________________________

From report at bugs.python.org  Mon Nov 21 21:17:26 2011
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 21 Nov 2011 20:17:26 +0000
Subject: [issue10621] >>> 1 + 2j --> (1 + 2j) and not (1+2j)
In-Reply-To: <1291454509.87.0.00219292943169.issue10621@psf.upfronthosting.co.za>
Message-ID: <1321906646.44.0.577920928162.issue10621@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

@Retro, stop reopening bugs. This is very much a matter of personal taste and the existing way is fine.

----------
resolution: remind -> rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10621>
_______________________________________

From report at bugs.python.org  Mon Nov 21 21:36:32 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 21 Nov 2011 20:36:32 +0000
Subject: [issue12328] multiprocessing's overlapped PipeConnection on Windows
In-Reply-To: <1307991196.59.0.849860111943.issue12328@psf.upfronthosting.co.za>
Message-ID: <E1RSabC-0003Js-Gp@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 08953a04b2e6 by Antoine Pitrou in branch 'default':
Issue #12328: Under Windows, refactor handling of Ctrl-C events and
http://hg.python.org/cpython/rev/08953a04b2e6

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12328>
_______________________________________

From report at bugs.python.org  Mon Nov 21 21:38:27 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 21 Nov 2011 20:38:27 +0000
Subject: [issue12328] multiprocessing's overlapped PipeConnection on Windows
In-Reply-To: <1307991196.59.0.849860111943.issue12328@psf.upfronthosting.co.za>
Message-ID: <1321907907.59.0.589719045777.issue12328@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I've re-added the fast uncontended path in semaphore.c and committed sigint_event.patch. Now I'm gonna take a look at pipe_poll_fix.patch...

----------
stage:  -> patch review
versions:  -Python 2.6, Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12328>
_______________________________________

From report at bugs.python.org  Mon Nov 21 21:53:50 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 21 Nov 2011 20:53:50 +0000
Subject: [issue13448] PEP 3155 implementation
Message-ID: <1321908830.82.0.349913947268.issue13448@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

Here is an issue covering PEP 3155 implementation. Hopefully a "review" link will appear in front of the hg repo URL.

----------
components: Interpreter Core
hgrepos: 91
messages: 148087
nosy: ncoghlan, pitrou
priority: normal
severity: normal
stage: patch review
status: open
title: PEP 3155 implementation
type: feature request
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13448>
_______________________________________

From report at bugs.python.org  Mon Nov 21 21:55:15 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 21 Nov 2011 20:55:15 +0000
Subject: [issue13448] PEP 3155 implementation
In-Reply-To: <1321908830.82.0.349913947268.issue13448@psf.upfronthosting.co.za>
Message-ID: <1321908915.8.0.274881690474.issue13448@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
keywords: +patch
Added file: http://bugs.python.org/file23744/baec10c6dcd4.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13448>
_______________________________________

From report at bugs.python.org  Mon Nov 21 21:55:24 2011
From: report at bugs.python.org (Joshua Root)
Date: Mon, 21 Nov 2011 20:55:24 +0000
Subject: [issue11149] [PATCH] Configure should enable -fwrapv for clang
In-Reply-To: <1297162007.28.0.193963502998.issue11149@psf.upfronthosting.co.za>
Message-ID: <1321908924.94.0.233069530266.issue11149@psf.upfronthosting.co.za>


Joshua Root <josh+python at root.id.au> added the comment:

The fix that was committed doesn't work if CC is a full path like /usr/bin/clang.

----------
nosy: +jmr

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11149>
_______________________________________

From report at bugs.python.org  Mon Nov 21 22:16:14 2011
From: report at bugs.python.org (Ned Deily)
Date: Mon, 21 Nov 2011 21:16:14 +0000
Subject: [issue13445] Enable linking the module pysqlite with Berkeley DB SQL
	instead of SQLite
In-Reply-To: <1321894515.42.0.740720237959.issue13445@psf.upfronthosting.co.za>
Message-ID: <1321910174.84.0.794848019425.issue13445@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Support for Berkeley DB (the bsddb) was removed from the standard library in Python 3 and replaced by a third-party module (bsddb3) listed in PyPI which is better able to keep up with changes in the various BDB releases.  

http://docs.python.org/py3k/whatsnew/3.0.html#library-changes
http://pypi.python.org/pypi/bsddb3/

What would be the reason for bringing back a dependency on BDB into the standard library?  Wouldn't this better be handled in the standalone pysqlite package?

----------
nosy: +jcea, ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13445>
_______________________________________

From report at bugs.python.org  Mon Nov 21 22:18:26 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 21 Nov 2011 21:18:26 +0000
Subject: [issue13448] PEP 3155 implementation
In-Reply-To: <1321908830.82.0.349913947268.issue13448@psf.upfronthosting.co.za>
Message-ID: <1321910306.48.0.239444758482.issue13448@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

I just have a comment: "XXX" should be replaced in "Python 3.3a0  3200 XXX".

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13448>
_______________________________________

From report at bugs.python.org  Mon Nov 21 22:31:19 2011
From: report at bugs.python.org (Lauren Foutz)
Date: Mon, 21 Nov 2011 21:31:19 +0000
Subject: [issue13445] Enable linking the module pysqlite with Berkeley DB SQL
	instead of SQLite
In-Reply-To: <1321894515.42.0.740720237959.issue13445@psf.upfronthosting.co.za>
Message-ID: <1321911079.73.0.151830365609.issue13445@psf.upfronthosting.co.za>


Lauren Foutz <lauren.foutz at gmail.com> added the comment:

Berkeley DB SQL is a separate library from Berkeley DB.  It is an SQL engine that uses the same API as SQLite and uses Berkeley DB as its backend.  The modules that support Berkeley DB lack all of the SQL features and cannot be used to operate on a Berkeley DB SQL databases.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13445>
_______________________________________

From report at bugs.python.org  Mon Nov 21 23:48:07 2011
From: report at bugs.python.org (Ned Deily)
Date: Mon, 21 Nov 2011 22:48:07 +0000
Subject: [issue13371] Some Carbon extensions don't build on OSX 10.7
In-Reply-To: <1320762505.71.0.135818589622.issue13371@psf.upfronthosting.co.za>
Message-ID: <1321915687.95.0.196726825131.issue13371@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

LGTM

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13371>
_______________________________________

From report at bugs.python.org  Tue Nov 22 00:30:40 2011
From: report at bugs.python.org (Giampaolo Rodola')
Date: Mon, 21 Nov 2011 23:30:40 +0000
Subject: [issue13245] sched.py kwargs addition and default time functions
In-Reply-To: <1319310354.56.0.392534213439.issue13245@psf.upfronthosting.co.za>
Message-ID: <1321918240.95.0.789427250895.issue13245@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

I think this should go in.
I'm going to provide a slighly modified version of the attached patch which includes document changes and get rid of some unit tests which are not really necessary in my opinion.

----------
nosy: +giampaolo.rodola

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13245>
_______________________________________

From report at bugs.python.org  Tue Nov 22 00:39:27 2011
From: report at bugs.python.org (Giampaolo Rodola')
Date: Mon, 21 Nov 2011 23:39:27 +0000
Subject: [issue13245] sched.py kwargs addition and default time functions
In-Reply-To: <1319310354.56.0.392534213439.issue13245@psf.upfronthosting.co.za>
Message-ID: <1321918767.15.0.586066430983.issue13245@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

Updated patch in attachment.

----------
Added file: http://bugs.python.org/file23745/issue13245.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13245>
_______________________________________

From report at bugs.python.org  Tue Nov 22 01:19:43 2011
From: report at bugs.python.org (Giampaolo Rodola')
Date: Tue, 22 Nov 2011 00:19:43 +0000
Subject: [issue13449] sched - provide an "async" argument for run() method
Message-ID: <1321921183.77.0.944975657865.issue13449@psf.upfronthosting.co.za>


New submission from Giampaolo Rodola' <g.rodola at gmail.com>:

If True it would run the scheduled functions due to expire soonest (if any) and then return.
This would make sched module usable into asynchronous applications.

----------
messages: 148095
nosy: giampaolo.rodola
priority: normal
severity: normal
status: open
title: sched - provide an "async" argument for run() method
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13449>
_______________________________________

From report at bugs.python.org  Tue Nov 22 01:19:54 2011
From: report at bugs.python.org (Giampaolo Rodola')
Date: Tue, 22 Nov 2011 00:19:54 +0000
Subject: [issue13449] sched - provide an "async" argument for run() method
In-Reply-To: <1321921183.77.0.944975657865.issue13449@psf.upfronthosting.co.za>
Message-ID: <1321921194.87.0.278674225828.issue13449@psf.upfronthosting.co.za>


Changes by Giampaolo Rodola' <g.rodola at gmail.com>:


----------
keywords: +patch
Added file: http://bugs.python.org/file23746/sched-async.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13449>
_______________________________________

From report at bugs.python.org  Tue Nov 22 01:42:36 2011
From: report at bugs.python.org (akira)
Date: Tue, 22 Nov 2011 00:42:36 +0000
Subject: [issue13450] fix ''.format_map test
Message-ID: <1321922556.51.0.541780569618.issue13450@psf.upfronthosting.co.za>


New submission from akira <4kir4.1i at gmail.com>:

It seems that some assertions in Lib/test/test_unicode.py:UnicodeTest.test_format_map do not implement their intent e.g.,

        self.assertRaises(TypeError, '{'.format_map)
        self.assertRaises(TypeError, '}'.format_map)
        self.assertRaises(TypeError, 'a{'.format_map)
        self.assertRaises(TypeError, 'a}'.format_map)
        self.assertRaises(TypeError, '{a'.format_map)
        self.assertRaises(TypeError, '}a'.format_map)

The intent might be to test:

  >>> '{'.format_map({})
  Traceback (most recent call last):
    File "<stdin>", line 1, in <module>
  ValueError: Single '{' encountered in format string

But it actually tests:

  >>> '{'.format_map()
  Traceback (most recent call last):
    File "<stdin>", line 1, in <module>
  TypeError: format_map() takes exactly one argument (0 given)

Provided correct-assertions-in-test_format_map.patch contains additional assertions e.g.,

      self.assertRaises(ValueError, '{'.format_map, {})

Old assertions might be useful so they're left untouched.

----------
components: Tests
files: correct-assertions-in-test_format_map.patch
keywords: patch
messages: 148096
nosy: akira
priority: normal
severity: normal
status: open
title: fix ''.format_map test
versions: Python 3.2, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file23747/correct-assertions-in-test_format_map.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13450>
_______________________________________

From report at bugs.python.org  Tue Nov 22 01:43:05 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 22 Nov 2011 00:43:05 +0000
Subject: [issue13449] sched - provide an "async" argument for run() method
In-Reply-To: <1321921183.77.0.944975657865.issue13449@psf.upfronthosting.co.za>
Message-ID: <1321922585.75.0.759966417789.issue13449@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I think this would be better served by a separate method. You could call it e.g. run_nowait().

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13449>
_______________________________________

From report at bugs.python.org  Tue Nov 22 01:43:32 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 22 Nov 2011 00:43:32 +0000
Subject: [issue13450] fix ''.format_map test
In-Reply-To: <1321922556.51.0.541780569618.issue13450@psf.upfronthosting.co.za>
Message-ID: <1321922612.32.0.607708321904.issue13450@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +eric.smith, rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13450>
_______________________________________

From report at bugs.python.org  Tue Nov 22 01:45:26 2011
From: report at bugs.python.org (akira)
Date: Tue, 22 Nov 2011 00:45:26 +0000
Subject: [issue13450] add assertions to implement the intent in ''.format_map
	test
In-Reply-To: <1321922556.51.0.541780569618.issue13450@psf.upfronthosting.co.za>
Message-ID: <1321922726.54.0.269821161483.issue13450@psf.upfronthosting.co.za>


Changes by akira <4kir4.1i at gmail.com>:


----------
title: fix ''.format_map test -> add assertions to implement the intent in ''.format_map test

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13450>
_______________________________________

From report at bugs.python.org  Tue Nov 22 01:47:29 2011
From: report at bugs.python.org (akira)
Date: Tue, 22 Nov 2011 00:47:29 +0000
Subject: [issue13450] add assertions to implement the intent in ''.format_map
	test
In-Reply-To: <1321922556.51.0.541780569618.issue13450@psf.upfronthosting.co.za>
Message-ID: <1321922849.1.0.548775068419.issue13450@psf.upfronthosting.co.za>


Changes by akira <4kir4.1i at gmail.com>:


Added file: http://bugs.python.org/file23748/correct-assertions-in-test_format_map.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13450>
_______________________________________

From report at bugs.python.org  Tue Nov 22 01:47:47 2011
From: report at bugs.python.org (akira)
Date: Tue, 22 Nov 2011 00:47:47 +0000
Subject: [issue13450] add assertions to implement the intent in ''.format_map
	test
In-Reply-To: <1321922556.51.0.541780569618.issue13450@psf.upfronthosting.co.za>
Message-ID: <1321922867.54.0.464334946265.issue13450@psf.upfronthosting.co.za>


Changes by akira <4kir4.1i at gmail.com>:


Removed file: http://bugs.python.org/file23747/correct-assertions-in-test_format_map.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13450>
_______________________________________

From report at bugs.python.org  Tue Nov 22 01:47:53 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Tue, 22 Nov 2011 00:47:53 +0000
Subject: [issue13405] Add DTrace probes
In-Reply-To: <1321299726.66.0.343368151185.issue13405@psf.upfronthosting.co.za>
Message-ID: <1321922873.98.0.0983953901587.issue13405@psf.upfronthosting.co.za>


Changes by Jes?s Cea Avi?n <jcea at jcea.es>:


Removed file: http://bugs.python.org/file23717/7c1b63f949e7.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13405>
_______________________________________

From report at bugs.python.org  Tue Nov 22 01:48:14 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Tue, 22 Nov 2011 00:48:14 +0000
Subject: [issue13405] Add DTrace probes
In-Reply-To: <1321299726.66.0.343368151185.issue13405@psf.upfronthosting.co.za>
Message-ID: <1321922894.52.0.654301295951.issue13405@psf.upfronthosting.co.za>


Changes by Jes?s Cea Avi?n <jcea at jcea.es>:


Removed file: http://bugs.python.org/file23718/62e7091812bc.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13405>
_______________________________________

From report at bugs.python.org  Tue Nov 22 01:48:15 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 22 Nov 2011 00:48:15 +0000
Subject: [issue13093] Redundant code in PyUnicode_EncodeDecimal()
In-Reply-To: <1317569955.86.0.21646060057.issue13093@psf.upfronthosting.co.za>
Message-ID: <E1RSeWn-0008D7-Cz@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset f29d7d597fae by Victor Stinner in branch '3.2':
Issue #13093: Fix error handling on PyUnicode_EncodeDecimal()
http://hg.python.org/cpython/rev/f29d7d597fae

New changeset bc53c11804ab by Victor Stinner in branch 'default':
(Merge 3.2) Issue #13093: Fix error handling on PyUnicode_EncodeDecimal()
http://hg.python.org/cpython/rev/bc53c11804ab

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13093>
_______________________________________

From report at bugs.python.org  Tue Nov 22 01:48:54 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Tue, 22 Nov 2011 00:48:54 +0000
Subject: [issue13405] Add DTrace probes
In-Reply-To: <1321299726.66.0.343368151185.issue13405@psf.upfronthosting.co.za>
Message-ID: <1321922934.21.0.323475932681.issue13405@psf.upfronthosting.co.za>


Changes by Jes?s Cea Avi?n <jcea at jcea.es>:


Added file: http://bugs.python.org/file23749/c64a284f4309.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13405>
_______________________________________

From report at bugs.python.org  Tue Nov 22 01:52:25 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 22 Nov 2011 00:52:25 +0000
Subject: [issue13093] Redundant code in PyUnicode_EncodeDecimal()
In-Reply-To: <1317569955.86.0.21646060057.issue13093@psf.upfronthosting.co.za>
Message-ID: <E1RSeao-000081-Qb@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 0cd197f13400 by Victor Stinner in branch '2.7':
Issue #13093: Fix error handling on PyUnicode_EncodeDecimal()
http://hg.python.org/cpython/rev/0cd197f13400

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13093>
_______________________________________

From report at bugs.python.org  Tue Nov 22 01:53:09 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 22 Nov 2011 00:53:09 +0000
Subject: [issue8646] PyUnicode_EncodeDecimal is undocumented
In-Reply-To: <1273247945.7.0.702043835904.issue8646@psf.upfronthosting.co.za>
Message-ID: <1321923189.74.0.40761565821.issue8646@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

I added tests for PyUnicode_EncodeDecimal() and PyUnicode_TransformDecimalToASCII() in Python 2.7, 3.2 and 3.3 (see also issue #13093).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8646>
_______________________________________

From report at bugs.python.org  Tue Nov 22 01:54:00 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 22 Nov 2011 00:54:00 +0000
Subject: [issue13093] Redundant code in PyUnicode_EncodeDecimal()
In-Reply-To: <1317569955.86.0.21646060057.issue13093@psf.upfronthosting.co.za>
Message-ID: <1321923240.45.0.0315713239977.issue13093@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

I fixed the issue in Python 2.7, 3.2 and 3.3.

See also the changeset 849e9277906a (Python 3.3).

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13093>
_______________________________________

From report at bugs.python.org  Tue Nov 22 02:00:35 2011
From: report at bugs.python.org (Eric V. Smith)
Date: Tue, 22 Nov 2011 01:00:35 +0000
Subject: [issue13450] add assertions to implement the intent in ''.format_map
	test
In-Reply-To: <1321922556.51.0.541780569618.issue13450@psf.upfronthosting.co.za>
Message-ID: <1321923635.13.0.942548330933.issue13450@psf.upfronthosting.co.za>


Changes by Eric V. Smith <eric at trueblade.com>:


----------
assignee:  -> eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13450>
_______________________________________

From report at bugs.python.org  Tue Nov 22 02:01:12 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Tue, 22 Nov 2011 01:01:12 +0000
Subject: [issue13405] Add DTrace probes
In-Reply-To: <1321299726.66.0.343368151185.issue13405@psf.upfronthosting.co.za>
Message-ID: <1321923672.28.0.485553970746.issue13405@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

New changeset.

New probes:

- "gc-start", "gc-done": Signal Garbage Collection operations. The first get the generation to scan, the second gets the number of objects collected.

- "line": Called in every Python line. Parameters: module, function, linenumber.

- "instance-new-start", "instance-new-done": information about instance creation.

 - Old style classes: get the name of the class, and the name of the module.

 - New style classes: get the name of the class and, IF WE CAN, the name of the module. This is not working 100%.

- "instance-delete-start", "instance-delete-done": information about instance deletion.

 - Old style classes: get the name of the class, and the name of the module.

 - New Style classes: Not working yet.

Shortcomings:

- We don't trace new style instances deletion yet.

- We don't trace most C objects creation/deletion.

- When displaying newstyle instances, the module parameter can be incorrect, for internal types.

 - The "line" probe is called again in the first and last line of a loop when the loop finishes.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13405>
_______________________________________

From report at bugs.python.org  Tue Nov 22 02:03:42 2011
From: report at bugs.python.org (Giampaolo Rodola')
Date: Tue, 22 Nov 2011 01:03:42 +0000
Subject: [issue13451] sched.py: speedup cancel() method
Message-ID: <1321923822.73.0.49972384361.issue13451@psf.upfronthosting.co.za>


New submission from Giampaolo Rodola' <g.rodola at gmail.com>:

<snippet>
# bench.py
import sched, time
events = []
scheduler = sched.scheduler(time.time, time.sleep)
for x in range(4000):
    scheduler.enter(1, 1, lambda: None, ())
t = time.time()
for x in scheduler._queue:
    scheduler.cancel(x)
print(time.time() - t)
</snippet>

Before the patch:
9.433167934417725

After the patch:
1.3120810985565186


I have another approach in mind, which avoids removing the element from the queue immediately, and which should be an order of magnitude faster, but I'll provide that as a separate patch since it poses questions about API and backward compatibility.

----------
files: sched-cancel-speedup.patch
keywords: patch
messages: 148103
nosy: giampaolo.rodola, rhettinger, stutzbach
priority: normal
severity: normal
status: open
title: sched.py: speedup cancel() method
versions: Python 3.3
Added file: http://bugs.python.org/file23750/sched-cancel-speedup.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13451>
_______________________________________

From report at bugs.python.org  Tue Nov 22 02:35:05 2011
From: report at bugs.python.org (Masha Katsman)
Date: Tue, 22 Nov 2011 01:35:05 +0000
Subject: [issue12759] "(?P=)" input for Tools/scripts/redemo.py raises
	unnhandled exception
In-Reply-To: <1313495654.73.0.277709437369.issue12759@psf.upfronthosting.co.za>
Message-ID: <1321925705.92.0.38204509929.issue12759@psf.upfronthosting.co.za>


Masha Katsman <mkatsman at yahoo.com> added the comment:

The problem with the above expression is that it does not specify a group name. The expression itself is not right. So, it blows up when it tries to parse the name. I put the check for the empty name before any processing is done.

----------
Added file: http://bugs.python.org/file23751/patch_for_12759

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12759>
_______________________________________

From report at bugs.python.org  Tue Nov 22 03:13:50 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 22 Nov 2011 02:13:50 +0000
Subject: [issue13451] sched.py: speedup cancel() method
In-Reply-To: <1321923822.73.0.49972384361.issue13451@psf.upfronthosting.co.za>
Message-ID: <1321928030.79.0.0653778398956.issue13451@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Can you post your other patch too?  I would like to review both at the same time.

----------
assignee:  -> rhettinger
components: +Library (Lib)
priority: normal -> low
type:  -> performance

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13451>
_______________________________________

From report at bugs.python.org  Tue Nov 22 03:25:53 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 22 Nov 2011 02:25:53 +0000
Subject: [issue13441] TestEnUSCollation.test_strxfrm() fails on Solaris
In-Reply-To: <1321833496.0.0.544021070577.issue13441@psf.upfronthosting.co.za>
Message-ID: <E1RSg3G-0007WG-Qo@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 6f9af4e3c1db by Victor Stinner in branch 'default':
Issue #13441: Disable temporary the check on the maximum character until
http://hg.python.org/cpython/rev/6f9af4e3c1db

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13441>
_______________________________________

From report at bugs.python.org  Tue Nov 22 06:55:04 2011
From: report at bugs.python.org (rohini)
Date: Tue, 22 Nov 2011 05:55:04 +0000
Subject: [issue13425] http.client.HTTPMessage.getallmatchingheaders() always
	returns []
In-Reply-To: <1321614230.59.0.764469605478.issue13425@psf.upfronthosting.co.za>
Message-ID: <1321941304.13.0.578051439929.issue13425@psf.upfronthosting.co.za>


rohini <rohinivinodh at gmail.com> added the comment:

Please review the attached patch. Like getheaders, getallmatchingheaders would also return (header,value) tuples. It is not backward compatible with 2.7.

----------
keywords: +patch
nosy: +rohini
Added file: http://bugs.python.org/file23752/13425.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13425>
_______________________________________

From report at bugs.python.org  Tue Nov 22 10:03:43 2011
From: report at bugs.python.org (Giampaolo Rodola')
Date: Tue, 22 Nov 2011 09:03:43 +0000
Subject: [issue13451] sched.py: speedup cancel() method
In-Reply-To: <1321923822.73.0.49972384361.issue13451@psf.upfronthosting.co.za>
Message-ID: <1321952623.0.0.90187350522.issue13451@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

In attachment. 

Before the patch:
9.433167934417725

After the patch:
0.0016150474548339844

scheduler.queue and scheduler.empty should be modified in accordance (which I haven't done, it's just to give you an idea).

----------
Added file: http://bugs.python.org/file23753/cancel-later-approach.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13451>
_______________________________________

From report at bugs.python.org  Tue Nov 22 10:57:51 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Tue, 22 Nov 2011 09:57:51 +0000
Subject: [issue13425] http.client.HTTPMessage.getallmatchingheaders() always
	returns []
In-Reply-To: <1321614230.59.0.764469605478.issue13425@psf.upfronthosting.co.za>
Message-ID: <1321955871.24.0.235965843687.issue13425@psf.upfronthosting.co.za>


Changes by Senthil Kumaran <senthil at uthcode.com>:


----------
nosy: +orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13425>
_______________________________________

From report at bugs.python.org  Tue Nov 22 13:12:49 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 22 Nov 2011 12:12:49 +0000
Subject: [issue13245] sched.py kwargs addition and default time functions
In-Reply-To: <1319310354.56.0.392534213439.issue13245@psf.upfronthosting.co.za>
Message-ID: <1321963969.81.0.377176006835.issue13245@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

+1 to kwargs support in sched.  I've also ended up modifying sched.py to support this in the past.

----------
nosy: +mark.dickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13245>
_______________________________________

From report at bugs.python.org  Tue Nov 22 13:19:27 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Tue, 22 Nov 2011 12:19:27 +0000
Subject: [issue13425] http.client.HTTPMessage.getallmatchingheaders() always
	returns []
In-Reply-To: <1321614230.59.0.764469605478.issue13425@psf.upfronthosting.co.za>
Message-ID: <1321964367.8.0.0216065306061.issue13425@psf.upfronthosting.co.za>


Petri Lehtinen <petri at digip.org> added the comment:

getallmatchinheaders() is not documented, i.e. it's not part of the public API. Furthermore, it's only used by http.server.CGIHTTPRequestHandler, and the comment above it even says that it should be moved there.

There are three options now:
1) Document the function to make it officially part of the public API
2) Rename and move the function to http.server
3) Leave it undocumented and just fix it

In any case, the first thing that should be done is to add a test for CGIHTTPRequestHandler that fails with the current (broken) getallmatchinheaders() implementation.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13425>
_______________________________________

From report at bugs.python.org  Tue Nov 22 13:24:49 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 22 Nov 2011 12:24:49 +0000
Subject: [issue13452] PyUnicode_EncodeDecimal: reject error handlers different
	than strict
Message-ID: <1321964689.08.0.0221252575292.issue13452@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

Error handling of PyUnicode_EncodeDecimal() is broken by design. The caller cannot know the size of the output buffer because each error handler produce a variable output, whereas the caller has to allocate 
this buffer and it is not possible to specify the size of the output buffer.

I propose to raise a ValueError if the error handler is different than "strict" and do this change in Python 2.7, 3.2 and 3.3.

In Python 2.7 code base, PyUnicode_EncodeDecimal() is always called with 
errors=NULL. In Python 3.x, the function is no more called.

Attached patch is for Python 3.2.

See also the issue #13093.

----------
components: Unicode
files: encode_decimal_errors.patch
keywords: patch
messages: 148111
nosy: ezio.melotti, haypo, loewis, skrah
priority: normal
severity: normal
status: open
title: PyUnicode_EncodeDecimal: reject error handlers different than strict
versions: Python 2.7, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file23754/encode_decimal_errors.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13452>
_______________________________________

From report at bugs.python.org  Tue Nov 22 13:40:13 2011
From: report at bugs.python.org (Giampaolo Rodola')
Date: Tue, 22 Nov 2011 12:40:13 +0000
Subject: [issue13245] sched.py kwargs addition and default time functions
In-Reply-To: <1319310354.56.0.392534213439.issue13245@psf.upfronthosting.co.za>
Message-ID: <1321965613.38.0.641991029345.issue13245@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

Checked in as f1a21f2e3bec and dc52db0fa2e5.
Thanks.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13245>
_______________________________________

From report at bugs.python.org  Tue Nov 22 13:41:19 2011
From: report at bugs.python.org (Eric V. Smith)
Date: Tue, 22 Nov 2011 12:41:19 +0000
Subject: [issue13450] add assertions to implement the intent in ''.format_map
	test
In-Reply-To: <1321922556.51.0.541780569618.issue13450@psf.upfronthosting.co.za>
Message-ID: <1321965679.35.0.463012977189.issue13450@psf.upfronthosting.co.za>


Eric V. Smith <eric at trueblade.com> added the comment:

I don't think the existing tests have any value. I might leave one of them, but I think I'll just use your new tests instead.

akira: I'd like to add your name to the Misc/ACKS file, if it's not already there. What's your full name?

Thanks for the bug report and patch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13450>
_______________________________________

From report at bugs.python.org  Tue Nov 22 13:53:15 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 22 Nov 2011 12:53:15 +0000
Subject: [issue12759] "(?P=)" input for Tools/scripts/redemo.py raises
	unnhandled exception
In-Reply-To: <1313495654.73.0.277709437369.issue12759@psf.upfronthosting.co.za>
Message-ID: <1321966395.5.0.963374393251.issue12759@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Thanks for the patch!
The patch should also include tests for this case in Lib/test/test_re.py

----------
components: +Regular Expressions
stage: needs patch -> test needed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12759>
_______________________________________

From report at bugs.python.org  Tue Nov 22 14:09:54 2011
From: report at bugs.python.org (Stefan Krah)
Date: Tue, 22 Nov 2011 13:09:54 +0000
Subject: [issue13452] PyUnicode_EncodeDecimal: reject error handlers different
	than strict
In-Reply-To: <1321964689.08.0.0221252575292.issue13452@psf.upfronthosting.co.za>
Message-ID: <1321967394.93.0.475122321631.issue13452@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

I'm only using the function with the NULL error handler. If I had
to use 'xmlcharrefreplace', presumably I'd overallocate 'output'
for the worst case scenario: sizeof("&#4294967295") per encoded
character.

It's hard to tell if people are using this feature. PyUnicode_EncodeDecimal()
was always undocumented (#8646), but part of the official Unicode API.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13452>
_______________________________________

From report at bugs.python.org  Tue Nov 22 14:16:53 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 22 Nov 2011 13:16:53 +0000
Subject: [issue13453] Tests and network timeouts
Message-ID: <1321967813.33.0.280179416852.issue13453@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

A lot of tests using the network are failing sometimes. They look like timeout or network failure.

Example:

======================================================================
ERROR: test_storlines (test.test_ftplib.TestTLS_FTPClassMixin)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/var/lib/buildbot/buildarea/3.x.warsaw-ubuntu-arm/build/Lib/test/test_ftplib.py", line 582, in test_storlines
    self.client.storlines('stor', f)
  File "/var/lib/buildbot/buildarea/3.x.warsaw-ubuntu-arm/build/Lib/ftplib.py", line 824, in storlines
    conn.unwrap()
  File "/var/lib/buildbot/buildarea/3.x.warsaw-ubuntu-arm/build/Lib/ssl.py", line 448, in unwrap
    s = self._sslobj.shutdown()
socket.timeout: The read operation timed out

----------
components: Tests
messages: 148116
nosy: haypo
priority: normal
severity: normal
status: open
title: Tests and network timeouts
versions: Python 2.7, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13453>
_______________________________________

From report at bugs.python.org  Tue Nov 22 14:18:49 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Tue, 22 Nov 2011 13:18:49 +0000
Subject: [issue13453] Tests and network timeouts
In-Reply-To: <1321967813.33.0.280179416852.issue13453@psf.upfronthosting.co.za>
Message-ID: <1321967929.45.0.212376290545.issue13453@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/issue13453>
_______________________________________

From report at bugs.python.org  Tue Nov 22 15:37:07 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 22 Nov 2011 14:37:07 +0000
Subject: [issue10318] "make altinstall" installs many files with incorrect
	shebangs
In-Reply-To: <1288926610.35.0.932494150274.issue10318@psf.upfronthosting.co.za>
Message-ID: <1321972627.97.0.718346349827.issue10318@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Patch to PEP 8 attached.

----------
Added file: http://bugs.python.org/file23755/pep8-shebangs.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10318>
_______________________________________

From report at bugs.python.org  Tue Nov 22 16:08:05 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 22 Nov 2011 15:08:05 +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: <1321974485.32.0.570335736129.issue12424@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Does your latest patch address my second review?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12424>
_______________________________________

From report at bugs.python.org  Tue Nov 22 16:08:45 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 22 Nov 2011 15:08:45 +0000
Subject: [issue13440] Explain the "status quo wins a stalemate" principle in
	the devguide
In-Reply-To: <1321833284.75.0.438515825131.issue13440@psf.upfronthosting.co.za>
Message-ID: <1321974525.81.0.642202556741.issue13440@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

+1

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13440>
_______________________________________

From report at bugs.python.org  Tue Nov 22 16:13:40 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 22 Nov 2011 15:13:40 +0000
Subject: [issue13443] wrong links and examples in the functional HOWTO
In-Reply-To: <1321850404.45.0.767133152656.issue13443@psf.upfronthosting.co.za>
Message-ID: <1321974820.29.0.641087261311.issue13443@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Broken links should obviously be fixed, either to their newer location if it can be found or to Web Archive links.

I think that it?s a good thing to link to some outside articles and code from the official docs; we acknowledge that the stdlib is not the whole of the Python world and we put good writings/code into the spotlight.  Here, even if the code is 2.x-only, the ideas and examples it contains can IMO still be valuable for readers, even if they can?t be directly used, so my vote is to keep them.

----------
nosy: +eric.araujo, rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13443>
_______________________________________

From report at bugs.python.org  Tue Nov 22 16:16:07 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 22 Nov 2011 15:16:07 +0000
Subject: [issue6135] subprocess seems to use local 8-bit encoding and gives no
	choice
In-Reply-To: <1243494524.57.0.870766192683.issue6135@psf.upfronthosting.co.za>
Message-ID: <1321974967.2.0.584318398461.issue6135@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/issue6135>
_______________________________________

From report at bugs.python.org  Tue Nov 22 16:25:33 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 22 Nov 2011 15:25:33 +0000
Subject: [issue13448] PEP 3155 implementation
In-Reply-To: <1321908830.82.0.349913947268.issue13448@psf.upfronthosting.co.za>
Message-ID: <1321975533.27.0.39406947369.issue13448@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Nothing to say; waiting for a doc update.

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13448>
_______________________________________

From report at bugs.python.org  Tue Nov 22 16:27:52 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 22 Nov 2011 15:27:52 +0000
Subject: [issue13224] Change str(x) to return only __qualname__ for some types
In-Reply-To: <1319053532.35.0.636674659737.issue13224@psf.upfronthosting.co.za>
Message-ID: <1321975672.22.0.0542036079957.issue13224@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

PEP 3155 is accepted and makes str(cls) and str(function) as well as repr(cls) and repr(function) return the qualified name, which obsoletes part of this request.  I haven?t checked if it has the same problem with Python methods.  str(module) is not changed by the PEP.

----------
title: Change str(class) to return only the class name -> Change str(x) to return only __qualname__ for some types

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13224>
_______________________________________

From report at bugs.python.org  Tue Nov 22 16:30:45 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 22 Nov 2011 15:30:45 +0000
Subject: [issue3932] HTMLParser cannot handle '&' and non-ascii characters in
	attribute names
In-Reply-To: <1222086790.7.0.800001604957.issue3932@psf.upfronthosting.co.za>
Message-ID: <1321975845.2.0.658613936983.issue3932@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

+1 on refusing the temptation to guess and to be half-working for some cases by accident.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3932>
_______________________________________

From report at bugs.python.org  Tue Nov 22 17:10:45 2011
From: report at bugs.python.org (Pyry Pakkanen)
Date: Tue, 22 Nov 2011 16:10:45 +0000
Subject: [issue13454] crash when deleting one pair from tee()
Message-ID: <1321978245.14.0.0332901316698.issue13454@psf.upfronthosting.co.za>


New submission from Pyry Pakkanen <frostburn at suomi24.fi>:

Running the following results in a Segmentation fault on Ubuntu 11.10 64-bit with both python and python3.

from itertools import *
c = count()
a,b = tee(c)
for i in range(10000000):
 next(a)
del(b)

----------
messages: 148124
nosy: PyryP
priority: normal
severity: normal
status: open
title: crash when deleting one pair from tee()
type: crash
versions: Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13454>
_______________________________________

From report at bugs.python.org  Tue Nov 22 17:22:33 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 22 Nov 2011 16:22:33 +0000
Subject: [issue13454] crash when deleting one pair from tee()
In-Reply-To: <1321978245.14.0.0332901316698.issue13454@psf.upfronthosting.co.za>
Message-ID: <1321978953.43.0.329916871926.issue13454@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

tee() uses a linked-list of teedataobject. This list is destroyed by recursive calls to teedataobject_dealloc().

Extract of the gdb trace:

#5  0x08171a8e in teedataobject_clear (tdo=0xad21b394) at ./Modules/itertoolsmodule.c:412
#6  0x08171b39 in teedataobject_dealloc (tdo=0xad21b394) at ./Modules/itertoolsmodule.c:421
#7  0x0805ed3d in _Py_Dealloc (op=<itertools.tee_dataobject at remote 0xad21b394>) at Objects/object.c:1676
#8  0x08171b16 in teedataobject_clear (tdo=0xad21b274) at ./Modules/itertoolsmodule.c:413
#9  0x08171b39 in teedataobject_dealloc (tdo=0xad21b274) at ./Modules/itertoolsmodule.c:421
#10 0x0805ed3d in _Py_Dealloc (op=<itertools.tee_dataobject at remote 0xad21b274>) at Objects/object.c:1676
#11 0x08171b16 in teedataobject_clear (tdo=0xad21b154) at ./Modules/itertoolsmodule.c:413
#12 0x08171b39 in teedataobject_dealloc (tdo=0xad21b154) at ./Modules/itertoolsmodule.c:421
#13 0x0805ed3d in _Py_Dealloc (op=<itertools.tee_dataobject at remote 0xad21b154>) at Objects/object.c:1676
#14 0x08171b16 in teedataobject_clear (tdo=0xad21b034) at ./Modules/itertoolsmodule.c:413
#15 0x08171b39 in teedataobject_dealloc (tdo=0xad21b034) at ./Modules/itertoolsmodule.c:421
#16 0x0805ed3d in _Py_Dealloc (op=<itertools.tee_dataobject at remote 0xad21b034>) at Objects/object.c:1676
#17 0x08171b16 in teedataobject_clear (tdo=0xad292ed4) at ./Modules/itertoolsmodule.c:413
#18 0x08171b39 in teedataobject_dealloc (tdo=0xad292ed4) at ./Modules/itertoolsmodule.c:421
#19 0x0805ed3d in _Py_Dealloc (op=<itertools.tee_dataobject at remote 0xad292ed4>) at Objects/object.c:1676
#20 0x08171b16 in teedataobject_clear (tdo=0xad292db4) at ./Modules/itertoolsmodule.c:413
#21 0x08171b39 in teedataobject_dealloc (tdo=0xad292db4) at ./Modules/itertoolsmodule.c:421
#22 0x0805ed3d in _Py_Dealloc (op=<itertools.tee_dataobject at remote 0xad292db4>) at Objects/object.c:1676
#23 0x08171b16 in teedataobject_clear (tdo=0xad292c94) at ./Modules/itertoolsmodule.c:413

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13454>
_______________________________________

From report at bugs.python.org  Tue Nov 22 17:24:14 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 22 Nov 2011 16:24:14 +0000
Subject: [issue13454] crash when deleting one pair from tee()
In-Reply-To: <1321978245.14.0.0332901316698.issue13454@psf.upfronthosting.co.za>
Message-ID: <1321979054.36.0.0759499543477.issue13454@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Confirmed on py3k, it doesn't seem to happen with smaller values.

----------
components: +Extension Modules
nosy: +ezio.melotti, rhettinger
stage:  -> test needed
versions: +Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13454>
_______________________________________

From report at bugs.python.org  Tue Nov 22 17:28:15 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 22 Nov 2011 16:28:15 +0000
Subject: [issue13454] crash when deleting one pair from tee()
In-Reply-To: <1321978245.14.0.0332901316698.issue13454@psf.upfronthosting.co.za>
Message-ID: <1321979295.37.0.834768057774.issue13454@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Also, a check for NULL would not hurt in tee_next():

diff -r 1e0e821d2626 Modules/itertoolsmodule.c
--- a/Modules/itertoolsmodule.c	Fri Nov 04 22:17:45 2011 +0100
+++ b/Modules/itertoolsmodule.c	Tue Nov 22 17:24:42 2011 +0100
@@ -475,6 +475,8 @@
 
     if (to->index >= LINKCELLS) {
         link = teedataobject_jumplink(to->dataobj);
+        if (link == NULL)
+            return NULL;
         Py_DECREF(to->dataobj);
         to->dataobj = (teedataobject *)link;
         to->index = 0;

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13454>
_______________________________________

From report at bugs.python.org  Tue Nov 22 17:47:17 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Tue, 22 Nov 2011 16:47:17 +0000
Subject: [issue13405] Add DTrace probes
In-Reply-To: <1321299726.66.0.343368151185.issue13405@psf.upfronthosting.co.za>
Message-ID: <1321980437.22.0.424162643999.issue13405@psf.upfronthosting.co.za>


Changes by Jes?s Cea Avi?n <jcea at jcea.es>:


Added file: http://bugs.python.org/file23756/750ca6da48f3.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13405>
_______________________________________

From report at bugs.python.org  Tue Nov 22 17:47:32 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Tue, 22 Nov 2011 16:47:32 +0000
Subject: [issue13405] Add DTrace probes
In-Reply-To: <1321299726.66.0.343368151185.issue13405@psf.upfronthosting.co.za>
Message-ID: <1321980452.96.0.0809996813244.issue13405@psf.upfronthosting.co.za>


Changes by Jes?s Cea Avi?n <jcea at jcea.es>:


Removed file: http://bugs.python.org/file23749/c64a284f4309.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13405>
_______________________________________

From report at bugs.python.org  Tue Nov 22 17:52:01 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Tue, 22 Nov 2011 16:52:01 +0000
Subject: [issue13405] Add DTrace probes
In-Reply-To: <1321299726.66.0.343368151185.issue13405@psf.upfronthosting.co.za>
Message-ID: <1321980721.37.0.901250213286.issue13405@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

- Line tracing is more efficient and corretly skip the last body line when the loop is done.

- Trace new style classes deletion.

- When creating new style classes, ignore internal classes. Show only user defined classes.

- Solve a possible crash if we are tracing "instance-delete-done" and the deleted instance cascades a class delete (if it was the last reference to the class).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13405>
_______________________________________

From report at bugs.python.org  Tue Nov 22 17:55:10 2011
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 22 Nov 2011 16:55:10 +0000
Subject: [issue13224] Change str(x) to return only __qualname__ for some types
In-Reply-To: <1321975672.22.0.0542036079957.issue13224@psf.upfronthosting.co.za>
Message-ID: <CAP7+vJJ_joD+XdgDszV3U+rhueLtALnm_1O8Xt7q18ANHNB9vA@mail.gmail.com>


Guido van Rossum <guido at python.org> added the comment:

Are you sure? The way I read the PEP, it just said that str(cls) and
str(func) should *use* qualname. That could mean returning '<function
f.g.h at 0x1234>' or '<class '__main__.C.D>'.

On Tue, Nov 22, 2011 at 7:27 AM, ?ric Araujo <report at bugs.python.org> wrote:
>
> ?ric Araujo <merwok at netwok.org> added the comment:
>
> PEP 3155 is accepted and makes str(cls) and str(function) as well as repr(cls) and repr(function) return the qualified name, which obsoletes part of this request. ?I haven?t checked if it has the same problem with Python methods. ?str(module) is not changed by the PEP.
>
> ----------
> title: Change str(class) to return only the class name -> Change str(x) to return only __qualname__ for some types
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue13224>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13224>
_______________________________________

From report at bugs.python.org  Tue Nov 22 18:28:51 2011
From: report at bugs.python.org (akira)
Date: Tue, 22 Nov 2011 17:28:51 +0000
Subject: [issue13450] add assertions to implement the intent in ''.format_map
	test
In-Reply-To: <1321922556.51.0.541780569618.issue13450@psf.upfronthosting.co.za>
Message-ID: <1321982931.39.0.960587909158.issue13450@psf.upfronthosting.co.za>


akira <4kir4.1i at gmail.com> added the comment:

TypeError tests can check that an implementation raises a correct exception type i.e., it doesn't raise ValueError prematurely on invalid format_string without checking that there is mapping argument.

METH_O does it for CPython. I'm not sure how other implementations might behave.

eric: I'd read http://docs.python.org/devguide/patch.html#preparation but I thought 4 lines are not worth it to change Misc/ACKS. Full pseudonym: Akira Li

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13450>
_______________________________________

From report at bugs.python.org  Tue Nov 22 18:55:55 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 22 Nov 2011 17:55:55 +0000
Subject: [issue13455] Reorganize tracker docs in the devguide
Message-ID: <1321984554.54.0.834071786299.issue13455@psf.upfronthosting.co.za>


New submission from Ezio Melotti <ezio.melotti at gmail.com>:

The documentation about the bug tracker is sparse in a few different places.  The devguide contains 4 pages:
 1. http://docs.python.org/devguide/helptriage.html
 2. http://docs.python.org/devguide/devrole.html
 3. http://docs.python.org/devguide/triaging.html
 4. http://docs.python.org/devguide/languishing.html

There are two wiki pages:
 5. http://wiki.python.org/moin/SubmittingBugs
 6. http://wiki.python.org/moin/TrackerDocs/

And an additional page in the official docs:
 7. http://docs.python.org/dev/py3k/bugs.html

Some content is duplicated, 5 and 7 are similar, and 6 has the same content of 3 and 2.

The idea is to have 2 pages about the tracker in the devguide:
 * A new "tracker.rst" page that includes all the information about the tracker except the description of the fields;
 * The old "triaging.rst", that only describes the meaning of the fields.

The attached patch groups this information in the new page, removing the old pages (1, 2, 4) and updating the index and toc.

The content of the wiki pages (5 and 6) should be deleted and a pointer to the devguide should be added instead.
The bugs page in the docs (7) should not contain all the steps necessary to register and open an issue IMHO, but just a short description and a link to the devguide.

Currently the structure of the new page is:
tracker.rst
  +-- Using the Issue Tracker
  |     +-- Checking if a bug already exists
  |     +-- Reporting an issue
  |
  +-- Helping Triage Issues
  |     +-- Classifying Reports
  |     +-- Reviewing Patches
  |     +-- Finding an Issue You Can Help With
  |     +-- Gaining the "Developer" Role on the Issue Tracker
  |
  +-- The Meta Tracker

I mostly copy/pasted from other pages (e.g. "Using the Issue Tracker" is copied from 7), so this should be reorganized a bit.
The things I would like to include here are:
 * how to search issues
 * how to report a new issue
 * how to classify issues
 * how to make reviews
 * how to find interesting issues
 * how to get the developer role
 * how to use the keyboard shortcuts

It might be better to just list all these things, or group them in "basic" (searching/reporting) and "advanced" (everything else), or keep a step by step "how to report a bug" separate and just describe specific tasks here (like "how to register/login/report").

----------
assignee: ezio.melotti
components: Devguide
files: issue13455.diff
keywords: patch
messages: 148131
nosy: brett.cannon, eli.bendersky, eric.araujo, ezio.melotti, ncoghlan, terry.reedy
priority: normal
severity: normal
stage: needs patch
status: open
title: Reorganize tracker docs in the devguide
Added file: http://bugs.python.org/file23757/issue13455.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13455>
_______________________________________

From report at bugs.python.org  Tue Nov 22 18:56:55 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 22 Nov 2011 17:56:55 +0000
Subject: [issue13093] Redundant code in PyUnicode_EncodeDecimal()
In-Reply-To: <1317569955.86.0.21646060057.issue13093@psf.upfronthosting.co.za>
Message-ID: <E1RSuaH-0006gp-Be@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 52fecdc1c5d8 by Charles-Fran?ois Natali in branch 'default':
Issue #13093: Perform a real merge.
http://hg.python.org/cpython/rev/52fecdc1c5d8

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13093>
_______________________________________

From report at bugs.python.org  Tue Nov 22 18:56:55 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 22 Nov 2011 17:56:55 +0000
Subject: [issue12156] test_multiprocessing.test_notify_all() timeout (1 hour)
	on FreeBSD 7.2
In-Reply-To: <1306147254.92.0.286085135906.issue12156@psf.upfronthosting.co.za>
Message-ID: <E1RSuaH-0006gp-BU@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset ed2d3680f489 by Charles-Fran?ois Natali in branch '2.7':
Issue #12156: Skip test_multiprocessing on systems which don't support enough
http://hg.python.org/cpython/rev/ed2d3680f489

New changeset 311bb5e65b02 by Charles-Fran?ois Natali in branch '3.2':
Issue #12156: Skip test_multiprocessing on systems which don't support enough
http://hg.python.org/cpython/rev/311bb5e65b02

New changeset 439ac346b20b by Charles-Fran?ois Natali in branch 'default':
Issue #12156: Skip test_multiprocessing on systems which don't support enough
http://hg.python.org/cpython/rev/439ac346b20b

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12156>
_______________________________________

From report at bugs.python.org  Tue Nov 22 19:52:20 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 22 Nov 2011 18:52:20 +0000
Subject: [issue13156] _PyGILState_Reinit assumes auto thread state will always
	exist which is not true.
In-Reply-To: <1318401227.21.0.161699609918.issue13156@psf.upfronthosting.co.za>
Message-ID: <E1RSvRp-00047A-E3@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset ba90839c4993 by Charles-Fran?ois Natali in branch '3.2':
Issue #13156: _PyGILState_Reinit(): Re-associate the auto thread state with the
http://hg.python.org/cpython/rev/ba90839c4993

New changeset aa6ce09d2350 by Charles-Fran?ois Natali in branch 'default':
Issue #13156: _PyGILState_Reinit(): Re-associate the auto thread state with the
http://hg.python.org/cpython/rev/aa6ce09d2350

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13156>
_______________________________________

From report at bugs.python.org  Tue Nov 22 19:54:50 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Tue, 22 Nov 2011 18:54:50 +0000
Subject: [issue13156] _PyGILState_Reinit assumes auto thread state will always
	exist which is not true.
In-Reply-To: <1318401227.21.0.161699609918.issue13156@psf.upfronthosting.co.za>
Message-ID: <1321988090.88.0.308829313173.issue13156@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

Alright, should be fixed now.
Graham, thanks for the report!

----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13156>
_______________________________________

From report at bugs.python.org  Tue Nov 22 20:02:14 2011
From: report at bugs.python.org (R. David Murray)
Date: Tue, 22 Nov 2011 19:02:14 +0000
Subject: [issue13456] Providing a custom HTTPResponse class to HTTPConnection
Message-ID: <1321988533.96.0.72454390842.issue13456@psf.upfronthosting.co.za>


New submission from R. David Murray <rdmurray at bitdance.com>:

The doc string for HTTPConnection.getresponse mentions (in broken English) that the instance's response_class attribute determines what class gets instantiated for a response.  The docs do not mention this attribute, nor any other way to control what class is used.

Since this attribute already exists and is mentioned in the doc string, can we consider this a doc error and just document it?

----------
assignee: docs at python
components: Documentation
messages: 148136
nosy: docs at python, orsenthil, r.david.murray
priority: normal
severity: normal
status: open
title: Providing a custom HTTPResponse class to HTTPConnection
versions: Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13456>
_______________________________________

From report at bugs.python.org  Tue Nov 22 20:02:43 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 22 Nov 2011 19:02:43 +0000
Subject: [issue13455] Reorganize tracker docs in the devguide
In-Reply-To: <1321984554.54.0.834071786299.issue13455@psf.upfronthosting.co.za>
Message-ID: <1321988563.0.0.00249533404507.issue13455@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I think the reason these docs are scattered is that the devguide is a guide, not a reference manual. I don't think this patch makes sense: if the tracker really needed so much text to explain how it works, then the tracker would have a severe UI problem. Most people use bug trackers without ever reading a manual first.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13455>
_______________________________________

From report at bugs.python.org  Tue Nov 22 20:15:59 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Tue, 22 Nov 2011 19:15:59 +0000
Subject: [issue13455] Reorganize tracker docs in the devguide
In-Reply-To: <1321984554.54.0.834071786299.issue13455@psf.upfronthosting.co.za>
Message-ID: <1321989359.84.0.0441169740063.issue13455@psf.upfronthosting.co.za>


Petri Lehtinen <petri at digip.org> added the comment:

It seems to me there's not that much text on how the tracker itself works. Only sections "Checking if a bug already exists" and "Reporting an issue" have this kind of information. The text in these sections seems to be mostly from http://docs.python.org/bugs.html, so it's not new content.

Other sections mostly deal with the way the tracker is used or should be used for the development of CPython.

I like the idea of this patch. As Antoine said, people usually know how to use web applications nowadays, so moving the info from http://docs.python.org/bugs.html to devguide (replacing it with a shorter description) sounds good.

----------
nosy: +petri.lehtinen

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13455>
_______________________________________

From report at bugs.python.org  Tue Nov 22 21:10:37 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Tue, 22 Nov 2011 20:10:37 +0000
Subject: [issue13425] http.client.HTTPMessage.getallmatchingheaders() always
	returns []
In-Reply-To: <1321614230.59.0.764469605478.issue13425@psf.upfronthosting.co.za>
Message-ID: <1321992637.52.0.129957883728.issue13425@psf.upfronthosting.co.za>


Petri Lehtinen <petri at digip.org> added the comment:

4) Deprecate the function to be removed in 3.4 or 3.5 and "fix" it to always return [].

This way we won't break any 3.0-3.2 code that is using the function, but the users of such code will start to get DeprecationWarnings in 3.3.

There's no meaningful way to fix the function correctly, as the original header data isn't stored anywhere in HTTPMessage or its base class email.message.Message. The function is also obsolete: the get_all() method of email.message.Message can be used.

@stachjankowski: How did you find this issue? Are you porting from 2.x to 3.x or have new 3.x code that uses this function?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13425>
_______________________________________

From report at bugs.python.org  Tue Nov 22 21:28:56 2011
From: report at bugs.python.org (Ram Rachum)
Date: Tue, 22 Nov 2011 20:28:56 +0000
Subject: [issue13457] Display module name as string in `ImportError`
Message-ID: <1321993736.11.0.640426182551.issue13457@psf.upfronthosting.co.za>


New submission from Ram Rachum <ram at rachum.com>:

Recently I was confronted with a mysterious error:

    ImportError: No module named datetime

Firther investigation revealed that the cause was a pickling problem that ran `__import__('datetime\r')`.

If `ImportError` would have shown the module name as a string, there would be no ambiguity:

    ImportError: No module named 'datetime\r'

----------
components: Interpreter Core
messages: 148140
nosy: cool-RR
priority: normal
severity: normal
status: open
title: Display module name as string in `ImportError`
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13457>
_______________________________________

From report at bugs.python.org  Tue Nov 22 21:29:04 2011
From: report at bugs.python.org (Ram Rachum)
Date: Tue, 22 Nov 2011 20:29:04 +0000
Subject: [issue13457] Display module name as string in `ImportError`
In-Reply-To: <1321993736.11.0.640426182551.issue13457@psf.upfronthosting.co.za>
Message-ID: <1321993744.64.0.565467003737.issue13457@psf.upfronthosting.co.za>


Changes by Ram Rachum <ram at rachum.com>:


----------
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13457>
_______________________________________

From report at bugs.python.org  Tue Nov 22 21:32:22 2011
From: report at bugs.python.org (Brian Curtin)
Date: Tue, 22 Nov 2011 20:32:22 +0000
Subject: [issue13457] Display module name as string in `ImportError`
In-Reply-To: <1321993736.11.0.640426182551.issue13457@psf.upfronthosting.co.za>
Message-ID: <1321993942.96.0.441898822775.issue13457@psf.upfronthosting.co.za>


Brian Curtin <brian at python.org> added the comment:

3.3 will be adding an attribute which would have "datetime\r" here. See #1559549, which might make this a duplicate.

You shouldn't (have to) rely on parsing the exception string.

----------
nosy: +brian.curtin

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13457>
_______________________________________

From report at bugs.python.org  Tue Nov 22 21:32:50 2011
From: report at bugs.python.org (Brian Curtin)
Date: Tue, 22 Nov 2011 20:32:50 +0000
Subject: [issue10854] Output .pyd name in error message of ImportError when
	DLL load fails
In-Reply-To: <1294415325.09.0.315523226252.issue10854@psf.upfronthosting.co.za>
Message-ID: <1321993970.6.0.881445697447.issue10854@psf.upfronthosting.co.za>


Changes by Brian Curtin <brian at python.org>:


----------
assignee:  -> brian.curtin

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10854>
_______________________________________

From report at bugs.python.org  Tue Nov 22 21:34:14 2011
From: report at bugs.python.org (Ram Rachum)
Date: Tue, 22 Nov 2011 20:34:14 +0000
Subject: [issue13457] Display module name as string in `ImportError`
In-Reply-To: <1321993736.11.0.640426182551.issue13457@psf.upfronthosting.co.za>
Message-ID: <1321994054.75.0.719358066453.issue13457@psf.upfronthosting.co.za>


Changes by Ram Rachum <ram at rachum.com>:


----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13457>
_______________________________________

From report at bugs.python.org  Tue Nov 22 21:41:15 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 22 Nov 2011 20:41:15 +0000
Subject: [issue13452] PyUnicode_EncodeDecimal: reject error handlers different
	than strict
In-Reply-To: <1321964689.08.0.0221252575292.issue13452@psf.upfronthosting.co.za>
Message-ID: <1321994475.71.0.0790859107083.issue13452@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> I'm only using the function with the NULL error handler.

I don't think that anyone uses it without something else. The function is used to prepare a string input for a function converting a string to an integer. I don't see how xmlcharrefreplace can be useful.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13452>
_______________________________________

From report at bugs.python.org  Tue Nov 22 22:02:30 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 22 Nov 2011 21:02:30 +0000
Subject: [issue13436] compile() doesn't work on ImportFrom with level=None
In-Reply-To: <1321747479.31.0.688458511993.issue13436@psf.upfronthosting.co.za>
Message-ID: <E1RSxTr-0007vp-JM@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset ffcdfc534942 by Amaury Forgeot d'Arc in branch '3.2':
Issue #13436: Fix a bogus error message when an AST object was passed
http://hg.python.org/cpython/rev/ffcdfc534942

New changeset 470f7d7c57ce by Amaury Forgeot d'Arc in branch '3.2':
Issue #13436: commit regenerated Python-ast.c
http://hg.python.org/cpython/rev/470f7d7c57ce

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13436>
_______________________________________

From report at bugs.python.org  Tue Nov 22 22:04:59 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 22 Nov 2011 21:04:59 +0000
Subject: [issue13436] compile() doesn't work on ImportFrom with level=None
In-Reply-To: <1321747479.31.0.688458511993.issue13436@psf.upfronthosting.co.za>
Message-ID: <1321995899.81.0.0481003219769.issue13436@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

I fixed the bogus error message, but "level=None" is still not allowed, whereas the docs promise that optional values can be None.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13436>
_______________________________________

From report at bugs.python.org  Tue Nov 22 22:22:07 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 22 Nov 2011 21:22:07 +0000
Subject: [issue13415] del os.environ[key] ignores errors
In-Reply-To: <1321481687.96.0.070295281604.issue13415@psf.upfronthosting.co.za>
Message-ID: <E1RSxmr-0001HA-5A@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 3e892f428278 by Victor Stinner in branch '3.2':
Issue #13415: os.unsetenv() doesn't ignore errors anymore.
http://hg.python.org/cpython/rev/3e892f428278

New changeset aa55b7dc43f7 by Victor Stinner in branch 'default':
(Merge 3.2) Issue #13415: os.unsetenv() doesn't ignore errors anymore.
http://hg.python.org/cpython/rev/aa55b7dc43f7

New changeset 53cf6f9f374e by Victor Stinner in branch '2.7':
Issue #13415: os.unsetenv() doesn't ignore errors anymore.
http://hg.python.org/cpython/rev/53cf6f9f374e

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13415>
_______________________________________

From report at bugs.python.org  Tue Nov 22 22:30:59 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 22 Nov 2011 21:30:59 +0000
Subject: [issue13436] compile() doesn't work on ImportFrom with level=None
In-Reply-To: <1321747479.31.0.688458511993.issue13436@psf.upfronthosting.co.za>
Message-ID: <E1RSxvQ-0001zU-Qm@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 2e5506d9a079 by Victor Stinner in branch '3.2':
Issue #13436: Fix unsetenv() test on Windows
http://hg.python.org/cpython/rev/2e5506d9a079

New changeset 029ad97883ef by Victor Stinner in branch 'default':
(Merge 3.2) Issue #13436: Fix unsetenv() test on Windows
http://hg.python.org/cpython/rev/029ad97883ef

New changeset e66ef9fa55de by Victor Stinner in branch '2.7':
Issue #13436: Fix unsetenv() test on Windows
http://hg.python.org/cpython/rev/e66ef9fa55de

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13436>
_______________________________________

From report at bugs.python.org  Tue Nov 22 22:35:16 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 22 Nov 2011 21:35:16 +0000
Subject: [issue13453] Tests and network timeouts
In-Reply-To: <1321967813.33.0.280179416852.issue13453@psf.upfronthosting.co.za>
Message-ID: <1321997716.47.0.576811612872.issue13453@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

test_urllib2net
test test_urllib2net failed -- Traceback (most recent call last):
  File "/usr/home/buildbot/buildarea/2.7.krah-freebsd/build/Lib/test/test_urllib2net.py", line 195, in test_sites_no_connection_close
    req = urllib2.urlopen(URL)
  File "/usr/home/buildbot/buildarea/2.7.krah-freebsd/build/Lib/urllib2.py", line 126, in urlopen
    return _opener.open(url, data, timeout)
  File "/usr/home/buildbot/buildarea/2.7.krah-freebsd/build/Lib/urllib2.py", line 394, in open
    response = self._open(req, data)
  File "/usr/home/buildbot/buildarea/2.7.krah-freebsd/build/Lib/urllib2.py", line 412, in _open
    '_open', req)
  File "/usr/home/buildbot/buildarea/2.7.krah-freebsd/build/Lib/urllib2.py", line 372, in _call_chain
    result = func(*args)
  File "/usr/home/buildbot/buildarea/2.7.krah-freebsd/build/Lib/urllib2.py", line 1201, in http_open
    return self.do_open(httplib.HTTPConnection, req)
  File "/usr/home/buildbot/buildarea/2.7.krah-freebsd/build/Lib/urllib2.py", line 1171, in do_open
    raise URLError(err)
URLError: <urlopen error [Errno 4] Non-recoverable failure in name resolution>

Re-running test 'test_urllib2net' in verbose mode
test_custom_headers (test.test_urllib2net.OtherNetworkTests) ... ok
test_file (test.test_urllib2net.OtherNetworkTests) ... ok
test_fileno (test.test_urllib2net.OtherNetworkTests) ... ok
test_ftp (test.test_urllib2net.OtherNetworkTests) ... ok
test_sites_no_connection_close (test.test_urllib2net.OtherNetworkTests) ... ok
test_urlwithfrag (test.test_urllib2net.OtherNetworkTests) ... ok
test_close (test.test_urllib2net.CloseSocketTest) ... ok
test_ftp_basic (test.test_urllib2net.TimeoutTest) ... ok
test_ftp_default_timeout (test.test_urllib2net.TimeoutTest) ... ok
test_ftp_no_timeout (test.test_urllib2net.TimeoutTest) ... ok
test_ftp_timeout (test.test_urllib2net.TimeoutTest) ... ok
test_http_basic (test.test_urllib2net.TimeoutTest) ... ok
test_http_default_timeout (test.test_urllib2net.TimeoutTest) ... ok
test_http_no_timeout (test.test_urllib2net.TimeoutTest) ... ok
test_http_timeout (test.test_urllib2net.TimeoutTest) ... ok

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13453>
_______________________________________

From report at bugs.python.org  Tue Nov 22 22:35:21 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 22 Nov 2011 21:35:21 +0000
Subject: [issue13453] Tests and network timeouts
In-Reply-To: <1321967813.33.0.280179416852.issue13453@psf.upfronthosting.co.za>
Message-ID: <1321997721.0.0.176455978932.issue13453@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

http://www.python.org/dev/buildbot/all/builders/AMD64%20FreeBSD%208.2%202.7/builds/405/steps/test/logs/stdio

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13453>
_______________________________________

From report at bugs.python.org  Tue Nov 22 22:37:58 2011
From: report at bugs.python.org (Eric Snow)
Date: Tue, 22 Nov 2011 21:37:58 +0000
Subject: [issue10854] Output .pyd name in error message of ImportError when
	DLL load fails
In-Reply-To: <1294415325.09.0.315523226252.issue10854@psf.upfronthosting.co.za>
Message-ID: <1321997878.57.0.0130567142696.issue10854@psf.upfronthosting.co.za>


Changes by Eric Snow <ericsnowcurrently at gmail.com>:


----------
nosy: +eric.snow

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10854>
_______________________________________

From report at bugs.python.org  Tue Nov 22 22:38:19 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 22 Nov 2011 21:38:19 +0000
Subject: [issue13453] Tests and network timeouts
In-Reply-To: <1321967813.33.0.280179416852.issue13453@psf.upfronthosting.co.za>
Message-ID: <1321997899.52.0.168852865588.issue13453@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

http://www.python.org/dev/buildbot/all/builders/x86%20OpenIndiana%203.x/builds/2435/steps/test/logs/stdio

Re-running test 'test_poplib' in verbose mode
test_apop (test.test_poplib.TestPOP3Class) ... ok
test_dele (test.test_poplib.TestPOP3Class) ... ok
test_exceptions (test.test_poplib.TestPOP3Class) ... ok
test_getwelcome (test.test_poplib.TestPOP3Class) ... ok
test_list (test.test_poplib.TestPOP3Class) ... ok
test_noop (test.test_poplib.TestPOP3Class) ... ok
test_pass_ (test.test_poplib.TestPOP3Class) ... ok
test_quit (test.test_poplib.TestPOP3Class) ... ok
test_retr (test.test_poplib.TestPOP3Class) ... ok
test_rpop (test.test_poplib.TestPOP3Class) ... ok
test_stat (test.test_poplib.TestPOP3Class) ... ok
test_top (test.test_poplib.TestPOP3Class) ... ok
test_uidl (test.test_poplib.TestPOP3Class) ... ok
test_user (test.test_poplib.TestPOP3Class) ... ok
testTimeoutDefault (test.test_poplib.TestTimeouts) ... ERROR
testTimeoutNone (test.test_poplib.TestTimeouts) ... ok
testTimeoutValue (test.test_poplib.TestTimeouts) ... ok
test__all__ (test.test_poplib.TestPOP3_SSLClass) ... ok
test_apop (test.test_poplib.TestPOP3_SSLClass) ... ok
test_context (test.test_poplib.TestPOP3_SSLClass) ... ok
test_dele (test.test_poplib.TestPOP3_SSLClass) ... ok
test_exceptions (test.test_poplib.TestPOP3_SSLClass) ... ok
test_getwelcome (test.test_poplib.TestPOP3_SSLClass) ... ok
test_list (test.test_poplib.TestPOP3_SSLClass) ... ok
test_noop (test.test_poplib.TestPOP3_SSLClass) ... ok
test_pass_ (test.test_poplib.TestPOP3_SSLClass) ... ok
test_quit (test.test_poplib.TestPOP3_SSLClass) ... ok
test_retr (test.test_poplib.TestPOP3_SSLClass) ... ok
test_rpop (test.test_poplib.TestPOP3_SSLClass) ... ok
test_stat (test.test_poplib.TestPOP3_SSLClass) ... ok
test_top (test.test_poplib.TestPOP3_SSLClass) ... ok
test_uidl (test.test_poplib.TestPOP3_SSLClass) ... ok
test_user (test.test_poplib.TestPOP3_SSLClass) ... ok

======================================================================
ERROR: testTimeoutDefault (test.test_poplib.TestTimeouts)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/test/test_poplib.py", line 348, in testTimeoutDefault
    pop = poplib.POP3("localhost", self.port)
  File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/poplib.py", line 84, in __init__
    self.sock = self._create_socket(timeout)
  File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/poplib.py", line 90, in _create_socket
    return socket.create_connection((self.host, self.port), timeout)
  File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/socket.py", line 405, in create_connection
    raise err
  File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/socket.py", line 396, in create_connection
    sock.connect(sa)
ConnectionRefusedError: [Errno 146] Connection refused

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13453>
_______________________________________

From report at bugs.python.org  Tue Nov 22 22:39:43 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 22 Nov 2011 21:39:43 +0000
Subject: [issue13453] Tests and network timeouts
In-Reply-To: <1321967813.33.0.280179416852.issue13453@psf.upfronthosting.co.za>
Message-ID: <1321997983.31.0.929599565776.issue13453@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

http://www.python.org/dev/buildbot/all/builders/AMD64%20OpenIndiana%202.7/builds/732/steps/test/logs/stdio

test test_telnetlib failed -- Traceback (most recent call last):
  File "/export/home/buildbot/64bits/2.7.cea-indiana-amd64/build/Lib/test/test_telnetlib.py", line 230, in test_read_eager_B
    self._test_read_any_eager_B('read_eager')
  File "/export/home/buildbot/64bits/2.7.cea-indiana-amd64/build/Lib/test/test_telnetlib.py", line 215, in _test_read_any_eager_B
    telnet = telnetlib.Telnet(HOST, self.port)
  File "/export/home/buildbot/64bits/2.7.cea-indiana-amd64/build/Lib/telnetlib.py", line 209, in __init__
    self.open(host, port, timeout)
  File "/export/home/buildbot/64bits/2.7.cea-indiana-amd64/build/Lib/telnetlib.py", line 225, in open
    self.sock = socket.create_connection((host, port), timeout)
  File "/export/home/buildbot/64bits/2.7.cea-indiana-amd64/build/Lib/socket.py", line 571, in create_connection
    raise err
error: [Errno 146] Connection refused

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13453>
_______________________________________

From report at bugs.python.org  Tue Nov 22 22:44:23 2011
From: report at bugs.python.org (Eric Snow)
Date: Tue, 22 Nov 2011 21:44:23 +0000
Subject: [issue13224] Change str(x) to return only __qualname__ for some types
In-Reply-To: <1319053532.35.0.636674659737.issue13224@psf.upfronthosting.co.za>
Message-ID: <1321998263.75.0.917294414072.issue13224@psf.upfronthosting.co.za>


Changes by Eric Snow <ericsnowcurrently at gmail.com>:


----------
nosy: +eric.snow

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13224>
_______________________________________

From report at bugs.python.org  Tue Nov 22 22:47:42 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 22 Nov 2011 21:47:42 +0000
Subject: [issue13415] del os.environ[key] ignores errors
In-Reply-To: <1321481687.96.0.070295281604.issue13415@psf.upfronthosting.co.za>
Message-ID: <1321998462.38.0.824845910665.issue13415@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Oh, it looks like unsetenv() has no return value on Mac OS X Tiger:

http://www.python.org/dev/buildbot/all/builders/PPC%20Tiger%202.7/builds/100/steps/compile/logs/stdio

./Modules/posixmodule.c: In function 'posix_unsetenv':
./Modules/posixmodule.c:7052: error: void value not ignored as it ought to be
make: *** [Modules/posixmodule.o] Error 1

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13415>
_______________________________________

From report at bugs.python.org  Tue Nov 22 22:53:38 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Tue, 22 Nov 2011 21:53:38 +0000
Subject: [issue13405] Add DTrace probes
In-Reply-To: <1321299726.66.0.343368151185.issue13405@psf.upfronthosting.co.za>
Message-ID: <1321998818.98.0.580767706003.issue13405@psf.upfronthosting.co.za>


Changes by Jes?s Cea Avi?n <jcea at jcea.es>:


Added file: http://bugs.python.org/file23758/a9f4ae43fd85.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13405>
_______________________________________

From report at bugs.python.org  Tue Nov 22 22:54:30 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Tue, 22 Nov 2011 21:54:30 +0000
Subject: [issue13405] Add DTrace probes
In-Reply-To: <1321299726.66.0.343368151185.issue13405@psf.upfronthosting.co.za>
Message-ID: <1321998870.8.0.0953011286799.issue13405@psf.upfronthosting.co.za>


Changes by Jes?s Cea Avi?n <jcea at jcea.es>:


Removed file: http://bugs.python.org/file23756/750ca6da48f3.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13405>
_______________________________________

From report at bugs.python.org  Tue Nov 22 23:03:54 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Tue, 22 Nov 2011 22:03:54 +0000
Subject: [issue13405] Add DTrace probes
In-Reply-To: <1321299726.66.0.343368151185.issue13405@psf.upfronthosting.co.za>
Message-ID: <1321999434.88.0.929473729008.issue13405@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

- Added documentaci?n.

- Change "sys.trace_capabilities" to an external "dtrace" extension module.

I don't care about Sun/Apple compatibility. The new probes are far more extensive, and they should be the new standard.

The code is tested under Solaris 10 x86 and x86-64. Could someone possibly test under Solaris SPARC 32/64 bits, and other platforms with dtrace support, like *bsd, mac, etc?.

PS: This code is for 2.7, because I think it is important to have a patch for interested parties to include in their python distributions. The plan is to integrate natively in 3.3.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13405>
_______________________________________

From report at bugs.python.org  Tue Nov 22 23:50:13 2011
From: report at bugs.python.org (Chris Miles)
Date: Tue, 22 Nov 2011 22:50:13 +0000
Subject: [issue13405] Add DTrace probes
In-Reply-To: <1321299726.66.0.343368151185.issue13405@psf.upfronthosting.co.za>
Message-ID: <1322002213.32.0.756559025608.issue13405@psf.upfronthosting.co.za>


Changes by Chris Miles <miles.chris at gmail.com>:


----------
nosy:  -chrismiles

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13405>
_______________________________________

From report at bugs.python.org  Wed Nov 23 00:36:12 2011
From: report at bugs.python.org (Zbyszek Szmek)
Date: Tue, 22 Nov 2011 23:36:12 +0000
Subject: [issue11682] PEP 380 reference implementation for 3.3
In-Reply-To: <1301110605.68.0.392943983038.issue11682@psf.upfronthosting.co.za>
Message-ID: <1322004972.35.0.443867104375.issue11682@psf.upfronthosting.co.za>


Zbyszek Szmek <zbyszek at in.waw.pl> added the comment:

Updated doc patch 0001-2.diff: following ncoghlan's request, the bulk of yield documentation is kept in expressions.rst, and simple_stmts.rst mostly refers to the other one. (In previous version it was the other way around).

After doing this change, I still think that it is better to have most of the documentation in the _statement_ part, and keep the _expression_ part relatively simple. The reason is that yield does more than just return a value, but also throws exceptions, suspends execution, etc. This is detached from the fact that is can be used in an expression.

Unfortunately yield as an expression is the only case where a statement can be used in an expression. Therefore there aren't any other cases which could be used as a guide.

----------
Added file: http://bugs.python.org/file23759/0001-2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11682>
_______________________________________

From report at bugs.python.org  Wed Nov 23 00:46:25 2011
From: report at bugs.python.org (Robert Xiao)
Date: Tue, 22 Nov 2011 23:46:25 +0000
Subject: [issue13458] _ssl memory leak in _get_peer_alt_names
Message-ID: <1322005585.35.0.144896453023.issue13458@psf.upfronthosting.co.za>


New submission from Robert Xiao <nneonneo at gmail.com>:

_ssl.c has a memory leak in _get_peer_alt_names.

The `names' object is initialized here:

Modules/_ssl.c:601:
        if (method->it)
            names = (GENERAL_NAMES*)
              (ASN1_item_d2i(NULL,
                             &p,
                             ext->value->length,
                             ASN1_ITEM_ptr(method->it)));
        else
            names = (GENERAL_NAMES*)
              (method->d2i(NULL,
                           &p,
                           ext->value->length));

However, `names' is not freed after use, so it simply leaks.

Trivial patch:

--- a/Modules/_ssl.c	2011-09-03 12:16:46.000000000 -0400
+++ b/Modules/_ssl.c	2011-11-22 19:41:12.000000000 -0400
@@ -679,6 +679,8 @@
             }
             Py_DECREF(t);
         }
+
+        sk_GENERAL_NAME_pop_free(names, GENERAL_NAME_free);
     }
     BIO_free(biobuf);
     if (peer_alt_names != Py_None) {


I tested this with a private certificate containing a subjectAltName field, and the following code:

import ssl, socket
sock = ssl.wrap_socket(socket.socket(), cert_reqs=ssl.CERT_REQUIRED)
sock.connect(('localhost', 443))
for i in range(100000):
    x=sock._sslobj.peer_certificate()

Before this change, Python's memory usage would continually increase to about 45MB at the end of the loop. After this change, the memory usage stays constant at around 6MB.

----------
components: Library (Lib)
messages: 148154
nosy: nneonneo
priority: normal
severity: normal
status: open
title: _ssl memory leak in _get_peer_alt_names
type: resource usage
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13458>
_______________________________________

From report at bugs.python.org  Wed Nov 23 00:46:56 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 22 Nov 2011 23:46:56 +0000
Subject: [issue13444] closed stdout causes error on stderr when the
	interpreter unconditionally flushes on shutdown
In-Reply-To: <1321888700.56.0.103830046171.issue13444@psf.upfronthosting.co.za>
Message-ID: <1322005616.44.0.46162414518.issue13444@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I think closing stdout is a legitimate desire so, yes, I would consider it a bug if we print an error in that case.
A patch could either first check the "closed" attribute, or silence the ValueError.

----------
stage:  -> needs patch
type:  -> behavior
versions: +Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13444>
_______________________________________

From report at bugs.python.org  Wed Nov 23 00:49:49 2011
From: report at bugs.python.org (Robert Xiao)
Date: Tue, 22 Nov 2011 23:49:49 +0000
Subject: [issue13458] _ssl memory leak in _get_peer_alt_names
In-Reply-To: <1322005585.35.0.144896453023.issue13458@psf.upfronthosting.co.za>
Message-ID: <1322005789.61.0.143019398619.issue13458@psf.upfronthosting.co.za>


Robert Xiao <nneonneo at gmail.com> added the comment:

Attaching patch.

----------
keywords: +patch
Added file: http://bugs.python.org/file23760/ssl.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13458>
_______________________________________

From report at bugs.python.org  Wed Nov 23 00:51:19 2011
From: report at bugs.python.org (Robert Xiao)
Date: Tue, 22 Nov 2011 23:51:19 +0000
Subject: [issue13458] _ssl memory leak in _get_peer_alt_names
In-Reply-To: <1322005585.35.0.144896453023.issue13458@psf.upfronthosting.co.za>
Message-ID: <1322005879.77.0.487156969864.issue13458@psf.upfronthosting.co.za>


Robert Xiao <nneonneo at gmail.com> added the comment:

Also applies to Python 2.7.

----------
versions: +Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13458>
_______________________________________

From report at bugs.python.org  Wed Nov 23 00:58:00 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 22 Nov 2011 23:58:00 +0000
Subject: [issue13458] _ssl memory leak in _get_peer_alt_names
In-Reply-To: <1322005585.35.0.144896453023.issue13458@psf.upfronthosting.co.za>
Message-ID: <1322006280.26.0.979473975424.issue13458@psf.upfronthosting.co.za>


Changes by Amaury Forgeot d'Arc <amauryfa at gmail.com>:


----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13458>
_______________________________________

From report at bugs.python.org  Wed Nov 23 01:03:25 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 23 Nov 2011 00:03:25 +0000
Subject: [issue12328] multiprocessing's overlapped PipeConnection on Windows
In-Reply-To: <1321814465.51.0.759877323291.issue12328@psf.upfronthosting.co.za>
Message-ID: <1322005661.3267.3.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Here is an updated patch (pipe_poll_fix.patch) which should be applied
> on top of sigint_event.patch.
> 
> It fixes the problems with PipeConnection.poll() and Queue.empty() and
> makes PipeListener.accept() use overlapped I/O.  This should make all
> the pipe releated blocking functions/methods interruptible on Windows.

I have the feeling that if we have to call GetLastError() at the Python
level, then there's something wrong with the APIs we're exposing from
the C extension. 
I see you check for ERROR_OPERATION_ABORTED. Is there any situation
where this can happen?
Also, it seems strange to call ov.cancel() and then
ov.GetOverlappedResult(). AFAICT, those two operations should be
mutually exclusive: you call the former if e.g. WaitForMultipleObjects
raised an exception, the latter otherwise.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12328>
_______________________________________

From report at bugs.python.org  Wed Nov 23 01:08:58 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 23 Nov 2011 00:08:58 +0000
Subject: [issue10318] "make altinstall" installs many files with incorrect
	shebangs
In-Reply-To: <1288926610.35.0.932494150274.issue10318@psf.upfronthosting.co.za>
Message-ID: <1322006938.72.0.537914542127.issue10318@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Hmm, my initial reaction is that that specific wording is stronger than I had in mind - there's nothing really wrong with having a shebang line and execute bit set on a top level module and symlinking it from /usr/bin. The problem is that we're doing those things for modules that we *don't* install as binaries, and that's silly (particularly when the shebang lines are wrong on altinstall). However, that concern can specifically by addressed by moving the new section down to be a subheading in the "Rules that apply only to the standard library" section.

I'd also mention the justification that this is due to such shebang lines creating a maintenance problem for handling parallel installations of different Python versions.

Also, with PEP 397 a viable candidate, we may as well make the wording OS neutral. Something like:

=======================
Executable Files and Shebang Lines

   Standard library modules (including test modules) should not be
   flagged as executable files nor contain a shebang line.

   Including shebang lines in standard library modules is an issue, as
   they create a maintenance problem when multiple versions of Python
   are installed in parallel. The easiest way to avoid accidentally
   invoking the wrong version of Python is to simply not include such
   lines at all.

   If a module provides command-line functionality, it can be used with
   ``python -m module`` or via a small script (in a different file) that
   imports the module and calls one of its functions (e.g. the ``pydoc``
   script imports the ``pydoc`` module and calls ``pydoc.cli()``).

   Any installed scripts should use a shebang line of the form::

        #!/usr/bin/env pythonX.Y

   where ``X.Y`` is the specific Python version being installed.
   Updating these lines to the correct Python version should be
   automated, either as part of the installation process or as part
   of the version update process (see PEP 101).
=======================

The PEP 8 update should be run by the wider audience of python-dev before it gets committed, though.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10318>
_______________________________________

From report at bugs.python.org  Wed Nov 23 01:16:46 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 23 Nov 2011 00:16:46 +0000
Subject: [issue13455] Reorganize tracker docs in the devguide
In-Reply-To: <1321984554.54.0.834071786299.issue13455@psf.upfronthosting.co.za>
Message-ID: <1322007406.02.0.207860052819.issue13455@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Documenting the tracker UI itself isn't the big issue - what is useful (and what I think Ezio is getting at) is having a single place where newcomers can get a better idea of how we *use* the tracker.

If someone just wants to report a bug, then sure, they shouldn't need to read the dev guide (so I disagree with the idea of making any significant changes to the bugs page in the docs), but making it easier for newcomers to learn the ropes is the main reason we have a devguide at all, so I'm definitely +1 on the general idea.

It would also give us a place to document the auto-linkification rules (similar to what was done recently for the post-commit hooks).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13455>
_______________________________________

From report at bugs.python.org  Wed Nov 23 01:50:06 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 23 Nov 2011 00:50:06 +0000
Subject: [issue13458] _ssl memory leak in _get_peer_alt_names
In-Reply-To: <1322005585.35.0.144896453023.issue13458@psf.upfronthosting.co.za>
Message-ID: <E1RT127-00019m-Lz@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 80d491aaeed2 by Antoine Pitrou in branch '3.2':
Issue #13458: Fix a memory leak in the ssl module when decoding a certificate with a subjectAltName.
http://hg.python.org/cpython/rev/80d491aaeed2

New changeset 3b5fef34c8c7 by Antoine Pitrou in branch 'default':
Issue #13458: Fix a memory leak in the ssl module when decoding a certificate with a subjectAltName.
http://hg.python.org/cpython/rev/3b5fef34c8c7

New changeset 61a5d44020cd by Antoine Pitrou in branch '2.7':
Issue #13458: Fix a memory leak in the ssl module when decoding a certificate with a subjectAltName.
http://hg.python.org/cpython/rev/61a5d44020cd

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13458>
_______________________________________

From report at bugs.python.org  Wed Nov 23 01:52:47 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 23 Nov 2011 00:52:47 +0000
Subject: [issue13458] _ssl memory leak in _get_peer_alt_names
In-Reply-To: <1322005585.35.0.144896453023.issue13458@psf.upfronthosting.co.za>
Message-ID: <1322009567.51.0.0608947759768.issue13458@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Patch committed, thank you.

----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
versions: +Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13458>
_______________________________________

From report at bugs.python.org  Wed Nov 23 01:55:39 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 23 Nov 2011 00:55:39 +0000
Subject: [issue11682] PEP 380 reference implementation for 3.3
In-Reply-To: <1301110605.68.0.392943983038.issue11682@psf.upfronthosting.co.za>
Message-ID: <1322009739.75.0.918798970551.issue11682@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

*Any* expression can be used as a standalone statement and (since PEP 352 was implemented) that now applies to 'yield' as well.

PEP 352 fundamentally changed the way yield was conceptualised within the language - thinking of it as "a statement that can be used as an expression" is just plain *wrong*. It's now just an expression that happens to have a couple of special cases in the grammar to allow the parentheses to be skipped when they're distracting rather than helpful.

That is, the only reason the yield statement still exists as a separate entity is to allow us to drop the otherwise mandatory parentheses:

  (yield val)    # yield expression as statement
  yield val      # yield statement

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11682>
_______________________________________

From report at bugs.python.org  Wed Nov 23 02:17:34 2011
From: report at bugs.python.org (Mike Fogel)
Date: Wed, 23 Nov 2011 01:17:34 +0000
Subject: [issue13459] logger.propagate=True behavior clarification
Message-ID: <1322011053.76.0.547589220073.issue13459@psf.upfronthosting.co.za>


New submission from Mike Fogel <mike at fogel.ca>:

Hi, there's been a fair amount of confusion over the interaction between logger.propagate and the ancestor logger's handlers and level.

http://bugs.python.org/issue7535
http://bugs.python.org/issue8327
http://bugs.python.org/issue9606

I think most this confusion could be avoided if the documentation for logger.propagate were expanded to explain clearly what happens when propagate evaluates to True - right now it just explains clearly what happens when it evaluates to False.

Attached is a documentation patch that does this.

Thanks for your consideration!

----------
assignee: docs at python
components: Documentation
files: logger_propagate_doc.diff
keywords: patch
messages: 148164
nosy: docs at python, mfogel, vinay.sajip
priority: normal
severity: normal
status: open
title: logger.propagate=True behavior clarification
versions: Python 2.7, Python 3.3
Added file: http://bugs.python.org/file23761/logger_propagate_doc.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13459>
_______________________________________

From report at bugs.python.org  Wed Nov 23 02:34:38 2011
From: report at bugs.python.org (Tyler Starke)
Date: Wed, 23 Nov 2011 01:34:38 +0000
Subject: [issue13460] urllib methods should demand unicode, instead demand str
Message-ID: <1322012077.59.0.596577613585.issue13460@psf.upfronthosting.co.za>


New submission from Tyler Starke <prof.ebral at gmail.com>:

It seems bad practice for urllib methods to demand a str instance and they should demand a unicode instance. By demanding a str instance the default behavior is too demanding, for the web space it is being used, for the English language. We would want Python to extend beyond English when it uses urllib

Currently I am encoding the unicode passed with 'utf-8' and that works.

----------
components: Library (Lib), Unicode
messages: 148165
nosy: Tyler.Starke, ezio.melotti
priority: normal
severity: normal
status: open
title: urllib methods should demand unicode, instead demand str
type: behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13460>
_______________________________________

From report at bugs.python.org  Wed Nov 23 02:48:38 2011
From: report at bugs.python.org (R. David Murray)
Date: Wed, 23 Nov 2011 01:48:38 +0000
Subject: [issue13460] urllib methods should demand unicode, instead demand str
In-Reply-To: <1322012077.59.0.596577613585.issue13460@psf.upfronthosting.co.za>
Message-ID: <1322012918.18.0.686813124217.issue13460@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I suspect you want to be using Python3, then.  Although it is nowhere near as simple as that...even with Python3 you still sometimes have to deal with the fact that the wire protocol is bytes.

----------
nosy: +r.david.murray
resolution:  -> out of date
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13460>
_______________________________________

From report at bugs.python.org  Wed Nov 23 03:13:45 2011
From: report at bugs.python.org (Tyler Starke)
Date: Wed, 23 Nov 2011 02:13:45 +0000
Subject: [issue13460] urllib methods should demand unicode, instead demand str
In-Reply-To: <1322012077.59.0.596577613585.issue13460@psf.upfronthosting.co.za>
Message-ID: <1322014425.11.0.511891399478.issue13460@psf.upfronthosting.co.za>


Tyler Starke <prof.ebral at gmail.com> added the comment:

well that was closed fast. I noticed in the docs that Python 3 demands a str type also.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13460>
_______________________________________

From report at bugs.python.org  Wed Nov 23 05:36:04 2011
From: report at bugs.python.org (Tyler Starke)
Date: Wed, 23 Nov 2011 04:36:04 +0000
Subject: [issue13460] urllib methods should demand unicode, instead demand str
In-Reply-To: <1322012077.59.0.596577613585.issue13460@psf.upfronthosting.co.za>
Message-ID: <1322022964.86.0.973556847844.issue13460@psf.upfronthosting.co.za>


Tyler Starke <prof.ebral at gmail.com> added the comment:

Nevermind. I had to download the source to see that it encodes to 'utf-8', or a passed encoding method, in the methods that are causing problems in 2.6.5.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13460>
_______________________________________

From report at bugs.python.org  Wed Nov 23 05:52:08 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Wed, 23 Nov 2011 04:52:08 +0000
Subject: [issue13439] turtle docstring for onkeyrelease references onkey,
	not onkeyrelease
In-Reply-To: <1321802124.14.0.262913683551.issue13439@psf.upfronthosting.co.za>
Message-ID: <1322023928.25.0.644205040845.issue13439@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/issue13439>
_______________________________________

From report at bugs.python.org  Wed Nov 23 07:30:42 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Wed, 23 Nov 2011 06:30:42 +0000
Subject: [issue13439] turtle docstring for onkeyrelease references onkey,
	not onkeyrelease
In-Reply-To: <1321802124.14.0.262913683551.issue13439@psf.upfronthosting.co.za>
Message-ID: <1322029842.28.0.639032044212.issue13439@psf.upfronthosting.co.za>


Petri Lehtinen <petri at digip.org> added the comment:

onkey and onkeyrelease are the same function, so you still get exactly the same behavior with the example in the docstring. This also makes it hard to have different docstrings for them.

Closing as wontfix.

----------
assignee:  -> docs at python
components: +Documentation
nosy: +docs at python, gregorlingl
resolution:  -> wont fix
stage:  -> committed/rejected
status: open -> closed
type:  -> behavior
versions: +Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13439>
_______________________________________

From report at bugs.python.org  Wed Nov 23 07:38:04 2011
From: report at bugs.python.org (Sterling Windmill)
Date: Wed, 23 Nov 2011 06:38:04 +0000
Subject: [issue6407] multiprocessing Pool should allow custom task queue
In-Reply-To: <1246627398.56.0.0568609724018.issue6407@psf.upfronthosting.co.za>
Message-ID: <1322030284.15.0.024300209994.issue6407@psf.upfronthosting.co.za>


Sterling Windmill <sterling at ampx.net> added the comment:

I would also like to see this functionality as I'm currently using more memory than I'd like when using multiprocessing.Pool

----------
nosy: +swindmill

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6407>
_______________________________________

From report at bugs.python.org  Wed Nov 23 08:35:23 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Wed, 23 Nov 2011 07:35:23 +0000
Subject: [issue6407] multiprocessing Pool should allow custom task queue
In-Reply-To: <1246627398.56.0.0568609724018.issue6407@psf.upfronthosting.co.za>
Message-ID: <1322033723.91.0.840553590076.issue6407@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/issue6407>
_______________________________________

From report at bugs.python.org  Wed Nov 23 09:09:00 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Wed, 23 Nov 2011 08:09:00 +0000
Subject: [issue12156] test_multiprocessing.test_notify_all() timeout (1 hour)
	on FreeBSD 7.2
In-Reply-To: <1306147254.92.0.286085135906.issue12156@psf.upfronthosting.co.za>
Message-ID: <1322035740.78.0.240579525578.issue12156@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

Alright, the test is now skipped when the system doesn't support enough POSIX semaphores.
I'm closing, we can still reopen in case another similar problem pops up (on other OS of course).

----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12156>
_______________________________________

From report at bugs.python.org  Wed Nov 23 09:22:44 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Wed, 23 Nov 2011 08:22:44 +0000
Subject: [issue13415] del os.environ[key] ignores errors
In-Reply-To: <1321481687.96.0.070295281604.issue13415@psf.upfronthosting.co.za>
Message-ID: <1322036564.06.0.203133673468.issue13415@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

> Oh, it looks like unsetenv() has no return value on Mac OS X Tiger

And neither does FreeBSD < 7:
http://python.org/dev/buildbot/all/builders/x86%20FreeBSD%206.4%203.x/builds/2015/steps/compile/logs/stdio

Note that ignoring unsetenv() return value is a bad idea:
http://xorl.wordpress.com/category/freebsd/page/2/

We could maybe add a configure-time check.

----------
nosy: +neologix

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13415>
_______________________________________

From report at bugs.python.org  Wed Nov 23 09:50:34 2011
From: report at bugs.python.org (=?utf-8?q?Stanis=C5=82aw_Jankowski?=)
Date: Wed, 23 Nov 2011 08:50:34 +0000
Subject: [issue13425] http.client.HTTPMessage.getallmatchingheaders() always
	returns []
In-Reply-To: <1321614230.59.0.764469605478.issue13425@psf.upfronthosting.co.za>
Message-ID: <1322038234.09.0.896850184608.issue13425@psf.upfronthosting.co.za>


Stanis?aw Jankowski <stach.jankowski at gmail.com> added the comment:

> @stachjankowski: How did you find this issue? Are you porting from 2.x to 3.x or have new 3.x code that uses this function?
No, it's just random finding.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13425>
_______________________________________

From report at bugs.python.org  Wed Nov 23 09:56:28 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 23 Nov 2011 08:56:28 +0000
Subject: [issue13459] logger.propagate=True behavior clarification
In-Reply-To: <1322011053.76.0.547589220073.issue13459@psf.upfronthosting.co.za>
Message-ID: <E1RT8co-00055e-5m@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 2c173769a957 by Vinay Sajip in branch '2.7':
Closes #13459: Clarified documentation on Logger.propagate. Thanks to Mike Fogel for the patch.
http://hg.python.org/cpython/rev/2c173769a957

New changeset a9f5639e18a1 by Vinay Sajip in branch '3.2':
Closes #13459: Clarified documentation on Logger.propagate. Thanks to Mike Fogel for the patch.
http://hg.python.org/cpython/rev/a9f5639e18a1

New changeset cc6693fdf6d5 by Vinay Sajip in branch 'default':
Closes #13459: Merged fix from 3.2.
http://hg.python.org/cpython/rev/cc6693fdf6d5

----------
nosy: +python-dev
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13459>
_______________________________________

From report at bugs.python.org  Wed Nov 23 10:32:48 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Wed, 23 Nov 2011 09:32:48 +0000
Subject: [issue13425] http.client.HTTPMessage.getallmatchingheaders() always
	returns []
In-Reply-To: <1321614230.59.0.764469605478.issue13425@psf.upfronthosting.co.za>
Message-ID: <1322040768.48.0.24156618355.issue13425@psf.upfronthosting.co.za>


Petri Lehtinen <petri at digip.org> added the comment:

> No, it's just random finding.

This strengthens my impression that no-one is actually using the function. Maybe we should just remove it from 3.3.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13425>
_______________________________________

From report at bugs.python.org  Wed Nov 23 10:42:19 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 23 Nov 2011 09:42:19 +0000
Subject: [issue13415] del os.environ
In-Reply-To: <1322036564.06.0.203133673468.issue13415@psf.upfronthosting.co.za>
Message-ID: <1522835.USvs9OVM6r@dsk000552>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> Note that ignoring unsetenv() return value is a bad idea:
> http://xorl.wordpress.com/category/freebsd/page/2/

Oh yeah, I remember this critical (local) vulnerability!

> We could maybe add a configure-time check.

Yes, it sounds like the best solution.

----------
title: del os.environ[key] ignores errors -> del os.environ

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13415>
_______________________________________

From report at bugs.python.org  Wed Nov 23 10:44:13 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Wed, 23 Nov 2011 09:44:13 +0000
Subject: [issue13425] http.client.HTTPMessage.getallmatchingheaders() always
	returns
In-Reply-To: <1322040768.48.0.24156618355.issue13425@psf.upfronthosting.co.za>
Message-ID: <CAPOVWORa+_mgy3eB=wuFvHJJNrx9i2T8vRP_JaTBrWTvxwm-sQ@mail.gmail.com>


Senthil Kumaran <senthil at uthcode.com> added the comment:

Let's make it useful, that's much better instead of removing it. I am
+1 with Ezio's suggestion on this to return a list of tuples with
matching headers.

----------
title: http.client.HTTPMessage.getallmatchingheaders() always returns [] -> http.client.HTTPMessage.getallmatchingheaders() always returns

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13425>
_______________________________________

From report at bugs.python.org  Wed Nov 23 10:49:15 2011
From: report at bugs.python.org (Christopher Smith)
Date: Wed, 23 Nov 2011 09:49:15 +0000
Subject: [issue13439] turtle docstring for onkeyrelease references onkey,
	not onkeyrelease
In-Reply-To: <1321802124.14.0.262913683551.issue13439@psf.upfronthosting.co.za>
Message-ID: <1322041755.38.0.669431539169.issue13439@psf.upfronthosting.co.za>


Christopher Smith <smichr at users.sourceforge.net> added the comment:

Sorry for the misdirection:

The docstring example for onkeypress is written using onkey instead of onkeypress. (There is no problem for onkey and onkeyrelease.)

----------
resolution: wont fix -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13439>
_______________________________________

From report at bugs.python.org  Wed Nov 23 10:54:27 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Wed, 23 Nov 2011 09:54:27 +0000
Subject: [issue13425] http.client.HTTPMessage.getallmatchingheaders() always
	returns
In-Reply-To: <1321614230.59.0.764469605478.issue13425@psf.upfronthosting.co.za>
Message-ID: <1322042067.84.0.504162614222.issue13425@psf.upfronthosting.co.za>


Petri Lehtinen <petri at digip.org> added the comment:

> Let's make it useful, that's much better instead of removing it. I am
> +1 with Ezio's suggestion on this to return a list of tuples with
> matching headers.

But there's already a function that does it:
    http://docs.python.org/dev/library/email.message.html#email.message.Message.get_all

HTTPMessage is a subclass of email.message.Message, so it's available in HTTPMessage as well.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13425>
_______________________________________

From report at bugs.python.org  Wed Nov 23 12:44:22 2011
From: report at bugs.python.org (sbt)
Date: Wed, 23 Nov 2011 11:44:22 +0000
Subject: [issue12328] multiprocessing's overlapped PipeConnection on Windows
In-Reply-To: <1307991196.59.0.849860111943.issue12328@psf.upfronthosting.co.za>
Message-ID: <1322048662.68.0.632615343915.issue12328@psf.upfronthosting.co.za>


sbt <shibturn at gmail.com> added the comment:

> I have the feeling that if we have to call GetLastError() at the
> Python level, then there's something wrong with the APIs we're 
> exposing from the C extension. 
> I see you check for ERROR_OPERATION_ABORTED. Is there any situation
> where this can happen?

There are three "expected" error conditions:

ERROR_OPERATION_ABORTED: operation stopped by CancelIo(Ex)()
ERROR_MORE_DATA: operation complete, but only got part of the message
ERROR_IO_INCOMPLETE: operation still has not finished

In the win32 api you need GetLastError() to distinguish between these cases, but maybe we can expose something better.

> Also, it seems strange to call ov.cancel() and then
> ov.GetOverlappedResult(). AFAICT, those two operations should be
> mutually exclusive: you call the former if e.g. WaitForMultipleObjects
> raised an exception, the latter otherwise.

If WaitForMultipleObjects() returns WAIT_OBJECT_0 + 0 then, as you say, there is no need to call ov.cancel(), but it is harmless to call it if the operation has already completed. 

The cases aren't really mutually exclusive: if you call ov.cancel() you *must* still do ov.GetOverlappedResult(True) to check for the race where the operation completes after the wait times out, but before ov.cancel() can stop it.  (Your original implementation had that bug -- see point (5) in my original bug report.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12328>
_______________________________________

From report at bugs.python.org  Wed Nov 23 13:52:14 2011
From: report at bugs.python.org (Charalampos Nikolaou)
Date: Wed, 23 Nov 2011 12:52:14 +0000
Subject: [issue13446] imaplib,
	fetch: improper behaviour on read-only selected mailboxes
In-Reply-To: <1321895059.52.0.840142009955.issue13446@psf.upfronthosting.co.za>
Message-ID: <1322052734.51.0.798598856124.issue13446@psf.upfronthosting.co.za>


Charalampos Nikolaou <char.nikolaou at gmail.com> added the comment:

Hi, actually I must have found the real culprit. And this is that imaplib does not include a function for the "EXAMINE" command. What it does is that when a user selects a mailbox as readonly, it executes an EXAMINE command instead of a SELEECT command, which is wrong according to RFC2060 (http://james.apache.org/server/rfclist/imap4/rfc2060.txt) that explicitly states the following:

"Read-only access through SELECT differs from the EXAMINE command in that certain read-only mailboxes MAY permit the change of permanent state on a per-user (as opposed to global) basis.  Netnews messages marked in  a server-based .newsrc file are an example of such per-user permanent state that can be modified with read-only mailboxes."

As a consequence of the above text, if a mailbox has been selected with the EXAMINE command, fetching a mail does not make the mail as read, which would be done if the mailbox had been selected with the SELECT command even in the case the mailbox had read-only permissions.

A quick patch for imaplib is to have it not raising any exceptions when checking the READ-ONLY state. In this way, one can open a read-only mailbox using the SELECT command as follows:

imap.select(mailbox)

Preventing imaplib from raising exceptions when using the above command with read-only mailboxes, it allows someone to fetch a message and then marked it as seen. After all, the exceptions are of no use, because the IMAP server is responsible for making security checks and not the client.

To have imaplib be compliant with RFC2060, I propose including an examine function which would be like select. Pure and simply.

I attach a patch for imaplib 2.58 (Python 2.6.2) which "solves" this misbehavior by not raising exceptions for READ-ONLY mailboxes when having opened them without "readonly=True". 

What are your opinions on this?

----------
keywords: +patch
Added file: http://bugs.python.org/file23762/imaplib.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13446>
_______________________________________

From report at bugs.python.org  Wed Nov 23 14:47:46 2011
From: report at bugs.python.org (=?utf-8?b?U8OpYmFzdGllbiBTYWJsw6k=?=)
Date: Wed, 23 Nov 2011 13:47:46 +0000
Subject: [issue1395] py3k: duplicated line endings when using read(1)
In-Reply-To: <1194308496.75.0.337158380504.issue1395@psf.upfronthosting.co.za>
Message-ID: <1322056066.12.0.867542017735.issue1395@psf.upfronthosting.co.za>


S?bastien Sabl? <sable at users.sourceforge.net> added the comment:

I am trying to get Python working when compiled with Visual Studio 2010 (cf issue 13210).

When running the tests with the python 2.7 branch compiled with VS2010, the "test_issue_1395_5" in test_io.py will cause Python to eat the whole memory within a few seconds and make the server completely unresponsive.

----------
nosy: +sable

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1395>
_______________________________________

From report at bugs.python.org  Wed Nov 23 14:48:43 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 23 Nov 2011 13:48:43 +0000
Subject: [issue1395] py3k: duplicated line endings when using read(1)
In-Reply-To: <1194308496.75.0.337158380504.issue1395@psf.upfronthosting.co.za>
Message-ID: <1322056123.58.0.0328958456038.issue1395@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/issue1395>
_______________________________________

From report at bugs.python.org  Wed Nov 23 14:51:12 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 23 Nov 2011 13:51:12 +0000
Subject: [issue1395] py3k: duplicated line endings when using read(1)
In-Reply-To: <1194308496.75.0.337158380504.issue1395@psf.upfronthosting.co.za>
Message-ID: <1322056272.06.0.0491808329351.issue1395@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

You should open a new issue for this new problem.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1395>
_______________________________________

From report at bugs.python.org  Wed Nov 23 15:02:39 2011
From: report at bugs.python.org (=?utf-8?b?U8OpYmFzdGllbiBTYWJsw6k=?=)
Date: Wed, 23 Nov 2011 14:02:39 +0000
Subject: [issue13461] Error on test_issue_1395_5 with Python 2.7 and VS2010
Message-ID: <1322056958.99.0.498945300571.issue13461@psf.upfronthosting.co.za>


New submission from S?bastien Sabl? <sable at users.sourceforge.net>:

I am trying to get Python working when compiled with Visual Studio 2010 (cf issue 13210).

When running the tests with the python 2.7 branch compiled with VS2010, the "test_issue_1395_5" in test_io.py will cause Python to eat the whole memory within a few seconds and make the server completely unresponsive.

----------
components: IO
messages: 148184
nosy: sable
priority: normal
severity: normal
status: open
title: Error on test_issue_1395_5 with Python 2.7 and VS2010
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13461>
_______________________________________

From report at bugs.python.org  Wed Nov 23 15:03:39 2011
From: report at bugs.python.org (=?utf-8?b?U8OpYmFzdGllbiBTYWJsw6k=?=)
Date: Wed, 23 Nov 2011 14:03:39 +0000
Subject: [issue1395] py3k: duplicated line endings when using read(1)
In-Reply-To: <1194308496.75.0.337158380504.issue1395@psf.upfronthosting.co.za>
Message-ID: <1322057019.49.0.916684834584.issue1395@psf.upfronthosting.co.za>


S?bastien Sabl? <sable at users.sourceforge.net> added the comment:

OK, sorry. Done in issue 13461.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1395>
_______________________________________

From report at bugs.python.org  Wed Nov 23 16:29:48 2011
From: report at bugs.python.org (=?utf-8?b?U8OpYmFzdGllbiBTYWJsw6k=?=)
Date: Wed, 23 Nov 2011 15:29:48 +0000
Subject: [issue13461] Error on test_issue_1395_5 with Python 2.7 and VS2010
In-Reply-To: <1322056958.99.0.498945300571.issue13461@psf.upfronthosting.co.za>
Message-ID: <1322062188.02.0.590219337651.issue13461@psf.upfronthosting.co.za>


S?bastien Sabl? <sable at users.sourceforge.net> added the comment:

The problem is in CTextIOWrapperTest.test_issue1395_5
Here is the backtrace:

 	msvcr100d.dll!memset()  Line 145	Asm
>	msvcr100d.dll!_heap_alloc_dbg_impl(unsigned __int64 nSize, int nBlockUse, const char * szFileName, int nLine, int * errno_tmp)  Line 498	C++
 	msvcr100d.dll!_nh_malloc_dbg_impl(unsigned __int64 nSize, int nhFlag, int nBlockUse, const char * szFileName, int nLine, int * errno_tmp)  Line 239 + 0x22 bytes	C++
 	msvcr100d.dll!_nh_malloc_dbg(unsigned __int64 nSize, int nhFlag, int nBlockUse, const char * szFileName, int nLine)  Line 302 + 0x2a bytes	C++
 	msvcr100d.dll!malloc(unsigned __int64 nSize)  Line 56 + 0x21 bytes	C++
 	python27_d.dll!PyObject_Malloc(unsigned __int64 nbytes)  Line 944	C
 	python27_d.dll!_PyObject_DebugMallocApi(char id, unsigned __int64 nbytes)  Line 1445 + 0xa bytes	C
 	python27_d.dll!_PyObject_DebugMalloc(unsigned __int64 nbytes)  Line 1413	C
 	python27_d.dll!PyString_FromStringAndSize(const char * str, __int64 size)  Line 88 + 0x11 bytes	C
 	python27_d.dll!do_mkvalue(const char * * p_format, char * * p_va, int flags)  Line 427 + 0xf bytes	C
 	python27_d.dll!va_build_value(const char * format, char * va, int flags)  Line 537 + 0x14 bytes	C
 	python27_d.dll!_Py_VaBuildValue_SizeT(const char * format, char * va)  Line 511	C
 	python27_d.dll!_PyObject_CallMethod_SizeT(_object * o, char * name, char * format, ...)  Line 2671 + 0xf bytes	C
 	python27_d.dll!textiowrapper_tell(textio * self, _object * args)  Line 2222 + 0x2c bytes	C



So the problem happens when calling in textio.c:
{{{
PyObject *decoded = PyObject_CallMethod(
            self->decoder, "decode", "s#", input, 1);
}}}

self->decoder is of type "_io.IncrementalNewlineDecoder" and input is "BBB".

This will result in PyString_FromStringAndSize being called with size = 4294967297, which will cause the server to fall.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13461>
_______________________________________

From report at bugs.python.org  Wed Nov 23 17:01:29 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 23 Nov 2011 16:01:29 +0000
Subject: [issue12328] multiprocessing's overlapped PipeConnection on Windows
In-Reply-To: <1322048662.68.0.632615343915.issue12328@psf.upfronthosting.co.za>
Message-ID: <1322063778.3322.2.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> There are three "expected" error conditions:
> 
> ERROR_OPERATION_ABORTED: operation stopped by CancelIo(Ex)()
> ERROR_MORE_DATA: operation complete, but only got part of the message
> ERROR_IO_INCOMPLETE: operation still has not finished
> 
> In the win32 api you need GetLastError() to distinguish between these
> cases, but maybe we can expose something better.

It seems to me that ERROR_OPERATION_ABORTED is a "true" error, and so
should raise an exception.

> The cases aren't really mutually exclusive: if you call ov.cancel()
> you *must* still do ov.GetOverlappedResult(True) to check for the race
> where the operation completes after the wait times out, but before
> ov.cancel() can stop it.  (Your original implementation had that bug
> -- see point (5) in my original bug report.)

Ah, right. Thanks for the explanation.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12328>
_______________________________________

From report at bugs.python.org  Wed Nov 23 17:39:01 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 23 Nov 2011 16:39:01 +0000
Subject: [issue13462] Improve code and tests for Mixin2to3
Message-ID: <1322066341.39.0.436349182896.issue13462@psf.upfronthosting.co.za>


New submission from ?ric Araujo <merwok at netwok.org>:

Currently distutils2 has two classes and one function to perform 2to3 conversion in the build_py and build_scripts commands.  The code is a bit messy and also lack tests, for example for the conversion of doctests in text files.  I?ve started revamping it so that it?s only one class that does the work, and I will also add many tests.

Benjamin: For Python 2.4 and 2.5, should the functionality just be unavailable or is there an official release of lib2to3 on PyPI?  I only found two2three, an old copy from the Subversion sandbox done by 3to2?s Joe Amenta, so I?m not sure I can be compatible with that (or if it?s even useful to try to convert 2.4 code to 3.x).

----------
assignee: eric.araujo
components: Distutils2
messages: 148188
nosy: alexis, benjamin.peterson, eric.araujo
priority: release blocker
severity: normal
status: open
title: Improve code and tests for Mixin2to3
type: behavior
versions: 3rd party, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13462>
_______________________________________

From report at bugs.python.org  Wed Nov 23 17:48:34 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 23 Nov 2011 16:48:34 +0000
Subject: [issue12618] py_compile cannot create files in current directory
In-Reply-To: <1311406971.17.0.312082121474.issue12618@psf.upfronthosting.co.za>
Message-ID: <1322066914.6.0.776017024008.issue12618@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Meador, maybe you would like to commit the tests (except for the one that?s the object of this report) yourself?  I don?t mind doing it, but as you have push rights now maybe you prefer to have your name directly associated with your work.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12618>
_______________________________________

From report at bugs.python.org  Wed Nov 23 17:52:32 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 23 Nov 2011 16:52:32 +0000
Subject: [issue13420] newer() function in dep_util.py discard changes in the
	same second
In-Reply-To: <1321529038.98.0.0841934486822.issue13420@psf.upfronthosting.co.za>
Message-ID: <1322067152.3.0.181298169819.issue13420@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

It?s a bit hard for me to isolate the distutils problem from the CDBS-specific parts (maybe because I?m tired :).  For years, sub-second resolution was not supported by distutils, and things were okay as long as the build* commands did the file creation and install* were only concerned with copying files.  Given the feature freeze, I?m very reluctant to add sub-second resolution.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13420>
_______________________________________

From report at bugs.python.org  Wed Nov 23 17:53:18 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 23 Nov 2011 16:53:18 +0000
Subject: [issue13462] Improve code and tests for Mixin2to3
In-Reply-To: <1322066341.39.0.436349182896.issue13462@psf.upfronthosting.co.za>
Message-ID: <1322067198.33.0.698465248286.issue13462@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Yes, last time I checked 2to3 doesn't work on 2.5 or 2.4. People will just have to run build_py2to3 on 2.6+.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13462>
_______________________________________

From report at bugs.python.org  Wed Nov 23 18:04:57 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 23 Nov 2011 17:04:57 +0000
Subject: [issue10318] "make altinstall" installs many files with incorrect
	shebangs
In-Reply-To: <1288926610.35.0.932494150274.issue10318@psf.upfronthosting.co.za>
Message-ID: <1322067897.01.0.0183869407517.issue10318@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> Hmm, my initial reaction is that that specific wording is stronger than I had in mind -
> there's nothing really wrong with having a shebang line and execute bit set on a top level
> module and symlinking it from /usr/bin.
Okay.  (On that topic, http://lists.debian.org/debian-python/2011/11/msg00058.html may interest you.)

> The problem is that we're doing those things for modules that we *don't* install as binaries,
> and that's silly
Yep.  Attached patch removes them for 3.3.

> I'd also mention the justification that this is due to such shebang lines creating a
> maintenance problem for handling parallel installations of different Python versions.
I?d rather just say that it?s unneeded.  With all due respect to the original poster, I don?t think this really caused problems.


I will move my addition to the stdlib-only section.  I?m not sure about OS-neutrality; the executable bit is Unix-specific and I?d rather use that exact term than a vague ?flagged as executable?.  I?ll make the part about shebangs neutral however, it won?t be hard.

About this part of your proposal:
> Any installed scripts should use a shebang line of the form::
>        #!/usr/bin/env pythonX.Y
Due to the use of distutils? build_scripts that hard-codes one path, I?m not sure it?s time yet to make that recommendation.  For packaging, I intend to launch a discussion about that behavior, which is often unhelpful.

I really appreciate your taking time to review, and will submit the next revision of the patch here before going to python-dev.

----------
Added file: http://bugs.python.org/file23763/no-shebangs-for-stdlib.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10318>
_______________________________________

From report at bugs.python.org  Wed Nov 23 18:06:22 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 23 Nov 2011 17:06:22 +0000
Subject: [issue13455] Reorganize tracker docs in the devguide
In-Reply-To: <1321984554.54.0.834071786299.issue13455@psf.upfronthosting.co.za>
Message-ID: <1322067982.76.0.559841031767.issue13455@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

+1 on grouping existing info into one or two files in the devguide
+1 to removing the wiki pages
+1 on keeping some basic directions in the main docs

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13455>
_______________________________________

From report at bugs.python.org  Wed Nov 23 18:13:53 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 23 Nov 2011 17:13:53 +0000
Subject: [issue13463] Fix parsing of package_data
Message-ID: <1322068433.36.0.783240091616.issue13463@psf.upfronthosting.co.za>


New submission from ?ric Araujo <merwok at netwok.org>:

In 288640098ea8, Jeremy fixed a bug in distutils2.config that prevented d2?s own setup.py script from working.  I had to revert that change because it caused tests to fail.  The bug needs to be identified exactly, then a test for it is needed, and finally an sdist should be created to check that all files are included.

As I want to release 1.0a4 very soon, I?ll work on this today or tomorrow.

----------
assignee: eric.araujo
components: Distutils2
messages: 148194
nosy: alexis, eric.araujo
priority: release blocker
severity: normal
stage: test needed
status: open
title: Fix parsing of package_data
type: behavior
versions: 3rd party, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13463>
_______________________________________

From report at bugs.python.org  Wed Nov 23 18:18:14 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 23 Nov 2011 17:18:14 +0000
Subject: [issue13009] Remove documentation in distutils2 repo
In-Reply-To: <1316444893.0.0.327846688186.issue13009@psf.upfronthosting.co.za>
Message-ID: <1322068694.01.0.25169600021.issue13009@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
priority: normal -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13009>
_______________________________________

From report at bugs.python.org  Wed Nov 23 18:18:51 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 23 Nov 2011 17:18:51 +0000
Subject: =?utf-8?q?=5Bissue12934=5D_pysetup_doesn=E2=80=99t_work_for_the_docutils_?=
	=?utf-8?q?project?=
In-Reply-To: <1315411968.07.0.253348749085.issue12934@psf.upfronthosting.co.za>
Message-ID: <1322068731.22.0.711851059265.issue12934@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Due to the same reason, it?s also not possible to run ?pysetup3.1 metadata? in the distutils2 repo, or ?pysetup2.4 metadata? in the distutils2-python3 repo.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12934>
_______________________________________

From report at bugs.python.org  Wed Nov 23 18:20:24 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 23 Nov 2011 17:20:24 +0000
Subject: [issue12779] Update packaging documentation
In-Reply-To: <1313686169.0.0.406072932055.issue12779@psf.upfronthosting.co.za>
Message-ID: <1322068824.68.0.667242410844.issue12779@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Making this a release blocker for d2 1.0a4.

----------
priority: normal -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12779>
_______________________________________

From report at bugs.python.org  Wed Nov 23 18:44:41 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 23 Nov 2011 17:44:41 +0000
Subject: [issue13125] test_all_project_files() expected failure
In-Reply-To: <1318012693.65.0.29583104397.issue13125@psf.upfronthosting.co.za>
Message-ID: <1322070281.8.0.563208333348.issue13125@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Ping.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13125>
_______________________________________

From report at bugs.python.org  Wed Nov 23 19:04:41 2011
From: report at bugs.python.org (Ronny Pfannschmidt)
Date: Wed, 23 Nov 2011 18:04:41 +0000
Subject: [issue13444] closed stdout causes error on stderr when the
	interpreter unconditionally flushes on shutdown
In-Reply-To: <1321888700.56.0.103830046171.issue13444@psf.upfronthosting.co.za>
Message-ID: <1322071481.66.0.829569012252.issue13444@psf.upfronthosting.co.za>


Ronny Pfannschmidt <ronny.pfannschmidt at gmail.com> added the comment:

i think checking for closed is the correct solution

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13444>
_______________________________________

From report at bugs.python.org  Wed Nov 23 19:14:22 2011
From: report at bugs.python.org (R. David Murray)
Date: Wed, 23 Nov 2011 18:14:22 +0000
Subject: [issue13464] HTTPResponse is missing an implementation of readinto
Message-ID: <1322072062.06.0.738377139897.issue13464@psf.upfronthosting.co.za>


New submission from R. David Murray <rdmurray at bitdance.com>:

HTTPResponse subclasses RawIOBase, but does not provide an implementation of readinto, only read.  This means that it is not conforming to the IO spec, and so it cannot be wrapped in a BufferedIOBase when using the C version of io.

----------
components: Library (Lib)
keywords: easy
messages: 148199
nosy: orsenthil, pitrou, r.david.murray
priority: normal
severity: normal
status: open
title: HTTPResponse is missing an implementation of readinto
type: behavior
versions: Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13464>
_______________________________________

From report at bugs.python.org  Wed Nov 23 19:20:06 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Wed, 23 Nov 2011 18:20:06 +0000
Subject: [issue12578] Erratic socket.gaierror: [Errno 11004] when using smtplib
In-Reply-To: <1310902779.89.0.705938348131.issue12578@psf.upfronthosting.co.za>
Message-ID: <1322072406.57.0.518439382333.issue12578@psf.upfronthosting.co.za>


Changes by Charles-Fran?ois Natali <neologix at free.fr>:


----------
resolution:  -> invalid
stage: test needed -> committed/rejected
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12578>
_______________________________________

From report at bugs.python.org  Wed Nov 23 19:43:32 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Wed, 23 Nov 2011 18:43:32 +0000
Subject: [issue13415] del os.environ
In-Reply-To: <1321481687.96.0.070295281604.issue13415@psf.upfronthosting.co.za>
Message-ID: <1322073812.37.0.612189123655.issue13415@psf.upfronthosting.co.za>


Changes by Charles-Fran?ois Natali <neologix at free.fr>:


----------
keywords: +needs review
stage:  -> patch review
Added file: http://bugs.python.org/file23764/broken_unsetenv.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13415>
_______________________________________

From report at bugs.python.org  Wed Nov 23 19:46:55 2011
From: report at bugs.python.org (Frank Wierzbicki)
Date: Wed, 23 Nov 2011 18:46:55 +0000
Subject: [issue13465] A Jython section in the dev guide would be great
Message-ID: <1322074015.2.0.311635199294.issue13465@psf.upfronthosting.co.za>


New submission from Frank Wierzbicki <fwierzbicki at gmail.com>:

Nick suggested this as a comment on a blog post of mine -- I'll come up with some content, but I wanted to log the bug straight away so I wouldn't forget.

----------
components: Devguide
messages: 148200
nosy: brett.cannon, ezio.melotti, fwierzbicki, ncoghlan
priority: normal
severity: normal
status: open
title: A Jython section in the dev guide would be great
type: feature request

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13465>
_______________________________________

From report at bugs.python.org  Wed Nov 23 20:10:47 2011
From: report at bugs.python.org (=?utf-8?q?Stanis=C5=82aw_Jankowski?=)
Date: Wed, 23 Nov 2011 19:10:47 +0000
Subject: [issue13425] http.client.HTTPMessage.getallmatchingheaders() always
	returns
In-Reply-To: <1321614230.59.0.764469605478.issue13425@psf.upfronthosting.co.za>
Message-ID: <1322075447.09.0.429639956224.issue13425@psf.upfronthosting.co.za>


Stanis?aw Jankowski <stach.jankowski at gmail.com> added the comment:

This issue has been reported previously, in issue5053. Unfortunately, I overlooked. Sorry.

----------
resolution:  -> duplicate
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13425>
_______________________________________

From report at bugs.python.org  Wed Nov 23 20:26:41 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Wed, 23 Nov 2011 19:26:41 +0000
Subject: [issue5054] CGIHTTPRequestHandler.run_cgi() HTTP_ACCEPT improperly
	parsed
In-Reply-To: <1232897403.01.0.0399148938595.issue5054@psf.upfronthosting.co.za>
Message-ID: <1322076401.89.0.734812266306.issue5054@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/issue5054>
_______________________________________

From report at bugs.python.org  Wed Nov 23 20:26:52 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Wed, 23 Nov 2011 19:26:52 +0000
Subject: [issue5053] http.client.HTTPMessage.getallmatchingheaders() always
	returns []
In-Reply-To: <1232897073.53.0.7443757693.issue5053@psf.upfronthosting.co.za>
Message-ID: <1322076412.69.0.384610733431.issue5053@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/issue5053>
_______________________________________

From report at bugs.python.org  Wed Nov 23 20:31:58 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Wed, 23 Nov 2011 19:31:58 +0000
Subject: [issue13425] http.client.HTTPMessage.getallmatchingheaders() always
	returns
In-Reply-To: <1321614230.59.0.764469605478.issue13425@psf.upfronthosting.co.za>
Message-ID: <1322076718.64.0.716772951475.issue13425@psf.upfronthosting.co.za>


Changes by Petri Lehtinen <petri at digip.org>:


----------
superseder:  -> http.client.HTTPMessage.getallmatchingheaders() always returns []

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13425>
_______________________________________

From report at bugs.python.org  Wed Nov 23 20:32:28 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Wed, 23 Nov 2011 19:32:28 +0000
Subject: [issue13425] http.client.HTTPMessage.getallmatchingheaders() always
	returns []
In-Reply-To: <1321614230.59.0.764469605478.issue13425@psf.upfronthosting.co.za>
Message-ID: <1322076748.29.0.652138942814.issue13425@psf.upfronthosting.co.za>


Changes by Petri Lehtinen <petri at digip.org>:


----------
title: http.client.HTTPMessage.getallmatchingheaders() always returns -> http.client.HTTPMessage.getallmatchingheaders() always returns []

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13425>
_______________________________________

From report at bugs.python.org  Wed Nov 23 20:33:25 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Wed, 23 Nov 2011 19:33:25 +0000
Subject: [issue5053] http.client.HTTPMessage.getallmatchingheaders() always
	returns []
In-Reply-To: <1232897073.53.0.7443757693.issue5053@psf.upfronthosting.co.za>
Message-ID: <1322076805.95.0.179797728239.issue5053@psf.upfronthosting.co.za>


Petri Lehtinen <petri at digip.org> added the comment:

#13425 was marked as duplicate of this issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5053>
_______________________________________

From report at bugs.python.org  Wed Nov 23 20:38:02 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Wed, 23 Nov 2011 19:38:02 +0000
Subject: [issue4773] HTTPMessage not documented and has inconsistent API
	across 2.6/3.0
In-Reply-To: <1230586952.45.0.591912771259.issue4773@psf.upfronthosting.co.za>
Message-ID: <1322077082.79.0.112978551957.issue4773@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/issue4773>
_______________________________________

From report at bugs.python.org  Wed Nov 23 20:58:43 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Wed, 23 Nov 2011 19:58:43 +0000
Subject: [issue13439] turtle: Errors in docstrings of onkey and onkeypress
In-Reply-To: <1321802124.14.0.262913683551.issue13439@psf.upfronthosting.co.za>
Message-ID: <1322078323.86.0.610707410155.issue13439@psf.upfronthosting.co.za>


Petri Lehtinen <petri at digip.org> added the comment:

There are actually many problems with docstrings of both onkey() and onkeypress().

Both:

- "Turtle instance named turtle" isn't used in the example

- The repl/doctest syntax is weird

onkeypress only:

- "key-press event" vs. "key-press-event"

- The example uses onkey() instead of onkeypress()

- The bottom comment says that the example draws a hexagon, but it actually draws a straight line.

----------
stage: committed/rejected -> 
title: turtle docstring for onkeyrelease references onkey, not onkeyrelease -> turtle: Errors in docstrings of onkey and onkeypress

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13439>
_______________________________________

From report at bugs.python.org  Wed Nov 23 21:00:48 2011
From: report at bugs.python.org (Aleksey)
Date: Wed, 23 Nov 2011 20:00:48 +0000
Subject: [issue13466] new timezones
Message-ID: <1322078448.54.0.772868924392.issue13466@psf.upfronthosting.co.za>


New submission from Aleksey <shitsu16 at gmail.com>:

Hi Guys,
Since 31 august 2011 in Russian Federation always DST time.
http://worldtimezone.net/dst_news/dst_news_russia36.html

But
>>> time.tzname
('MSK', 'MSK')
>>> time.localtime().tm_isdst
0
>>> time.timezone
-10800
>>> time.altzone
-14400

i think tm_isdst must be always 1 for my zone, or timezone must be equal altzone

----------
messages: 148204
nosy: Rioky
priority: normal
severity: normal
status: open
title: new timezones
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13466>
_______________________________________

From report at bugs.python.org  Wed Nov 23 21:01:50 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Wed, 23 Nov 2011 20:01:50 +0000
Subject: [issue13439] turtle: Errors in docstrings of onkey and onkeypress
In-Reply-To: <1321802124.14.0.262913683551.issue13439@psf.upfronthosting.co.za>
Message-ID: <1322078510.07.0.511525955303.issue13439@psf.upfronthosting.co.za>


Petri Lehtinen <petri at digip.org> added the comment:

The problems with onkey() are also there in 2.7. onkeypress() is new in 3.x.

----------
keywords: +easy
stage:  -> needs patch
versions: +Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13439>
_______________________________________

From report at bugs.python.org  Wed Nov 23 21:57:11 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 23 Nov 2011 20:57:11 +0000
Subject: [issue13466] new timezones
In-Reply-To: <1322078448.54.0.772868924392.issue13466@psf.upfronthosting.co.za>
Message-ID: <1322081831.62.0.370488283352.issue13466@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
components: +Extension Modules
nosy: +belopolsky, lemburg
stage:  -> test needed
versions: +Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13466>
_______________________________________

From report at bugs.python.org  Wed Nov 23 22:00:19 2011
From: report at bugs.python.org (A.M. Kuchling)
Date: Wed, 23 Nov 2011 21:00:19 +0000
Subject: [issue13443] wrong links and examples in the functional HOWTO
In-Reply-To: <1321850404.45.0.767133152656.issue13443@psf.upfronthosting.co.za>
Message-ID: <1322082019.87.0.764544362818.issue13443@psf.upfronthosting.co.za>


A.M. Kuchling <lists at amk.ca> added the comment:

Here's a patch against the 3.3 trunk.

----------
Added file: http://bugs.python.org/file23765/functional-patch.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13443>
_______________________________________

From report at bugs.python.org  Wed Nov 23 22:35:33 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 23 Nov 2011 21:35:33 +0000
Subject: [issue13466] new timezones
In-Reply-To: <1322078448.54.0.772868924392.issue13466@psf.upfronthosting.co.za>
Message-ID: <1322084133.98.0.943951192814.issue13466@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

On my Ubuntu machine, I get:

$ zdump -v Europe/Moscow | grep 201[0-9]
Europe/Moscow  Sat Mar 27 22:59:59 2010 UTC = Sun Mar 28 01:59:59 2010 MSK isdst=0 gmtoff=10800
Europe/Moscow  Sat Mar 27 23:00:00 2010 UTC = Sun Mar 28 03:00:00 2010 MSD isdst=1 gmtoff=14400
Europe/Moscow  Sat Oct 30 22:59:59 2010 UTC = Sun Oct 31 02:59:59 2010 MSD isdst=1 gmtoff=14400
Europe/Moscow  Sat Oct 30 23:00:00 2010 UTC = Sun Oct 31 02:00:00 2010 MSK isdst=0 gmtoff=10800
Europe/Moscow  Sat Mar 26 22:59:59 2011 UTC = Sun Mar 27 01:59:59 2011 MSK isdst=0 gmtoff=10800
Europe/Moscow  Sat Mar 26 23:00:00 2011 UTC = Sun Mar 27 03:00:00 2011 MSK isdst=0 gmtoff=14400
[and nothing else, whereas other locations can show changes up to year 2499]

If I read this information correctly, this says that about 8 months ago, DST was not applied as usual; instead, the definition of MSK changed from UTC+3 to UTC+4.
Of course Python uses the same data, so is right to display tm_idst=0.

OTOH, time.timezone should be -4*3600==-14400, and here I think Python is wrong.  Also, time.daylight should be zero, whereas:

$ TZ=Europe/Moscow ./python
Python 3.3.0a0 (default:53cc2668d54f, Nov 23 2011, 22:19:40) 
[GCC 4.4.3] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import time
>>> time.tzname, time.timezone, time.daylight
(('MSK', 'MSK'), -10800, 1)

The error comes from the way Python computes timezone and daylight: it queries the tm_gmtoff of two timestamps, one close to the first of January, the other close to the first of July.  But last January the previous definition of the timezone was still in force...  and indeed, when I changed the code to use *next* January instead, I have the expected values.

Is there an algorithm that gives the correct answer?  Taking the 1st of January closest to the current date would not work either.  Or is there another way (in portable C) to approach timezones?

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13466>
_______________________________________

From report at bugs.python.org  Wed Nov 23 23:12:49 2011
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Wed, 23 Nov 2011 22:12:49 +0000
Subject: [issue13466] new timezones
In-Reply-To: <1322084133.98.0.943951192814.issue13466@psf.upfronthosting.co.za>
Message-ID: <4ECD6FCE.6010604@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Amaury Forgeot d'Arc wrote:
> 
> The error comes from the way Python computes timezone and daylight: it queries the tm_gmtoff of two timestamps, one close to the first of January, the other close to the first of July.  But last January the previous definition of the timezone was still in force...  and indeed, when I changed the code to use *next* January instead, I have the expected values.
> 
> Is there an algorithm that gives the correct answer?  Taking the 1st of January closest to the current date would not work either.  Or is there another way (in portable C) to approach timezones?

A fairly "correct" way is to query the time zone database at time module
import time by using the DST and GMT offset of that time.

IMO time.timezone and time.daylight should be deprecated since they
will give wrong results around DST changes (both switch times and
legal changes such as the described one) in long running processes
such as daemons.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13466>
_______________________________________

From report at bugs.python.org  Wed Nov 23 23:16:57 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Wed, 23 Nov 2011 22:16:57 +0000
Subject: [issue4111] Add Systemtap/DTrace probes
In-Reply-To: <1223827695.04.0.0893695004368.issue4111@psf.upfronthosting.co.za>
Message-ID: <1322086617.02.0.174052135224.issue4111@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

This project continues in issue #13405.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4111>
_______________________________________

From report at bugs.python.org  Wed Nov 23 23:26:07 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 23 Nov 2011 22:26:07 +0000
Subject: [issue10318] "make altinstall" installs many files with incorrect
	shebangs
In-Reply-To: <1288926610.35.0.932494150274.issue10318@psf.upfronthosting.co.za>
Message-ID: <1322087167.85.0.126098373052.issue10318@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Hmm, interesting mailing list post - I hadn't thought about how the auto-initialisation of sys.path[0] aligns with the Windows vs Unix difference in PATH handling (i.e. whether or not the current directory is considered to be on PATH), with Python coming down in favour of the usually-more-convenient-but-less-secure Windows approach.

We have -S to disable all site processing, -s to disable user site packages and -E to ignore PYTHONPATH and PYTHONHOME - perhaps there should be another flag to skip the auto-initialisation of sys.path[0]. I may include something along those lines in PEP 395.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10318>
_______________________________________

From report at bugs.python.org  Wed Nov 23 23:57:30 2011
From: report at bugs.python.org (anatoly techtonik)
Date: Wed, 23 Nov 2011 22:57:30 +0000
Subject: [issue13405] Add DTrace probes
In-Reply-To: <1321299726.66.0.343368151185.issue13405@psf.upfronthosting.co.za>
Message-ID: <1322089050.23.0.658983135573.issue13405@psf.upfronthosting.co.za>


Changes by anatoly techtonik <techtonik at gmail.com>:


----------
nosy: +techtonik

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13405>
_______________________________________

From report at bugs.python.org  Thu Nov 24 00:11:08 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 23 Nov 2011 23:11:08 +0000
Subject: [issue13455] Reorganize tracker docs in the devguide
In-Reply-To: <1321984554.54.0.834071786299.issue13455@psf.upfronthosting.co.za>
Message-ID: <1322089868.98.0.515629705388.issue13455@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

> I think the reason these docs are scattered is that the devguide is a 
> guide, not a reference manual. I don't think this patch makes sense: if 
> the tracker really needed so much text to explain how it works, then 
> the tracker would have a severe UI problem. Most people use bug
> trackers without ever reading a manual first.

This is true, however different people can figure out a different amount of things just by using and experiment with something.  While most of the tasks should be obvious, some are a bit more advanced, and even the "obvious" once might not be obvious for everyone.  So IMHO writing down a few sentences doesn't hurt.
Also the lines between developer, contributor, and user that reports an issue are not so well defined, so it might be ok to add information that are not aimed just to core-developers in the devguide.

> If someone just wants to report a bug, then sure, they shouldn't need 
> to read the dev guide 

I also don't expect them to follow the bugs page in the doc step by step.  I think they can figure out most of the steps on their own -- but if they get stuck with a specific step (e.g. registration), they should be able to find more information about it easily.  Having all the doc in the same place and a short section for each possible step would solve this, and it's IMHO better than a descriptive section of the whole process.  Similarly this applies for the description of the fields (that's why I used a list and highlighted with bold text the fields' names).

> (so I disagree with the idea of making any significant changes
>  to the bugs page in the docs)

I was planning to replace it with a paragraph that says that something like "If you think you found an issue, you can search the bug tracker at <bugs.python.org> to see if the issue is known.  If it's not, you can register to the issue tracker and report it.  For more information see the <devguide>.  It is not possible to submit anonymous reports."

> It would also give us a place to document the auto-linkification 
> rules (similar to what was done recently for the post-commit hooks).

This is already documented in the "triaging" page, in the section about the "Comment" field.


This issue was initially reported on the meta tracker[0], I moved the discussion here to get more people involved before making changes.

[0]: http://psf.upfronthosting.co.za/roundup/meta/issue119

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13455>
_______________________________________

From report at bugs.python.org  Thu Nov 24 00:17:35 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 23 Nov 2011 23:17:35 +0000
Subject: [issue13466] new timezones
In-Reply-To: <1322078448.54.0.772868924392.issue13466@psf.upfronthosting.co.za>
Message-ID: <1322090255.57.0.5529039197.issue13466@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

> A fairly "correct" way is to query the time zone database at time module
> import time by using the DST and GMT offset of that time.

But that does not give the *other* timezone :-(

> IMO time.timezone and time.daylight should be deprecated since they
> will give wrong results around DST changes (both switch times and
> legal changes such as the described one) in long running processes
> such as daemons.

time.timezone is the non-DST timezone: this value does not change around
the DST change date.  That's why the current implementation uses "absolute"
dates like the of January: DST changes are often in March and October.

What about this algorithm:
- pick the first of January and the first of July surrounding the current date
- if both have tm_idst==0, the region has no DST. Use the current GMT offset for
  both timezone and altzone; daylight=0
- otherwise, use the *current* time and get its DST and GMT offset. This is enough
to compute both timezone and altzone (with the relation altzone=timezone-3600)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13466>
_______________________________________

From report at bugs.python.org  Thu Nov 24 00:19:28 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 23 Nov 2011 23:19:28 +0000
Subject: [issue13466] new timezones
In-Reply-To: <1322078448.54.0.772868924392.issue13466@psf.upfronthosting.co.za>
Message-ID: <1322090368.28.0.0815149576897.issue13466@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Another way to fix the issue is to wait 40 days.  There won't be any release in-between anyway!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13466>
_______________________________________

From report at bugs.python.org  Thu Nov 24 00:28:04 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 23 Nov 2011 23:28:04 +0000
Subject: [issue13448] PEP 3155 implementation
In-Reply-To: <1321908830.82.0.349913947268.issue13448@psf.upfronthosting.co.za>
Message-ID: <1322090884.61.0.209564751244.issue13448@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


Added file: http://bugs.python.org/file23766/942ba1e2f8c1.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13448>
_______________________________________

From report at bugs.python.org  Thu Nov 24 00:29:40 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 23 Nov 2011 23:29:40 +0000
Subject: [issue13448] PEP 3155 implementation
In-Reply-To: <1321908830.82.0.349913947268.issue13448@psf.upfronthosting.co.za>
Message-ID: <1322090980.13.0.234545479857.issue13448@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

New patch addressing Benjamin's and Victor's comments.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13448>
_______________________________________

From report at bugs.python.org  Thu Nov 24 00:38:24 2011
From: report at bugs.python.org (sbt)
Date: Wed, 23 Nov 2011 23:38:24 +0000
Subject: [issue12328] multiprocessing's overlapped PipeConnection on Windows
In-Reply-To: <1307991196.59.0.849860111943.issue12328@psf.upfronthosting.co.za>
Message-ID: <1322091504.45.0.551082620446.issue12328@psf.upfronthosting.co.za>


sbt <shibturn at gmail.com> added the comment:

> It seems to me that ERROR_OPERATION_ABORTED is a "true" error, and so
> should raise an exception.

I guess so, although we do expect it whenever poll() times out.  What exception would be appropriate? BlockingIOError? TimeoutError?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12328>
_______________________________________

From report at bugs.python.org  Thu Nov 24 00:51:26 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 23 Nov 2011 23:51:26 +0000
Subject: [issue13455] Reorganize tracker docs in the devguide
In-Reply-To: <1322089868.98.0.515629705388.issue13455@psf.upfronthosting.co.za>
Message-ID: <1322091978.3284.8.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> This is true, however different people can figure out a different
> amount of things just by using and experiment with something.  While
> most of the tasks should be obvious, some are a bit more advanced, and
> even the "obvious" once might not be obvious for everyone.  So IMHO
> writing down a few sentences doesn't hurt.

Well, it does hurt, because the more sentences you write, the more the
devguide becomes bloated and difficult to follow (especially for
non-native English speakers who might not read English very fast). The
devguide is *already* too big.

The devguide was supposed to be something that you read quickly and
easily, not an exhaustive reference of how development works. Or at
least there should be a clear separation between the two (the guide
part, and the reference part). The guide part being the most important,
while the reference is really optional.

And, really, if you want people to feel more comfortable with the
tracker, it would be more productive to improve the tracker itself. No
amount of documentation will make a UI usable.

> Also the lines between developer, contributor, and user that reports
> an issue are not so well defined, so it might be ok to add information
> that are not aimed just to core-developers in the devguide.

The devguide is *not* primarily for core developers. It's for new
contributors who want to get set up, so that they don't give up in the
absence of clear indications. Being useful for core developers is a nice
extra, but it was not the original intent.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13455>
_______________________________________

From report at bugs.python.org  Thu Nov 24 01:13:41 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 24 Nov 2011 00:13:41 +0000
Subject: [issue13448] PEP 3155 implementation
In-Reply-To: <1321908830.82.0.349913947268.issue13448@psf.upfronthosting.co.za>
Message-ID: <1322093621.19.0.170916756299.issue13448@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Ah, PyFunction_NewWithQualName is now public.

Why an upper P in "PyFunction_NewWithQualName"? If you use an upper P, it should use an underscore in Python: __qual_name__ to be consistent. So I suggest to change the C name :-) PyFunction_NewWithQualname or PyFunction_NewWithQualifiedName. I don't have a preference between these two choices.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13448>
_______________________________________

From report at bugs.python.org  Thu Nov 24 01:17:18 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 24 Nov 2011 00:17:18 +0000
Subject: [issue13415] del os.environ[key] ignores errors
In-Reply-To: <1321481687.96.0.070295281604.issue13415@psf.upfronthosting.co.za>
Message-ID: <1322093838.64.0.416692114124.issue13415@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
title: del os.environ -> del os.environ[key] ignores errors

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13415>
_______________________________________

From report at bugs.python.org  Thu Nov 24 01:27:29 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 24 Nov 2011 00:27:29 +0000
Subject: [issue12328] multiprocessing's overlapped PipeConnection on Windows
In-Reply-To: <1322091504.45.0.551082620446.issue12328@psf.upfronthosting.co.za>
Message-ID: <1322094141.3284.11.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> > It seems to me that ERROR_OPERATION_ABORTED is a "true" error, and so
> > should raise an exception.
> 
> I guess so, although we do expect it whenever poll() times out.  What
> exception would be appropriate? BlockingIOError? TimeoutError?

I would say either an OSError with the appropriate winerror, or a
specific exception (_multiprocessing.win32.OperationAbortedError?).
Or perhaps a ValueError.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12328>
_______________________________________

From report at bugs.python.org  Thu Nov 24 01:28:10 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 24 Nov 2011 00:28:10 +0000
Subject: [issue13448] PEP 3155 implementation
In-Reply-To: <1322093621.19.0.170916756299.issue13448@psf.upfronthosting.co.za>
Message-ID: <1322094182.3284.12.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Why an upper P in "PyFunction_NewWithQualName"? If you use an upper P,
> it should use an underscore in Python: __qual_name__ to be consistent.

__getattr__ / PyObject_GetAttr.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13448>
_______________________________________

From report at bugs.python.org  Thu Nov 24 01:49:34 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 24 Nov 2011 00:49:34 +0000
Subject: [issue13465] A Jython section in the dev guide would be great
In-Reply-To: <1322074015.2.0.311635199294.issue13465@psf.upfronthosting.co.za>
Message-ID: <1322095774.53.0.451632052851.issue13465@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Uh, rather -1 on this. I would suggest Jython gets its own devguide (which can of course copy stuff from CPython's), since Jython and CPython are distinct projects. No need to confuse readers by mixing instructions for two different projects in a single guide.

----------
nosy: +pitrou
resolution:  -> rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13465>
_______________________________________

From report at bugs.python.org  Thu Nov 24 02:37:30 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 24 Nov 2011 01:37:30 +0000
Subject: [issue13455] Reorganize tracker docs in the devguide
In-Reply-To: <1321984554.54.0.834071786299.issue13455@psf.upfronthosting.co.za>
Message-ID: <1322098650.32.0.494647861456.issue13455@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

> Well, it does hurt, because the more sentences you write, the more the
> devguide becomes bloated and difficult to follow

OTOH is easy to ignore an "how to register to the tracker" section if you are already registered or if you don't need to register now or you think you know how to do it.
Also note that I'm not adding these sections, but I'm just moving them from the bugs page in the doc (with some markup changes and refactoring).
The only section I added is "Finding an Issue You Can Help With".

> The devguide is *not* primarily for core developers. It's for new
> contributors who want to get set up, so that they don't give up in the
> absence of clear indications.

Agreed, and registering and using the bug tracker is part of this set up, regardless of how obvious the process is (or should be).

Anyway, it would be fine with me to not document these "basic" tasks (how to register/login/search), but it seems to me that people think that the content of the bugs page is useful, and I would rather have it with the rest in the devguide, rather than having it in a separate page.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13455>
_______________________________________

From report at bugs.python.org  Thu Nov 24 02:40:24 2011
From: report at bugs.python.org (Felix Steffenhagen)
Date: Thu, 24 Nov 2011 01:40:24 +0000
Subject: [issue13422] Subprocess: children hang due to open pipes
In-Reply-To: <1321562143.65.0.570707046808.issue13422@psf.upfronthosting.co.za>
Message-ID: <1322098824.21.0.0333834886389.issue13422@psf.upfronthosting.co.za>


Felix Steffenhagen <felix at sutus.com> added the comment:

The problem I have with the solution that is currently implemented is that subprocess is waiting for the spawned child although the child is not running anymore.
In my case this issue occured when invoking samba or the small sample daemon (see attached file above).
For example, invoking the daemon from a bash, the daemon program exits immediately and its spawned child is running in the background. The point is that the bash is accessible right after starting the daemon. It is not waiting for the daemon process in the background to close the open pipe.

What do you think of using a waitpid for this scenario?
subprocess.Popen could wait for the pid of the daemon starter and gets back control once the pid of the daemon starter is gone. This way, subprocess.Popen does not need to wait for EOF on left-open pipes.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13422>
_______________________________________

From report at bugs.python.org  Thu Nov 24 03:38:26 2011
From: report at bugs.python.org (INADA Naoki)
Date: Thu, 24 Nov 2011 02:38:26 +0000
Subject: [issue13467] Typo in doc for library/sysconfig
Message-ID: <1322102306.14.0.426447482004.issue13467@psf.upfronthosting.co.za>


New submission from INADA Naoki <songofacandy at gmail.com>:

http://docs.python.org/library/sysconfig.html#sysconfig.get_path

> If scheme is provided, it must be a value from the list returned by get_path_names().

s/get_path_names/get_scheme_names/

----------
assignee: docs at python
components: Documentation
messages: 148223
nosy: docs at python, naoki
priority: normal
severity: normal
status: open
title: Typo in doc for library/sysconfig
versions: Python 2.7, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13467>
_______________________________________

From report at bugs.python.org  Thu Nov 24 03:39:41 2011
From: report at bugs.python.org (Babak M)
Date: Thu, 24 Nov 2011 02:39:41 +0000
Subject: [issue5305] imaplib should support international mailbox names
In-Reply-To: <1234935371.11.0.35650041724.issue5305@psf.upfronthosting.co.za>
Message-ID: <1322102381.99.0.151631483179.issue5305@psf.upfronthosting.co.za>


Babak M <babak.mn at gmail.com> added the comment:

There's a working implementation of this in PloneMailList.
http://svn.plone.org/svn/collective/mxmImapClient/trunk/imapUTF7.py

----------
nosy: +BabakM

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5305>
_______________________________________

From report at bugs.python.org  Thu Nov 24 04:03:50 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 24 Nov 2011 03:03:50 +0000
Subject: [issue13465] A Jython section in the dev guide would be great
In-Reply-To: <1322074015.2.0.311635199294.issue13465@psf.upfronthosting.co.za>
Message-ID: <1322103830.43.0.769611327156.issue13465@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Hosting "docs.python.org/devguide/jython" doesn't seem like an unreasonable idea at all to me, and what's the benefit to CPython in making the Jython team go to the effort of building out independent deployment and source control infrastructure for their own devguide?

wiki.python.org is already shared between the two projects, and pydotorg hosts the Jython source control infrastructure in addition to CPython's.

More generally, given that we now provide cross-links to PyPy, Jython and IronPython from the download pages, it also seems reasonable to provide pointers to their own "get involved" resources from the CPython devguide.

----------
resolution: rejected -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13465>
_______________________________________

From report at bugs.python.org  Thu Nov 24 04:49:55 2011
From: report at bugs.python.org (Tom Dignan)
Date: Thu, 24 Nov 2011 03:49:55 +0000
Subject: [issue13468] Python 2.7.1 SegmentationFaults when given high
	recursion limit
Message-ID: <1322106595.12.0.230558460851.issue13468@psf.upfronthosting.co.za>


New submission from Tom Dignan <tom at adeptdev.com>:

On my system, the magic number to make this segfault seems to be 26200:

tom at tralfamadore ~/Downloads $ python recur1.py  26199
160164968

tom at tralfamadore ~/Downloads $ python recur1.py  26200
Segmentation fault

Here's the source:

#!/usr/bin/python
import sys

if len(sys.argv) < 2:
    print "usage %r <number>" % sys.argv[0]
    sys.exit(1)

number = int(sys.argv[1])

sys.setrecursionlimit(number + 2)

f = (lambda n: (f(n - 1) if n > 0 else 0) + 
    (n if n % 3 == 0 or n % 5 == 0 else 0))

print f(number)

sys.exit(0)

----------
components: None
messages: 148226
nosy: tdignan
priority: normal
severity: normal
status: open
title: Python 2.7.1 SegmentationFaults when given high recursion limit
type: crash
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13468>
_______________________________________

From report at bugs.python.org  Thu Nov 24 04:56:08 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 24 Nov 2011 03:56:08 +0000
Subject: [issue11816] Refactor the dis module to provide better building
	blocks for bytecode analysis
In-Reply-To: <1302394810.0.0.38146154248.issue11816@psf.upfronthosting.co.za>
Message-ID: <1322106968.78.0.488212001494.issue11816@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Meador's suggested name change has grown on me, so I plan to switch the name of the new API to "get_instructions()" and the new class to "Instruction".

----------
assignee: rhettinger -> ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11816>
_______________________________________

From report at bugs.python.org  Thu Nov 24 05:52:14 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Thu, 24 Nov 2011 04:52:14 +0000
Subject: [issue13443] wrong links and examples in the functional HOWTO
In-Reply-To: <1321850404.45.0.767133152656.issue13443@psf.upfronthosting.co.za>
Message-ID: <1322110334.37.0.59802972179.issue13443@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

Andrew, thanks, but I still think it's a bigger problem that the page discusses a module which is not available on Python 3.x - this means that a user following the page can't just type in the code and make it run.

The links can be fixed and kept there, as ?ric suggests, perhaps with a disclaimer, but code on the page itself should be valid - this is part of our official documentation, after all.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13443>
_______________________________________

From report at bugs.python.org  Thu Nov 24 06:22:45 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 24 Nov 2011 05:22:45 +0000
Subject: [issue13468] Python 2.7.1 SegmentationFaults when given high
	recursion limit
In-Reply-To: <1322106595.12.0.230558460851.issue13468@psf.upfronthosting.co.za>
Message-ID: <1322112165.6.0.675131768239.issue13468@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Of course; that's what the recursion limit protects against.

----------
nosy: +benjamin.peterson
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13468>
_______________________________________

From report at bugs.python.org  Thu Nov 24 08:10:39 2011
From: report at bugs.python.org (Jussi Eronen)
Date: Thu, 24 Nov 2011 07:10:39 +0000
Subject: [issue13469] TimedRotatingFileHandler fails to handle intervals of
	several weeks correctly
Message-ID: <1322118639.78.0.741046011353.issue13469@psf.upfronthosting.co.za>


New submission from Jussi Eronen <exec at iki.fi>:

When specifying a time period of several weeks, say when w0 and interval 4, the rollover still happens weekly instead of every 4 weeks. The log file names are as though the rollover happens every 4 weeks, which furthers the confusion. 

In the file system, it looks like this:

-rw-r----- 1 x x  94189100 2011-10-24 23:59 x.log.2011-09-27
-rw-r----- 1 x x  51059765 2011-11-01 00:59 x.log.2011-10-04

This seems to be the result of computeRollover not handling multiple weeks at all.

----------
components: Library (Lib)
messages: 148230
nosy: exec
priority: normal
severity: normal
status: open
title: TimedRotatingFileHandler fails to handle intervals of several weeks correctly
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13469>
_______________________________________

From report at bugs.python.org  Thu Nov 24 08:23:52 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Thu, 24 Nov 2011 07:23:52 +0000
Subject: [issue13469] TimedRotatingFileHandler fails to handle intervals of
	several weeks correctly
In-Reply-To: <1322118639.78.0.741046011353.issue13469@psf.upfronthosting.co.za>
Message-ID: <1322119432.96.0.395236835286.issue13469@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/issue13469>
_______________________________________

From report at bugs.python.org  Thu Nov 24 08:26:00 2011
From: report at bugs.python.org (Florent Xicluna)
Date: Thu, 24 Nov 2011 07:26:00 +0000
Subject: [issue13470] A user may need ... when she has ...
Message-ID: <1322119560.63.0.526352282157.issue13470@psf.upfronthosting.co.za>


New submission from Florent Xicluna <florent.xicluna at gmail.com>:

http://docs.python.org/library/sys.html#sys.setrecursionlimit
http://docs.python.org/dev/library/sys.html#sys.setrecursionlimit

Doc for Python 2.7 says:
"A user may need to set the limit higher when she has ..."

Doc for Python 3.3 says:
"A user may need to set the limit higher when they have ..."


IMHO "she" and "they" are not right here.
Is it an initiative of the "Python diversity" group :-)

----------
assignee: docs at python
components: Documentation
messages: 148231
nosy: docs at python, flox
priority: low
severity: normal
stage: needs patch
status: open
title: A user may need ... when she has ...
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13470>
_______________________________________

From report at bugs.python.org  Thu Nov 24 08:48:33 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Thu, 24 Nov 2011 07:48:33 +0000
Subject: [issue12170] index() and count() methods of bytes and bytearray
	should accept byte ints
In-Reply-To: <1306266550.46.0.554812052221.issue12170@psf.upfronthosting.co.za>
Message-ID: <1322120913.18.0.449736953752.issue12170@psf.upfronthosting.co.za>


Petri Lehtinen <petri at digip.org> added the comment:

Just a thought: Would this change be worthy for the "What's new in 3.3" list?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12170>
_______________________________________

From report at bugs.python.org  Thu Nov 24 10:18:17 2011
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Thu, 24 Nov 2011 09:18:17 +0000
Subject: [issue13466] new timezones
In-Reply-To: <1322090255.57.0.5529039197.issue13466@psf.upfronthosting.co.za>
Message-ID: <4ECE0BC5.7070504@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Amaury Forgeot d'Arc wrote:
> 
> Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:
> 
>> A fairly "correct" way is to query the time zone database at time module
>> import time by using the DST and GMT offset of that time.
> 
> But that does not give the *other* timezone :-(

Which other timezone ?

You set time.timezone to the GMT offset of the import time
and then subtract another 3600 seconds in case tm_isdst is
set.

>> IMO time.timezone and time.daylight should be deprecated since they
>> will give wrong results around DST changes (both switch times and
>> legal changes such as the described one) in long running processes
>> such as daemons.
> 
> time.timezone is the non-DST timezone: this value does not change around
> the DST change date. 

No, but time.daylight changes and time.timezone can change in situations
like these where a region decides to change the way DST is dealt
with, e.g. switches to the DST timezone or moves the switchover date.

Since both values are tied to a specific time I don't think it's
a good idea to have them as module globals.

> That's why the current implementation uses "absolute"
> dates like the of January: DST changes are often in March and October.

Such an algorithm can be used as fallback solution in case
tm_isdst is -1 (unknown), but not in case the DST information
is available.

> What about this algorithm:
> - pick the first of January and the first of July surrounding the current date
> - if both have tm_idst==0, the region has no DST. Use the current GMT offset for
>   both timezone and altzone; daylight=0

Those two steps are not necessary. If tm_isdst == 0, you already know that
the current time zone is not DST.

> - otherwise, use the *current* time and get its DST and GMT offset. This is enough
> to compute both timezone and altzone (with the relation altzone=timezone-3600)

That's what I suggested above.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13466>
_______________________________________

From report at bugs.python.org  Thu Nov 24 10:54:06 2011
From: report at bugs.python.org (flying sheep)
Date: Thu, 24 Nov 2011 09:54:06 +0000
Subject: [issue12776] argparse: type conversion function should be called only
	once
In-Reply-To: <1313657878.1.0.958946060112.issue12776@psf.upfronthosting.co.za>
Message-ID: <1322128446.78.0.599369995243.issue12776@psf.upfronthosting.co.za>


flying sheep <flying-sheep at web.de> added the comment:

this is annoying:

i?m creating a reindentation script that reindents any valid python script. the user can specify if, and how many spaces he/she wants to use per indentation level. `0` or leaving the option out means ?one tab per level?.

if the argument is given, appended code works as intended. but in the default case, the code fails for any of the two default values i tried.

i would expect that one of the default values works: either `0`, if the default value *is* converted via the `type` function, or `"\t"` if the default value bypasses it.

it seems that argparse applies the `type` function to the default instantly, and then to the argument (be it the already-converted default or a passed option).

this breaks `type` functions which aren?t reflexive for values from their result set, i.e.: `t(x) = y => t(y) = y` must be true for all `x` that the function can handle

----------
nosy: +flying sheep
Added file: http://bugs.python.org/file23767/argparse_test.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12776>
_______________________________________

From report at bugs.python.org  Thu Nov 24 11:20:09 2011
From: report at bugs.python.org (Arnaud Fontaine)
Date: Thu, 24 Nov 2011 10:20:09 +0000
Subject: [issue12776] argparse: type conversion function should be called only
	once
In-Reply-To: <1313657878.1.0.958946060112.issue12776@psf.upfronthosting.co.za>
Message-ID: <1322130009.96.0.3525430332.issue12776@psf.upfronthosting.co.za>


Arnaud Fontaine <arnau at debian.org> added the comment:

Does the patch I attached fix your issue?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12776>
_______________________________________

From report at bugs.python.org  Thu Nov 24 11:25:31 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 24 Nov 2011 10:25:31 +0000
Subject: [issue13465] A Jython section in the dev guide would be great
In-Reply-To: <1322103830.43.0.769611327156.issue13465@psf.upfronthosting.co.za>
Message-ID: <1322130022.3288.19.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Hosting "docs.python.org/devguide/jython" doesn't seem like an
> unreasonable idea at all to me, and what's the benefit to CPython in
> making the Jython team go to the effort of building out independent
> deployment and source control infrastructure for their own devguide?

We can *host* (in the Web hosting sense) the jython devguide. That
certainly doesn't mean it belongs in the same piece of documentation.

Our devguide was created to explain how to contribute to the CPython
project. Creating a Jython section only makes things messier than they
are, and it certainly doesn't help our users.

Really, I'm sure setting up a crontab and creating an hg repo is easy
enough for the Jython people (or whoever wants to help them in that
matter).

> wiki.python.org is already shared between the two projects, and
> pydotorg hosts the Jython source control infrastructure in addition to
> CPython's.

Providing infrastructure is not the same as sharing the development
resources themselves. We don't share the (CPython) hg repo, and we don't
share the (CPython) bug tracker. There's no reason to share the
(CPython) devguide, not until the two projects merge together.

(as for the wiki... well, suffice to say that it's a terrible mess and I
hope it's not an example for the devguide. If the wiki was actually
useful and practical we wouldn't have made the devguide a separate site,
I guess)

> More generally, given that we now provide cross-links to PyPy, Jython
> and IronPython from the download pages, it also seems reasonable to
> provide pointers to their own "get involved" resources from the
> CPython devguide.

We already provide pointers from the devguide:
http://docs.python.org/devguide/#other-interpreter-implementations
It's only a matter of changing the URLs if these projects ask us to.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13465>
_______________________________________

From report at bugs.python.org  Thu Nov 24 11:27:19 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 24 Nov 2011 10:27:19 +0000
Subject: [issue12170] index() and count() methods of bytes and bytearray
	should accept byte ints
In-Reply-To: <1306266550.46.0.554812052221.issue12170@psf.upfronthosting.co.za>
Message-ID: <1322130439.78.0.886144454785.issue12170@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Just a thought: Would this change be worthy for the "What's new in 3.3" 
> list?

I think so.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12170>
_______________________________________

From report at bugs.python.org  Thu Nov 24 11:31:28 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 24 Nov 2011 10:31:28 +0000
Subject: [issue13466] new timezones
In-Reply-To: <1322078448.54.0.772868924392.issue13466@psf.upfronthosting.co.za>
Message-ID: <1322130688.2.0.565362365512.issue13466@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

> > But that does not give the *other* timezone :-(
> Which other timezone ?
I meant the other timezone *name*.

I think we don't understand each other:
- time.timezone is the offset of the local (non-DST) timezone.
- time.altzone is the offset of local DST timezone.
They don't depend on the current date, they depend only on the timezone database.
localtime() only gives the timezone for a given point in time, and the time module needs to present two timezones.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13466>
_______________________________________

From report at bugs.python.org  Thu Nov 24 11:34:00 2011
From: report at bugs.python.org (flying sheep)
Date: Thu, 24 Nov 2011 10:34:00 +0000
Subject: [issue12776] argparse: type conversion function should be called only
	once
In-Reply-To: <1313657878.1.0.958946060112.issue12776@psf.upfronthosting.co.za>
Message-ID: <1322130840.97.0.941718325795.issue12776@psf.upfronthosting.co.za>


flying sheep <flying-sheep at web.de> added the comment:

i don?t know, since i get python from the ubuntu repositories, sorry.

in which python release will this patch first be integrated?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12776>
_______________________________________

From report at bugs.python.org  Thu Nov 24 11:49:03 2011
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Thu, 24 Nov 2011 10:49:03 +0000
Subject: [issue13466] new timezones
In-Reply-To: <1322130688.2.0.565362365512.issue13466@psf.upfronthosting.co.za>
Message-ID: <4ECE210A.5030504@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Amaury Forgeot d'Arc wrote:
> 
> Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:
> 
>>> But that does not give the *other* timezone :-(
>> Which other timezone ?
> I meant the other timezone *name*.
> 
> I think we don't understand each other:
> - time.timezone is the offset of the local (non-DST) timezone.
> - time.altzone is the offset of local DST timezone.

Yes, I know.

> They don't depend on the current date, they depend only on the timezone database.
> localtime() only gives the timezone for a given point in time, and the time module needs to present two timezones.

Right, but they should only depend on the data in the timezone
database at the time of import of the module and not determine
the values by looking at specific dates in the past.

The only problem is finding out whether the locale uses DST in
case the current import time points to a non-DST time. This can
be checked by looking at Jan 1st and June 1st after
the current import time (ie. in the future) and then testing
tm_isdst. If there is a DST change, then you set
time.altzone = time.timezone - 3600. Otherwise, you set
time.altzone = time.timezone.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13466>
_______________________________________

From report at bugs.python.org  Thu Nov 24 12:00:18 2011
From: report at bugs.python.org (Arnaud Fontaine)
Date: Thu, 24 Nov 2011 11:00:18 +0000
Subject: [issue12776] argparse: type conversion function should be called only
	once
In-Reply-To: <1313657878.1.0.958946060112.issue12776@psf.upfronthosting.co.za>
Message-ID: <1322132418.2.0.0365995915892.issue12776@psf.upfronthosting.co.za>


Arnaud Fontaine <arnau at debian.org> added the comment:

It would definitely help if you could apply the patch for Python 2.7 manually on your local installation (after making a backup of course). You can just download the patch for Python 2.7 then (only the first part of the patch can be applied, the second part is for the test so it doesn't matter):

# cd /usr/lib/python2.7/
# patch -b -p2 -i /PATH/TO/THE/PATCH

Thanks much.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12776>
_______________________________________

From report at bugs.python.org  Thu Nov 24 12:12:55 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 24 Nov 2011 11:12:55 +0000
Subject: [issue13415] del os.environ[key] ignores errors
In-Reply-To: <1321481687.96.0.070295281604.issue13415@psf.upfronthosting.co.za>
Message-ID: <1322133175.42.0.31918099235.issue13415@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Using broken_unsetenv.diff + autoconf, Python compiles correctly on Mac OS X Tiger.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13415>
_______________________________________

From report at bugs.python.org  Thu Nov 24 12:31:03 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 24 Nov 2011 11:31:03 +0000
Subject: [issue13470] A user may need ... when she has ...
In-Reply-To: <1322119560.63.0.526352282157.issue13470@psf.upfronthosting.co.za>
Message-ID: <1322134263.83.0.597766458132.issue13470@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

"they" is right and "she" is actually right too.

See http://en.wikipedia.org/wiki/Singular_they

----------
nosy: +pitrou
resolution:  -> works for me
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13470>
_______________________________________

From report at bugs.python.org  Thu Nov 24 13:26:25 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 24 Nov 2011 12:26:25 +0000
Subject: [issue13469] TimedRotatingFileHandler fails to handle intervals of
	several weeks correctly
In-Reply-To: <1322118639.78.0.741046011353.issue13469@psf.upfronthosting.co.za>
Message-ID: <1322137585.69.0.842083985815.issue13469@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +vinay.sajip
type:  -> behavior
versions: +Python 2.7, Python 3.2, Python 3.3 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13469>
_______________________________________

From report at bugs.python.org  Thu Nov 24 13:31:36 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 24 Nov 2011 12:31:36 +0000
Subject: [issue6407] multiprocessing Pool should allow custom task queue
In-Reply-To: <1246627398.56.0.0568609724018.issue6407@psf.upfronthosting.co.za>
Message-ID: <1322137896.78.0.956922213343.issue6407@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

As the name implies, _setup_queues is a private method. It feels a bit weird to recommend overriding it in a subclass.

----------
nosy: +pitrou
stage: test needed -> needs patch
versions: +Python 3.3 -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6407>
_______________________________________

From report at bugs.python.org  Thu Nov 24 13:52:51 2011
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 24 Nov 2011 12:52:51 +0000
Subject: [issue13415] del os.environ[key] ignores errors
In-Reply-To: <1321481687.96.0.070295281604.issue13415@psf.upfronthosting.co.za>
Message-ID: <E1RTYn6-0004L1-6d@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 1b83fd683e28 by Victor Stinner in branch 'default':
Close #13415: Test in configure if unsetenv() has a return value or not.
http://hg.python.org/cpython/rev/1b83fd683e28

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13415>
_______________________________________

From report at bugs.python.org  Thu Nov 24 13:58:12 2011
From: report at bugs.python.org (Ask Solem)
Date: Thu, 24 Nov 2011 12:58:12 +0000
Subject: [issue6407] multiprocessing Pool should allow custom task queue
In-Reply-To: <1246627398.56.0.0568609724018.issue6407@psf.upfronthosting.co.za>
Message-ID: <1322139492.66.0.950759627873.issue6407@psf.upfronthosting.co.za>


Ask Solem <ask at celeryproject.org> added the comment:

@swindmill, if you provide a doc/test patch then this can probably be merged.

@pitrou, We could change it to `setup_queues`, though I don't think
even changing the name of "private" methods is a good idea.  It could simply be an alias to `_setup_queues` or vice versa.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6407>
_______________________________________

From report at bugs.python.org  Thu Nov 24 14:46:24 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 24 Nov 2011 13:46:24 +0000
Subject: [issue10359] ISO C cleanup
In-Reply-To: <1289225493.06.0.31753137713.issue10359@psf.upfronthosting.co.za>
Message-ID: <1322142384.56.0.296648399385.issue10359@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Do the changes to Python/Python-ast.c and Modules/_ctypes/libffi/src/x86/ffi.c still apply?  (libffi is an external project, but our copy is already edited so we might as well do one more change).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10359>
_______________________________________

From report at bugs.python.org  Thu Nov 24 14:49:28 2011
From: report at bugs.python.org (Thorsten Simons)
Date: Thu, 24 Nov 2011 13:49:28 +0000
Subject: [issue13471] setting access time beyond Jan. 2038 on remote share
	failes on Win7 x64
Message-ID: <1322142567.98.0.834575465366.issue13471@psf.upfronthosting.co.za>


New submission from Thorsten Simons <th at snomis.de>:

Using Python '3.2.2 (default, Sep  4 2011, 09:07:29) [MSC v.1500 64 bit (AMD64)]' on Windows 7 Professional SP1:

If you set an access time for a file beyond Jan. 2038 on a file stored in a local NTFS filesystem, all's well:

>>> os.utime('c:\\temp_target\\ulp', (3433232323, 3433232323))
>>> os.stat('c:\\temp_target\\ulp')
nt.stat_result(st_mode=33206, st_ino=2251799813820060, st_dev=0, st_nlink=1, st_uid=0, st_gid=0, st_size=0, st_atime=3433232323, st_mtime=3433232323, st_ctime=1322133855)
>>> time.ctime(3433232323)
'Mon Oct 17 13:38:43 2078'

If you try to do this on a remote share (mounted as y:), provided by a Linux x64 box running Samba x64, things are different:

>>> os.utime('y:\\temp_target2\\ulp', (3433232323, 3433232323))
>>> os.stat('y:\\temp_target2\\ulp')
nt.stat_result(st_mode=33206, st_ino=67150103, st_dev=0, st_nlink=1, st_uid=0, st_gid=0, st_size=0, st_atime=910692730085, st_mtime=910692730085, st_ctime=1322133629)
>>> time.ctime(910692730085)
Traceback (most recent call last):
  File "<pyshell#22>", line 1, in <module>
    time.ctime(910692730085)
ValueError: unconvertible time

So, setting of access/modification time does not work - assumeably, we run into a 32-bit boundary somewhere...

Interestingly, if you set the respective access time from a Linux x64 box, you can see the right access time within Windows 7 via Explorer/Properties...

----------
components: Windows
messages: 148248
nosy: Thorsten.Simons
priority: normal
severity: normal
status: open
title: setting access time beyond Jan. 2038 on remote share failes on Win7 x64
type: behavior
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13471>
_______________________________________

From report at bugs.python.org  Thu Nov 24 14:52:49 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 24 Nov 2011 13:52:49 +0000
Subject: =?utf-8?q?=5Bissue13472=5D_Quick_Start_in_devguide_doesn=E2=80=99t_mentio?=
	=?utf-8?q?n_build_dependencies?=
Message-ID: <1322142769.6.0.687458451697.issue13472@psf.upfronthosting.co.za>


New submission from ?ric Araujo <merwok at netwok.org>:

The Quick Start section in the devguide does not tell people what they need to install in order to compile Python.  A short mention or a link to a section with all info should be added.

I can contribute info for Debian and derivative systems: ?aptitude build-dep pythonX.Y?

----------
messages: 148249
nosy: eric.araujo, ezio.melotti
priority: normal
severity: normal
status: open
title: Quick Start in devguide doesn?t mention build dependencies

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13472>
_______________________________________

From report at bugs.python.org  Thu Nov 24 14:53:08 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 24 Nov 2011 13:53:08 +0000
Subject: [issue12776] argparse: type conversion function should be called only
	once
In-Reply-To: <1313657878.1.0.958946060112.issue12776@psf.upfronthosting.co.za>
Message-ID: <1322142788.16.0.560386624319.issue12776@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Mucking with your installed Python is probably a bad idea, and it may also be an old version (compared to the current development version which has seen hundreds of changes) where testing the patch would not give useful results.  Please see the devguide.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12776>
_______________________________________

From report at bugs.python.org  Thu Nov 24 14:59:56 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 24 Nov 2011 13:59:56 +0000
Subject: [issue13471] setting access time beyond Jan. 2038 on remote share
	failes on Win7 x64
In-Reply-To: <1322142567.98.0.834575465366.issue13471@psf.upfronthosting.co.za>
Message-ID: <1322143196.31.0.929027754195.issue13471@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

The timestamp is converted to time_t (32 bits) and then to FILE_TIME (64 bits). A function to convert directly a PyObject to FILE_TIME should be written.

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13471>
_______________________________________

From report at bugs.python.org  Thu Nov 24 15:04:32 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 24 Nov 2011 14:04:32 +0000
Subject: [issue13448] PEP 3155 implementation
In-Reply-To: <1321908830.82.0.349913947268.issue13448@psf.upfronthosting.co.za>
Message-ID: <1322143472.85.0.486600655898.issue13448@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

BTW Antoine, will you update the doc to mention __qualname__ or would you like help?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13448>
_______________________________________

From report at bugs.python.org  Thu Nov 24 15:05:31 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 24 Nov 2011 14:05:31 +0000
Subject: [issue13448] PEP 3155 implementation
In-Reply-To: <1321908830.82.0.349913947268.issue13448@psf.upfronthosting.co.za>
Message-ID: <1322143531.46.0.860072936338.issue13448@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

And of course, right after I post this I look at my terminal and see the ?Add docs? commit.  Ignore me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13448>
_______________________________________

From report at bugs.python.org  Thu Nov 24 15:06:39 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 24 Nov 2011 14:06:39 +0000
Subject: [issue13448] PEP 3155 implementation
In-Reply-To: <1321908830.82.0.349913947268.issue13448@psf.upfronthosting.co.za>
Message-ID: <1322143599.21.0.0662841650856.issue13448@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
Removed message: http://bugs.python.org/msg148253

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13448>
_______________________________________

From report at bugs.python.org  Thu Nov 24 15:06:42 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 24 Nov 2011 14:06:42 +0000
Subject: [issue13448] PEP 3155 implementation
In-Reply-To: <1321908830.82.0.349913947268.issue13448@psf.upfronthosting.co.za>
Message-ID: <1322143602.29.0.41590350065.issue13448@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
Removed message: http://bugs.python.org/msg148252

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13448>
_______________________________________

From report at bugs.python.org  Thu Nov 24 15:07:15 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 24 Nov 2011 14:07:15 +0000
Subject: [issue13448] PEP 3155 implementation
In-Reply-To: <1321908830.82.0.349913947268.issue13448@psf.upfronthosting.co.za>
Message-ID: <1322143635.75.0.357968240766.issue13448@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Doc patch looks good.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13448>
_______________________________________

From report at bugs.python.org  Thu Nov 24 15:20:11 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 24 Nov 2011 14:20:11 +0000
Subject: =?utf-8?q?=5Bissue12934=5D_pysetup_doesn=E2=80=99t_work_for_the_docutils_?=
	=?utf-8?q?project?=
In-Reply-To: <1315411968.07.0.253348749085.issue12934@psf.upfronthosting.co.za>
Message-ID: <1322144411.06.0.593823659035.issue12934@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

This is a problem on my side, not in distutils2.  My pysetupX.Y scripts are just shell one-liners of this form:

  PYTHONPATH=~/path/to/d2 pythonX.Y -m distutils2.run "$@"

Because of sys.path initialization, d2 tried to import docutils from the working directory instead of the version in site-packages.  If I install d2 and run the installed pysetup script, d2 and docutils are imported from site-packages and everything is fine.

----------
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12934>
_______________________________________

From report at bugs.python.org  Thu Nov 24 15:32:05 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 24 Nov 2011 14:32:05 +0000
Subject: =?utf-8?q?=5Bissue13472=5D_Quick_Start_in_devguide_doesn=E2=80=99t_mentio?=
	=?utf-8?q?n_build_dependencies?=
In-Reply-To: <1322142769.6.0.687458451697.issue13472@psf.upfronthosting.co.za>
Message-ID: <1322145125.3.0.0785641684353.issue13472@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Well, it's a quick start. The link to "build Python" actually tells you about dependencies.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13472>
_______________________________________

From report at bugs.python.org  Thu Nov 24 15:39:46 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 24 Nov 2011 14:39:46 +0000
Subject: [issue13461] Error on test_issue_1395_5 with Python 2.7 and VS2010
In-Reply-To: <1322056958.99.0.498945300571.issue13461@psf.upfronthosting.co.za>
Message-ID: <1322145586.05.0.791333871303.issue13461@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

What if you replace:

PyObject *decoded = PyObject_CallMethod(
            self->decoder, "decode", "s#", input, 1);

with:

PyObject *decoded = PyObject_CallMethod(
            self->decoder, "decode", "s#", input, (Py_ssize_t) 1);

----------
nosy: +brian.curtin, loewis, pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13461>
_______________________________________

From report at bugs.python.org  Thu Nov 24 15:45:13 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 24 Nov 2011 14:45:13 +0000
Subject: [issue13473] Add tests for files byte-compiled by distutils[2]
Message-ID: <1322145911.61.0.528651769931.issue13473@psf.upfronthosting.co.za>


New submission from ?ric Araujo <merwok at netwok.org>:

I recently changed packaging.util.byte_compile, the function used by the build_py and install_lib commands, so that it can create .pyc and/or .pyo files independently of the calling?s Python -O or -B flags (dad02a080bbc), but I think I introduced a bug.  To check that bug and fully test byte_compile before I further simplify the function and backport the whole fix to distutils, I wanted to add tests that load a .pyc or .pyo file and make sure that the right optimization level is used (nothing for --compile, level one for --optimize=1, level 2 for --optimize=2).

In the attached patch, I run a Python with -O, -OO or no flag in a subprocess to import a module that prints different things depending on the optimization level.  The .pyc or .pyo file is already created by packaging, but I have no check that makes sure that they are not recreated (which I don?t want) and I don?t know if the optimizations in compile.c are applied during byte-compilation or after import (which would make my tests not exercise what I want).

(I tried to use imp.load_module at first but it?s not very friendly.  Other ideas that I had after the patch was done: Use subprocess + imp so that I can import pyc or pyo as I wish; use open + dis module.)

So, could you import experts review the functions added in packaging.tests.support and tell me if they exercise what I want?

----------
assignee: eric.araujo
components: Distutils, Distutils2
files: p7g-tests-bytecompiled-files.diff
keywords: patch
messages: 148258
nosy: alexis, brett.cannon, eric.araujo, ncoghlan, tarek
priority: normal
severity: normal
stage: commit review
status: open
title: Add tests for files byte-compiled by distutils[2]
versions: 3rd party, Python 2.7, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file23768/p7g-tests-bytecompiled-files.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13473>
_______________________________________

From report at bugs.python.org  Thu Nov 24 15:56:59 2011
From: report at bugs.python.org (Florent Xicluna)
Date: Thu, 24 Nov 2011 14:56:59 +0000
Subject: [issue13470] A user may need ... when she has ...
In-Reply-To: <1322119560.63.0.526352282157.issue13470@psf.upfronthosting.co.za>
Message-ID: <1322146619.05.0.397199122913.issue13470@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

This explanation is enough. Thanks.

----------
resolution: works for me -> invalid
stage: needs patch -> committed/rejected
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13470>
_______________________________________

From report at bugs.python.org  Thu Nov 24 15:57:41 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 24 Nov 2011 14:57:41 +0000
Subject: [issue13473] Add tests for files byte-compiled by distutils[2]
In-Reply-To: <1322145911.61.0.528651769931.issue13473@psf.upfronthosting.co.za>
Message-ID: <1322146661.37.0.178542215895.issue13473@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

(For the reference, the bug I added is this: http://hg.python.org/cpython/rev/c10946a17420#l6.45

p7g.util.byte_compile calls py_compile.compile with a filename ending in .pyc or .pyo as appropriate, but the optimization level in the py_compile.compile function depends on the calling Python?s -O option.  When byte_compile wants to create a .pyo file but is run under a python without -O, it spawns a subprocess with the -O option.  The fix I did made sure that the filename used (pyc or pyo) did not depend on the calling Python?s -O, *but* it should not have removed the setting of -O/-OO in the subprocess, as it?s the only way to control the optimization level in py_compile.compile before 3.2.  I think I will use a py_compile or compileall function so that I can have control over the optimization level from Python, which will let me remove the inelegant spawning in byte_compile, and I will backport that function for distutils2.

If this makes no sense, please ignore.  I?m not sure I would have understood what I?m talking about a year ago.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13473>
_______________________________________

From report at bugs.python.org  Thu Nov 24 16:17:17 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 24 Nov 2011 15:17:17 +0000
Subject: [issue13313] test_time fails: tzset() do not change timezone
In-Reply-To: <1320166603.97.0.58939508903.issue13313@psf.upfronthosting.co.za>
Message-ID: <1322147837.66.0.993822031815.issue13313@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Duplicate of #11886.

----------
nosy: +haypo
resolution:  -> duplicate
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13313>
_______________________________________

From report at bugs.python.org  Thu Nov 24 16:17:20 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 24 Nov 2011 15:17:20 +0000
Subject: [issue11886] test_time.test_tzset() fails on "x86 FreeBSD 7.2 3.x":
	AEST timezone called "EST"
In-Reply-To: <1303307593.46.0.897474878267.issue11886@psf.upfronthosting.co.za>
Message-ID: <1322147840.78.0.420031417147.issue11886@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Issue #13313 has been marked as a duplicate of this issue. Interesting message from flox:

"Maybe it is related.
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=93810

Ambiguous timezone names (AEST vs EST)"

----------
nosy: +flox

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11886>
_______________________________________

From report at bugs.python.org  Thu Nov 24 16:18:32 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 24 Nov 2011 15:18:32 +0000
Subject: [issue2377] Replace __import__ w/ importlib.__import__
In-Reply-To: <1205808012.99.0.46136974085.issue2377@psf.upfronthosting.co.za>
Message-ID: <1322147912.6.0.248651660663.issue2377@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/issue2377>
_______________________________________

From report at bugs.python.org  Thu Nov 24 16:18:35 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 24 Nov 2011 15:18:35 +0000
Subject: [issue11886] test_time.test_tzset() fails on "x86 FreeBSD 7.2 3.x":
	AEST timezone called "EST"
In-Reply-To: <1303307593.46.0.897474878267.issue11886@psf.upfronthosting.co.za>
Message-ID: <1322147915.64.0.698090046531.issue11886@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> Is there a way to force configure run on the bot?

./configure is run for each build of each buildbot.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11886>
_______________________________________

From report at bugs.python.org  Thu Nov 24 16:24:06 2011
From: report at bugs.python.org (Masha Katsman)
Date: Thu, 24 Nov 2011 15:24:06 +0000
Subject: [issue12759] "(?P=)" input for Tools/scripts/redemo.py raises
	unnhandled exception
In-Reply-To: <1313495654.73.0.277709437369.issue12759@psf.upfronthosting.co.za>
Message-ID: <1322148246.72.0.610261692071.issue12759@psf.upfronthosting.co.za>


Masha Katsman <mkatsman at yahoo.com> added the comment:

Updating the patch with the test. The test checks that the re exception is thrown in case of the (?P=) and (?P<>) expressions.
It used to raise an Index exception. My only question is, the exception we raise now says, there invalid characters in the group name, whether in our case the group name is just empty.

----------
Added file: http://bugs.python.org/file23769/patch_for_12759

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12759>
_______________________________________

From report at bugs.python.org  Thu Nov 24 16:27:34 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 24 Nov 2011 15:27:34 +0000
Subject: [issue11886] test_time.test_tzset() fails on "x86 FreeBSD 7.2 3.x":
	AEST timezone called "EST"
In-Reply-To: <1303307593.46.0.897474878267.issue11886@psf.upfronthosting.co.za>
Message-ID: <1322148454.8.0.89037615583.issue11886@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

I don't see this issue as a bug in Python, but just that the timezone database is different on some OSes. Can't we just accept both names, AEST and EST? Attached patch changes test_time to tolerate EST name for 'AEST-10AEDT-11,M10.5.0,M3.5.0' ("Victoria") time zone.

----------
keywords: +patch
Added file: http://bugs.python.org/file23770/time_aest.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11886>
_______________________________________

From report at bugs.python.org  Thu Nov 24 16:55:41 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 24 Nov 2011 15:55:41 +0000
Subject: [issue13224] Change str(x) to return only __qualname__ for some types
In-Reply-To: <1319053532.35.0.636674659737.issue13224@psf.upfronthosting.co.za>
Message-ID: <1322150141.65.0.323534951271.issue13224@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

You are right, I misinterpreted ?use?.  I cloned the the PEP 3155 repo and ran my test script (I?ll attach it for reference) and reprs/strs are indeed "<class '__main__.A.B'>" and "<function makestrip.<locals>.strip at ...>", so this request is not obsoleted.

I?ve updated my patch to use qualnames for str(cls) and str(func).  As I reported before, if I want str(sys.exc_info) to be 'exc_info', then Python unbound methods (i.e. functions) are affected:

    <method 'update' of 'dict' objects>
    <built-in method update of dict object at ...>
    <method 'tolist' of 'array.array' objects>
    <built-in method tolist of array.array object at ...>
 ?  Counter.update
    <bound method Counter.update of Counter()>
 ?  Top.Nested.method  # this checks qualnames are used
    <bound method Nested.method of <__main__.Top.Nested object at ...>

It seems to me that this is not a problem: Python 3 unbound methods *are* functions.  If you decide that having str(method) unchanged for all kinds of methods is more important than giving all kinds of functions a short str, I can do it.

----------
dependencies: +PEP 3155 implementation
Added file: http://bugs.python.org/file23771/change-some-str.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13224>
_______________________________________

From report at bugs.python.org  Thu Nov 24 16:56:39 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 24 Nov 2011 15:56:39 +0000
Subject: [issue13224] Change str(x) to return only __qualname__ for some types
In-Reply-To: <1319053532.35.0.636674659737.issue13224@psf.upfronthosting.co.za>
Message-ID: <1322150199.36.0.857912648409.issue13224@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


Added file: http://bugs.python.org/file23772/test-str-repr.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13224>
_______________________________________

From report at bugs.python.org  Thu Nov 24 16:56:42 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 24 Nov 2011 15:56:42 +0000
Subject: [issue13224] Change str(x) to return only __qualname__ for some types
In-Reply-To: <1319053532.35.0.636674659737.issue13224@psf.upfronthosting.co.za>
Message-ID: <1322150202.12.0.384354060841.issue13224@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


Removed file: http://bugs.python.org/file23468/change-class-__str__.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13224>
_______________________________________

From report at bugs.python.org  Thu Nov 24 16:56:43 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 24 Nov 2011 15:56:43 +0000
Subject: [issue13224] Change str(x) to return only __qualname__ for some types
In-Reply-To: <1319053532.35.0.636674659737.issue13224@psf.upfronthosting.co.za>
Message-ID: <1322150203.76.0.38965761072.issue13224@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


Removed file: http://bugs.python.org/file23591/change-some-__str__.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13224>
_______________________________________

From report at bugs.python.org  Thu Nov 24 16:57:55 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 24 Nov 2011 15:57:55 +0000
Subject: [issue13224] Change str(x) to return only the (qual)name for some
	types
In-Reply-To: <1319053532.35.0.636674659737.issue13224@psf.upfronthosting.co.za>
Message-ID: <1322150275.6.0.798350167023.issue13224@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
title: Change str(x) to return only __qualname__ for some types -> Change str(x) to return only the (qual)name for some types

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13224>
_______________________________________

From report at bugs.python.org  Thu Nov 24 16:59:47 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 24 Nov 2011 15:59:47 +0000
Subject: [issue13443] wrong links and examples in the functional HOWTO
In-Reply-To: <1321850404.45.0.767133152656.issue13443@psf.upfronthosting.co.za>
Message-ID: <1322150387.5.0.428766839273.issue13443@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Thanks for the fixed links amk.  I think they can be fixed in the repo right now.

[Eli]
> I still think it's a bigger problem that the page discusses a module which
> is not available on Python 3.x - this means that a user following the page
> can't just type in the code and make it run.
It?s only one section that?s affected, so +1 to replacing its contents with just a link and short description (?the functional module does X and Y for Python 2?).  Before doing that, would you have the time to contact its author and inquire about porting plans?

(BTW, the file is also inconsistent in its use of :: vs. implicit code blocks; I wonder if that affects doctest or the ?hide prompts? button.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13443>
_______________________________________

From report at bugs.python.org  Thu Nov 24 17:05:43 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 24 Nov 2011 16:05:43 +0000
Subject: =?utf-8?q?=5Bissue13472=5D_devguide_doesn=E2=80=99t_list_all_build_depend?=
	=?utf-8?q?encies?=
In-Reply-To: <1322142769.6.0.687458451697.issue13472@psf.upfronthosting.co.za>
Message-ID: <1322150743.16.0.951105454441.issue13472@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Okay.  I just hope that people following the quick start and having build issues will follow the link.

I followed it and the section only mentions zlib, I think it could be exhaustive.

----------
title: Quick Start in devguide doesn?t mention build dependencies -> devguide doesn?t list all build dependencies

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13472>
_______________________________________

From report at bugs.python.org  Thu Nov 24 17:09:32 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 24 Nov 2011 16:09:32 +0000
Subject: [issue10507] Check well-formedness of reST markup within "make
	patchcheck"
In-Reply-To: <1290443371.49.0.836951290391.issue10507@psf.upfronthosting.co.za>
Message-ID: <1322150972.36.0.369303797961.issue10507@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Alternatively, make patchcheck could print ?Did you build the docs??, just as it currently prints ?Did you run the test suite?? if C or Python files were modified.  Building the docs would not check Misc/NEWS, the original motivation for this request, but I?m not sure it?s a big issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10507>
_______________________________________

From report at bugs.python.org  Thu Nov 24 17:11:18 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 24 Nov 2011 16:11:18 +0000
Subject: [issue7611] shlex not posix compliant when parsing "foo#bar"
In-Reply-To: <1262248963.08.0.673944744724.issue7611@psf.upfronthosting.co.za>
Message-ID: <1322151078.28.0.415637711536.issue7611@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> The manual just says "When operating in POSIX mode, shlex will try to be as close as
> possible to the POSIX shell parsing rules." but gives no reference to which authority it is
> following or what the rules are in either case.
I think it actually does: The POSIX specification defines the behavior of a compliant /bin/sh shell.

See also #1521950.

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7611>
_______________________________________

From report at bugs.python.org  Thu Nov 24 17:16:14 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Thu, 24 Nov 2011 16:16:14 +0000
Subject: [issue13443] wrong links and examples in the functional HOWTO
In-Reply-To: <1321850404.45.0.767133152656.issue13443@psf.upfronthosting.co.za>
Message-ID: <1322151374.81.0.921846844286.issue13443@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

> Before doing that, would you have the time to contact its author and inquire about porting plans?

I hope to find the time. I was also thinking about an alternative - since the HOWTO probably uses just a handful of functions from that module perhaps they can just be re-implemented and placed in the HOWTO. This can remove the unhealthy dependency on an external module, as well as provide some extra examples.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13443>
_______________________________________

From report at bugs.python.org  Thu Nov 24 17:20:41 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 24 Nov 2011 16:20:41 +0000
Subject: [issue1521950] shlex.split() does not tokenize like the shell
Message-ID: <1322151641.87.0.774271190439.issue1521950@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Thanks for the comments.

> There are really two cases in one bug.
> The first part is that the shell will split tokens at characters that shlex doesn't.  The handling
> of &, |, ;, >, and < could be done by adjusting the definition of shlex.wordchars.  The shell may
> also understands things like: &&, ||, |&, and >&.  The exact definition of these depends on the
> shell, so maybe it's best to just split them out as separate tokens and let the user figure out the
> compound meanings.
Yes.  I think that the main use of shlex is really to parse a line into chunks with a way to embed spaces; it?s intended to parse a program command line (?prog --blah "value stillthesamevalue" "arg samearg"?), but not necessarily a full shell line (with & and | and whatnot).  When people have a line containing & and |, then they need a shell to execute it, so they would not call shlex.split but just pass the full line to os.system or subprocess.Popen.  Do you remember what use cases you had when you opened this report?

> The proper handling of quotes/escapes requires some kind of new interface.  You need to distinguish
> between tokens that were modified by the quote/escape rules and those that were not.
I don?t see why I would care about quotes in the result of shlex.split.

See also #7611.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1521950>
_______________________________________

From report at bugs.python.org  Thu Nov 24 17:22:42 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 24 Nov 2011 16:22:42 +0000
Subject: [issue13455] Reorganize tracker docs in the devguide
In-Reply-To: <1321984554.54.0.834071786299.issue13455@psf.upfronthosting.co.za>
Message-ID: <1322151762.12.0.912835582666.issue13455@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> [...] The devguide is *already* too big. [...]
> The devguide was supposed to be something that you read quickly and easily, not an exhaustive
> reference of how development works. Or at least there should be a clear separation between the
> two (the guide part, and the reference part). [...]
> The devguide is *not* primarily for core developers. It's for new contributors who want to get
> set up, so that they don't give up in the absence of clear indications. [...]

Thanks Antoine, I was not aware of that or I had forgotten it.  The old python.org/dev pages contained information for new and experienced core devs too, so I thought the devguide was intended to contain the same info.  I?ll support a clearer separation between the guide and the reference, to make the devguide less overwhelming for new contributors but still complete for core devs.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13455>
_______________________________________

From report at bugs.python.org  Thu Nov 24 17:25:54 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Thu, 24 Nov 2011 16:25:54 +0000
Subject: [issue13422] Subprocess: children hang due to open pipes
In-Reply-To: <1322098824.21.0.0333834886389.issue13422@psf.upfronthosting.co.za>
Message-ID: <CAH_1eM0Ju8kTSu5WCcMSU-Y9yWjzDXDpgOwadZJ0--LE9gdRgQ@mail.gmail.com>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

> The problem I have with the solution that is currently implemented is that subprocess is waiting for the spawned child although the child is not running anymore.
> In my case this issue occured when invoking samba or the small sample daemon (see attached file above).
> For example, invoking the daemon from a bash, the daemon program exits immediately and its spawned child is running in the background. The point is that the bash is accessible right after starting the daemon. It is not waiting for the daemon process in the background to close the open pipe.
>
> What do you think of using a waitpid for this scenario?
> subprocess.Popen could wait for the pid of the daemon starter and gets back control once the pid of the daemon starter is gone. This way, subprocess.Popen does not need to wait for EOF on left-open pipes.

That would defeat the semantics of communicate(): it is supposed to
wait until EOF.
If this doesn't work for your use case, simply don't use
communicate(), or close stdout and stderr in your child process.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13422>
_______________________________________

From report at bugs.python.org  Thu Nov 24 17:28:12 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 24 Nov 2011 16:28:12 +0000
Subject: [issue13443] wrong links and examples in the functional HOWTO
In-Reply-To: <1321850404.45.0.767133152656.issue13443@psf.upfronthosting.co.za>
Message-ID: <1322152092.44.0.572694257749.issue13443@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Good idea.  The functions used are: compose, partial (which we have in functools), flip, foldl.

I will disagree with ?unhealthy?: I?m sure adding this link was a deliberate exposure of an external module, to put a well-written solution to the spotlight as a service to the users and an acknowledgment to the author.  If the cost is a little links bookkeeping for us, it is small :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13443>
_______________________________________

From report at bugs.python.org  Thu Nov 24 17:33:59 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 24 Nov 2011 16:33:59 +0000
Subject: [issue5302] Allow package_data specs/globs to match directories
In-Reply-To: <1234909934.56.0.127417684931.issue5302@psf.upfronthosting.co.za>
Message-ID: <1322152439.74.0.430782963447.issue5302@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I need to fix this for distutils2?s next release (with #13463 and #5302), to include distutils2/tests/fake_dists.

----------
assignee: tarek -> eric.araujo
priority: high -> release blocker
title: Allow package_data globs match directories -> Allow package_data specs/globs to match directories
versions: +Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5302>
_______________________________________

From report at bugs.python.org  Thu Nov 24 17:34:14 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 24 Nov 2011 16:34:14 +0000
Subject: [issue13463] Fix parsing of package_data
In-Reply-To: <1322068433.36.0.783240091616.issue13463@psf.upfronthosting.co.za>
Message-ID: <1322152454.67.0.828889702516.issue13463@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
dependencies: +Allow package_data specs/globs to match directories, package_data only allows one glob per-package

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13463>
_______________________________________

From report at bugs.python.org  Thu Nov 24 17:34:35 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 24 Nov 2011 16:34:35 +0000
Subject: [issue11805] package_data only allows one glob per-package
In-Reply-To: <1302301429.27.0.797210396018.issue11805@psf.upfronthosting.co.za>
Message-ID: <1322152475.24.0.00872615180198.issue11805@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I need this to package test files for distutils2?s own next release, so pragmatism/compatibility will win for the short term :)

I?ll fix it together with #13463 and #5302.

----------
priority: normal -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11805>
_______________________________________

From report at bugs.python.org  Thu Nov 24 17:38:14 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 24 Nov 2011 16:38:14 +0000
Subject: [issue9510] sqlite3.Warning isnt a subclass of exceptions.Warning
In-Reply-To: <1280927892.96.0.292259619194.issue9510@psf.upfronthosting.co.za>
Message-ID: <1322152694.62.0.422138848569.issue9510@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> Reading PEP 0249 I can see Gerhard is correct, this patch would violate the PEP.
Me too.

> I think that the PEP is slightly flawed in that users are encouraged to raise exceptions
> called "Warning".  IMHO a Warning is never an exceptional condition and should be notified
> by the warnings framework.
That?s probably a bad word choice in the PEP.

> This obviously confused the authors of MySQLdb, who do indeed warn() their Warning classes
> rather than raise() them, and it is very useful to be able to filter them.
> To obey the letter of the PEP the authors of the MySQLdb interface multiply inherit their
> Warning class from exceptions.StandardError and exceptions.Warning.
I think they are mistaken, given that the DB API warnings are actually errors.

----------
stage: patch review -> committed/rejected

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9510>
_______________________________________

From report at bugs.python.org  Thu Nov 24 17:41:31 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 24 Nov 2011 16:41:31 +0000
Subject: [issue8473] doctest fails if you have inconsistent lineendings
In-Reply-To: <1271781617.9.0.374951389596.issue8473@psf.upfronthosting.co.za>
Message-ID: <1322152891.08.0.711169521128.issue8473@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

The string in the test does not have mixed line endings, and the accompanying comment talks about testing files with CRLF on Unix.

Terry, do you want to (update and) commit this?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8473>
_______________________________________

From report at bugs.python.org  Thu Nov 24 17:43:28 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 24 Nov 2011 16:43:28 +0000
Subject: [issue9458] xml.etree.ElementTree.ElementTree.write(): encoding
	handling problems
In-Reply-To: <1280782925.67.0.136452249646.issue9458@psf.upfronthosting.co.za>
Message-ID: <1322153008.99.0.752783261342.issue9458@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Thanks for the patch.  The examples in your message need to be converted to a patch that applies to 3.2 or 2.7, so that we can reproduce the bug before fixing it.

----------
stage:  -> test needed
versions: +Python 2.7, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9458>
_______________________________________

From report at bugs.python.org  Thu Nov 24 17:44:04 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 24 Nov 2011 16:44:04 +0000
Subject: [issue9458] xml.etree.ElementTree.ElementTree.write(): encoding
	handling problems
In-Reply-To: <1280782925.67.0.136452249646.issue9458@psf.upfronthosting.co.za>
Message-ID: <1322153044.49.0.622876242412.issue9458@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/issue9458>
_______________________________________

From report at bugs.python.org  Thu Nov 24 17:51:24 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 24 Nov 2011 16:51:24 +0000
Subject: [issue9957] SpooledTemporayFile.truncate should take size parameter
In-Reply-To: <1285552951.71.0.864499786785.issue9957@psf.upfronthosting.co.za>
Message-ID: <1322153484.56.0.693752577153.issue9957@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Patch looks good to me, but I?d like another review.

----------
nosy: +ncoghlan
type: feature request -> behavior
versions: +Python 2.7, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9957>
_______________________________________

From report at bugs.python.org  Thu Nov 24 17:56:41 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Thu, 24 Nov 2011 16:56:41 +0000
Subject: [issue13469] TimedRotatingFileHandler fails to handle intervals of
	several weeks correctly
In-Reply-To: <1322118639.78.0.741046011353.issue13469@psf.upfronthosting.co.za>
Message-ID: <1322153801.18.0.704940064723.issue13469@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

TimedRotatingFileHandler does not, by design, support multiple-week rollovers: the W mode is for a specific day of the week, and is documented as "Weekday" rather than "Weeks" (the other modes are documented as Seconds, Minutes, Hours, Days).

I don't currently have time to consider such support, but I'll certainly look at a patch (with tests).

----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13469>
_______________________________________

From report at bugs.python.org  Thu Nov 24 18:17:49 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 24 Nov 2011 17:17:49 +0000
Subject: [issue12485] textwrap.wrap: new argument for more pleasing output
In-Reply-To: <1309745581.79.0.51605072509.issue12485@psf.upfronthosting.co.za>
Message-ID: <1322155069.91.0.8306373576.issue12485@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
stage: patch review -> test needed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12485>
_______________________________________

From report at bugs.python.org  Thu Nov 24 18:47:01 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 24 Nov 2011 17:47:01 +0000
Subject: [issue9957] SpooledTemporayFile.truncate should take size parameter
In-Reply-To: <1285552951.71.0.864499786785.issue9957@psf.upfronthosting.co.za>
Message-ID: <1322156821.72.0.191584906427.issue9957@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Looks ok to me as well. I think this is a new feature, so 3.3-only IMHO.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9957>
_______________________________________

From amauryfa at gmail.com  Thu Nov 24 19:41:04 2011
From: amauryfa at gmail.com (Amaury Forgeot d'Arc)
Date: Thu, 24 Nov 2011 19:41:04 +0100
Subject: [issue13471] setting access time beyond Jan. 2038 on remote share
	failes on Win7 x64
In-Reply-To: <1322143196.31.0.929027754195.issue13471@psf.upfronthosting.co.za>
References: <1322142567.98.0.834575465366.issue13471@psf.upfronthosting.co.za>
	<1322143196.31.0.929027754195.issue13471@psf.upfronthosting.co.za>
Message-ID: <CAGmFidaVo6VXPTAEcrYG4EnKBbAyD+1xfyGQKUfttppaf77DKQ@mail.gmail.com>

> The timestamp is converted to time_t (32 bits) and then to FILE_TIME (64
bits).
> A function to convert directly a PyObject to FILE_TIME should be written.

I thought that time_t was 64 bits on Windows
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-bugs-list/attachments/20111124/e343221d/attachment.html>

From report at bugs.python.org  Thu Nov 24 19:41:21 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 24 Nov 2011 18:41:21 +0000
Subject: [issue13471] setting access time beyond Jan. 2038 on remote share
	failes on Win7 x64
In-Reply-To: <1322143196.31.0.929027754195.issue13471@psf.upfronthosting.co.za>
Message-ID: <CAGmFidaVo6VXPTAEcrYG4EnKBbAyD+1xfyGQKUfttppaf77DKQ@mail.gmail.com>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

bits).
> A function to convert directly a PyObject to FILE_TIME should be written.

I thought that time_t was 64 bits on Windows

----------
nosy: +Amaury.Forgeot.d'Arc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13471>
_______________________________________

From report at bugs.python.org  Thu Nov 24 19:48:09 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 24 Nov 2011 18:48:09 +0000
Subject: =?utf-8?q?=5Bissue13472=5D_devguide_doesn=E2=80=99t_list_all_build_depend?=
	=?utf-8?q?encies?=
In-Reply-To: <1322142769.6.0.687458451697.issue13472@psf.upfronthosting.co.za>
Message-ID: <1322160489.57.0.592479654527.issue13472@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

I agree with Antoine, there's no need to mention them in the quickstart.  Moreover these dependencies are optional, so there's no need to install them unless they are specifically needed (on a related note I would also add an "optional" in the warning that says "Python build finished, but the necessary bits to build these modules were not found" -- I've seen enough people complaining that the build "failed" because this dependencies were missing).
Explaining how to get them in the build page sounds fine to me.

----------
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13472>
_______________________________________

From report at bugs.python.org  Thu Nov 24 20:01:04 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 24 Nov 2011 19:01:04 +0000
Subject: [issue10507] Check well-formedness of reST markup within "make
	patchcheck"
In-Reply-To: <1290443371.49.0.836951290391.issue10507@psf.upfronthosting.co.za>
Message-ID: <1322161264.38.0.76481767584.issue10507@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti
versions:  -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10507>
_______________________________________

From report at bugs.python.org  Thu Nov 24 20:07:56 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 24 Nov 2011 19:07:56 +0000
Subject: [issue13465] A Jython section in the dev guide would be great
In-Reply-To: <1322074015.2.0.311635199294.issue13465@psf.upfronthosting.co.za>
Message-ID: <1322161676.9.0.904131453404.issue13465@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

I'd search the Jython devguide at http://www.jython.org/devguide/, having it at http://docs.python.org/devguide/jython/ doesn't make much sense IMHO (especially if it is a "full" guide with several pages).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13465>
_______________________________________

From report at bugs.python.org  Thu Nov 24 21:04:30 2011
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 24 Nov 2011 20:04:30 +0000
Subject: [issue12170] index() and count() methods of bytes and bytearray
	should accept byte ints
In-Reply-To: <1306266550.46.0.554812052221.issue12170@psf.upfronthosting.co.za>
Message-ID: <E1RTfWp-0008HL-8v@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 736b0aec412b by Petri Lehtinen in branch 'default':
Add a "What's New" entry for #12170
http://hg.python.org/cpython/rev/736b0aec412b

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12170>
_______________________________________

From report at bugs.python.org  Thu Nov 24 21:10:59 2011
From: report at bugs.python.org (Eric Snow)
Date: Thu, 24 Nov 2011 20:10:59 +0000
Subject: [issue13474] Mention of "-m" Flag Missing From Doc on Execution Model
Message-ID: <1322165458.97.0.989343856998.issue13474@psf.upfronthosting.co.za>


New submission from Eric Snow <ericsnowcurrently at gmail.com>:

The doc on code execution[1] leaves out mention of the -m flag.  Seems like it belongs there too.

[1] Doc/reference/executionmodel.rst

----------
assignee: docs at python
components: Documentation
messages: 148288
nosy: docs at python, eric.snow
priority: normal
severity: normal
status: open
title: Mention of "-m" Flag Missing From Doc on Execution Model
versions: Python 2.7, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13474>
_______________________________________

From report at bugs.python.org  Thu Nov 24 21:32:26 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 24 Nov 2011 20:32:26 +0000
Subject: [issue13474] Mention of "-m" Flag Missing From Doc on Execution Model
In-Reply-To: <1322165458.97.0.989343856998.issue13474@psf.upfronthosting.co.za>
Message-ID: <1322166746.9.0.292294716323.issue13474@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13474>
_______________________________________

From report at bugs.python.org  Thu Nov 24 22:50:47 2011
From: report at bugs.python.org (sbt)
Date: Thu, 24 Nov 2011 21:50:47 +0000
Subject: [issue13448] PEP 3155 implementation
In-Reply-To: <1321908830.82.0.349913947268.issue13448@psf.upfronthosting.co.za>
Message-ID: <1322171447.01.0.221201262315.issue13448@psf.upfronthosting.co.za>


sbt <shibturn at gmail.com> added the comment:

Is it intended that pickle will use __qualname__?

----------
nosy: +sbt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13448>
_______________________________________

From report at bugs.python.org  Thu Nov 24 23:19:37 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 24 Nov 2011 22:19:37 +0000
Subject: [issue9957] SpooledTemporayFile.truncate should take size parameter
In-Reply-To: <1285552951.71.0.864499786785.issue9957@psf.upfronthosting.co.za>
Message-ID: <1322173177.75.0.397109973689.issue9957@psf.upfronthosting.co.za>


Changes by Nick Coghlan <ncoghlan at gmail.com>:


----------
versions:  -Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9957>
_______________________________________

From report at bugs.python.org  Thu Nov 24 23:20:48 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 24 Nov 2011 22:20:48 +0000
Subject: [issue11816] Refactor the dis module to provide better building
	blocks for bytecode analysis
In-Reply-To: <1302394810.0.0.38146154248.issue11816@psf.upfronthosting.co.za>
Message-ID: <1322173248.56.0.737741946866.issue11816@psf.upfronthosting.co.za>


Changes by Nick Coghlan <ncoghlan at gmail.com>:


Added file: http://bugs.python.org/file23773/9512712044a6.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11816>
_______________________________________

From report at bugs.python.org  Thu Nov 24 23:29:14 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 24 Nov 2011 22:29:14 +0000
Subject: [issue11682] PEP 380 reference implementation for 3.3
In-Reply-To: <1301110605.68.0.392943983038.issue11682@psf.upfronthosting.co.za>
Message-ID: <1322173754.58.0.145386167325.issue11682@psf.upfronthosting.co.za>


Changes by Nick Coghlan <ncoghlan at gmail.com>:


Added file: http://bugs.python.org/file23774/0d1d76f68750.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11682>
_______________________________________

From report at bugs.python.org  Thu Nov 24 23:49:07 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 24 Nov 2011 22:49:07 +0000
Subject: [issue13448] PEP 3155 implementation
In-Reply-To: <1321908830.82.0.349913947268.issue13448@psf.upfronthosting.co.za>
Message-ID: <1322174947.78.0.419438311335.issue13448@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Yes, but that can be a separate patch - step 1 is to make the attribute available, then relevant modules can subsequently be updated to use it as appropriate.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13448>
_______________________________________

From report at bugs.python.org  Thu Nov 24 23:55:52 2011
From: report at bugs.python.org (Marian Ganisin)
Date: Thu, 24 Nov 2011 22:55:52 +0000
Subject: [issue10131] deepcopying an xml.dom.minidom.Document generates an
	invalid XML document
In-Reply-To: <1287322940.78.0.0838139062813.issue10131@psf.upfronthosting.co.za>
Message-ID: <1322175352.94.0.156193661453.issue10131@psf.upfronthosting.co.za>


Marian Ganisin <marian.ganisin at gmail.com> added the comment:

Code from msg146175 with attached patch applied:

>>> import sys
>>> print(sys.version_info)
sys.version_info(major=2, minor=7, micro=2, releaselevel='final', serial=0)
>>> import copy, pickle
>>> from xml.dom.minidom import NodeList
>>> 
>>> obj = NodeList()
>>> obj.append('a')
>>> 
>>> obj2 = copy.deepcopy(obj)
>>> print(obj2)
['a']
>>> 
>>> obj2 = pickle.loads(pickle.dumps(obj))
>>> print(obj2)
['a']

Result is same in both cases.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10131>
_______________________________________

From report at bugs.python.org  Fri Nov 25 00:56:08 2011
From: report at bugs.python.org (=?utf-8?q?C=C3=A9dric_Krier?=)
Date: Thu, 24 Nov 2011 23:56:08 +0000
Subject: [issue7652] Merge C version of decimal into py3k.
In-Reply-To: <1262860972.65.0.690079130991.issue7652@psf.upfronthosting.co.za>
Message-ID: <1322178968.28.0.158105421616.issue7652@psf.upfronthosting.co.za>


Changes by C?dric Krier <cedric.krier at b2ck.com>:


----------
nosy: +ced

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7652>
_______________________________________

From report at bugs.python.org  Fri Nov 25 01:22:04 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 25 Nov 2011 00:22:04 +0000
Subject: [issue7611] shlex not posix compliant when parsing "foo#bar"
In-Reply-To: <1262248963.08.0.673944744724.issue7611@psf.upfronthosting.co.za>
Message-ID: <1322180524.59.0.612679045715.issue7611@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

The doc section has no reference, as in a live web link, to any version of the POSIX specification. This is unlike other doc sections that implement various RFCs (which also get updated). The docs also link to specific references for the Unicode version supported, which has changed from version to version.

The OP quotes (without giving a link) from the 2008 version. POSIX and shlex are much older than that, implying that shlex might conform to an earlier version, just as other modules implement older RFCs that have been superceded.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7611>
_______________________________________

From report at bugs.python.org  Fri Nov 25 01:30:00 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 25 Nov 2011 00:30:00 +0000
Subject: [issue11849] glibc allocator doesn't release all free()ed memory
In-Reply-To: <1302858518.86.0.0355572789659.issue11849@psf.upfronthosting.co.za>
Message-ID: <1322181000.89.0.989499659253.issue11849@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

For the record, this seems to make large allocations slower:

-> with patch:
$ ./python -m timeit "b'x'*200000"
10000 loops, best of 3: 27.2 usec per loop

-> without patch:
$ ./python -m timeit "b'x'*200000"
100000 loops, best of 3: 7.4 usec per loop

Not sure we should care, though. It's still very fast.
(noticed in http://mail.python.org/pipermail/python-dev/2011-November/114610.html )

----------
nosy: +eli.bendersky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11849>
_______________________________________

From report at bugs.python.org  Fri Nov 25 01:33:55 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 25 Nov 2011 00:33:55 +0000
Subject: [issue13448] PEP 3155 implementation
In-Reply-To: <1322171447.01.0.221201262315.issue13448@psf.upfronthosting.co.za>
Message-ID: <1322180935.3302.0.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Is it intended that pickle will use __qualname__?

That's part of the plan for PEP 3154, yes.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13448>
_______________________________________

From report at bugs.python.org  Fri Nov 25 01:46:34 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 25 Nov 2011 00:46:34 +0000
Subject: [issue13475] Add '-p'/'--path0' command line option to override
	sys.path[0] initialisation
Message-ID: <1322181994.22.0.955887054946.issue13475@psf.upfronthosting.co.za>


New submission from Nick Coghlan <ncoghlan at gmail.com>:

PEP 395 spends a lot of time discussing ways that the current automatic initialisation of sys.path[0] can go wrong, and even the proposed improvements in that PEP don't claim to fix the default behaviour for every possible scenario (just many of the most common ones).

The unittest module gets around similar problems with test autodiscovery by providing an explicit "-t" (for 'toplevel') command line option.

While '-t' is not available for the main interpreter executable (and nor is '-d' for directory), '-p' for "path0" is a possibility.

Directory execution (for example) would then be equivalent to:

  python -p dirname dirname/__main__.py

A separate '--nopath0' option could also be provided to explicitly disable path initialisation based on the script being executed (see http://lists.debian.org/debian-python/2011/11/msg00058.html)

----------
messages: 148295
nosy: ncoghlan
priority: normal
severity: normal
status: open
title: Add '-p'/'--path0' command line option to override sys.path[0] initialisation

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13475>
_______________________________________

From report at bugs.python.org  Fri Nov 25 01:47:11 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 25 Nov 2011 00:47:11 +0000
Subject: [issue10318] "make altinstall" installs many files with incorrect
	shebangs
In-Reply-To: <1288926610.35.0.932494150274.issue10318@psf.upfronthosting.co.za>
Message-ID: <1322182031.01.0.613767294443.issue10318@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

I created #13475 to discuss the idea of a command line option to override sys.path[0] initialisation.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10318>
_______________________________________

From report at bugs.python.org  Fri Nov 25 01:52:33 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 25 Nov 2011 00:52:33 +0000
Subject: [issue11849] glibc allocator doesn't release all free()ed memory
In-Reply-To: <1302858518.86.0.0355572789659.issue11849@psf.upfronthosting.co.za>
Message-ID: <1322182353.3.0.939754541302.issue11849@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

More surprising is that, even ignoring the allocation cost, other operations on the memory area seem more expensive:

$ ./python -m timeit -s "b=bytearray(500000)" "b[:] = b"
-> python 3.3:
1000 loops, best of 3: 367 usec per loop
-> python 3.2:
10000 loops, best of 3: 185 usec per loop

(note how this is just a dump memcpy)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11849>
_______________________________________

From report at bugs.python.org  Fri Nov 25 02:39:41 2011
From: report at bugs.python.org (Dan Christian)
Date: Fri, 25 Nov 2011 01:39:41 +0000
Subject: [issue1521950] shlex.split() does not tokenize like the shell
In-Reply-To: <1322151641.87.0.774271190439.issue1521950@psf.upfronthosting.co.za>
Message-ID: <CAEcGQ+MYODTGLRyxhBQJq2mfM+PZYNASUedJ=7oa_b45C8197A@mail.gmail.com>


Dan Christian <robodan at users.sourceforge.net> added the comment:

Of course, that's how it's used.  That's all it can do right now.

I was was splitting and combining commands (using ;, &&, and ||) and
then running the resulting (mega) one liners over ssh.  It still gets
run by a shell, but I was specifying the control flow. 0

 It's kind of like a makefile command block.  You want to be able to
specify if a failure aborts the sequence, or is ignored (&& vs ;).
Sometimes there are fallback commands (via ||).  Of course, you can
also group using ().

Once things are split properly, then understanding the shell control
characters is straight forward.  I my mind, shlex.split() should
either be as close to shell syntax as possible, or have a clear
explanation of what is different (and why).

I ended up doing my own parsing.  I'm not actually at that company
anymore, so I can't pull up the code.

I'll see if I can come up with a reference case and maybe a unittest
this weekend (that's really the only time I'll have to dig into it).

-Dan

On Thu, Nov 24, 2011 at 9:20 AM, ?ric Araujo <report at bugs.python.org> wrote:
>
> ?ric Araujo <merwok at netwok.org> added the comment:
>
> Thanks for the comments.
>
>> There are really two cases in one bug.
>> The first part is that the shell will split tokens at characters that shlex doesn't. ?The handling
>> of &, |, ;, >, and < could be done by adjusting the definition of shlex.wordchars. ?The shell may
>> also understands things like: &&, ||, |&, and >&. ?The exact definition of these depends on the
>> shell, so maybe it's best to just split them out as separate tokens and let the user figure out the
>> compound meanings.
> Yes. ?I think that the main use of shlex is really to parse a line into chunks with a way to embed spaces; it?s intended to parse a program command line (?prog --blah "value stillthesamevalue" "arg samearg"?), but not necessarily a full shell line (with & and | and whatnot). ?When people have a line containing & and |, then they need a shell to execute it, so they would not call shlex.split but just pass the full line to os.system or subprocess.Popen. ?Do you remember what use cases you had when you opened this report?
>
>> The proper handling of quotes/escapes requires some kind of new interface. ?You need to distinguish
>> between tokens that were modified by the quote/escape rules and those that were not.
> I don?t see why I would care about quotes in the result of shlex.split.
>
> See also #7611.
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue1521950>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1521950>
_______________________________________

From report at bugs.python.org  Fri Nov 25 02:57:03 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 25 Nov 2011 01:57:03 +0000
Subject: [issue13476] Simple exclusion filter for unittest autodiscovery
Message-ID: <1322186223.31.0.112270498917.issue13476@psf.upfronthosting.co.za>


New submission from Nick Coghlan <ncoghlan at gmail.com>:

unittest autodiscovery is very nice, but a '-x' option to specify directory patterns *not* to search could be a nice enhancement.

(In my specific case, I want to run most of my tests, but one batch are Django tests and it would be nice to have an easy way to tell unittest to ignore them)

----------
components: Library (Lib)
messages: 148299
nosy: michael.foord, ncoghlan
priority: normal
severity: normal
stage: needs patch
status: open
title: Simple exclusion filter for unittest autodiscovery
type: feature request
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13476>
_______________________________________

From report at bugs.python.org  Fri Nov 25 02:57:24 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 25 Nov 2011 01:57:24 +0000
Subject: [issue13476] Simple exclusion filter for unittest autodiscovery
In-Reply-To: <1322186223.31.0.112270498917.issue13476@psf.upfronthosting.co.za>
Message-ID: <1322186244.86.0.172249509733.issue13476@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/issue13476>
_______________________________________

From report at bugs.python.org  Fri Nov 25 03:01:48 2011
From: report at bugs.python.org (Eric Snow)
Date: Fri, 25 Nov 2011 02:01:48 +0000
Subject: [issue13475] Add '-p'/'--path0' command line option to override
	sys.path[0] initialisation
In-Reply-To: <1322181994.22.0.955887054946.issue13475@psf.upfronthosting.co.za>
Message-ID: <1322186508.49.0.990313412383.issue13475@psf.upfronthosting.co.za>


Changes by Eric Snow <ericsnowcurrently at gmail.com>:


----------
nosy: +eric.snow

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13475>
_______________________________________

From report at bugs.python.org  Fri Nov 25 04:11:05 2011
From: report at bugs.python.org (Brandon Craig Rhodes)
Date: Fri, 25 Nov 2011 03:11:05 +0000
Subject: [issue13477] tarfile module should have a command line
Message-ID: <1322190665.85.0.356467902383.issue13477@psf.upfronthosting.co.za>


New submission from Brandon Craig Rhodes <brandon at rhodesmill.org>:

The tarfile module should have a simple command line that allows it to be executed with "-m" ? even if its only ability was to take a filename and extract it to the current directory, it could be a lifesaver on Windows machines where Python has been installed but nothing else. Would such a patch be welcome if I could write one up?

----------
messages: 148300
nosy: brandon-rhodes
priority: normal
severity: normal
status: open
title: tarfile module should have a command line

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13477>
_______________________________________

From report at bugs.python.org  Fri Nov 25 04:18:28 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 25 Nov 2011 03:18:28 +0000
Subject: [issue13477] tarfile module should have a command line
In-Reply-To: <1322190665.85.0.356467902383.issue13477@psf.upfronthosting.co.za>
Message-ID: <1322191108.93.0.00122899260576.issue13477@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

The feature request seems reasonable to me, but this can only go in 3.3.
If you want to propose a patch, you might want to check the devguide and what other modules like zipfile do.

----------
nosy: +ezio.melotti, lars.gustaebel
stage:  -> test needed
type:  -> feature request
versions: +Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13477>
_______________________________________

From report at bugs.python.org  Fri Nov 25 05:39:55 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 25 Nov 2011 04:39:55 +0000
Subject: [issue11365] Integrate Buildroot patches (cross-compilation)
In-Reply-To: <1299015633.09.0.58407944374.issue11365@psf.upfronthosting.co.za>
Message-ID: <1322195995.99.0.790085781404.issue11365@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11365>
_______________________________________

From report at bugs.python.org  Fri Nov 25 05:44:45 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 25 Nov 2011 04:44:45 +0000
Subject: [issue4966] Improving Lib Doc Sequence Types Section
In-Reply-To: <1232149418.64.0.0450574767427.issue4966@psf.upfronthosting.co.za>
Message-ID: <1322196285.76.0.0425283378859.issue4966@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
versions:  -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4966>
_______________________________________

From report at bugs.python.org  Fri Nov 25 05:46:21 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 25 Nov 2011 04:46:21 +0000
Subject: [issue10811] sqlite segfault with generators
In-Reply-To: <1294018427.94.0.141740646278.issue10811@psf.upfronthosting.co.za>
Message-ID: <1322196381.22.0.0255098613861.issue10811@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Can this be closed?

----------
nosy: +ezio.melotti
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10811>
_______________________________________

From report at bugs.python.org  Fri Nov 25 06:34:55 2011
From: report at bugs.python.org (Arnaud Fontaine)
Date: Fri, 25 Nov 2011 05:34:55 +0000
Subject: [issue12776] argparse: type conversion function should be called only
	once
In-Reply-To: <1313657878.1.0.958946060112.issue12776@psf.upfronthosting.co.za>
Message-ID: <1322199295.66.0.435647115762.issue12776@psf.upfronthosting.co.za>


Arnaud Fontaine <arnau at debian.org> added the comment:

I have had a look at the issue more closely and my initial patch was not completely right as it didn't work properly with argparse_test.py despite all tests passing.

Therefore, I have amended my patch to not check whether action.default was a basestring which didn't make sense at all, but check instead if action.default is None (action.default default value is None if not given to add_argument as far as I understand). I also added a test for the issue reported above as it was missing and ran patchcheck to make sure everything was fine. All the tests (include argparse_test.py) passes without problem.

Could you please apply them? Many thanks.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12776>
_______________________________________

From report at bugs.python.org  Fri Nov 25 06:37:01 2011
From: report at bugs.python.org (Arnaud Fontaine)
Date: Fri, 25 Nov 2011 05:37:01 +0000
Subject: [issue12776] argparse: type conversion function should be called only
	once
In-Reply-To: <1313657878.1.0.958946060112.issue12776@psf.upfronthosting.co.za>
Message-ID: <1322199421.6.0.667110182309.issue12776@psf.upfronthosting.co.za>


Changes by Arnaud Fontaine <arnau at debian.org>:


Added file: http://bugs.python.org/file23775/py2.7-argparse-call-type-function-once-v3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12776>
_______________________________________

From report at bugs.python.org  Fri Nov 25 06:38:11 2011
From: report at bugs.python.org (Arnaud Fontaine)
Date: Fri, 25 Nov 2011 05:38:11 +0000
Subject: [issue12776] argparse: type conversion function should be called only
	once
In-Reply-To: <1313657878.1.0.958946060112.issue12776@psf.upfronthosting.co.za>
Message-ID: <1322199491.43.0.00996926809448.issue12776@psf.upfronthosting.co.za>


Changes by Arnaud Fontaine <arnau at debian.org>:


Added file: http://bugs.python.org/file23776/py3k-argparse-call-type-function-once-v3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12776>
_______________________________________

From report at bugs.python.org  Fri Nov 25 06:43:21 2011
From: report at bugs.python.org (Arnaud Fontaine)
Date: Fri, 25 Nov 2011 05:43:21 +0000
Subject: [issue12776] argparse: type conversion function should be called only
	once
In-Reply-To: <1313657878.1.0.958946060112.issue12776@psf.upfronthosting.co.za>
Message-ID: <1322199801.19.0.486897493818.issue12776@psf.upfronthosting.co.za>


Arnaud Fontaine <arnau at debian.org> added the comment:

BTW, about argparse_test, the default should be either '0' or 0 but not '\t' AFAIK because even the default value is converted using the given type function. It fails even with the last 2.7 version but it works well with my patch...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12776>
_______________________________________

From report at bugs.python.org  Fri Nov 25 07:09:29 2011
From: report at bugs.python.org (Eric Snow)
Date: Fri, 25 Nov 2011 06:09:29 +0000
Subject: [issue13475] Add '-p'/'--path0' command line option to override
	sys.path[0] initialisation
In-Reply-To: <1322181994.22.0.955887054946.issue13475@psf.upfronthosting.co.za>
Message-ID: <1322201369.94.0.963717599819.issue13475@psf.upfronthosting.co.za>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

+1  Both the -p and --nopath0 would be great additions and a good match for PEP 395.

So "-p ." would be equivalent to the current implicit sys.path[0] initialization, right?  Would any other effects happen with "-p" than sys.path[0] initialization?  I'll follow up with my one concern (the implicit "-p .") in a follow-up message.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13475>
_______________________________________

From report at bugs.python.org  Fri Nov 25 08:41:07 2011
From: report at bugs.python.org (kxroberto)
Date: Fri, 25 Nov 2011 07:41:07 +0000
Subject: [issue1459867] Message.as_string should use "mangle_from_=unixfrom"?
Message-ID: <1322206867.02.0.759758889271.issue1459867@psf.upfronthosting.co.za>


kxroberto <kxroberto at users.sourceforge.net> added the comment:

I'd still say this is a plain bug, which simply should be fixed.

"People who have working code" must have already a smart work around: either - or! : By doing the 5 low level code lines of .as_string() on their own. (there is no other way to produce clearly either a unixfrom=True or unixfrom=False Message). 
As of now this is simply neither nor. People are just quiet (I wonder), because the bug effect is rare. 

If somebody really wants to produce a unix mbox format for antiquated purposes, he would use unixfrom=True, when calling this function. (because otherwise its not complete unixfrom). And then the patched version is ok as well.

But when you call with unixfrom=False (default), a partially unixfrom=True mangled MIME body comes out. This is just buggy ...

Most striking is, that all lines in the message body (which the mail recipient reads), which start with the word "From", are converted to ">From". This is not acceptable. 

"a little bit more likely to preserve format of the message that was fed into it" :  Certainly mail message bodies must not be altered in a funny way when mangling is not ordered. 

I cannot imagine that sb can consciously or unconsciously rely on the bug. But in 99% of cases the patch would just fix peoples buggy programs.

If this really cannot be fixed, then at least a extra function next to as_string should be added (e.g. as_unmangled_string()), which allows creation of legal unmangled message. 
The current function can so far only produce a managled message, but consistently only then if in addition it is called explicitely with unixfrom=True ;-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1459867>
_______________________________________

From report at bugs.python.org  Fri Nov 25 09:13:35 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Fri, 25 Nov 2011 08:13:35 +0000
Subject: [issue13478] No documentation for timeit.default_timer
Message-ID: <1322208815.17.0.598781679655.issue13478@psf.upfronthosting.co.za>


New submission from Sandro Tosi <sandro.tosi at gmail.com>:

Hello,
timeit documentation doesn't mention default_timer, while the module exposes it publicly and there's code snippets on the web using it. It should be documented then.


ps: adding Georg to nosy as per Experts list

----------
assignee: docs at python
components: Documentation
messages: 148307
nosy: docs at python, georg.brandl, sandro.tosi
priority: normal
severity: normal
stage: needs patch
status: open
title: No documentation for timeit.default_timer
versions: Python 2.7, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13478>
_______________________________________

From report at bugs.python.org  Fri Nov 25 09:17:07 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Fri, 25 Nov 2011 08:17:07 +0000
Subject: [issue11849] glibc allocator doesn't release all free()ed memory
In-Reply-To: <1322181000.89.0.989499659253.issue11849@psf.upfronthosting.co.za>
Message-ID: <CAH_1eM2pTRsFd86bmf-ztdVhfUHA3Cx7EPT2mjq1pxxbvWB4pQ@mail.gmail.com>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

> For the record, this seems to make large allocations slower:
>
> -> with patch:
> $ ./python -m timeit "b'x'*200000"
> 10000 loops, best of 3: 27.2 usec per loop
>
> -> without patch:
> $ ./python -m timeit "b'x'*200000"
> 100000 loops, best of 3: 7.4 usec per loop
>

Yes, IIRC, I warned it could be a possible side effect: since we're
now using mmap() instead of brk() for large allocations (between 256B
and 32/64MB), it can be slower (that's the reason adaptive mmap
threadshold was introduced in the first place).

> More surprising is that, even ignoring the allocation cost, other operations on the memory area seem more expensive:

Hum, this it strange.
I see you're comparing 3.2 and default: could you run the same
benchmark on default with and without the patch ?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11849>
_______________________________________

From report at bugs.python.org  Fri Nov 25 09:22:27 2011
From: report at bugs.python.org (kxroberto)
Date: Fri, 25 Nov 2011 08:22:27 +0000
Subject: [issue13432] Encoding alias "unicode"
In-Reply-To: <1321702512.61.0.807104309131.issue13432@psf.upfronthosting.co.za>
Message-ID: <1322209347.38.0.890598120907.issue13432@psf.upfronthosting.co.za>


kxroberto <kxroberto at users.sourceforge.net> added the comment:

I wonder where is the origin, who is the inventor of the frequent charset=unicode? But:


"Sorry, but it's not obviously that Unicode means UTF-8."

When I faced
<meta content="text/html; charset=unicode" http-equiv="Content-Type"/>
the first time on the web, I guessed it is UTF-8 without looking. It even sounds colloquially reasonable ;-)  And its right 99.999% of cases. 
(UTF-16 is less frequent than this non-canonical "unicode")


"Definitely; this will just serve to create more confusion for beginners over what a Unicode string is:
unicodestring.encode('unicode')   <- WTF?"

I guess no python tutorial writer or encoding menu writer poses that example. That string comes in on technical paths:  web, MIME etc.
In the aliases.py there are many other names which are not canonical. frequency > convenience > alias


"Joining the chorus: people who need it in their application will have to add it themselves (monkeypatching the aliases dictionary as appropriate)."

Those people first would need to be aware of the option: Be all-seeing, or all wait for the first bug reports ...  


Reverse question: what would be the minus of having this alias?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13432>
_______________________________________

From report at bugs.python.org  Fri Nov 25 09:41:19 2011
From: report at bugs.python.org (Eric Snow)
Date: Fri, 25 Nov 2011 08:41:19 +0000
Subject: [issue8754] quote bad module name in ImportError-like messages
In-Reply-To: <1274202200.16.0.392487565261.issue8754@psf.upfronthosting.co.za>
Message-ID: <1322210479.73.0.88137436162.issue8754@psf.upfronthosting.co.za>


Changes by Eric Snow <ericsnowcurrently at gmail.com>:


----------
nosy: +eric.snow

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8754>
_______________________________________

From report at bugs.python.org  Fri Nov 25 09:53:01 2011
From: report at bugs.python.org (Eric Snow)
Date: Fri, 25 Nov 2011 08:53:01 +0000
Subject: [issue13475] Add '-p'/'--path0' command line option to override
	sys.path[0] initialisation
In-Reply-To: <1322181994.22.0.955887054946.issue13475@psf.upfronthosting.co.za>
Message-ID: <1322211181.82.0.909365539545.issue13475@psf.upfronthosting.co.za>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

The current behavior is an implicit "-p .", which causes all sorts of hard-to-figure-out problems, most of which PEP 395 is rightly trying to fix.  I'm suggesting that the next step would be to make "--nopath0" the default (rendering the flag unnecessary).  Since this changes the status quo, I'll try to make the case here that it's worth it.

---

First of all, the current implicit sys.path[0] initialization for scripts has been around since forever.  Why would we change it now?  The inspiration is three-fold: we _said_ we got rid of implicit relative imports already, PEP 395 already has made a case for changing the status quo (though not to this degree), and a "-p" flag provides a simple mechanism to get the current behavior explicitly.

Like Nick says in PEP 395, "PEP 328 eliminated implicit relative imports from imported modules. This PEP proposes that the de facto implicit relative imports from main modules that are provided by the current initialisation behaviour for sys.path[0] also be eliminated."

I'm just saying we should go all the way, and that the "-p" flag would allow that.  As far as I can tell, there are two meaningful use cases for the currently implicit sys.path[0]:  When you are first _learning_ Python (not actually using it)...  When you are working on a new project...  Let's look at both, first relative to the currently implicit "-p .", then to the explicit site.

1. (current behavior) implicit sys.path[0] initialization

When a beginner is first learning Python, they learn at the interactive prompt or by running a single script.  Pretty quickly they learn about writing their own modules and using import to load them.

Where do the modules live?  In the CWD from which they are calling the Python executable.  The current implicit "-p ." means they can import their modules right there, and not have to learn yet about sys.path.  That's nice since they can concentrate their focus.

But later they _will_ run into hard-to-figure-out problems when they start relying on what are effectively implicit relative imports.  Or they will run into one of the problems that PEP 395 explains, which are likewise head-scratchers.  All of this can be pretty frustrating when you still don't know about things like the import machinery.

Consider how that beginner uses the implicit sys.path[0] behavior on a project, once they have some experience (hopefully I don't misrepresent something Nick explained to me).  The src/ directory of the project won't be under sys.path yet.  So to quickly test out their script, they change to src/ and run their script from there (something PEP 395 rightfully proposes fine-tuning).  They conveniently don't have to manually fiddle with sys.path.  That's a pretty neat trick.

The problem I have with this is that there's no difference between the sys.path workaround for the script and it's expected normal usage.  If you aren't aware of what's going on behind-the-scenes, you may end up with some confusing import exceptions later on.

2. explicit sys.path[0] initialization

With a -p flag, it's really easy to say "-p ." and get the previous implicit behavior.  Consider the impact on our beginner.  The try to run their script that imports modules in their CWD, but end up with an ImportError because we no longer have an implicit "-p .".

How is this an improvement?  No more mysterious default behavior.  There's only one way it will fail and it will fail the same way every time.  They'll learn pretty quickly (if not taught already) you have to use the -p flag if you want to import modules that aren't in the "standard" places.  The ImportError message, special-cased for imports in __main__, could help in that regard.

<aside>
As an aside, implicit or explicit "--nopath0", the path to the file for the failed import can really help in related situations.  Including it as an attribute on the ImportError, and especially in the error message, would rock.  See issue1559549.
</aside>

For the "src/" use-case, the developer won't be able to rely on the implicit behavior anymore.  A simple, explicit "-p ." fills the gap and makes it clear that they are doing something unusual.  On top of that, they can use -p with the path to the "src/" directory from anywhere and not have to change their directory.  All the better if -p takes advantage of the proposals in PEP 395.


In the end, this boils down to opt-in vs. opt-out.  Either you opt-in to the sys.path[0] initialization by using -p, or you opt-out of the default implicit "-p ." by passing "--nopath0".  It's a case of "explicit is better than implicit" without a clear reason, to me, that the status quo is worth the exception anymore in the face of the alternative.

My only concern would be backwards compatibility.  How much do scripts out there rely on the implicit sys.path[0] initialization that aren't already broken by the removal of implicit relative imports?  I simply don't know.

However, I do know that having the -p flag that Nick has recommended would be awesome.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13475>
_______________________________________

From report at bugs.python.org  Fri Nov 25 10:02:43 2011
From: report at bugs.python.org (kxroberto)
Date: Fri, 25 Nov 2011 09:02:43 +0000
Subject: [issue13479] pickle to picky on re-defined classes
Message-ID: <1322211763.06.0.781568755806.issue13479@psf.upfronthosting.co.za>


New submission from kxroberto <kxroberto at users.sourceforge.net>:

When a class definition was re-executed (reload, exec ..) , pickling of existing instances fails for to picky reason (class object id mismatch). Solved by the one liner patch below.

Rational: Python is dynamic. Like with any normal attribute lookup: When its the same module/..name  this class is really meant - no matter about its id. 
(During unpickling its another id anyway, the code may have evolved years ...)


diff -ur --strip _orig/pickle.py ./pickle.py
--- _orig/pickle.py	2008-09-08 10:58:32 +0000
+++ ./pickle.py	2011-11-24 15:47:11 +0000
@@ -747,7 +747,7 @@
                 "Can't pickle %r: it's not found as %s.%s" %
                 (obj, module, name))
         else:
-            if klass is not obj:
+            if klass.__name__ != obj.__name__:
                 raise PicklingError(
                     "Can't pickle %r: it's not the same object as %s.%s" %
                     (obj, module, name))

----------
components: Library (Lib)
messages: 148311
nosy: kxroberto
priority: normal
severity: normal
status: open
title: pickle to picky on re-defined classes
type: crash
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/issue13479>
_______________________________________

From report at bugs.python.org  Fri Nov 25 10:03:34 2011
From: report at bugs.python.org (kxroberto)
Date: Fri, 25 Nov 2011 09:03:34 +0000
Subject: [issue13479] pickle too picky on re-defined classes
In-Reply-To: <1322211763.06.0.781568755806.issue13479@psf.upfronthosting.co.za>
Message-ID: <1322211814.92.0.220147880401.issue13479@psf.upfronthosting.co.za>


Changes by kxroberto <kxroberto at users.sourceforge.net>:


----------
title: pickle to picky on re-defined classes -> pickle too picky on re-defined classes

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13479>
_______________________________________

From report at bugs.python.org  Fri Nov 25 10:43:35 2011
From: report at bugs.python.org (Martin Panter)
Date: Fri, 25 Nov 2011 09:43:35 +0000
Subject: [issue10278] add time.wallclock() method
In-Reply-To: <1288624210.23.0.0497533122542.issue10278@psf.upfronthosting.co.za>
Message-ID: <1322214215.33.0.552826974791.issue10278@psf.upfronthosting.co.za>


Changes by Martin Panter <vadmium+py at gmail.com>:


----------
nosy: +vadmium

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10278>
_______________________________________

From report at bugs.python.org  Fri Nov 25 11:49:19 2011
From: report at bugs.python.org (Michael Foord)
Date: Fri, 25 Nov 2011 10:49:19 +0000
Subject: [issue10278] add time.wallclock() method
In-Reply-To: <1288624210.23.0.0497533122542.issue10278@psf.upfronthosting.co.za>
Message-ID: <1322218159.48.0.253126920611.issue10278@psf.upfronthosting.co.za>


Changes by Michael Foord <michael at voidspace.org.uk>:


----------
nosy:  -michael.foord
versions: +Python 3.3 -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10278>
_______________________________________

From report at bugs.python.org  Fri Nov 25 12:43:21 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 25 Nov 2011 11:43:21 +0000
Subject: [issue13432] Encoding alias "unicode"
In-Reply-To: <1322209347.38.0.890598120907.issue13432@psf.upfronthosting.co.za>
Message-ID: <2470327.8K650ryu5s@dsk000552>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> <meta content="text/html; charset=unicode" http-equiv="Content-Type"/>

Python is not a language written for the web, it's generic language to program 
anything! If you have a problem to parse an HTML page, the special case should 
be added to the HTML parser, not to the language.

Do you have the encoding issue with a parser included in Python 
(html.parser.*)? If you have the issue with an third-party parser, you have to 
report the bug there.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13432>
_______________________________________

From report at bugs.python.org  Fri Nov 25 13:18:13 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 25 Nov 2011 12:18:13 +0000
Subject: [issue11849] glibc allocator doesn't release all free()ed memory
In-Reply-To: <1302858518.86.0.0355572789659.issue11849@psf.upfronthosting.co.za>
Message-ID: <1322223493.53.0.369885830763.issue11849@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> I see you're comparing 3.2 and default: could you run the same
> benchmark on default with and without the patch ?

Same results:
-> default branch:
1000 loops, best of 3: 364 usec per loop
-> default branch with patch reverted:
10000 loops, best of 3: 185 usec per loop

(with kernel 2.6.38.8-desktop-8.mga and glibc-2.12.1-11.2.mga1)

And I can reproduce on another machine:

-> default branch:
1000 loops, best of 3: 224 usec per loop
-> default branch with patch reverted:
10000 loops, best of 3: 88 usec per loop

(Debian stable with kernel 2.6.32-5-686 and glibc 2.11.2-10)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11849>
_______________________________________

From report at bugs.python.org  Fri Nov 25 13:52:56 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 25 Nov 2011 12:52:56 +0000
Subject: [issue11849] glibc allocator doesn't release all free()ed memory
In-Reply-To: <1302858518.86.0.0355572789659.issue11849@psf.upfronthosting.co.za>
Message-ID: <1322225576.44.0.73701624914.issue11849@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Ah, sorry, false alarm. "b[:] = b" actually makes a temporary copy of the bytearray when assigning to itself (!).

However, there's still another strange regression:

$ ./python -m timeit \
  -s "n=300000; f=open('10MB.bin', 'rb', buffering=0); b=bytearray(n)" \
  "f.seek(0);f.readinto(b)"

-> default branch:
10000 loops, best of 3: 43 usec per loop
-> default branch with patch reverted:
10000 loops, best of 3: 27.5 usec per loop

FileIO.readinto executes a single read() into the passed buffer.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11849>
_______________________________________

From report at bugs.python.org  Fri Nov 25 14:26:46 2011
From: report at bugs.python.org (Rasmus Ory Nielsen)
Date: Fri, 25 Nov 2011 13:26:46 +0000
Subject: [issue12559] gzip.open() needs an optional encoding argument
In-Reply-To: <1310657482.81.0.606922001994.issue12559@psf.upfronthosting.co.za>
Message-ID: <1322227606.66.0.485295538849.issue12559@psf.upfronthosting.co.za>


Changes by Rasmus Ory Nielsen <ron at ron.dk>:


----------
nosy: +rasmusory

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12559>
_______________________________________

From report at bugs.python.org  Fri Nov 25 15:51:35 2011
From: report at bugs.python.org (Asa Dawson)
Date: Fri, 25 Nov 2011 14:51:35 +0000
Subject: [issue13480] range exits loop without action when start is higher
	than end
Message-ID: <1322232695.49.0.811038839727.issue13480@psf.upfronthosting.co.za>


New submission from Asa Dawson <sunderphon at googlemail.com>:

range has an odd behavior in which it assumes (regardless of start/end) that it should be counting up. Attempting something such as:

for i in range(10,0):
    print i

This loop simply runs through without doing anything, because start is larger than end.

I'm putting forward the proposition that when end is lower than start, range should count downwards rather than upwards.

----------
components: None
messages: 148315
nosy: Asa.Dawson
priority: normal
severity: normal
status: open
title: range exits loop without action when start is higher than end
type: behavior
versions: Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13480>
_______________________________________

From report at bugs.python.org  Fri Nov 25 15:59:31 2011
From: report at bugs.python.org (R. David Murray)
Date: Fri, 25 Nov 2011 14:59:31 +0000
Subject: [issue13480] range exits loop without action when start is higher
	than end
In-Reply-To: <1322232695.49.0.811038839727.issue13480@psf.upfronthosting.co.za>
Message-ID: <1322233171.79.0.76838935233.issue13480@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Nope.  If you want to count backward, use a negative step.  Not doing anything if end is lower than start allows code to take advantage of "don't care" edge cases, just like 'abc'[4:] returning the empty string does.  Range is often used in 'for' loops, so having the loop not execute if the computed end is less than the computed start is an intentional and important feature.

----------
nosy: +r.david.murray
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13480>
_______________________________________

From report at bugs.python.org  Fri Nov 25 16:00:08 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 25 Nov 2011 15:00:08 +0000
Subject: [issue13402] Document absoluteness of sys.executable
In-Reply-To: <1321289437.84.0.982753479785.issue13402@psf.upfronthosting.co.za>
Message-ID: <1322233208.53.0.636778099863.issue13402@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

This is the bug I was thinking about: #7774.  Adding some people from that discussion to nosy.

----------
nosy: +flox, haypo, pitrou, ronaldoussoren, schmir

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13402>
_______________________________________

From report at bugs.python.org  Fri Nov 25 16:08:12 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 25 Nov 2011 15:08:12 +0000
Subject: [issue11365] Integrate Buildroot patches (cross-compilation)
In-Reply-To: <1299015633.09.0.58407944374.issue11365@psf.upfronthosting.co.za>
Message-ID: <1322233692.87.0.441117665236.issue11365@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

The distutils changes will not happen, we?re under a feature freeze.  Cross-compilation support would need to be added to packaging, and we need to port Python?s build process to packaging too for 3.4 or 3.5.  Also, it?s very hard to decide to accept one solution from the dozen of different patch sets posted on the various issues.  I think this would need a concerted effort from all people who have worked on patches, with goals clearly defined in a public mailing list, then python-dev agreement (including MvL, who turns a very critical eye to such patches), then one patch satisfying the requirements.

I don?t like to reject the hard work of contributors who want to give back, but given the situation I describe above I?m inclined to close all of these bugs for now.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11365>
_______________________________________

From report at bugs.python.org  Fri Nov 25 16:15:13 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 25 Nov 2011 15:15:13 +0000
Subject: [issue13400] packaging: build command should accept --compile,
	--no-compile and --optimize options
In-Reply-To: <1321281623.21.0.854677924579.issue13400@psf.upfronthosting.co.za>
Message-ID: <1322234113.79.0.92300725469.issue13400@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Thinking about this, build_py --compile clearly refers to byte-compilation of Python modules, but the same option on the build command is more ambiguous: It could be interpreted to mean ?skip C compilation?.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13400>
_______________________________________

From report at bugs.python.org  Fri Nov 25 16:15:31 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 25 Nov 2011 15:15:31 +0000
Subject: [issue11365] Integrate Buildroot patches (cross-compilation)
In-Reply-To: <1322233692.87.0.441117665236.issue11365@psf.upfronthosting.co.za>
Message-ID: <1322233833.3272.0.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> The distutils changes will not happen, we?re under a feature freeze.
> Cross-compilation support would need to be added to packaging, and we
> need to port Python?s build process to packaging too for 3.4 or 3.5.

Why 3.4 or 3.5?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11365>
_______________________________________

From report at bugs.python.org  Fri Nov 25 16:16:04 2011
From: report at bugs.python.org (=?utf-8?b?U8OpYmFzdGllbiBTYWJsw6k=?=)
Date: Fri, 25 Nov 2011 15:16:04 +0000
Subject: [issue13210] Support Visual Studio 2010
In-Reply-To: <1318942521.44.0.961979099616.issue13210@psf.upfronthosting.co.za>
Message-ID: <1322234164.16.0.0498401835171.issue13210@psf.upfronthosting.co.za>


S?bastien Sabl? <sable at users.sourceforge.net> added the comment:

I don't have commit access on hg.python.org, so I also created a clone on bitbucket at:
https://bitbucket.org/sablefr/py27vs2010/overview

I work with a patch queue for the moment since everything is not completely settled yet.

The patch are against python 2.7 for the moment, I will do the same for python trunk soon.
I can run all the tests with builbot and I am working on reducing the errors.

Currently I am at:
337 tests OK.
5 tests failed:
    test_anydbm test_pep277 test_shelve test_subprocess test_trace
1 test altered the execution environment:
    test_distutils
45 tests skipped:
    test_aepack test_al test_applesingle test_bsddb185 test_cd test_cl
    test_commands test_crypt test_curses test_dbm test_dl test_epoll
    test_fcntl test_fork1 test_gdb test_gdbm test_gl test_grp
    test_imgfile test_ioctl test_kqueue test_linuxaudiodev test_macos
    test_macostools test_mhlib test_nis test_openpty test_ossaudiodev
    test_pipes test_poll test_posix test_pty test_pwd test_readline
    test_resource test_scriptpackages test_sunaudiodev test_tcl
    test_threadsignals test_tk test_ttk_guionly test_ttk_textonly
    test_wait3 test_wait4 test_zipfile64
6 skips unexpected on win32:
    test_gdb test_readline test_tcl test_tk test_ttk_guionly
    test_ttk_textonly

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13210>
_______________________________________

From report at bugs.python.org  Fri Nov 25 16:20:03 2011
From: report at bugs.python.org (Brian Curtin)
Date: Fri, 25 Nov 2011 15:20:03 +0000
Subject: [issue13210] Support Visual Studio 2010
In-Reply-To: <1318942521.44.0.961979099616.issue13210@psf.upfronthosting.co.za>
Message-ID: <1322234403.18.0.978965693937.issue13210@psf.upfronthosting.co.za>


Brian Curtin <brian at python.org> added the comment:

Just to be sure in case you didn't know, but patches against 2.7 for this issue won't be accepted.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13210>
_______________________________________

From report at bugs.python.org  Fri Nov 25 16:21:27 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 25 Nov 2011 15:21:27 +0000
Subject: [issue11365] Integrate Buildroot patches (cross-compilation)
In-Reply-To: <1299015633.09.0.58407944374.issue11365@psf.upfronthosting.co.za>
Message-ID: <1322234487.05.0.991705437838.issue11365@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Because I don?t think anyone will have the time to try to port Python?s setup.py to packaging, fix the bugs it founds and add the features it needs in time for 3.3.  On my own todo lists, there is much work still needed to define the public API, add features we want, test it with real applications such as pip, fix major bugs, make the docs usable.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11365>
_______________________________________

From report at bugs.python.org  Fri Nov 25 16:22:08 2011
From: report at bugs.python.org (Silvan Jegen)
Date: Fri, 25 Nov 2011 15:22:08 +0000
Subject: [issue9708] cElementTree iterparse does not support "parser" argument
In-Reply-To: <1283032296.54.0.54816594665.issue9708@psf.upfronthosting.co.za>
Message-ID: <1322234528.94.0.959215612769.issue9708@psf.upfronthosting.co.za>


Silvan Jegen <s.jegen at gmail.com> added the comment:

I changed a few lines in the glue code of the _elementtree.c Module of Python 3.3.0a0 to add support for the "parser" argument. I do have to admit though that I am not familiar with the Python/C-API so this solution may not be ideal (i. e. it may be falling back to the Python implementation of iterparse without me realizing).

Please note that it is not possible to give an ElementTree.XMLParser instance as a parameter to the cElementTree.iterparse function (which may not be desirable in any case) using this patch.

I assume that the patch will be applicable to Python 2.7.x as well, but I did not try it. I can apply/adapt it to Python 2.7.x, if you think that would be useful.

----------
keywords: +patch
nosy: +Shugyousha
Added file: http://bugs.python.org/file23777/issue9708.Python330a0.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9708>
_______________________________________

From report at bugs.python.org  Fri Nov 25 16:33:05 2011
From: report at bugs.python.org (=?utf-8?b?U8OpYmFzdGllbiBTYWJsw6k=?=)
Date: Fri, 25 Nov 2011 15:33:05 +0000
Subject: [issue13210] Support Visual Studio 2010
In-Reply-To: <1318942521.44.0.961979099616.issue13210@psf.upfronthosting.co.za>
Message-ID: <1322235185.87.0.841823804471.issue13210@psf.upfronthosting.co.za>


S?bastien Sabl? <sable at users.sourceforge.net> added the comment:

Yes I know, but this is my primary target as this is the version that I use in my product for the moment.

I will test python trunk soon now that Python 2.7 with VS2010 is in a rather good shape.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13210>
_______________________________________

From report at bugs.python.org  Fri Nov 25 16:34:37 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 25 Nov 2011 15:34:37 +0000
Subject: [issue13210] Support Visual Studio 2010
In-Reply-To: <1318942521.44.0.961979099616.issue13210@psf.upfronthosting.co.za>
Message-ID: <1322235277.18.0.339543077326.issue13210@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Just to avoid misunderstandings: The Subversion concept of trunk (or rather py3k trunk) maps to the Mercurial branch named default, which is what you get when you clone hg.python.org/cpython.  This is 3.3.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13210>
_______________________________________

From report at bugs.python.org  Fri Nov 25 16:38:26 2011
From: report at bugs.python.org (=?utf-8?b?U8OpYmFzdGllbiBTYWJsw6k=?=)
Date: Fri, 25 Nov 2011 15:38:26 +0000
Subject: [issue13461] Error on test_issue_1395_5 with Python 2.7 and VS2010
In-Reply-To: <1322056958.99.0.498945300571.issue13461@psf.upfronthosting.co.za>
Message-ID: <1322235506.15.0.579952390551.issue13461@psf.upfronthosting.co.za>


S?bastien Sabl? <sable at users.sourceforge.net> added the comment:

Thanks Antoine! It solved the issue.

I will check soon with Python trunk to see if the same thing applies.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13461>
_______________________________________

From report at bugs.python.org  Fri Nov 25 16:48:05 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 25 Nov 2011 15:48:05 +0000
Subject: [issue13461] Error on test_issue_1395_5 with Python 2.7 and VS2010
In-Reply-To: <1322056958.99.0.498945300571.issue13461@psf.upfronthosting.co.za>
Message-ID: <1322236085.96.0.271199961143.issue13461@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
versions: +Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13461>
_______________________________________

From report at bugs.python.org  Fri Nov 25 16:48:11 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 25 Nov 2011 15:48:11 +0000
Subject: [issue13461] Error on test_issue_1395_5 with Python 2.7 and VS2010
In-Reply-To: <1322056958.99.0.498945300571.issue13461@psf.upfronthosting.co.za>
Message-ID: <1322236091.24.0.222638911762.issue13461@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
priority: normal -> high
type:  -> crash

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13461>
_______________________________________

From report at bugs.python.org  Fri Nov 25 16:52:25 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 25 Nov 2011 15:52:25 +0000
Subject: [issue13461] Error on test_issue_1395_5 with Python 2.7 and VS2010
In-Reply-To: <1322056958.99.0.498945300571.issue13461@psf.upfronthosting.co.za>
Message-ID: <1322236345.96.0.309151345981.issue13461@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

I've identified a few other cases where a '#' format is passed a numeric literal:

Python/codecs.c:514: return Py_BuildValue("(u#n)", &end, 0, end);
Modules/_io/textio.c:2323: DECODER_DECODE(input, 1, n);

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13461>
_______________________________________

From report at bugs.python.org  Fri Nov 25 16:58:27 2011
From: report at bugs.python.org (Meador Inge)
Date: Fri, 25 Nov 2011 15:58:27 +0000
Subject: [issue12618] py_compile cannot create files in current directory
In-Reply-To: <1311406971.17.0.312082121474.issue12618@psf.upfronthosting.co.za>
Message-ID: <1322236707.51.0.430765400122.issue12618@psf.upfronthosting.co.za>


Meador Inge <meadori at gmail.com> added the comment:

?ric, sure, I will commit the tests sometime today.  Then I will respond to the 'os.path.abspath' question as well.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12618>
_______________________________________

From report at bugs.python.org  Fri Nov 25 17:06:17 2011
From: report at bugs.python.org (=?utf-8?b?U8OpYmFzdGllbiBTYWJsw6k=?=)
Date: Fri, 25 Nov 2011 16:06:17 +0000
Subject: [issue10752] build_ssl.py is relying on unreliable behaviour of
	os.popen
In-Reply-To: <1292972982.57.0.365932571977.issue10752@psf.upfronthosting.co.za>
Message-ID: <1322237177.62.0.282761687556.issue10752@psf.upfronthosting.co.za>


S?bastien Sabl? <sable at users.sourceforge.net> added the comment:

I had the same issue while compiling Python 2.7 with ActivePerl on windows, and I can confirm that the proposed patch solves the issue.

----------
nosy: +sable
versions: +Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10752>
_______________________________________

From report at bugs.python.org  Fri Nov 25 17:20:16 2011
From: report at bugs.python.org (Brian Curtin)
Date: Fri, 25 Nov 2011 16:20:16 +0000
Subject: [issue13210] Support Visual Studio 2010
In-Reply-To: <1318942521.44.0.961979099616.issue13210@psf.upfronthosting.co.za>
Message-ID: <1322238016.76.0.726245969771.issue13210@psf.upfronthosting.co.za>


Brian Curtin <brian at python.org> added the comment:

Before we both go down the same paths and duplicate effort, http://hg.python.org/sandbox/vs2010port/ has already completed the transition in terms of running the conversion, saving off the VS9 files, making some minimal code changes (errno module specifically), and has begun to fix tests. This is already done for 'default' aka 3.3.

8 tests failed:
    test_distutils test_email test_io test_os test_packaging
    test_pep3151 test_socket test_subprocess

The distutils and packaging test failures seem to be about differences in command line flags for some of the VS2010 binaries (looks like a link.exe issue in one). Most of the others are about remaining errno differences, and the subprocess issue is with too many files being open.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13210>
_______________________________________

From report at bugs.python.org  Fri Nov 25 17:29:05 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 25 Nov 2011 16:29:05 +0000
Subject: [issue12876] Make Test Error : ImportError: No module named _sha256
In-Reply-To: <1314873741.02.0.732192179897.issue12876@psf.upfronthosting.co.za>
Message-ID: <1322238545.21.0.19769576794.issue12876@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Sorry to be of little help.  I also have a problem with hashlib, but it?s with Python 2.4 on Debian multiarch with linux3, so probably different from your problem.  You could try asking on the python-dev mailing list.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12876>
_______________________________________

From report at bugs.python.org  Fri Nov 25 17:37:55 2011
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Fri, 25 Nov 2011 16:37:55 +0000
Subject: [issue13400] packaging: build command should accept --compile,
	--no-compile and --optimize options
In-Reply-To: <1321281623.21.0.854677924579.issue13400@psf.upfronthosting.co.za>
Message-ID: <1322239075.51.0.575412769163.issue13400@psf.upfronthosting.co.za>


Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com> added the comment:

Maybe --byte-compile and --no-byte-compile could be used.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13400>
_______________________________________

From report at bugs.python.org  Fri Nov 25 17:40:07 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 25 Nov 2011 16:40:07 +0000
Subject: =?utf-8?q?=5Bissue13472=5D_devguide_doesn=E2=80=99t_list_all_build_depend?=
	=?utf-8?q?encies?=
In-Reply-To: <1322142769.6.0.687458451697.issue13472@psf.upfronthosting.co.za>
Message-ID: <1322239207.8.0.50468199604.issue13472@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> Moreover these dependencies are optional, so there's no need to install them unless they are
> specifically needed
I think about it in the reverse: You want a featurefull library, and disable some things (zlib, ssl, threads) only if you specifically don?t want them (if you?re a Twisted fan for example <async wink>).

> (on a related note I would also add an "optional" in the warning that says "Python build
> finished, but the necessary bits to build these modules were not found" -- I've seen enough
> people complaining that the build "failed" because this dependencies were missing).
Sure.  I read all changesets for Python?s setup.py recently (don?t judge) and the addition of this message and further edits to its wording were done exactly to avoid people worrying that their python binary is not usable.

> Explaining how to get them in the build page sounds fine to me.
Okay; do we need to collect info for all major OSes (I?m taking the list of stable 3.2 buildbots to determine ?major?)?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13472>
_______________________________________

From report at bugs.python.org  Fri Nov 25 17:46:03 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 25 Nov 2011 16:46:03 +0000
Subject: [issue9957] SpooledTemporayFile.truncate should take size parameter
In-Reply-To: <1285552951.71.0.864499786785.issue9957@psf.upfronthosting.co.za>
Message-ID: <1322239563.4.0.556972629376.issue9957@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Okay, then stable branches need a doc/docstring patch to remove the statement that SpooledTemporaryFile ?operates exactly as TemporaryFile does?.  Ryan, would you like to do that patch too?

Antoine, will you commit?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9957>
_______________________________________

From report at bugs.python.org  Fri Nov 25 17:53:03 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 25 Nov 2011 16:53:03 +0000
Subject: [issue13475] Add '-p'/'--path0' command line option to override
	sys.path[0] initialisation
In-Reply-To: <1322181994.22.0.955887054946.issue13475@psf.upfronthosting.co.za>
Message-ID: <1322239983.24.0.228263845301.issue13475@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I don?t understand all the issues and it?s too late for me to read all the thread, but I hope these comments are helpful:

- If our goal is to help na?ve users, then one or two new options wouldn?t help (people want to run ?python path/to/thing.py? and want it to Just Work?)

- Getting a very helpful error message is second-best to Just Working?

- This probably needs a wider audience, python-ideas or python-dev, and maybe a PEP to explain all the issues and all the considered solutions.

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13475>
_______________________________________

From report at bugs.python.org  Fri Nov 25 17:58:26 2011
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 25 Nov 2011 16:58:26 +0000
Subject: [issue13479] pickle too picky on re-defined classes
In-Reply-To: <1322211763.06.0.781568755806.issue13479@psf.upfronthosting.co.za>
Message-ID: <1322240306.93.0.572233427854.issue13479@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

Hm, this change allows many other *undesirable* objects pass the test as well. I'd prefer to stick to the rule, "when in doubt, raise an error".
Maybe using == instead of 'is' as the test would be acceptable?

----------
nosy: +gvanrossum

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13479>
_______________________________________

From report at bugs.python.org  Fri Nov 25 18:01:19 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 25 Nov 2011 17:01:19 +0000
Subject: [issue1521950] shlex.split() does not tokenize like the shell
Message-ID: <1322240479.95.0.427549844498.issue1521950@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> Of course, that's how it's used.  That's all it can do right now.
:) What I meant is that it is *meant* to be used in this way.

> I was was splitting and combining commands (using ;, &&, and ||) and then running the resulting
> (mega) one liners over ssh.  It still gets run by a shell, but I was specifying the control flow.
Thank you for the reply.  It is indeed a valuable use case to pass a command line as one string to ssh, and the split/quote combo should round-trip and be useful for this usage.

> I'll see if I can come up with a reference case and maybe a unittest this weekend
Great!  A new argument (with a default value which gets us the previous behavior) will probably be needed, to preserve backward compatibility.

----------
nosy: +niemeyer
versions: +Python 3.3 -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1521950>
_______________________________________

From report at bugs.python.org  Fri Nov 25 18:08:11 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 25 Nov 2011 17:08:11 +0000
Subject: [issue9957] SpooledTemporayFile.truncate should take size parameter
In-Reply-To: <1285552951.71.0.864499786785.issue9957@psf.upfronthosting.co.za>
Message-ID: <E1RTzFy-0006p0-09@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 5a6911930bad by Antoine Pitrou in branch 'default':
Issue #9957: SpooledTemporaryFile.truncate() now accepts an optional size parameter, as other file-like objects.
http://hg.python.org/cpython/rev/5a6911930bad

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9957>
_______________________________________

From report at bugs.python.org  Fri Nov 25 18:09:03 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 25 Nov 2011 17:09:03 +0000
Subject: [issue9957] SpooledTemporayFile.truncate should take size parameter
In-Reply-To: <1285552951.71.0.864499786785.issue9957@psf.upfronthosting.co.za>
Message-ID: <1322240943.83.0.85808918266.issue9957@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Committed, thank you. By the way, Ryan, we now use Mercurial for developing, the Subversion repository is obsolete (see the devguide for more info).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9957>
_______________________________________

From report at bugs.python.org  Fri Nov 25 18:12:04 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 25 Nov 2011 17:12:04 +0000
Subject: [issue13400] packaging: build command should accept --compile,
	--no-compile and --optimize options
In-Reply-To: <1321281623.21.0.854677924579.issue13400@psf.upfronthosting.co.za>
Message-ID: <1322241124.16.0.610286092483.issue13400@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Juste a note: currently, when a command sets one option from the value given to another command, they have the same name, with two kinds of exceptions:
- build --build-lib becomes build_lib --build-dir (etc.)
- install --install-lib becomes install_lib --install-dir (etc.)

So, introducing --(no-)byte-compile and --optimize-bytecode= would change that scheme, but it is not a big deal.

On the third hand, maybe this is an opportunity to change the option names on the build_py and install* commands too.  For example, for a long time I thought that --optimize implied --compile, but actually they?re distinct options.

BTW, would these new options simplify some scripts you have, or do you just request them for consistency?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13400>
_______________________________________

From report at bugs.python.org  Fri Nov 25 18:38:31 2011
From: report at bugs.python.org (Eric Snow)
Date: Fri, 25 Nov 2011 17:38:31 +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: <1322242711.09.0.416991698941.issue12307@psf.upfronthosting.co.za>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

?ric has addressed this in http://hg.python.org/peps/rev/6c7415a4f0f3 (thanks ?ric).  Do the docs for python.org have to be manually rebuilt or is that on a cron?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12307>
_______________________________________

From report at bugs.python.org  Fri Nov 25 18:59:11 2011
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Fri, 25 Nov 2011 17:59:11 +0000
Subject: [issue13400] packaging: build command should accept --compile,
	--no-compile and --optimize options
In-Reply-To: <1321281623.21.0.854677924579.issue13400@psf.upfronthosting.co.za>
Message-ID: <1322243951.52.0.771014524667.issue13400@psf.upfronthosting.co.za>


Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com> added the comment:

Byte-compilation should be disabled during building of packages in Gentoo. PYTHONDONTWRITEBYTECODE="1" is set by default in environment. This variable affects distutils and until recently it affected packaging. --no-byte-compile will have to be explicitly passed to `pysetup${version} run build` and `pysetup${version} run install_dist` to disable byte-compilation.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13400>
_______________________________________

From report at bugs.python.org  Fri Nov 25 19:03:55 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 25 Nov 2011 18:03:55 +0000
Subject: [issue13448] PEP 3155 implementation
In-Reply-To: <1321908830.82.0.349913947268.issue13448@psf.upfronthosting.co.za>
Message-ID: <E1RU07t-0002xA-V1@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset e1dbc72bd97f by Antoine Pitrou in branch 'default':
PEP 3155 / issue #13448: Qualified name for classes and functions.
http://hg.python.org/cpython/rev/e1dbc72bd97f

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13448>
_______________________________________

From report at bugs.python.org  Fri Nov 25 19:39:46 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 25 Nov 2011 18:39:46 +0000
Subject: =?utf-8?q?=5Bissue13472=5D_devguide_doesn=E2=80=99t_list_all_build_depend?=
	=?utf-8?q?encies?=
In-Reply-To: <1322142769.6.0.687458451697.issue13472@psf.upfronthosting.co.za>
Message-ID: <1322246386.58.0.522253169095.issue13472@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

> I think about it in the reverse: You want a featurefull library, and 
> disable some things (zlib, ssl, threads) only if you specifically 
> don?t want them (if you?re a Twisted fan for example <async wink>).

I have a few arguments in favor of my position:
1) Python and its test suite should always run without errors, even when some dependencies are missing (I've found and fixed several issues related to zlib because it was missing here);
2) The default Python installed with the OS will use whatever dependencies are already provided, so if you add all the missing ones manually, you'll be testing in a scenario that is different from the "default" one (you might argue that if no one installs all the missing dependencies, we can't know if they all work together everywhere (IIRC at some point we had a discussion about having a buildbot without the optional dependencies too));
3) Hard work pays off later. Laziness pays off now!

> the addition of this message and further edits to its wording were done
> exactly to avoid people worrying that their python binary is not usable.

But it's still missing an "optional" before modules imho.  The second message that says to "look in setup.py in detect_modules()" doesn't seem too useful too (but maybe I should take a look ;).  There are a couple of threads on Core-Mentorship by people that got confused by these messages (and some include discussions about finding the dependencies).

> Okay; do we need to collect info for all major OSes
> (I?m taking the list of stable 3.2 buildbots to determine ?major?)?

You can also do it incrementally, adding e.g. "For Debian and derivative systems you can use ``aptitude build-dep pythonX.Y``." and then add other items to the list as soon as we figure them out (you can also try to figure them out in advanced, as long as finding the command for some obscure platform doesn't keep on hold the list of commands for other well known platforms).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13472>
_______________________________________

From report at bugs.python.org  Fri Nov 25 19:44:16 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 25 Nov 2011 18:44:16 +0000
Subject: [issue13448] PEP 3155 implementation
In-Reply-To: <1321908830.82.0.349913947268.issue13448@psf.upfronthosting.co.za>
Message-ID: <1322246656.95.0.915128738371.issue13448@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Now committed together with docs and a what's new entry. Thanks for the reviews!

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13448>
_______________________________________

From report at bugs.python.org  Fri Nov 25 20:06:52 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 25 Nov 2011 19:06:52 +0000
Subject: [issue13093] Redundant code in PyUnicode_EncodeDecimal()
In-Reply-To: <1317569955.86.0.21646060057.issue13093@psf.upfronthosting.co.za>
Message-ID: <E1RU16o-0007yL-KX@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset a20fae95618c by Victor Stinner in branch 'default':
Close #13093: PyUnicode_EncodeDecimal() doesn't support error handlers
http://hg.python.org/cpython/rev/a20fae95618c

----------
stage: patch review -> committed/rejected

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13093>
_______________________________________

From report at bugs.python.org  Fri Nov 25 20:09:42 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 25 Nov 2011 19:09:42 +0000
Subject: [issue13093] Redundant code in PyUnicode_EncodeDecimal()
In-Reply-To: <1317569955.86.0.21646060057.issue13093@psf.upfronthosting.co.za>
Message-ID: <1322248182.75.0.811432608331.issue13093@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
Removed message: http://bugs.python.org/msg148348

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13093>
_______________________________________

From report at bugs.python.org  Fri Nov 25 20:10:17 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 25 Nov 2011 19:10:17 +0000
Subject: [issue13452] PyUnicode_EncodeDecimal: reject error handlers different
	than strict
In-Reply-To: <1321964689.08.0.0221252575292.issue13452@psf.upfronthosting.co.za>
Message-ID: <1322248217.97.0.610563279042.issue13452@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Hum, I only changed PyUnicode_EncodeDecimal in Python 3.3, I prefer to not touch stable releases (2.7, 3.2).

New changeset a20fae95618c by Victor Stinner in branch 'default':
Close #13093: PyUnicode_EncodeDecimal() doesn't support error handlers
http://hg.python.org/cpython/rev/a20fae95618c

(Oops, I specified the wrong issue number: fixed in 9a712ad593bb)

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13452>
_______________________________________

From report at bugs.python.org  Fri Nov 25 20:22:05 2011
From: report at bugs.python.org (Eric Snow)
Date: Fri, 25 Nov 2011 19:22:05 +0000
Subject: [issue13475] Add '-p'/'--path0' command line option to override
	sys.path[0] initialisation
In-Reply-To: <1322181994.22.0.955887054946.issue13475@psf.upfronthosting.co.za>
Message-ID: <1322248925.73.0.390938259519.issue13475@psf.upfronthosting.co.za>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

First of all, I don't want Nick's proposal in this issue (the -p and --nopath0 flags) to be misunderstood because of me.  His is a great idea that will make a really useful shortcut available and will _not_ change any current behavior.

My (overly) long message is an attempt to justify going with a more drastic variation, to which your response applies exclusively.  I stand by what I said, but I would be quite happy with the original proposal, to which your response does not apply.  :)

Just wanted to make all that clear so I don't get in the way of a good thing.  :)

Your comments are spot on.  Your concerns are exactly the ones I would need to assuage before my alternative would be acceptable.  When I get a chance I'll take this to python-ideas.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13475>
_______________________________________

From report at bugs.python.org  Fri Nov 25 20:23:00 2011
From: report at bugs.python.org (Eli Collins)
Date: Fri, 25 Nov 2011 19:23:00 +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: <1322248980.29.0.629192054283.issue12424@psf.upfronthosting.co.za>


Eli Collins <elic at assurancetechnologies.com> added the comment:

The second patchset (9170231ebf14.diff) should implement all the changes you suggested in your second review (dated 2011-09-05).

---

The only non-addressed item in your second review was a request for clarification on a potential error I noticed (and described somewhat poorly). On later examination, I realized I was mistaken, so didn't want to trouble anyone further with it. 

(If you want details... I noticed that if a line ends with ";;", _pop_values() will call interpret() with an empty string. I initially though that would cause an error, but later realized it just means interpret() would return False, causing the line to be ignored, which is probably fine for that border case - especially since packaging.metadata has the same behavior for lines ending with ";").

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12424>
_______________________________________

From report at bugs.python.org  Fri Nov 25 20:25:35 2011
From: report at bugs.python.org (Dan Christian)
Date: Fri, 25 Nov 2011 19:25:35 +0000
Subject: [issue1521950] shlex.split() does not tokenize like the shell
In-Reply-To: <1322240479.95.0.427549844498.issue1521950@psf.upfronthosting.co.za>
Message-ID: <CAEcGQ+POMTHT1PmJdRc4jF5bo=1z31kvu_08deY_8vD2sE25fw@mail.gmail.com>


Dan Christian <robodan at users.sourceforge.net> added the comment:

I've attached a diff to test_shlex.py and a script that I used to
verify what the shells actually do.
Both are relative to Python-3.2.2/Lib/test

I'm completely ignoring the quotes issue for now.  That should
probably be an enhancement.  I don't think it really matters until the
parsing issues are resolved.

ref_shlex is python 2 syntax.  python -3 shows that it should convert cleanly.
./ref_shlex.py
It will run by default against /bin/*sh
If you don't want that, do something like: export SHELLS='/bin/sh,/bin/csh'
It runs as a unittest.  So you will only see dots if all shells do
what it expects.  Some shells are flaky (e.g. zsh, tcsh), so you may
need to run it multiple times.

Getting this into the mainline will be interesting.  I would think it
would take some community discussion.  I may be able to convince
people that the current behaviour is wrong, but I can't tell you what
will break if it is "fixed".  And should the fix be the default?  As
you mentioned, it depends on what people expect it to do and how it is
currently being used.  I see the first step as presenting a clear case
of how it should work.

-Dan

On Fri, Nov 25, 2011 at 10:01 AM, ?ric Araujo <report at bugs.python.org> wrote:
>
> ?ric Araujo <merwok at netwok.org> added the comment:
>
>> Of course, that's how it's used. ?That's all it can do right now.
> :) What I meant is that it is *meant* to be used in this way.
>
>> I was was splitting and combining commands (using ;, &&, and ||) and then running the resulting
>> (mega) one liners over ssh. ?It still gets run by a shell, but I was specifying the control flow.
> Thank you for the reply. ?It is indeed a valuable use case to pass a command line as one string to ssh, and the split/quote combo should round-trip and be useful for this usage.
>
>> I'll see if I can come up with a reference case and maybe a unittest this weekend
> Great! ?A new argument (with a default value which gets us the previous behavior) will probably be needed, to preserve backward compatibility.
>
> ----------
> nosy: +niemeyer
> versions: +Python 3.3 -Python 3.2
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue1521950>
> _______________________________________
>

----------
keywords: +patch
Added file: http://bugs.python.org/file23778/ref_shlex.py
Added file: http://bugs.python.org/file23779/test_shlex.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1521950>
_______________________________________
-------------- next part --------------
#!/usr/bin/env python

"""Test how various shells parse syntax.
This is only expected to work on Unix based systems.
We use the unittest infrastructure, but this isn't a normal test.

Usage:
  ref_shelex.py [options] shells...
"""
# Written by: Dan Christian for issue1521950

import glob
import re
import os, sys
import optparse
import subprocess
import unittest


TempDir = '/tmp'                 # where we will write temp files
Shells = ['/bin/sh', '/bin/bash'] # list of shells to test against

class ShellTest(unittest.TestCase):
    bgRe = re.compile(r'\[\d+\]\s+(\d+|\+ Done)$') # backgrounded command output

    def Run(self,
            shell,           # shell to use
            command,         # command to run
            filepath=None):  # any files that are expected
        """Carefully run a shell command.
        Capture stdout, stderr, and exit status.
        Returns: (ret, out, err)
           ret is the return status
           out is the list of lines to stdout
           err is the list of lines to stderr
        """
        start_cwd = os.getcwd()
        call = [shell, '-c', command]
        #print "Running: %s -c '%s'" % (shell, command)
        outpath = 'stdout.txt'
        errpath = 'stderr.txt'
        ret = -1
        out = None
        err = None
        fileout = None
        try:
            os.chdir(TempDir)
            outfp = open(outpath, 'w')
            errfp = open(errpath, 'w')
            if filepath and os.path.isfile(filepath):
                os.remove(filepath)
            ret = subprocess.call(call, stdout=outfp, stderr = errfp)
            #print "Returned: %d" % ret
            outfp = open(outpath, 'r')
            out = outfp.readlines()
            os.remove(outpath)
            errfp = open(errpath, 'r')
            err = errfp.readlines()
            os.remove(errpath)
            if filepath:
                ffp = open(filepath)
                fileout = ffp.readlines()
                os.remove(filepath)
        except OSError as msg:
            print "Exception!", msg
            os.chdir(start_cwd)
            # leave files behind for debugging
            self.assertTrue(0, "Hit an exception running: " % (
                    ' '.join(call)))
        return (ret, out, err, fileout)

    def testTrue(self):
        """ Trivial case to test execution. """
        for shell in Shells:
            cmd = '/bin/true'
            (ret, out, err, fout) = self.Run(shell, cmd)
            self.assertEquals(
                0, ret,
                "Expected %s -c '%s' to return 0, not %d" % (shell, cmd, ret))
            self.assertEquals(
                [], out,
                "Expected %s -c '%s' send nothing to stdout, not: %s" % (
                    shell, cmd, out))
            self.assertEquals(
                [], err,
                "Expected %s -c '%s' send nothing to stderr, not: %s" % (
                    shell, cmd, err))

    def testEcho(self):
        """ Simple case to test stdout. """
        for shell in Shells:
            cmd = 'echo "hello world"'
            (ret, out, err, fout) = self.Run(shell, cmd)
            self.assertEquals(
                0, ret,
                "Expected %s -c '%s' to return 0, not %d" % (shell, cmd, ret))
            self.assertEquals(
                1, len(out),
                "Expected %s -c '%s' to output 1 line of stdout, not: %s" % (
                    shell, cmd, out))
            self.assertEquals(
                [], err,
                "Expected %s -c '%s' send nothing to stderr, not: %s" % (
                    shell, cmd, err))

    def testRedirectS(self):
        """ output redirect with space """
        for shell in Shells:
            fpath = "out.txt"
            cmd = 'echo "hi" > %s' % fpath
            (ret, out, err, fout) = self.Run(shell, cmd, fpath)
            self.assertEquals(
                0, ret,
                "Expected %s -c '%s' to return 0, not %d" % (shell, cmd, ret))
            self.assertEquals(
                [], out,
                "Expected %s -c '%s' send nothing to stdout, not: %s" % (
                    shell, cmd, out))
            self.assertEquals(
                [], err,
                "Expected %s -c '%s' send nothing to stderr, not: %s" % (
                    shell, cmd, err))
            self.assertEquals(1, len(fout))

    def testRedirectNS(self):
        """ output redirect without space """
        for shell in Shells:
            fpath = "out.txt"
            cmd = 'echo "hi"> %s' % fpath
            (ret, out, err, fout) = self.Run(shell, cmd, fpath)
            self.assertEquals(
                0, ret,
                "Expected %s -c '%s' to return 0, not %d" % (shell, cmd, ret))
            self.assertEquals(
                [], out,
                "Expected %s -c '%s' send nothing to stdout, not: %s" % (
                    shell, cmd, out))
            self.assertEquals(
                [], err,
                "Expected %s -c '%s' send nothing to stderr, not: %s" % (
                    shell, cmd, err))
            self.assertEquals(1, len(fout))

    def testTwoEchoS(self):
        """ Two seperate output lines (with space) """
        for shell in Shells:
            cmd = 'echo hi ; echo bye'
            (ret, out, err, fout) = self.Run(shell, cmd)
            self.assertEquals(
                0, ret,
                "Expected %s -c '%s' to return 0, not %d" % (shell, cmd, ret))
            self.assertEquals(['hi\n', 'bye\n'], out)
            self.assertEquals(
                [], err,
                "Expected %s -c '%s' send nothing to stderr, not: %s" % (
                    shell, cmd, err))

    def testTwoEchoNS(self):
        """ Two seperate output lines (with space) """
        for shell in Shells:
            cmd = 'echo hi;echo bye'
            (ret, out, err, fout) = self.Run(shell, cmd)
            self.assertEquals(
                0, ret,
                "Expected %s -c '%s' to return 0, not %d" % (shell, cmd, ret))
            self.assertEquals(['hi\n', 'bye\n'], out)
            self.assertEquals(
                [], err,
                "Expected %s -c '%s' send nothing to stderr, not: %s" % (
                    shell, cmd, err))

    def testBgEcho(self):
        """ Two seperate output lines but unordered """
        # This is flaky.  The output can vary on zsh and tcsh.  Just re-run.
        for shell in Shells:
            cmd = 'echo hi&echo bye; wait'
            (ret, out, err, fout) = self.Run(shell, cmd)
            self.assertEquals(
                0, ret,
                "Expected %s -c '%s' to return 0, not %d" % (shell, cmd, ret))
            # You may get extra lines on csh (hi, bye, bg notice, done notice)
            self.assertTrue(
                len(out) in (2, 3, 4),
                "Expected %s -c '%s' to output 2-4 lines, not %d\n%s" % (
                    shell, cmd, len(out), out))
            self.assertEquals(
                [], err,
                "Expected %s -c '%s' send nothing to stderr, not: %s" % (
                    shell, cmd, err))


def main(args):
    global TempDir, Shells

    val = os.getenv('TEMPDIR')
    if val:
        TempDir = val
    val = os.getenv('SHELLS')
    if val in ('AUTO', 'auto'):
        Shells = glob.glob('/bin/*sh')
        if not Shells:
            print "No shells found as /bin/*sh"
            sys.exit(2)
    elif val is not None:
        Shells = val.split(',')

    print "Testing shells: %s" % ', '.join(Shells)
    unittest.main()  
    

if __name__ == "__main__":
    main(sys.argv[1:])
-------------- next part --------------
--- test_shlex-orig.py	2011-09-03 10:16:44.000000000 -0600
+++ test_shlex.py	2011-11-25 12:01:07.000000000 -0700
@@ -173,6 +173,41 @@
                              "%s: %s != %s" %
                              (self.data[i][0], l, self.data[i][1:]))
 
+    def testSyntaxSplitAmpersand(self):
+        """Test handling of syntax splitting of &"""
+        # these should all parse to the same output
+        src = ['echo hi && echo bye',
+               'echo hi&&echo bye',
+               'echo "hi"&&echo "bye"']
+        ref = ['echo', 'hi', '&&', 'echo', 'bye']
+        # Maybe this should be: ['echo', 'hi', '&', '&', 'echo', 'bye']
+        for ss in src:
+            result = shlex.split(ss)
+            self.assertEqual(ref, result, "While splitting '%s'" % ss)
+
+    def testSyntaxSplitSemicolon(self):
+        """Test handling of syntax splitting of ;"""
+        # these should all parse to the same output
+        src = ['echo hi ; echo bye',
+               'echo hi; echo bye',
+               'echo hi;echo bye']
+        ref = ['echo', 'hi', ';', 'echo', 'bye']
+        for ss in src:
+            result = shlex.split(ss)
+            self.assertEqual(ref, result, "While splitting '%s'" % ss)
+
+    def testSyntaxSplitRedirect(self):
+        """Test handling of syntax splitting of >"""
+        # of course, the same applies to <, |
+        # these should all parse to the same output
+        src = ['echo hi > out',
+               'echo hi> out',
+               'echo hi>out']
+        ref = ['echo', 'hi', '>', 'out']
+        for ss in src:
+            result = shlex.split(ss)
+            self.assertEqual(ref, result, "While splitting '%s'" % ss)
+
 # Allow this test to be used with old shlex.py
 if not getattr(shlex, "split", None):
     for methname in dir(ShlexTest):

From report at bugs.python.org  Fri Nov 25 20:38:42 2011
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 25 Nov 2011 19:38:42 +0000
Subject: [issue13432] Encoding alias "unicode"
In-Reply-To: <1321702512.61.0.807104309131.issue13432@psf.upfronthosting.co.za>
Message-ID: <1322249922.68.0.264654284856.issue13432@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

The mapping "unicode" -> "utf-8" is simply not defined unambiguously, in addition to being factually wrong. For example, when Microsoft talks about Unicode they mean UTF-16.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13432>
_______________________________________

From report at bugs.python.org  Fri Nov 25 20:46:50 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 25 Nov 2011 19:46:50 +0000
Subject: [issue13432] Encoding alias "unicode"
In-Reply-To: <1321702512.61.0.807104309131.issue13432@psf.upfronthosting.co.za>
Message-ID: <1322250410.14.0.730680331923.issue13432@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> For example, when Microsoft talks about Unicode they mean UTF-16.

Sorry, but UTF-16 is ambiguously: do you mean UTF-16-LE or UTF-16-BE? ;-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13432>
_______________________________________

From report at bugs.python.org  Fri Nov 25 20:51:32 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 25 Nov 2011 19:51:32 +0000
Subject: [issue13402] Document absoluteness of sys.executable
In-Reply-To: <1321289437.84.0.982753479785.issue13402@psf.upfronthosting.co.za>
Message-ID: <1322250692.25.0.319491621705.issue13402@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

LGTM too.
You could also add a test to test_sys ensuring that sys.executable is always executable.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13402>
_______________________________________

From report at bugs.python.org  Fri Nov 25 21:04:24 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 25 Nov 2011 20:04:24 +0000
Subject: [issue13402] Document absoluteness of sys.executable
In-Reply-To: <1321289437.84.0.982753479785.issue13402@psf.upfronthosting.co.za>
Message-ID: <1322251464.7.0.338952798709.issue13402@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> You could also add a test to test_sys ensuring that sys.executable
> is always executable.

And that sys.executable is absolute?

sys.executable is an empty string if sys.argv[0] has been changed and Python is unable to retrieve the real path to the Python executable. See the issue #7774. The fact that sys.executable can be empty should be documented.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13402>
_______________________________________

From report at bugs.python.org  Fri Nov 25 21:11:41 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 25 Nov 2011 20:11:41 +0000
Subject: [issue13402] Document absoluteness of sys.executable
In-Reply-To: <1322251464.7.0.338952798709.issue13402@psf.upfronthosting.co.za>
Message-ID: <1322251603.3272.35.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> > You could also add a test to test_sys ensuring that sys.executable
> > is always executable.
> 
> And that sys.executable is absolute?

Er, yes, that's what I meant. Sorry.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13402>
_______________________________________

From report at bugs.python.org  Fri Nov 25 21:38:20 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 25 Nov 2011 20:38:20 +0000
Subject: [issue12856] tempfile PRNG reuse between parent and child process
In-Reply-To: <1314664313.38.0.204964767206.issue12856@psf.upfronthosting.co.za>
Message-ID: <E1RU2XL-0006Iq-4F@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 3c9ddd93c983 by Antoine Pitrou in branch '3.2':
Issue #12856: Ensure child processes do not inherit the parent's random seed for filename generation in the tempfile module.
http://hg.python.org/cpython/rev/3c9ddd93c983

New changeset 588087429809 by Antoine Pitrou in branch 'default':
Issue #12856: Ensure child processes do not inherit the parent's random seed for filename generation in the tempfile module.
http://hg.python.org/cpython/rev/588087429809

New changeset e42be90eb9c5 by Antoine Pitrou in branch '2.7':
Issue #12856: Ensure child processes do not inherit the parent's random seed for filename generation in the tempfile module.
http://hg.python.org/cpython/rev/e42be90eb9c5

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12856>
_______________________________________

From report at bugs.python.org  Fri Nov 25 21:39:52 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 25 Nov 2011 20:39:52 +0000
Subject: [issue12856] tempfile PRNG reuse between parent and child process
In-Reply-To: <1314664313.38.0.204964767206.issue12856@psf.upfronthosting.co.za>
Message-ID: <1322253592.53.0.301113508735.issue12856@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Patch committed, thank you!

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12856>
_______________________________________

From report at bugs.python.org  Fri Nov 25 22:03:39 2011
From: report at bugs.python.org (Dan Christian)
Date: Fri, 25 Nov 2011 21:03:39 +0000
Subject: [issue1521950] shlex.split() does not tokenize like the shell
In-Reply-To: <CAEcGQ+POMTHT1PmJdRc4jF5bo=1z31kvu_08deY_8vD2sE25fw@mail.gmail.com>
Message-ID: <CAEcGQ+OsquYfNGZuw-Piu0=nPFDARr7EJAk58DdDd94YsZMm1g@mail.gmail.com>


Dan Christian <robodan at users.sourceforge.net> added the comment:

I just realized that I left out a major case.  The shell will also
split ().  I think this is now complete.  If you do "man bash" and
skip down to DEFINITONS it lists all the control characters.

I've attached updated versions of ref_shlex.py and test_shlex.diff.
They replace the previous ones.

-Dan

On Fri, Nov 25, 2011 at 12:25 PM, Dan Christian <report at bugs.python.org> wrote:
>
> Dan Christian <robodan at users.sourceforge.net> added the comment:
>
> I've attached a diff to test_shlex.py and a script that I used to
> verify what the shells actually do.
> Both are relative to Python-3.2.2/Lib/test
>
> I'm completely ignoring the quotes issue for now. ?That should
> probably be an enhancement. ?I don't think it really matters until the
> parsing issues are resolved.
>
> ref_shlex is python 2 syntax. ?python -3 shows that it should convert cleanly.
> ./ref_shlex.py
> It will run by default against /bin/*sh
> If you don't want that, do something like: export SHELLS='/bin/sh,/bin/csh'
> It runs as a unittest. ?So you will only see dots if all shells do
> what it expects. ?Some shells are flaky (e.g. zsh, tcsh), so you may
> need to run it multiple times.
>
> Getting this into the mainline will be interesting. ?I would think it
> would take some community discussion. ?I may be able to convince
> people that the current behaviour is wrong, but I can't tell you what
> will break if it is "fixed". ?And should the fix be the default? ?As
> you mentioned, it depends on what people expect it to do and how it is
> currently being used. ?I see the first step as presenting a clear case
> of how it should work.
>
> -Dan

----------
Added file: http://bugs.python.org/file23780/ref_shlex.py
Added file: http://bugs.python.org/file23781/test_shlex.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1521950>
_______________________________________
-------------- next part --------------
#!/usr/bin/env python

"""Test how various shells parse syntax.
This is only expected to work on Unix based systems.
We use the unittest infrastructure, but this isn't a normal test.

Usage:
  ref_shelex.py [options] shells...
"""
# Written by: Dan Christian for issue1521950
# References: man bash   # look at DEFINITIONS and SHELL GRAMMAR

import glob
import re
import os, sys
import subprocess
import unittest


TempDir = '/tmp'                 # where we will write temp files
Shells = ['/bin/sh', '/bin/bash'] # list of shells to test against

class ShellTest(unittest.TestCase):
    bgRe = re.compile(r'\[\d+\]\s+(\d+|\+ Done)$') # backgrounded command output

    def Run(self,
            shell,           # shell to use
            command,         # command to run
            filepath=None):  # any files that are expected
        """Carefully run a shell command.
        Capture stdout, stderr, and exit status.
        Returns: (ret, out, err)
           ret is the return status
           out is the list of lines to stdout
           err is the list of lines to stderr
        """
        start_cwd = os.getcwd()
        call = [shell, '-c', command]
        #print "Running: %s -c '%s'" % (shell, command)
        outpath = 'stdout.txt'
        errpath = 'stderr.txt'
        ret = -1
        out = None
        err = None
        fileout = None
        try:
            os.chdir(TempDir)
            outfp = open(outpath, 'w')
            errfp = open(errpath, 'w')
            if filepath and os.path.isfile(filepath):
                os.remove(filepath)
            ret = subprocess.call(call, stdout=outfp, stderr = errfp)
            #print "Returned: %d" % ret
            outfp = open(outpath, 'r')
            out = outfp.readlines()
            os.remove(outpath)
            errfp = open(errpath, 'r')
            err = errfp.readlines()
            os.remove(errpath)
            if filepath:
                ffp = open(filepath)
                fileout = ffp.readlines()
                os.remove(filepath)
        except OSError as msg:
            print "Exception!", msg
            os.chdir(start_cwd)
            # leave files behind for debugging
            self.assertTrue(0, "Hit an exception running: " % (
                    ' '.join(call)))
        return (ret, out, err, fileout)

    def testTrue(self):
        """ Trivial case to test execution. """
        for shell in Shells:
            cmd = '/bin/true'
            (ret, out, err, fout) = self.Run(shell, cmd)
            self.assertEquals(
                0, ret,
                "Expected %s -c '%s' to return 0, not %d" % (shell, cmd, ret))
            self.assertEquals(
                [], out,
                "Expected %s -c '%s' send nothing to stdout, not: %s" % (
                    shell, cmd, out))
            self.assertEquals(
                [], err,
                "Expected %s -c '%s' send nothing to stderr, not: %s" % (
                    shell, cmd, err))

    def testEcho(self):
        """ Simple case to test stdout. """
        for shell in Shells:
            cmd = 'echo "hello world"'
            (ret, out, err, fout) = self.Run(shell, cmd)
            self.assertEquals(
                0, ret,
                "Expected %s -c '%s' to return 0, not %d" % (shell, cmd, ret))
            self.assertEquals(
                1, len(out),
                "Expected %s -c '%s' to output 1 line of stdout, not: %s" % (
                    shell, cmd, out))
            self.assertEquals(
                [], err,
                "Expected %s -c '%s' send nothing to stderr, not: %s" % (
                    shell, cmd, err))

    def testRedirectS(self):
        """ output redirect with space """
        for shell in Shells:
            fpath = "out.txt"
            cmd = 'echo "hi" > %s' % fpath
            (ret, out, err, fout) = self.Run(shell, cmd, fpath)
            self.assertEquals(
                0, ret,
                "Expected %s -c '%s' to return 0, not %d" % (shell, cmd, ret))
            self.assertEquals(
                [], out,
                "Expected %s -c '%s' send nothing to stdout, not: %s" % (
                    shell, cmd, out))
            self.assertEquals(
                [], err,
                "Expected %s -c '%s' send nothing to stderr, not: %s" % (
                    shell, cmd, err))
            self.assertEquals(1, len(fout))

    def testRedirectNS(self):
        """ output redirect without space """
        for shell in Shells:
            fpath = "out.txt"
            cmd = 'echo "hi"> %s' % fpath
            (ret, out, err, fout) = self.Run(shell, cmd, fpath)
            self.assertEquals(
                0, ret,
                "Expected %s -c '%s' to return 0, not %d" % (shell, cmd, ret))
            self.assertEquals(
                [], out,
                "Expected %s -c '%s' send nothing to stdout, not: %s" % (
                    shell, cmd, out))
            self.assertEquals(
                [], err,
                "Expected %s -c '%s' send nothing to stderr, not: %s" % (
                    shell, cmd, err))
            self.assertEquals(1, len(fout))

    def testTwoEchoS(self):
        """ Two seperate output lines (with space) """
        for shell in Shells:
            cmd = 'echo hi ; echo bye'
            (ret, out, err, fout) = self.Run(shell, cmd)
            self.assertEquals(
                0, ret,
                "Expected %s -c '%s' to return 0, not %d" % (shell, cmd, ret))
            self.assertEquals(['hi\n', 'bye\n'], out)
            self.assertEquals(
                [], err,
                "Expected %s -c '%s' send nothing to stderr, not: %s" % (
                    shell, cmd, err))

    def testTwoEchoNS(self):
        """ Two seperate output lines (with space) """
        for shell in Shells:
            cmd = 'echo hi;echo bye'
            (ret, out, err, fout) = self.Run(shell, cmd)
            self.assertEquals(
                0, ret,
                "Expected %s -c '%s' to return 0, not %d" % (shell, cmd, ret))
            self.assertEquals(['hi\n', 'bye\n'], out)
            self.assertEquals(
                [], err,
                "Expected %s -c '%s' send nothing to stderr, not: %s" % (
                    shell, cmd, err))

    def testParenS(self):
        """ Sub shell (with spaces) """
        for shell in Shells:
            cmd = '( echo hi )'
            (ret, out, err, fout) = self.Run(shell, cmd)
            self.assertEquals(
                0, ret,
                "Expected %s -c '%s' to return 0, not %d" % (shell, cmd, ret))
            self.assertEquals(
                ['hi\n'], out,
                "Expected %s -c '%s' to return 'hi', not: %s" % (
                    shell, cmd, out))
            self.assertEquals(
                [], err,
                "Expected %s -c '%s' send nothing to stderr, not: %s" % (
                    shell, cmd, err))

    def testParenNS(self):
        """ Sub shell (no spaces) """
        for shell in Shells:
            cmd = '(echo hi)'
            (ret, out, err, fout) = self.Run(shell, cmd)
            self.assertEquals(
                0, ret,
                "Expected %s -c '%s' to return 0, not %d" % (shell, cmd, ret))
            self.assertEquals(['hi\n'], out,
                "Expected %s -c '%s' to return 'hi', not: %s" % (
                    shell, cmd, out))
            self.assertEquals(
                [], err,
                "Expected %s -c '%s' send nothing to stderr, not: %s" % (
                    shell, cmd, err))

    def testBgEcho(self):
        """ Two seperate output lines but unordered """
        # This is flaky.  The output can vary on zsh and tcsh.  Just re-run.
        for shell in Shells:
            cmd = 'echo hi&echo bye; wait'
            (ret, out, err, fout) = self.Run(shell, cmd)
            self.assertEquals(
                0, ret,
                "Expected %s -c '%s' to return 0, not %d" % (shell, cmd, ret))
            # You may get extra lines on csh (hi, bye, bg notice, done notice)
            self.assertTrue(
                len(out) in (2, 3, 4),
                "Expected %s -c '%s' to output 2-4 lines, not %d\n%s" % (
                    shell, cmd, len(out), out))
            self.assertEquals(
                [], err,
                "Expected %s -c '%s' send nothing to stderr, not: %s" % (
                    shell, cmd, err))


def main(args):
    global TempDir, Shells

    val = os.getenv('TEMPDIR')
    if val:
        TempDir = val
    val = os.getenv('SHELLS')
    if val in ('AUTO', 'auto'):
        Shells = glob.glob('/bin/*sh')
        if not Shells:
            print "No shells found as /bin/*sh"
            sys.exit(2)
    elif val is not None:
        Shells = val.split(',')

    print "Testing shells: %s" % ', '.join(Shells)
    unittest.main()  
    

if __name__ == "__main__":
    main(sys.argv[1:])
-------------- next part --------------
--- test_shlex-orig.py	2011-09-03 10:16:44.000000000 -0600
+++ test_shlex.py	2011-11-25 13:56:23.000000000 -0700
@@ -173,6 +173,54 @@
                              "%s: %s != %s" %
                              (self.data[i][0], l, self.data[i][1:]))
 
+    def testSyntaxSplitAmpersand(self):
+        """Test handling of syntax splitting of &"""
+        # Could take these forms: &&, &, |&, ;&, ;;&
+        # of course, the same applies to | and ||
+        # these should all parse to the same output
+        src = ['echo hi && echo bye',
+               'echo hi&&echo bye',
+               'echo "hi"&&echo "bye"']
+        ref = ['echo', 'hi', '&&', 'echo', 'bye']
+        # Maybe this should be: ['echo', 'hi', '&', '&', 'echo', 'bye']
+        for ss in src:
+            result = shlex.split(ss)
+            self.assertEqual(ref, result, "While splitting '%s'" % ss)
+
+    def testSyntaxSplitSemicolon(self):
+        """Test handling of syntax splitting of ;"""
+        # Could take these forms: ;, ;;, ;&, ;;&
+        # these should all parse to the same output
+        src = ['echo hi ; echo bye',
+               'echo hi; echo bye',
+               'echo hi;echo bye']
+        ref = ['echo', 'hi', ';', 'echo', 'bye']
+        for ss in src:
+            result = shlex.split(ss)
+            self.assertEqual(ref, result, "While splitting '%s'" % ss)
+
+    def testSyntaxSplitRedirect(self):
+        """Test handling of syntax splitting of >"""
+        # of course, the same applies to <, |
+        # these should all parse to the same output
+        src = ['echo hi > out',
+               'echo hi> out',
+               'echo hi>out']
+        ref = ['echo', 'hi', '>', 'out']
+        for ss in src:
+            result = shlex.split(ss)
+            self.assertEqual(ref, result, "While splitting '%s'" % ss)
+
+    def testSyntaxSplitParen(self):
+        """Test handling of syntax splitting of ()"""
+        # these should all parse to the same output
+        src = ['( echo hi )',
+               '(echo hi)']
+        ref = ['(', 'echo', 'hi', ')']
+        for ss in src:
+            result = shlex.split(ss)
+            self.assertEqual(ref, result, "While splitting '%s'" % ss)
+
 # Allow this test to be used with old shlex.py
 if not getattr(shlex, "split", None):
     for methname in dir(ShlexTest):

From report at bugs.python.org  Fri Nov 25 22:08:34 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 25 Nov 2011 21:08:34 +0000
Subject: [issue12567] curses implementation of Unicode is wrong in Python 3
In-Reply-To: <1310682817.11.0.980195084883.issue12567@psf.upfronthosting.co.za>
Message-ID: <E1RU30a-0008JR-OJ@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset c3581ca21a57 by Victor Stinner in branch 'default':
Issue #12567: The curses module uses Unicode functions for Unicode arguments
http://hg.python.org/cpython/rev/c3581ca21a57

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12567>
_______________________________________

From report at bugs.python.org  Fri Nov 25 22:09:54 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Fri, 25 Nov 2011 21:09:54 +0000
Subject: [issue13432] Encoding alias "unicode"
In-Reply-To: <1322209347.38.0.890598120907.issue13432@psf.upfronthosting.co.za>
Message-ID: <4ED00421.8070505@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> Reverse question: what would be the minus of having this alias?

Please accept that this issue is closed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13432>
_______________________________________

From report at bugs.python.org  Fri Nov 25 22:51:18 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Fri, 25 Nov 2011 21:51:18 +0000
Subject: [issue11849] glibc allocator doesn't release all free()ed memory
In-Reply-To: <1322225576.44.0.73701624914.issue11849@psf.upfronthosting.co.za>
Message-ID: <CAH_1eM1j9-zMNWP2Sxe4sZFYM16Ejezw9FxQk+Z3qtXD6mqmzA@mail.gmail.com>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

> However, there's still another strange regression:
>
> $ ./python -m timeit \
>   -s "n=300000; f=open('10MB.bin', 'rb', buffering=0); b=bytearray(n)" \
>   "f.seek(0);f.readinto(b)"
>
> -> default branch:
> 10000 loops, best of 3: 43 usec per loop
> -> default branch with patch reverted:
> 10000 loops, best of 3: 27.5 usec per loop
>
> FileIO.readinto executes a single read() into the passed buffer.

On my box:
default:
$ ./python -m timeit -s "n=300000; f=open('/tmp/10MB.bin', 'rb');
b=bytearray(n)" "f.seek(0);f.readinto(b)"
1000 loops, best of 3: 640 usec per loop

default without patch ("$ hg revert -r 68258 Objects/obmalloc.c && make"):
$ ./python -m timeit -s "n=300000; f=open('/tmp/10MB.bin', 'rb');
b=bytearray(n)" "f.seek(0);f.readinto(b)"
1000 loops, best of 3: 663 usec per loop

I'm just observing a random variance (but my computer is maybe too
slow to notice).
However, I really don't see how the patch could play a role here.

Concerning the slight performance regression, if it's a problem, I see
two options:
- revert the patch
- replace calls to malloc()/free() by mmap()/munmap() to allocate/free
arenas (but I'm not sure anonymous mappings are supported by every OS
out there, so this might lead to some ugly #ifdef's...)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11849>
_______________________________________

From report at bugs.python.org  Fri Nov 25 23:00:01 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 25 Nov 2011 22:00:01 +0000
Subject: [issue11849] glibc allocator doesn't release all free()ed memory
In-Reply-To: <CAH_1eM1j9-zMNWP2Sxe4sZFYM16Ejezw9FxQk+Z3qtXD6mqmzA@mail.gmail.com>
Message-ID: <1322258101.3272.41.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> On my box:
> default:
> $ ./python -m timeit -s "n=300000; f=open('/tmp/10MB.bin', 'rb');
> b=bytearray(n)" "f.seek(0);f.readinto(b)"
> 1000 loops, best of 3: 640 usec per loop
> 
> default without patch ("$ hg revert -r 68258 Objects/obmalloc.c && make"):
> $ ./python -m timeit -s "n=300000; f=open('/tmp/10MB.bin', 'rb');
> b=bytearray(n)" "f.seek(0);f.readinto(b)"
> 1000 loops, best of 3: 663 usec per loop
> 
> I'm just observing a random variance (but my computer is maybe too
> slow to notice).

Hmm, quite slow indeed, are you sure you're not running in debug mode?

> However, I really don't see how the patch could play a role here.
> 
> Concerning the slight performance regression, if it's a problem, I see
> two options:
> - revert the patch
> - replace calls to malloc()/free() by mmap()/munmap() to allocate/free
> arenas (but I'm not sure anonymous mappings are supported by every OS
> out there, so this might lead to some ugly #ifdef's...)

If the performance regression is limited to read(), I don't think it's
really an issue, but using mmap/munmap explicitly would probably benicer
anyway (1? because it lets the glibc choose whatever heuristic is best,
2? because it would help release memory on more systems than just glibc
systems). I think limiting ourselves to systems which have
MMAP_ANONYMOUS is good enough.

Here is what the glibc malloc does btw:

/*
   Nearly all versions of mmap support MAP_ANONYMOUS,
   so the following is unlikely to be needed, but is
   supplied just in case.
*/

#ifndef MAP_ANONYMOUS

static int dev_zero_fd = -1; /* Cached file descriptor for /dev/zero. */

#define MMAP(addr, size, prot, flags) ((dev_zero_fd < 0) ? \
 (dev_zero_fd = open("/dev/zero", O_RDWR), \
  mmap((addr), (size), (prot), (flags), dev_zero_fd, 0)) : \
   mmap((addr), (size), (prot), (flags), dev_zero_fd, 0))

#else

#define MMAP(addr, size, prot, flags) \
 (mmap((addr), (size), (prot), (flags)|MAP_ANONYMOUS, -1, 0))

#endif

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11849>
_______________________________________

From report at bugs.python.org  Fri Nov 25 23:38:22 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 25 Nov 2011 22:38:22 +0000
Subject: [issue12567] curses implementation of Unicode is wrong in Python 3
In-Reply-To: <1310682817.11.0.980195084883.issue12567@psf.upfronthosting.co.za>
Message-ID: <1322260702.68.0.145557735352.issue12567@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

This broke several Gentoo buildbots.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12567>
_______________________________________

From report at bugs.python.org  Fri Nov 25 23:45:19 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Fri, 25 Nov 2011 22:45:19 +0000
Subject: [issue11849] glibc allocator doesn't release all free()ed memory
In-Reply-To: <1322258101.3272.41.camel@localhost.localdomain>
Message-ID: <CAH_1eM13a3yGKiNtKYYGDoJFSoPUFf4kr12GwEjiSf2aLgXR2Q@mail.gmail.com>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

> Hmm, quite slow indeed, are you sure you're not running in debug mode?
>

Well, yes, but it's no faster with a non-debug build: my laptop is
really crawling :-)

> If the performance regression is limited to read(), I don't think it's
> really an issue, but using mmap/munmap explicitly would probably benicer
> anyway (1? because it lets the glibc choose whatever heuristic is best,
> 2? because it would help release memory on more systems than just glibc
> systems). I think limiting ourselves to systems which have
> MMAP_ANONYMOUS is good enough.
>

Agreed.
Here's a patch.

----------
Added file: http://bugs.python.org/file23782/arenas_mmap.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11849>
_______________________________________
-------------- next part --------------
diff --git a/Objects/obmalloc.c b/Objects/obmalloc.c
--- a/Objects/obmalloc.c
+++ b/Objects/obmalloc.c
@@ -2,8 +2,11 @@
 
 #ifdef WITH_PYMALLOC
 
-#ifdef HAVE_MALLOPT_MMAP_THRESHOLD
-  #include <malloc.h>
+#ifdef HAVE_MMAP
+ #include <sys/mman.h>
+ #ifdef MAP_ANONYMOUS
+  #define ARENAS_USE_MMAP
+ #endif
 #endif
 
 #ifdef WITH_VALGRIND
@@ -183,15 +186,15 @@
 /*
  * The allocator sub-allocates <Big> blocks of memory (called arenas) aligned
  * on a page boundary. This is a reserved virtual address space for the
- * current process (obtained through a malloc call). In no way this means
- * that the memory arenas will be used entirely. A malloc(<Big>) is usually
- * an address range reservation for <Big> bytes, unless all pages within this
- * space are referenced subsequently. So malloc'ing big blocks and not using
- * them does not mean "wasting memory". It's an addressable range wastage...
+ * current process (obtained through a malloc()/mmap() call). In no way this
+ * means that the memory arenas will be used entirely. A malloc(<Big>) is
+ * usually an address range reservation for <Big> bytes, unless all pages within
+ * this space are referenced subsequently. So malloc'ing big blocks and not
+ * using them does not mean "wasting memory". It's an addressable range
+ * wastage...
  *
- * Therefore, allocating arenas with malloc is not optimal, because there is
- * some address space wastage, but this is the most portable way to request
- * memory from the system across various platforms.
+ * Arenas are allocated with mmap() on systems supporting anonymous memory
+ * mappings to reduce heap fragmentation.
  */
 #define ARENA_SIZE              (256 << 10)     /* 256KB */
 
@@ -557,11 +560,6 @@
         if (numarenas > PY_SIZE_MAX / sizeof(*arenas))
             return NULL;                /* overflow */
 #endif
-#ifdef HAVE_MALLOPT_MMAP_THRESHOLD
-        /* Ensure arenas are allocated by mmap to avoid heap fragmentation. */
-        if (numarenas == INITIAL_ARENA_OBJECTS)
-            mallopt(M_MMAP_THRESHOLD, ARENA_SIZE);
-#endif
         nbytes = numarenas * sizeof(*arenas);
         arenaobj = (struct arena_object *)realloc(arenas, nbytes);
         if (arenaobj == NULL)
@@ -594,7 +592,12 @@
     arenaobj = unused_arena_objects;
     unused_arena_objects = arenaobj->nextarena;
     assert(arenaobj->address == 0);
+#ifdef ARENAS_USE_MMAP
+    arenaobj->address = (uptr)mmap(NULL, ARENA_SIZE, PROT_READ|PROT_WRITE,
+                                   MAP_PRIVATE|MAP_ANONYMOUS, -1, 0);
+#else
     arenaobj->address = (uptr)malloc(ARENA_SIZE);
+#endif
     if (arenaobj->address == 0) {
         /* The allocation failed: return NULL after putting the
          * arenaobj back.
@@ -1071,7 +1074,11 @@
                 unused_arena_objects = ao;
 
                 /* Free the entire arena. */
+#ifdef ARENAS_USE_MMAP
+                munmap((void *)ao->address, ARENA_SIZE);
+#else
                 free((void *)ao->address);
+#endif
                 ao->address = 0;                        /* mark unassociated */
                 --narenas_currently_allocated;
 
diff --git a/configure.in b/configure.in
--- a/configure.in
+++ b/configure.in
@@ -2567,8 +2567,8 @@
  getgrouplist getgroups getlogin getloadavg getpeername getpgid getpid \
  getpriority getresuid getresgid getpwent getspnam getspent getsid getwd \
  if_nameindex \
- initgroups kill killpg lchmod lchown lockf linkat lstat lutimes memrchr \
- mbrtowc mkdirat mkfifo \
+ initgroups kill killpg lchmod lchown lockf linkat lstat lutimes mmap \
+ memrchr mbrtowc mkdirat mkfifo \
  mkfifoat mknod mknodat mktime mremap nice openat pathconf pause pipe2 plock poll \
  posix_fallocate posix_fadvise pread \
  pthread_init pthread_kill putenv pwrite readlink readlinkat readv realpath renameat \
@@ -2679,15 +2679,6 @@
   [AC_MSG_RESULT(no)
 ])
 
-AC_MSG_CHECKING(whether mallopt can set malloc mmap threshold)
-AC_COMPILE_IFELSE([AC_LANG_PROGRAM([[
-#include <malloc.h>
-]], [[mallopt(M_MMAP_THRESHOLD, 256 * 1024)]])],
-  [AC_DEFINE(HAVE_MALLOPT_MMAP_THRESHOLD, 1, Define if mallopt can set malloc mmap threshold.)
-   AC_MSG_RESULT(yes)],
-  [AC_MSG_RESULT(no)
-])
-
 AC_MSG_CHECKING(for broken unsetenv)
 AC_COMPILE_IFELSE([AC_LANG_PROGRAM([[
 #include <stdlib.h>
diff --git a/pyconfig.h.in b/pyconfig.h.in
--- a/pyconfig.h.in
+++ b/pyconfig.h.in
@@ -512,9 +512,6 @@
 /* Define this if you have the makedev macro. */
 #undef HAVE_MAKEDEV
 
-/* Define if mallopt can set malloc mmap threshold. */
-#undef HAVE_MALLOPT_MMAP_THRESHOLD
-
 /* Define to 1 if you have the `mbrtowc' function. */
 #undef HAVE_MBRTOWC
 
@@ -545,6 +542,9 @@
 /* Define to 1 if you have the `mktime' function. */
 #undef HAVE_MKTIME
 
+/* Define to 1 if you have the `mmap' function. */
+#undef HAVE_MMAP
+
 /* Define to 1 if you have the `mremap' function. */
 #undef HAVE_MREMAP
 

From report at bugs.python.org  Sat Nov 26 00:18:47 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 25 Nov 2011 23:18:47 +0000
Subject: [issue2286] Stack overflow exception caused by test_marshal on
	Windows x64
In-Reply-To: <1205499475.78.0.0465561571315.issue2286@psf.upfronthosting.co.za>
Message-ID: <1322263127.42.0.173155649228.issue2286@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

The 'official' PSF build for 2.7 (and 3.x) is done with VS2008, so this may not be the last problem you have. I am pretty sure this will never change for 2.7, but that is not to say we cannot make a simple change to accommodate VS2010. I am sure we will eventually update VS for 3.x. Can you test 3.2 or even better 3.3?

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2286>
_______________________________________

From report at bugs.python.org  Sat Nov 26 00:52:11 2011
From: report at bugs.python.org (sbt)
Date: Fri, 25 Nov 2011 23:52:11 +0000
Subject: [issue13448] PEP 3155 implementation
In-Reply-To: <1321908830.82.0.349913947268.issue13448@psf.upfronthosting.co.za>
Message-ID: <1322265131.5.0.631848129099.issue13448@psf.upfronthosting.co.za>


sbt <shibturn at gmail.com> added the comment:

There are some callables which are missing __qualname__:

  method_descriptor
  wrapper_descriptor
  builtin_function_or_method

For the descriptors, at least, obj.__qualname__ should be equivalent to

  obj.__objclass__.__qualname__ + '.' + obj.__name__

Were these overlooked?

  PS C:\Repos\cpython> .\PCbuild\python_d
  Python 3.3.0a0 (default, Nov 25 2011, 22:14:28) [MSC v.1500 32 bit (Intel)] on win32
  Type "help", "copyright", "credits" or "license" for more information.
  >>> import pickle
  [66213 refs]
  >>> attribs = ('__class__', '__name__', '__qualname__')
  [66220 refs]
  >>> for o in (pickle.Pickler, pickle.Pickler.dump, object.__init__, min):
  ...   print([getattr(o, a, None) for a in attribs])
  ...
  [<class 'type'>, 'Pickler', 'Pickler']
  [<class 'method_descriptor'>, 'dump', None]
  [<class 'wrapper_descriptor'>, '__init__', None]
  [<class 'builtin_function_or_method'>, 'min', None]
  [66265 refs]

Also I notice that bound methods have a misleading __qualname__:

  >>> class A:
  ...   def f(self): pass
  ...
  [66348 refs]
  >>> A().f.__qualname__
  'A.f'

Maybe this should be 'A().f' instead.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13448>
_______________________________________

From report at bugs.python.org  Sat Nov 26 01:02:01 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 26 Nov 2011 00:02:01 +0000
Subject: [issue13481] Use an accurate clock in timeit
Message-ID: <1322265721.78.0.0567796730825.issue13481@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

This patch uses an accurate POSIX clock if possible in the timeit module.

----------
components: Library (Lib)
files: timeit_clock.patch
keywords: patch
messages: 148369
nosy: georg.brandl, pitrou
priority: normal
severity: normal
stage: patch review
status: open
title: Use an accurate clock in timeit
type: feature request
versions: Python 3.3
Added file: http://bugs.python.org/file23783/timeit_clock.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13481>
_______________________________________

From report at bugs.python.org  Sat Nov 26 01:08:48 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 26 Nov 2011 00:08:48 +0000
Subject: [issue13433] String format documentation contains error regarding %g
In-Reply-To: <1321707692.58.0.601543510069.issue13433@psf.upfronthosting.co.za>
Message-ID: <1322266128.44.0.41917762925.issue13433@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I find the doc for g/G less than clear.

1. (main entry) "Uses lowercase exponential format if exponent is less than -4 or not less than precision, decimal format otherwise."

'not less' means 'equal or greater', which to me is clearer. Even better and clearer to me would be "Uses decimal format if -4 <= exponent < precision, exponential format otherwise."


2. (note 4) "The precision determines the number of significant digits before and after the decimal point and defaults to 6."

>>> format(.001, 'g')
'0.001'

I only count 4, not 6.

Whoops, that is sort of documented, but in a really backwards way, by saying what the alternate form is. "The alternate form ... trailing zeroes are not removed as they would otherwise be."

>>> format(.001, '.3g')
'0.001'

Now I count 4, not 3.

3. (several notes) 'The alternate form'? I initially though this meant one of the two forms for g/G but then saw it used for other formats with just one form. It took too much searching to find the entry for '#', which I had never noticed before. Please expand to "The alternate '#' form" or add "(Alternate forms are selected by the '#' flag.)" after "Notes:".

I agree with C.I. that we could give some subtle emphasis that g/G treat precision differently. But the difference is more than just including the minimum 1 char before the decimal point in the precision.

>>> format(.001, 'f')
'0.001000'

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13433>
_______________________________________

From report at bugs.python.org  Sat Nov 26 01:15:58 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 26 Nov 2011 00:15:58 +0000
Subject: [issue13436] compile() doesn't work on ImportFrom with level=None
In-Reply-To: <1321747479.31.0.688458511993.issue13436@psf.upfronthosting.co.za>
Message-ID: <1322266558.56.0.558920162624.issue13436@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Does this apply to 2.7 as well?

I believe msg148146 is due to a commit message typo.

----------
nosy: +haypo, terry.reedy
versions: +Python 3.2, Python 3.3 -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13436>
_______________________________________

From report at bugs.python.org  Sat Nov 26 01:18:38 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 26 Nov 2011 00:18:38 +0000
Subject: [issue13437] Provide links to the source code for every module in the
	documentation
In-Reply-To: <1321748971.83.0.182041155467.issue13437@psf.upfronthosting.co.za>
Message-ID: <1322266718.46.0.0484243275355.issue13437@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13437>
_______________________________________

From report at bugs.python.org  Sat Nov 26 01:22:03 2011
From: report at bugs.python.org (sbt)
Date: Sat, 26 Nov 2011 00:22:03 +0000
Subject: [issue13448] PEP 3155 implementation
In-Reply-To: <1321908830.82.0.349913947268.issue13448@psf.upfronthosting.co.za>
Message-ID: <1322266923.11.0.614612487971.issue13448@psf.upfronthosting.co.za>


sbt <shibturn at gmail.com> added the comment:

For builtin_function_or_method it seems obj.__qualname__ should be

  obj.__self__.__qualname__ + '.' + obj.__name__

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13448>
_______________________________________

From report at bugs.python.org  Sat Nov 26 01:23:04 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 26 Nov 2011 00:23:04 +0000
Subject: [issue13440] Explain the "status quo wins a stalemate" principle in
	the devguide
In-Reply-To: <1321833284.75.0.438515825131.issue13440@psf.upfronthosting.co.za>
Message-ID: <1322266984.77.0.38780674885.issue13440@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Or expand 'Reporting Bugs' to 'Reporting Bugs and Requesting Features', perhaps renamed to 'Suggesting Improvements'. My point is that aspiring developers are not the only one that need to read the guideline, not withstanding the fact the some new developers or would-be developers are also enthusiastic in making proposals.

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13440>
_______________________________________

From report at bugs.python.org  Sat Nov 26 01:23:43 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 26 Nov 2011 00:23:43 +0000
Subject: [issue11849] glibc allocator doesn't release all free()ed memory
In-Reply-To: <1302858518.86.0.0355572789659.issue11849@psf.upfronthosting.co.za>
Message-ID: <E1RU63R-0003S1-HT@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset e7aa72e6aad4 by Antoine Pitrou in branch 'default':
Better resolution for issue #11849: Ensure that free()d memory arenas are really released
http://hg.python.org/cpython/rev/e7aa72e6aad4

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11849>
_______________________________________

From report at bugs.python.org  Sat Nov 26 01:26:08 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 26 Nov 2011 00:26:08 +0000
Subject: [issue13443] wrong links and examples in the functional HOWTO
In-Reply-To: <1321850404.45.0.767133152656.issue13443@psf.upfronthosting.co.za>
Message-ID: <1322267168.61.0.494567324221.issue13443@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13443>
_______________________________________

From report at bugs.python.org  Sat Nov 26 01:31:02 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 26 Nov 2011 00:31:02 +0000
Subject: [issue13448] PEP 3155 implementation
In-Reply-To: <1322265131.5.0.631848129099.issue13448@psf.upfronthosting.co.za>
Message-ID: <1322267163.3272.45.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> There are some callables which are missing __qualname__:
> 
>   method_descriptor
>   wrapper_descriptor
>   builtin_function_or_method
> 
> For the descriptors, at least, obj.__qualname__ should be equivalent to
> 
>   obj.__objclass__.__qualname__ + '.' + obj.__name__
> 
> Were these overlooked?

Indeed, they were overlooked. Due to the way they are instantiated,
though, it would be quite a bit harder to devise a __qualname__ for
them.

> Also I notice that bound methods have a misleading __qualname__:
> 
>   >>> class A:
>   ...   def f(self): pass
>   ...
>   [66348 refs]
>   >>> A().f.__qualname__
>   'A.f'
> 
> Maybe this should be 'A().f' instead.

I am a bit surprised that this works at all. Apparently attribute
lookups are redirected to the underlying function.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13448>
_______________________________________

From report at bugs.python.org  Sat Nov 26 02:09:19 2011
From: report at bugs.python.org (Matt Joiner)
Date: Sat, 26 Nov 2011 01:09:19 +0000
Subject: [issue12822] NewGIL should use CLOCK_MONOTONIC if possible.
In-Reply-To: <1314085416.99.0.752578807259.issue12822@psf.upfronthosting.co.za>
Message-ID: <1322269759.32.0.935280395875.issue12822@psf.upfronthosting.co.za>


Changes by Matt Joiner <anacrolix at gmail.com>:


----------
nosy: +anacrolix

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12822>
_______________________________________

From report at bugs.python.org  Sat Nov 26 05:38:36 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 26 Nov 2011 04:38:36 +0000
Subject: [issue13380] ctypes: add an internal function for reseting the ctypes
	caches
In-Reply-To: <1320902561.22.0.487865927239.issue13380@psf.upfronthosting.co.za>
Message-ID: <E1RUA26-0002tg-Oa@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 6783aa5c15ae by Meador Inge in branch '2.7':
Issue #13380: add an internal function for resetting the ctypes caches
http://hg.python.org/cpython/rev/6783aa5c15ae

New changeset fa59b3758b14 by Meador Inge in branch '3.2':
Issue #13380: add an internal function for resetting the ctypes caches
http://hg.python.org/cpython/rev/fa59b3758b14

New changeset 963d861d0eb5 by Meador Inge in branch 'default':
Issue #13380: add an internal function for resetting the ctypes caches
http://hg.python.org/cpython/rev/963d861d0eb5

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13380>
_______________________________________

From report at bugs.python.org  Sat Nov 26 05:40:34 2011
From: report at bugs.python.org (Meador Inge)
Date: Sat, 26 Nov 2011 04:40:34 +0000
Subject: [issue13380] ctypes: add an internal function for reseting the ctypes
	caches
In-Reply-To: <1320902561.22.0.487865927239.issue13380@psf.upfronthosting.co.za>
Message-ID: <1322282434.0.0.805273228013.issue13380@psf.upfronthosting.co.za>


Meador Inge <meadori at gmail.com> added the comment:

Committed.  Thanks for the review Antoine.

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13380>
_______________________________________

From report at bugs.python.org  Sat Nov 26 06:19:47 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 26 Nov 2011 05:19:47 +0000
Subject: [issue13475] Add '-p'/'--path0' command line option to override
	sys.path[0] initialisation
In-Reply-To: <1322181994.22.0.955887054946.issue13475@psf.upfronthosting.co.za>
Message-ID: <1322284787.62.0.250278700261.issue13475@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Yeah, sorry Eric (Snow), you're trying to bite off *way* more than is reasonable by proposing to removing sys.path[0] auto-initialisation. While it has its problems, it's also far too entrenched in people's expections of Python's behaviour to consider removing at this late date. The earliest such a radical change could likely be considered is Python 4.

?ric (Araujo): the "just do the right thing" aspect is covered by PEP 395. This is an orthogonal proposal that allows power users the ability to override the automatic initialisation to handle those cases where it goes wrong.

That said, I may still make this suggestion part of PEP 395 rather than a distinct proposal, even though there's no direct dependency (in either direction) between this suggestion and the other ideas in that PEP.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13475>
_______________________________________

From report at bugs.python.org  Sat Nov 26 06:21:27 2011
From: report at bugs.python.org (Eric Snow)
Date: Sat, 26 Nov 2011 05:21:27 +0000
Subject: [issue13475] Add '-p'/'--path0' command line option to override
	sys.path[0] initialisation
In-Reply-To: <1322181994.22.0.955887054946.issue13475@psf.upfronthosting.co.za>
Message-ID: <1322284887.07.0.810708794077.issue13475@psf.upfronthosting.co.za>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

Yeah, the more I think about it, the more I agree it's Python 4 fodder.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13475>
_______________________________________

From report at bugs.python.org  Sat Nov 26 06:45:37 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 26 Nov 2011 05:45:37 +0000
Subject: [issue12618] py_compile cannot create files in current directory
In-Reply-To: <1311406971.17.0.312082121474.issue12618@psf.upfronthosting.co.za>
Message-ID: <E1RUB4s-0000Ls-FV@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset bcc7bf3963cc by Meador Inge in branch '2.7':
Issue #12618: create unit tests for the py_compile module
http://hg.python.org/cpython/rev/bcc7bf3963cc

New changeset 2be3a2e63683 by Meador Inge in branch '3.2':
Issue #12618: create unit tests for the py_compile module
http://hg.python.org/cpython/rev/2be3a2e63683

New changeset f8f58db0715e by Meador Inge in branch 'default':
Issue #12618: create unit tests for the py_compile module
http://hg.python.org/cpython/rev/f8f58db0715e

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12618>
_______________________________________

From report at bugs.python.org  Sat Nov 26 07:13:23 2011
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 26 Nov 2011 06:13:23 +0000
Subject: [issue13481] Use an accurate clock in timeit
In-Reply-To: <1322265721.78.0.0567796730825.issue13481@psf.upfronthosting.co.za>
Message-ID: <1322288003.68.0.638569055943.issue13481@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

So does the accuracy outweigh using a Python function to call the actual clock function? (and usuable -> usable)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13481>
_______________________________________

From report at bugs.python.org  Sat Nov 26 07:41:39 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 26 Nov 2011 06:41:39 +0000
Subject: [issue11816] Refactor the dis module to provide better building
	blocks for bytecode analysis
In-Reply-To: <1302394810.0.0.38146154248.issue11816@psf.upfronthosting.co.za>
Message-ID: <1322289699.17.0.851774909669.issue11816@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Somewhat inevitably, the detailed disassembler tests broke when Antoine updated the code generation for function definitions (as part of PEP 3155). (At least, the tests broke, and PEP 3155 seems the most likely culprit).

I subsequently realised there's a potential opportunity here: if Instruction objects define an __eq__ method instead of relying on the custom "assertBytecodeExactlyMatches" helper method the new disassembly tests currently use, then the sequence diffing functionality in unittest could be very helpful in identifying and fixing discrepancies between actual output and expected output.

However, the assertBytecodeExactlyMatches() API has this concept of a "line_offset" which it uses to cope with some of the introspection fodder moving around in the files, so the question then becomes how to deal with that in the context of an __eq__ implementation.

Accordingly, my current plan is to offer "line_offset" as a keyword-only argument to get_instructions() itself. That way, the entire sequence of generated bytecode can easily be adjusted to (for example), be based around the first line being line 1, even if the actual code object being disassembled is located elsewhere in the original source file.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11816>
_______________________________________

From report at bugs.python.org  Sat Nov 26 09:16:39 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 26 Nov 2011 08:16:39 +0000
Subject: [issue11816] Refactor the dis module to provide better building
	blocks for bytecode analysis
In-Reply-To: <1302394810.0.0.38146154248.issue11816@psf.upfronthosting.co.za>
Message-ID: <1322295399.34.0.165667572201.issue11816@psf.upfronthosting.co.za>


Changes by Nick Coghlan <ncoghlan at gmail.com>:


Removed file: http://bugs.python.org/file23773/9512712044a6.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11816>
_______________________________________

From report at bugs.python.org  Sat Nov 26 09:26:38 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 26 Nov 2011 08:26:38 +0000
Subject: [issue11816] Refactor the dis module to provide better building
	blocks for bytecode analysis
In-Reply-To: <1302394810.0.0.38146154248.issue11816@psf.upfronthosting.co.za>
Message-ID: <1322295998.27.0.0939706724282.issue11816@psf.upfronthosting.co.za>


Changes by Nick Coghlan <ncoghlan at gmail.com>:


Added file: http://bugs.python.org/file23773/9512712044a6.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11816>
_______________________________________

From report at bugs.python.org  Sat Nov 26 09:38:34 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 26 Nov 2011 08:38:34 +0000
Subject: [issue11816] Refactor the dis module to provide better building
	blocks for bytecode analysis
In-Reply-To: <1302394810.0.0.38146154248.issue11816@psf.upfronthosting.co.za>
Message-ID: <1322296714.31.0.986679009246.issue11816@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

I have updated my BitBucket repo with the following changes:

- the main API is now dis.get_instructions()
- the info class is now dis.Instruction
- get_instructions() accepts a 'line_offset' argument that is added to any source code line numbers
- the printing of individual lines in all the disassembly operations is now handled by a private Instruction._disassemble() helper method
- assertBytecodeExactlyMatches now relies on the list comparison machinery in unittest, as well as the Instruction.__eq__ implementation provide by collections.namedtuple (this gives *much* better error messages when discrepancies are found)
- to further improve error messages reported by unittest (which can truncate representations), the order of the Instruction fields now has 'opname' first, then 'opcode', then the remaining fields.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11816>
_______________________________________

From report at bugs.python.org  Sat Nov 26 09:50:05 2011
From: report at bugs.python.org (Martin Unzner)
Date: Sat, 26 Nov 2011 08:50:05 +0000
Subject: [issue13482] _tkinter.TclError: invalid command name "tixDirSelectBox"
Message-ID: <1322297405.04.0.473643719264.issue13482@psf.upfronthosting.co.za>


New submission from Martin Unzner <abmelden22 at gmx.de>:

Hi all,

while executing the following piece of code:

import tkinter
import tkinter.tix

if __name__=='__main__':
    root = tkinter.Tk()
    dirlist = tkinter.tix.DirSelectBox(root)
    dirlist.pack()
    root.mainloop()

the following error occurred:

Traceback (most recent call last):
  File "<...>", line 6, in <module>
    dirlist = tkinter.tix.DirSelectBox(root)
  File "C:\Python32\lib\tkinter\tix.py", line 712, in __init__
    TixWidget.__init__(self, master, 'tixDirSelectBox', ['options'], cnf, kw)
  File "C:\Python32\lib\tkinter\tix.py", line 322, in __init__
    self.tk.call(widgetName, self._w, *extra)
_tkinter.TclError: invalid command name "tixDirSelectBox"

Thanks!

Martin

----------
components: Tkinter
messages: 148384
nosy: Martin.Unzner
priority: normal
severity: normal
status: open
title: _tkinter.TclError: invalid command name "tixDirSelectBox"
type: behavior
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13482>
_______________________________________

From report at bugs.python.org  Sat Nov 26 10:17:01 2011
From: report at bugs.python.org (Christian Iversen)
Date: Sat, 26 Nov 2011 09:17:01 +0000
Subject: [issue13433] String format documentation contains error regarding %g
In-Reply-To: <1321707692.58.0.601543510069.issue13433@psf.upfronthosting.co.za>
Message-ID: <1322299021.47.0.79408462963.issue13433@psf.upfronthosting.co.za>


Christian Iversen <ci at sikkerhed.org> added the comment:

Terry, the %g format always trims trailing zeroes, so you'd have to try with a number that doesn't end in zero.

I had to make a re-implementation of format for javascript:

http://paste.pocoo.org/show/513078/

If you look at the %g case, you can clearly see how much more complex and different it is, not that that itself indicates a bug. But it is different for sure :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13433>
_______________________________________

From report at bugs.python.org  Sat Nov 26 10:41:32 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 26 Nov 2011 09:41:32 +0000
Subject: [issue13481] Use an accurate clock in timeit
In-Reply-To: <1322265721.78.0.0567796730825.issue13481@psf.upfronthosting.co.za>
Message-ID: <1322300492.54.0.740002491021.issue13481@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Well, you only call the clock at the begining and end of a timing run, not at each iteration.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13481>
_______________________________________

From report at bugs.python.org  Sat Nov 26 11:33:21 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 26 Nov 2011 10:33:21 +0000
Subject: [issue13415] del os.environ[key] ignores errors
In-Reply-To: <1321481687.96.0.070295281604.issue13415@psf.upfronthosting.co.za>
Message-ID: <E1RUFZP-0001hi-2J@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 23ed66484ff2 by Charles-Fran?ois Natali in branch 'default':
Issue #13415: Skip test_os.test_unset_error on FreeBSD < 7 and OS X < 10.6
http://hg.python.org/cpython/rev/23ed66484ff2

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13415>
_______________________________________

From report at bugs.python.org  Sat Nov 26 11:37:20 2011
From: report at bugs.python.org (Martin Unzner)
Date: Sat, 26 Nov 2011 10:37:20 +0000
Subject: [issue13482] _tkinter.TclError: invalid command name "tixDirSelectBox"
In-Reply-To: <1322297405.04.0.473643719264.issue13482@psf.upfronthosting.co.za>
Message-ID: <1322303840.57.0.0772540451743.issue13482@psf.upfronthosting.co.za>


Martin Unzner <abmelden22 at gmx.de> added the comment:

Sorry, I just found the programming example in the documentary. Works now.

----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13482>
_______________________________________

From report at bugs.python.org  Sat Nov 26 11:37:49 2011
From: report at bugs.python.org (=?utf-8?q?Lars_Gust=C3=A4bel?=)
Date: Sat, 26 Nov 2011 10:37:49 +0000
Subject: [issue13477] tarfile module should have a command line
In-Reply-To: <1322190665.85.0.356467902383.issue13477@psf.upfronthosting.co.za>
Message-ID: <1322303869.33.0.21537104476.issue13477@psf.upfronthosting.co.za>


Lars Gust?bel <lars at gustaebel.de> added the comment:

This is no bad idea. I recommend keeping it as simple as possible. I would definitely not be supportive of a full tar clone. List, extract, create - that should be enough. There are two possible command line choices: do what the zipfile module does or emulate tar. I am in favor of the latter.

----------
assignee:  -> lars.gustaebel
priority: normal -> low
stage: test needed -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13477>
_______________________________________

From report at bugs.python.org  Sat Nov 26 11:56:01 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sat, 26 Nov 2011 10:56:01 +0000
Subject: [issue13481] Use an accurate clock in timeit
In-Reply-To: <1322265721.78.0.0567796730825.issue13481@psf.upfronthosting.co.za>
Message-ID: <1322304961.75.0.728095247439.issue13481@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

_clocks = ['CLOCK_PROCESS_CPUTIME_ID', 'CLOCK_MONOTONIC_RAW',
               'CLOCK_MONOTONIC', 'CLOCK_REALTIME']


Beware, we're mixing CPU time and wall-clock time:
$ ./python -c "from time import *; id = CLOCK_REALTIME; t = clock_gettime(id); sleep(1); print(clock_gettime(id) - t)"
1.0011036396026611
$ ./python -c "from time import *; id = CLOCK_PROCESS_CPUTIME_ID; t = clock_gettime(id); sleep(1); print(clock_gettime(id) - t)"
9.480300000003217e-05

Right now, timeit measures wall-clock time:
"""
On either platform, the default timer functions measure wall clock time, not the CPU time. [...] On Unix, you can use clock() to measure CPU time.
"""

With CLOCK_PROCESS_CPUTIME_ID:
- depending on the platform, we'll measure either wall-clock time or CPU time
- preemtion, blocking syscalls, etc won't be accounted for (so, for example, I/O-related tests will be meaningless)

----------
nosy: +neologix

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13481>
_______________________________________

From report at bugs.python.org  Sat Nov 26 12:00:37 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 26 Nov 2011 11:00:37 +0000
Subject: [issue13481] Use an accurate clock in timeit
In-Reply-To: <1322304961.75.0.728095247439.issue13481@psf.upfronthosting.co.za>
Message-ID: <1322304937.3400.1.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> With CLOCK_PROCESS_CPUTIME_ID:
> - depending on the platform, we'll measure either wall-clock time or
> CPU time

Indeed. I thought CPU time would be more useful (and that's the point of
the patch) but perhaps it breaks the spec.

> - preemtion, blocking syscalls, etc won't be accounted for (so, for
> example, I/O-related tests will be meaningless)

But does it include kernel CPU time for the given process?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13481>
_______________________________________

From report at bugs.python.org  Sat Nov 26 12:12:41 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sat, 26 Nov 2011 11:12:41 +0000
Subject: [issue13481] Use an accurate clock in timeit
In-Reply-To: <1322265721.78.0.0567796730825.issue13481@psf.upfronthosting.co.za>
Message-ID: <1322305961.91.0.187968883224.issue13481@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

> Indeed. I thought CPU time would be more useful (and that's the point
> of the patch)

Ah, OK.
Then you should probably rename the issue "make timeit measure CPU time", or something like that, because I really thought this issue was about using a more accurate clock (less jitter, can't go backward, etc). And also update the documentation :-)

>  but perhaps it breaks the spec.

Well, I almost never use timeit so I can't make a call, but that's definitely a semantics change, and this may puzzle some users, especially since it will really depend on the OS/kernel version in use (and so it won't be documented).

> But does it include kernel CPU time for the given process?

Yes. But it won't be reliable, for example, to measure the performance of a new readinto() implentation, since time spent by the process in 'S' or 'D' state won't be accounted for.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13481>
_______________________________________

From report at bugs.python.org  Sat Nov 26 13:34:36 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 26 Nov 2011 12:34:36 +0000
Subject: [issue13481] Use an accurate clock in timeit
In-Reply-To: <1322305961.91.0.187968883224.issue13481@psf.upfronthosting.co.za>
Message-ID: <1322310575.3400.4.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> > But does it include kernel CPU time for the given process?
> 
> Yes. But it won't be reliable, for example, to measure the performance
> of a new readinto() implentation, since time spent by the process in
> 'S' or 'D' state won't be accounted for.

Then I'm not sure this is a good idea anymore.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13481>
_______________________________________

From report at bugs.python.org  Sat Nov 26 13:50:02 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 26 Nov 2011 12:50:02 +0000
Subject: [issue13475] Add '-p'/'--path0' command line option to override
	sys.path[0] initialisation
In-Reply-To: <1322181994.22.0.955887054946.issue13475@psf.upfronthosting.co.za>
Message-ID: <1322311802.78.0.611354887774.issue13475@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Eric: Actually I posted my comments after reading only Nick?s message, not yours, so no worry :)

Nick:
> the "just do the right thing" aspect is covered by PEP 395.
This is great.  Thanks for clarifying.

> This is an orthogonal proposal that allows power users the ability to override the
> automatic initialisation to handle those cases where it goes wrong.
If I?m understanding correctly, #12934 is one of those issues.  I agree that an option would be better than nothing, but 1) it would not help with older Pythons 2) it would not help na?ve users 3) it would complicate the command-line interface of Python.  (Not saying I?m against the idea, just listing cons.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13475>
_______________________________________

From report at bugs.python.org  Sat Nov 26 13:54:19 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 26 Nov 2011 12:54:19 +0000
Subject: [issue13450] add assertions to implement the intent in ''.format_map
	test
In-Reply-To: <1321922556.51.0.541780569618.issue13450@psf.upfronthosting.co.za>
Message-ID: <1322312059.01.0.236675117271.issue13450@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

When someone puts thought into a report or patch, they deserve to be in Misc/ACKS.  Just noticing one typo doesn?t qualify, but pretty much anything above does.  :)

----------
nosy: +eric.araujo
versions:  -Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13450>
_______________________________________

From report at bugs.python.org  Sat Nov 26 14:02:34 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 26 Nov 2011 13:02:34 +0000
Subject: [issue13465] A Jython section in the dev guide would be great
In-Reply-To: <1322074015.2.0.311635199294.issue13465@psf.upfronthosting.co.za>
Message-ID: <1322312554.82.0.305685208111.issue13465@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

python.org is not specific to CPython, but I agree with Antoine that docs.python.org/devguide is.  So I went and found the blog post that Frank alludes to in the OP is here: http://fwierzbicki.blogspot.com/2011/11/contributing-to-jython.html
Nick proposed adding a jython page to the cpython devguide and Frank agreed, saying ?much of a dev guide I might put up would largely cut and paste from there?.  If Jython development is very much like CPython?s apart from repo URI, build process and bug tracker URI, then it could fit in just one page and be part of the devguide.  If the process widely differs and many pages would be needed, then separate devguides may be better.

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13465>
_______________________________________

From report at bugs.python.org  Sat Nov 26 14:04:05 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 26 Nov 2011 13:04:05 +0000
Subject: [issue13467] Typo in doc for library/sysconfig
In-Reply-To: <1322102306.14.0.426447482004.issue13467@psf.upfronthosting.co.za>
Message-ID: <1322312645.58.0.651313369297.issue13467@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Thanks, I?ll fix this.

----------
assignee: docs at python -> eric.araujo
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13467>
_______________________________________

From report at bugs.python.org  Sat Nov 26 14:06:48 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 26 Nov 2011 13:06:48 +0000
Subject: [issue13474] Mention of "-m" Flag Missing From Doc on Execution Model
In-Reply-To: <1322165458.97.0.989343856998.issue13474@psf.upfronthosting.co.za>
Message-ID: <1322312808.79.0.667399763603.issue13474@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I guess you?re suggesting adding a mention of -m in the section near the top that says that a script file and code passed to -c are blocks?  Makes sense.  The same commit could also improve the markup to link to the description of script, -c and -m in using/cmdline.  (I think we have another doc bug open about cross-linking using/cmdline and other parts, but I don?t have the number at hand.)

----------
nosy: +eric.araujo, ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13474>
_______________________________________

From report at bugs.python.org  Sat Nov 26 14:12:42 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 26 Nov 2011 13:12:42 +0000
Subject: [issue13483] Use VirtualAlloc to allocate memory arenas
Message-ID: <1322313162.87.0.914810161445.issue13483@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

Similar to issue #11849, this patch proposes to use VirtualAlloc/VirtualFree to allocate the Python allocator's memory arenas (rather than malloc() / free()). It might help release more memory if there is some fragmentation, although I don't know how Microsoft's malloc() works.

----------
components: Interpreter Core, Windows
files: va.patch
keywords: patch
messages: 148399
nosy: brian.curtin, neologix, pitrou, tim.golden
priority: low
severity: normal
status: open
title: Use VirtualAlloc to allocate memory arenas
type: resource usage
versions: Python 3.3
Added file: http://bugs.python.org/file23784/va.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13483>
_______________________________________

From report at bugs.python.org  Sat Nov 26 14:16:27 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 26 Nov 2011 13:16:27 +0000
Subject: [issue13477] tarfile module should have a command line
In-Reply-To: <1322190665.85.0.356467902383.issue13477@psf.upfronthosting.co.za>
Message-ID: <1322313387.6.0.676970699957.issue13477@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/issue13477>
_______________________________________

From report at bugs.python.org  Sat Nov 26 14:17:43 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 26 Nov 2011 13:17:43 +0000
Subject: [issue12618] py_compile cannot create files in current directory
In-Reply-To: <1311406971.17.0.312082121474.issue12618@psf.upfronthosting.co.za>
Message-ID: <1322313463.14.0.115567331197.issue12618@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

The tests break on the Windows buildbots:

======================================================================
ERROR: test_relative_path (test.test_py_compile.PyCompileTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\test\test_py_compile.py", line 33, in test_relative_path
    py_compile.compile(os.path.relpath(self.source_path),
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\ntpath.py", line 622, in relpath
    raise ValueError(error)
ValueError: path is on mount 'c:', start on mount 'D:'

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12618>
_______________________________________

From report at bugs.python.org  Sat Nov 26 14:24:09 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 26 Nov 2011 13:24:09 +0000
Subject: [issue13457] Use repr(module name) ImportErrors
In-Reply-To: <1321993736.11.0.640426182551.issue13457@psf.upfronthosting.co.za>
Message-ID: <1322313849.37.0.893941719333.issue13457@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

__import__ and importlib in Python 3.3 already use repr (see c4361bab6914 and 9f9b7b656761):

  Traceback (most recent call last):
    File "<string>", line 1, in <module>
  ImportError: No module named 'string\n'

For other stdlib modules, see #8754.

----------
nosy: +eric.araujo
resolution:  -> out of date
stage:  -> committed/rejected
title: Display module name as string in `ImportError` -> Use repr(module name) ImportErrors

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13457>
_______________________________________

From report at bugs.python.org  Sat Nov 26 14:35:28 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 26 Nov 2011 13:35:28 +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: <1322314528.18.0.570218531585.issue12307@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I read this report again a few days ago and saw you were right, so I fixed it.  Thanks!

(The peps repo is not hooked up to close bugs, because we don?t usually use the bug tracker to discuss PEPs (we use mailing lists).  The PEPs pages (not docs! :) on python.org are built automatically (doing otherwise would be a shame for programmers in 2010!))

----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12307>
_______________________________________

From report at bugs.python.org  Sat Nov 26 14:35:32 2011
From: report at bugs.python.org (Giampaolo Rodola')
Date: Sat, 26 Nov 2011 13:35:32 +0000
Subject: [issue13451] sched.py: speedup cancel() method
In-Reply-To: <1321923822.73.0.49972384361.issue13451@psf.upfronthosting.co.za>
Message-ID: <1322314532.92.0.219314438781.issue13451@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

New patch in attachment takes care of modifying empty() and queue property according with the new implementation.
With this, the API behaves the same as before (this was my main concern).
Also, it's smarter when it comes to cleaning up too many pending cancelled items:

if self._cancellations > 50 \
  and self._cancellations > (len(self._queue) >> 1):
     ...

Also, I made a little benchmark script (in attachment) to make sure that the speed of the rest of the API hasn't been significantly affected by this change:


BEFORE THE PATCH

test_cancel                    : time=0.66648 : calls=1 : stdev=0.00000
test_empty                     : time=0.00026 : calls=1 : stdev=0.00000
test_enter                     : time=0.00309 : calls=1 : stdev=0.00000
test_queue                     : time=6.20777 : calls=1 : stdev=0.00000
test_run                       : time=0.00746 : calls=1 : stdev=0.00000


AFTER THE PATCH

test_cancel                    : time=0.00054 : calls=1 : stdev=0.00000
test_empty                     : time=0.00031 : calls=1 : stdev=0.00000
test_enter                     : time=0.00375 : calls=1 : stdev=0.00000
test_queue                     : time=6.30314 : calls=1 : stdev=0.00000
test_run                       : time=0.00716 : calls=1 : stdev=0.00000

----------
nosy: +josiah.carlson, josiahcarlson
Added file: http://bugs.python.org/file23785/cancel.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13451>
_______________________________________

From report at bugs.python.org  Sat Nov 26 14:36:03 2011
From: report at bugs.python.org (Giampaolo Rodola')
Date: Sat, 26 Nov 2011 13:36:03 +0000
Subject: [issue13451] sched.py: speedup cancel() method
In-Reply-To: <1321923822.73.0.49972384361.issue13451@psf.upfronthosting.co.za>
Message-ID: <1322314563.53.0.671703272832.issue13451@psf.upfronthosting.co.za>


Changes by Giampaolo Rodola' <g.rodola at gmail.com>:


Added file: http://bugs.python.org/file23786/bench.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13451>
_______________________________________

From report at bugs.python.org  Sat Nov 26 14:40:17 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 26 Nov 2011 13:40:17 +0000
Subject: [issue13400] packaging: build command should have options to control
	byte-compilation
In-Reply-To: <1321281623.21.0.854677924579.issue13400@psf.upfronthosting.co.za>
Message-ID: <1322314817.65.0.411534925853.issue13400@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Okay, I think it?s a valuable use case.

(Out of curiosity, why don?t you want byte-compiled files on your system?  It speeds up imports, and problems due to the presence of stray pyc files when the py is deleted are gone in 3.2+.  Maybe you have custom tools to byte-compile, like Debian?)

Do you have any opinion about my renaming suggestion?
Without renaming, we?d have that:

  build --byte-compile --no-byte-compile --optimize-bytecode=[012]
  build_py --compile --no-compile --optimize=[012]

If we want to use the same name and make the names clearer, we could have:

  build(_py) --compile-pyc --no-compile-pyc --compile-pyo=[012]

----------
title: packaging: build command should accept --compile, --no-compile and --optimize options -> packaging: build command should have options to control byte-compilation

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13400>
_______________________________________

From report at bugs.python.org  Sat Nov 26 14:42:26 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 26 Nov 2011 13:42:26 +0000
Subject: [issue10752] build_ssl.py is relying on unreliable behaviour of
	os.popen
In-Reply-To: <1292972982.57.0.365932571977.issue10752@psf.upfronthosting.co.za>
Message-ID: <1322314946.81.0.869285624838.issue10752@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +brian.curtin, tim.golden
stage:  -> patch review
versions: +Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10752>
_______________________________________

From report at bugs.python.org  Sat Nov 26 14:56:25 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 26 Nov 2011 13:56:25 +0000
Subject: [issue1521950] shlex.split() does not tokenize like the shell
Message-ID: <1322315785.43.0.703498350921.issue1521950@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


Removed file: http://bugs.python.org/file23778/ref_shlex.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1521950>
_______________________________________

From report at bugs.python.org  Sat Nov 26 14:56:27 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 26 Nov 2011 13:56:27 +0000
Subject: [issue1521950] shlex.split() does not tokenize like the shell
Message-ID: <1322315787.41.0.223543669556.issue1521950@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


Removed file: http://bugs.python.org/file23779/test_shlex.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1521950>
_______________________________________

From report at bugs.python.org  Sat Nov 26 15:12:55 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 26 Nov 2011 14:12:55 +0000
Subject: [issue1521950] shlex.split() does not tokenize like the shell
Message-ID: <1322316775.16.0.470249070612.issue1521950@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Thanks for the diff and test.  (I removed the older versions; there are ?edit? links in the list of files leading to pages where it?s possible to remove them, if one has the required permissions.)

Your script passes with dash, which is probably the most POSIX-compliant shell we can find.  (bash has extensions, zsh/csh don?t use the POSIX shell language, so I think the behavior of dash should be our reference, not the bash man page.)

> I may be able to convince people that the current behaviour is wrong, but I can't tell you what will
> break if it is "fixed".  And should the fix be the default?  As you mentioned, it depends on what
> people expect it to do and how it is currently being used.

python-dev takes compatibility seriously.  Some things are clearly bugs and we fix them, even if it will break buggy code out there.  For example, we recently fixed bugs in HTML parsing: We had a specification to decide that they were really bugs, and we judged that no sane program could be relying on the exact behavior of the parser.  shlex is another case; in my opinion, it?s been used for years to implement parsing similar, but not identical in all cases, to the shell?s, and as there is code out there that depends on the current behavior of shlex and does not need to support && || ; ( ), if we add support for these tokens we should not break the existing code.  Given that we can?t test all programs that use shlex, I think we?ll have to add a new parameter, with a default value which gets us the previous behavior, as I said in my previous message.

(BTW, would you mind editing the quoted section when you reply by email?  Otherwise we get unhelpful, distracting walls of quoted texts.  Thanks in advance.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1521950>
_______________________________________

From report at bugs.python.org  Sat Nov 26 15:17:27 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 26 Nov 2011 14:17:27 +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: <1322317047.65.0.66125206804.issue12424@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> if a line ends with ";;", _pop_values() will call interpret() with an empty string. [...]
> it just means interpret() would return False, causing the line to be ignored, which is probably
> fine for that border case

Hm, I?d rather call that a bug.  _pop_values should not call interpret, or interpret('') should return True (there is no condition that fails), or _pop_values should raise an exception (pro: errors should never pass silently, con: it?s not an error if we define that the empty string is a no-op, and it?s more user-friendly to do that).  I?m inclined to let interpret(''), do you think it?s sensible?

----------
assignee: tarek -> eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12424>
_______________________________________

From report at bugs.python.org  Sat Nov 26 15:26:31 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 26 Nov 2011 14:26:31 +0000
Subject: =?utf-8?q?=5Bissue13472=5D_devguide_doesn=E2=80=99t_list_all_build_depend?=
	=?utf-8?q?encies?=
In-Reply-To: <1322142769.6.0.687458451697.issue13472@psf.upfronthosting.co.za>
Message-ID: <1322317591.03.0.28482488503.issue13472@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> I have a few arguments in favor of my position:
Hm, I said that people wanted a ?feature-full library? but I was confused: We?re talking about a Python built for contributing, not to develop your app, so my argument does not apply.  So, the devguide should list the optional build deps *and* say something like ?these are not needed to run Python and its test suite, but you may need one them of for some patches?.

> (I've found and fixed several issues related to zlib because it was missing here)
I know :)  I have a Python built without threads and run packaging and distutils tests with it from time to time, but it seems I can?t disable zlib at configure time.

>> the addition of this message and further edits to its wording were done
>> exactly to avoid people worrying that their python binary is not usable.
> But it's still missing an "optional" before modules imho.
What I meant is that the history of this messages says that you can just go ahead and add ?optional?.

> The second message that says to "look in setup.py in detect_modules()" doesn't seem too
> useful too (but maybe I should take a look ;).
It is scary code.

>> Okay; do we need to collect info for all major OSes
> You can also do it incrementally
Okay, I?ll make a patch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13472>
_______________________________________

From report at bugs.python.org  Sat Nov 26 15:35:19 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 26 Nov 2011 14:35:19 +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: <1322318119.57.0.885438145419.issue12424@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Latest patch looks good.

Looking at the examples with ';;' or even '--', I think that their role is non-obvious.  Even though the PEP and docs explained them, there is value in using intuitive (?guessable?) markup.  So if the constraints are that a marker delimiter should be non-ambiguous and short, why not using something like '#IF#' or '#condition:'?  (This will probably require agreement on the fellowship mailing list.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12424>
_______________________________________

From report at bugs.python.org  Sat Nov 26 15:40:13 2011
From: report at bugs.python.org (Giampaolo Rodola')
Date: Sat, 26 Nov 2011 14:40:13 +0000
Subject: [issue8684] improvements to sched.py
In-Reply-To: <1273552070.58.0.496415961493.issue8684@psf.upfronthosting.co.za>
Message-ID: <1322318413.09.0.831814810345.issue8684@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

Looking back at this patch, I think we can extract the thread-synchronization parts and the peek() method, as they're both valuable additions, especially the first one.

The very sched doc says:

> In multi-threaded environments, the scheduler class has limitations 
> with respect to thread-safety, inability to insert a new task before 
> the one currently pending in a running scheduler, and holding up the 
> main thread until the event queue is empty. Instead, the preferred 
> approach is to use the threading.Timer class instead.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8684>
_______________________________________

From report at bugs.python.org  Sat Nov 26 15:40:24 2011
From: report at bugs.python.org (Dan Christian)
Date: Sat, 26 Nov 2011 14:40:24 +0000
Subject: [issue1521950] shlex.split() does not tokenize like the shell
In-Reply-To: <1322316775.16.0.470249070612.issue1521950@psf.upfronthosting.co.za>
Message-ID: <CAEcGQ+OB1ftaDtpEF+A-SQhw-JTYnUomyWW1zhUSzi+iAU5R4w@mail.gmail.com>


Dan Christian <robodan at users.sourceforge.net> added the comment:

On Sat, Nov 26, 2011 at 7:12 AM, ?ric Araujo <report at bugs.python.org> wrote:
> Your script passes with dash, which is probably the most POSIX-compliant shell we can find. ?(bash has extensions, zsh/csh don?t use the POSIX shell language, so I think the behavior of dash should be our reference, not the bash man page.)

I was just looking for a reference where I didn't have to sift through
tons of documentation.  Most systems have bash.  Before that I was
just working from experience (I've done a lot of shell scripting).

> there is code out there that depends on the current behavior of shlex and does not need to support && || ; ( ), if we add support for these tokens we should not break the existing code.

Here's a thought on how that might work (just brainstorming).  shlex
uses a series of character strings to drive it's parsing:  whitespace,
escape, quotes.  Add another one: control = '();<>|&'.  If it is unset
(by default?), then the behavior is as before.  If it is set, then
shlex will output any character in control as a separate token.

There might be a shell specific script (or maybe it's left to the
user) that decides that certain tokens can be recombined:  '&&', '||',
'|&', '>>', etc.  This code is pretty simple:  walk the token
sequence, if you see a two token pair, pop the second and combine it
into the first.

-Dan

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1521950>
_______________________________________

From report at bugs.python.org  Sat Nov 26 15:52:15 2011
From: report at bugs.python.org (Meador Inge)
Date: Sat, 26 Nov 2011 14:52:15 +0000
Subject: [issue12618] py_compile cannot create files in current directory
In-Reply-To: <1322313463.14.0.115567331197.issue12618@psf.upfronthosting.co.za>
Message-ID: <CAK1Qoops0YNRtTrdGeP5AMTkF6sBQs4hF7Lu+thh6E-9otk4Dg@mail.gmail.com>


Meador Inge <meadori at gmail.com> added the comment:

On Sat, Nov 26, 2011 at 7:17 AM, Antoine Pitrou <report at bugs.python.org> wrote:

> The tests break on the Windows buildbots:

I am investigating now.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12618>
_______________________________________

From report at bugs.python.org  Sat Nov 26 16:13:18 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Sat, 26 Nov 2011 15:13:18 +0000
Subject: [issue6715] xz compressor support
In-Reply-To: <1250502444.31.0.107447392137.issue6715@psf.upfronthosting.co.za>
Message-ID: <1322320398.75.0.185847696478.issue6715@psf.upfronthosting.co.za>


Nadeem Vawda <nadeem.vawda at gmail.com> added the comment:

Victor: Thanks for the review; I've replied to your comments and updated
the patch. Let me know what you think of the changes.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6715>
_______________________________________

From report at bugs.python.org  Sat Nov 26 16:25:01 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 26 Nov 2011 15:25:01 +0000
Subject: [issue1521950] shlex.split() does not tokenize like the shell
Message-ID: <1322321101.44.0.549991421257.issue1521950@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> I was just looking for a reference where I didn't have to sift through tons of documentation.
Sure :)  That?s why I suggest using dash for quick tests and rely on the work of other people who did read the POSIX spec.  I?ll have to check it too before committing a patch.

> shlex uses a series of character strings to drive it's parsing:  whitespace, escape, quotes.
> Add another one: control = '();<>|&'.  If it is unset (by default?), then the behavior is as
> before.
So we would need to add a Shlex subclass to the module to provide the new behavior.  I think I prefer a new argument, because we can just extend the existing class and functions instead of adding subtly differing duplicates.

> If it is set, then shlex will output any character in control as a separate token.
Unless it is part of a quoted segment, right?  (See #7611 for 'foo#bar' vs. 'foo #bar').

> There might be a shell specific script (or maybe it's left to the user)
> that decides that certain tokens can be recombined:
Seems to much complexity.  I really prefer if we agree on one command parsing behavior (POSIX, i.e. dash) and improve shlex to support that.  People wanting zsh rules can write their own subclass.

> '&&', '||', '|&', '>>', etc.
Wouldn?t it be more correct to consider them different tokens?  I don?t have a format training in CS or programming, so I?m not sure that my definition is correct at all, but in my mind a token is a unit, and thus & and && are two different things.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1521950>
_______________________________________

From report at bugs.python.org  Sat Nov 26 16:38:08 2011
From: report at bugs.python.org (David W. Lambert)
Date: Sat, 26 Nov 2011 15:38:08 +0000
Subject: [issue13484] mail rejected: tutor@python.org
Message-ID: <1322321888.72.0.32483398033.issue13484@psf.upfronthosting.co.za>


New submission from David W. Lambert <b49P23TIvg at stny.rr.com>:

I sent this question to tutor at python.org as advertised at
http://mail.python.org/mailman/listinfo/tutor
The message was returned, and we still need an answer to the question.  I'll post it as a separate bug.
Thank you, Dave.


From: 	David Ward Lambert <b49P23TIvg at stny.rr.com>
To: 	tutor at python.org
Subject: 	tkinter question I have not been able to resolve.
Date: 	Mon, 21 Nov 2011 22:15:23 -0500


http://forums.devshed.com/python-programming-11/setting-tkinter-checkbox-default-graphical-state-865148.html

Summary: Trouble initiating button in "checked" state.

If you answer to me, I'll post the answer at the devshed forum.
If you answer at the forum I'll probably find it.

Thank you, Dave Lambert
also known as b49P23TIvg

----------
components: None
messages: 148414
nosy: LambertDW
priority: normal
severity: normal
status: open
title: mail rejected: tutor at python.org

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13484>
_______________________________________

From report at bugs.python.org  Sat Nov 26 16:58:59 2011
From: report at bugs.python.org (David W. Lambert)
Date: Sat, 26 Nov 2011 15:58:59 +0000
Subject: [issue13485] tcl question
Message-ID: <1322323139.8.0.0736428803132.issue13485@psf.upfronthosting.co.za>


New submission from David W. Lambert <b49P23TIvg at stny.rr.com>:

I was unable to solve this question.

http://forums.devshed.com/python-programming-11/setting-tkinter-checkbox-default-graphical-state-865148.html
        
        Summary: Trouble initiating button in "checked" state.
        
        If you answer to me, I'll post the answer at the devshed forum.
        If you answer at the forum I'll probably find it.
        
  
I doubt this is a python bug.  I doubt this is a tcl bug.  I think the proper forum would be the "How do I use tcl?" forum.  Sorry, I've posed the question here.

        Thank you, Dave Lambert
        also known as b49P23TIvg

----------
components: Library (Lib)
messages: 148415
nosy: LambertDW
priority: normal
severity: normal
status: open
title: tcl question

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13485>
_______________________________________

From report at bugs.python.org  Sat Nov 26 17:32:05 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 26 Nov 2011 16:32:05 +0000
Subject: [issue13484] mail rejected: tutor@python.org
In-Reply-To: <1322321888.72.0.32483398033.issue13484@psf.upfronthosting.co.za>
Message-ID: <1322325125.21.0.219256520202.issue13484@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Please report troubles to the listmasters listed on the bottom of each mailing list?s description page.  Thanks.

----------
components:  -None
nosy: +eric.araujo
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13484>
_______________________________________

From report at bugs.python.org  Sat Nov 26 18:46:37 2011
From: report at bugs.python.org (Dan Christian)
Date: Sat, 26 Nov 2011 17:46:37 +0000
Subject: [issue1521950] shlex.split() does not tokenize like the shell
In-Reply-To: <1322321101.44.0.549991421257.issue1521950@psf.upfronthosting.co.za>
Message-ID: <CAEcGQ+OO9c7Cg--OD-35zCGXWRjnkQ+q=EHQWNcd5nnR7UGUrg@mail.gmail.com>


Dan Christian <robodan at users.sourceforge.net> added the comment:

> Sure :) ?That?s why I suggest using dash for quick tests and rely on the work of other people who did read the POSIX spec. ?I?ll have to check it too before committing a patch.

The point of ref_shlex.py is that all shells act the same for common
cases and shlex doesn't match any of them.  The only real split it
that csh based shells do some things differently that sh based shells
('2>' vs '&>').

>> shlex uses a series of character strings to drive it's parsing: ?whitespace, escape, quotes.
>> Add another one: control = '();<>|&'. ?If it is unset (by default?), then the behavior is as
>> before.
> So we would need to add a Shlex subclass to the module to provide the new behavior. ?I think I prefer a new argument, because we can just extend the existing class and functions instead of adding subtly differing duplicates.

You don't have to do a subclass (although that might have some
advantages).  You could do something like:
def shlex(s, comments=False, posix=True, control=False):
...
  if control:
    if control is True:
      self.control = '();<>|&'
    else:
      self.control = control  # let user specify their own control set

>> If it is set, then shlex will output any character in control as a separate token.
> Unless it is part of a quoted segment, right? ?(See #7611 for 'foo#bar' vs. 'foo #bar').

Correct, quotes wouldn't change.

>> There might be a shell specific script (or maybe it's left to the user)
>> that decides that certain tokens can be recombined:
> Seems to much complexity. ?I really prefer if we agree on one command parsing behavior (POSIX, i.e. dash) and improve shlex to support that. ?People wanting zsh rules can write their own subclass.

shlex is a pretty simple lexer (as lexers go), and I wouldn't want it
to get complicated.  It's easier in the current code structure to
split everything and then re-join as needed.  This also allows you to
select sh vs csh joining rules (e.g. '|&' means different things in sh
vs csh).  Every shell that I've seen follows one of those two flavors
for syntax.

>> '&&', '||', '|&', '>>', etc.
> Wouldn?t it be more correct to consider them different tokens? ?I don?t have a format training in CS or programming, so I?m not sure that my definition is correct at all, but in my mind a token is a unit, and thus & and && are two different things.

Ideally, the final tokens have exact meanings.  It easier to write
handler code for '&&' than ('&', '&').  This is just a case of whether
the parse joins them together or it's done in a second step.  The
current code doesn't do much look ahead, so it's hard for the lexer to
produce things like '&&' directly.

-Dan

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1521950>
_______________________________________

From report at bugs.python.org  Sat Nov 26 19:01:22 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 26 Nov 2011 18:01:22 +0000
Subject: [issue12618] py_compile cannot create files in current directory
In-Reply-To: <1311406971.17.0.312082121474.issue12618@psf.upfronthosting.co.za>
Message-ID: <E1RUMYz-0001qF-53@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset b23453530d5f by Meador Inge in branch '2.7':
Issue #12618: fix py_compile unit tests to handle different drives on Windows
http://hg.python.org/cpython/rev/b23453530d5f

New changeset 7097d52cacee by Meador Inge in branch '3.2':
Issue #12618: fix py_compile unit tests to handle different drives on Windows
http://hg.python.org/cpython/rev/7097d52cacee

New changeset 5243752e19aa by Meador Inge in branch 'default':
Issue #12618: fix py_compile unit tests to handle different drives on Windows
http://hg.python.org/cpython/rev/5243752e19aa

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12618>
_______________________________________

From report at bugs.python.org  Sat Nov 26 19:06:28 2011
From: report at bugs.python.org (Meador Inge)
Date: Sat, 26 Nov 2011 18:06:28 +0000
Subject: [issue12618] py_compile cannot create files in current directory
In-Reply-To: <1311406971.17.0.312082121474.issue12618@psf.upfronthosting.co.za>
Message-ID: <1322330788.83.0.020188893259.issue12618@psf.upfronthosting.co.za>


Meador Inge <meadori at gmail.com> added the comment:

The tests are fixed now.  A relative path was being computed, but on Windows the current working directory drive and the drive of the relative path we were computing was different (and so this test bug would *not* be seen if running on a Windows box with a single "C: drive" setup).

/me sighs at the concept of Windows drives.  Thanks for the heads up on the test break Antoine.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12618>
_______________________________________

From report at bugs.python.org  Sat Nov 26 20:50:00 2011
From: report at bugs.python.org (R. David Murray)
Date: Sat, 26 Nov 2011 19:50:00 +0000
Subject: [issue13460] urllib methods should demand unicode, instead demand str
In-Reply-To: <1322012077.59.0.596577613585.issue13460@psf.upfronthosting.co.za>
Message-ID: <1322337000.82.0.219721835861.issue13460@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Well, most of the point of Python3 is that the string type *is* unicode, which is what I meant by saying that you probably wanted Python3 in order to solve your concern :)

There are still a few bugs to work out in the wire-protocol/unicode interface in Python3, but it is a *lot* cleaner than it was in Python2.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13460>
_______________________________________

From report at bugs.python.org  Sat Nov 26 21:44:05 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sat, 26 Nov 2011 20:44:05 +0000
Subject: [issue13485] tcl question
In-Reply-To: <1322323139.8.0.0736428803132.issue13485@psf.upfronthosting.co.za>
Message-ID: <1322340245.45.0.674049668894.issue13485@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Sorry, the issue tracker is not a place to ask for help.
Please use the python-list mailing list or the comp.lang.python channel instead.

----------
nosy: +amaury.forgeotdarc
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13485>
_______________________________________

From report at bugs.python.org  Sat Nov 26 22:11:59 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 26 Nov 2011 21:11:59 +0000
Subject: [issue13444] closed stdout causes error on stderr when the
	interpreter unconditionally flushes on shutdown
In-Reply-To: <1321888700.56.0.103830046171.issue13444@psf.upfronthosting.co.za>
Message-ID: <E1RUPXR-0000Ci-Pv@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 150e096095e5 by Antoine Pitrou in branch '3.2':
Issue #13444: When stdout has been closed explicitly, we should not attempt to flush it at shutdown and print an error.
http://hg.python.org/cpython/rev/150e096095e5

New changeset 37300a1df7d7 by Antoine Pitrou in branch 'default':
Issue #13444: When stdout has been closed explicitly, we should not attempt to flush it at shutdown and print an error.
http://hg.python.org/cpython/rev/37300a1df7d7

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13444>
_______________________________________

From report at bugs.python.org  Sat Nov 26 22:11:59 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 26 Nov 2011 21:11:59 +0000
Subject: [issue5319] stdout error at interpreter shutdown fails to return OS
	error status
In-Reply-To: <1235065081.04.0.732738239861.issue5319@psf.upfronthosting.co.za>
Message-ID: <E1RUPXR-0000Ci-QH@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 150e096095e5 by Antoine Pitrou in branch '3.2':
Issue #13444: When stdout has been closed explicitly, we should not attempt to flush it at shutdown and print an error.
http://hg.python.org/cpython/rev/150e096095e5

New changeset 37300a1df7d7 by Antoine Pitrou in branch 'default':
Issue #13444: When stdout has been closed explicitly, we should not attempt to flush it at shutdown and print an error.
http://hg.python.org/cpython/rev/37300a1df7d7

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5319>
_______________________________________

From report at bugs.python.org  Sat Nov 26 22:59:43 2011
From: report at bugs.python.org (Jahangir)
Date: Sat, 26 Nov 2011 21:59:43 +0000
Subject: [issue13486] msvc9compiler.py doesn't properly generate manifest
	files.
Message-ID: <1322344783.33.0.460870481781.issue13486@psf.upfronthosting.co.za>


New submission from Jahangir <j4hangir at yahoo.com>:

msvc9compiler.py aims to generate a manifestation file but it will always fail as MSVC (cl.exe) needs a second /MANIFEST parameter to do so.

This makes the subsequent 'linking' processes fail with the following error:

general error c1010070: Failed to load and parse the manifest. The system cannot find the file specified.


http://msdn.microsoft.com/en-us/library/f2c0w594.aspx (default value is NO)

----------
assignee: tarek
components: Distutils
files: msvc9compiler.py.diff
keywords: patch
messages: 148424
nosy: Jahangir, eric.araujo, tarek
priority: normal
severity: normal
status: open
title: msvc9compiler.py doesn't properly generate manifest files.
type: compile error
versions: Python 3.2
Added file: http://bugs.python.org/file23787/msvc9compiler.py.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13486>
_______________________________________

From report at bugs.python.org  Sat Nov 26 23:25:53 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 26 Nov 2011 22:25:53 +0000
Subject: [issue7111] abort when stderr is closed
In-Reply-To: <1255335800.65.0.921782203194.issue7111@psf.upfronthosting.co.za>
Message-ID: <1322346353.7.0.994951709053.issue7111@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Attached patch allows Python to run even if no standard stream is available. I use dup() to detect whether a fd is valid.

----------
keywords: +patch
nosy: +neologix
stage:  -> patch review
versions: +Python 3.3 -Python 3.1
Added file: http://bugs.python.org/file23788/nostdio.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7111>
_______________________________________

From report at bugs.python.org  Sun Nov 27 00:00:48 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 26 Nov 2011 23:00:48 +0000
Subject: [issue13415] del os.environ[key] ignores errors
In-Reply-To: <1321481687.96.0.070295281604.issue13415@psf.upfronthosting.co.za>
Message-ID: <1322348448.57.0.367046748503.issue13415@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Oh, thanks Charles Fran?ois for your two patches.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13415>
_______________________________________

From report at bugs.python.org  Sun Nov 27 00:07:56 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 26 Nov 2011 23:07:56 +0000
Subject: [issue6715] xz compressor support
In-Reply-To: <1250502444.31.0.107447392137.issue6715@psf.upfronthosting.co.za>
Message-ID: <1322348876.49.0.857880550381.issue6715@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

The last patch (9276fc685c05.diff) looks good to me. Go ahead for the commit!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6715>
_______________________________________

From report at bugs.python.org  Sun Nov 27 00:20:17 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 26 Nov 2011 23:20:17 +0000
Subject: [issue13415] del os.environ[key] ignores errors
In-Reply-To: <1321481687.96.0.070295281604.issue13415@psf.upfronthosting.co.za>
Message-ID: <E1RURXb-0003sn-Oy@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 919259054621 by Victor Stinner in branch 'default':
Issue #13415: Help to locate curses.h when _curses module is linked to ncursesw
http://hg.python.org/cpython/rev/919259054621

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13415>
_______________________________________

From report at bugs.python.org  Sun Nov 27 00:21:09 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 26 Nov 2011 23:21:09 +0000
Subject: [issue13415] del os.environ[key] ignores errors
In-Reply-To: <1321481687.96.0.070295281604.issue13415@psf.upfronthosting.co.za>
Message-ID: <1322349669.46.0.768820059361.issue13415@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
Removed message: http://bugs.python.org/msg148428

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13415>
_______________________________________

From report at bugs.python.org  Sun Nov 27 00:21:20 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 26 Nov 2011 23:21:20 +0000
Subject: [issue12567] curses implementation of Unicode is wrong in Python 3
In-Reply-To: <1310682817.11.0.980195084883.issue12567@psf.upfronthosting.co.za>
Message-ID: <1322349680.14.0.948050792235.issue12567@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

New changeset 919259054621 by Victor Stinner in branch 'default':
Issue #13415: Help to locate curses.h when _curses module is linked to ncursesw
http://hg.python.org/cpython/rev/919259054621

(Oops, wrong issue number, again)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12567>
_______________________________________

From report at bugs.python.org  Sun Nov 27 00:26:08 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 26 Nov 2011 23:26:08 +0000
Subject: [issue12567] curses implementation of Unicode is wrong in Python 3
In-Reply-To: <1310682817.11.0.980195084883.issue12567@psf.upfronthosting.co.za>
Message-ID: <1322349968.78.0.131001788598.issue12567@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> This broke several Gentoo buildbots.

setup.py is unable to locate correctly curses.h. I added a hack to always search in /usr/include/ncursesw/. The hack is needed on Ubuntu 11.10 if you only have libncursesw5-dev but not libncursesw-dev for example.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12567>
_______________________________________

From report at bugs.python.org  Sun Nov 27 00:33:12 2011
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sat, 26 Nov 2011 23:33:12 +0000
Subject: [issue13475] Add '-p'/'--path0' command line option to override
	sys.path[0] initialisation
In-Reply-To: <1322181994.22.0.955887054946.issue13475@psf.upfronthosting.co.za>
Message-ID: <1322350392.9.0.56439876508.issue13475@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/issue13475>
_______________________________________

From report at bugs.python.org  Sun Nov 27 00:36:24 2011
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sat, 26 Nov 2011 23:36:24 +0000
Subject: [issue6135] subprocess seems to use local 8-bit encoding and gives no
	choice
In-Reply-To: <1243494524.57.0.870766192683.issue6135@psf.upfronthosting.co.za>
Message-ID: <1322350584.21.0.00932849508161.issue6135@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/issue6135>
_______________________________________

From report at bugs.python.org  Sun Nov 27 00:46:46 2011
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sat, 26 Nov 2011 23:46:46 +0000
Subject: [issue13466] new timezones
In-Reply-To: <1322078448.54.0.772868924392.issue13466@psf.upfronthosting.co.za>
Message-ID: <1322351206.57.0.174981032951.issue13466@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/issue13466>
_______________________________________

From report at bugs.python.org  Sun Nov 27 01:03:47 2011
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sun, 27 Nov 2011 00:03:47 +0000
Subject: [issue10318] "make altinstall" installs many files with incorrect
	shebangs
In-Reply-To: <1288926610.35.0.932494150274.issue10318@psf.upfronthosting.co.za>
Message-ID: <1322352227.65.0.880633598982.issue10318@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/issue10318>
_______________________________________

From report at bugs.python.org  Sun Nov 27 01:11:53 2011
From: report at bugs.python.org (Eric Snow)
Date: Sun, 27 Nov 2011 00:11:53 +0000
Subject: [issue13457] Use repr(module name) ImportErrors
In-Reply-To: <1321993736.11.0.640426182551.issue13457@psf.upfronthosting.co.za>
Message-ID: <1322352713.64.0.695439388256.issue13457@psf.upfronthosting.co.za>


Changes by Eric Snow <ericsnowcurrently at gmail.com>:


----------
nosy: +eric.snow

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13457>
_______________________________________

From report at bugs.python.org  Sun Nov 27 01:16:42 2011
From: report at bugs.python.org (Eric Snow)
Date: Sun, 27 Nov 2011 00:16:42 +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: <1322353002.81.0.690871643781.issue12307@psf.upfronthosting.co.za>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

Thanks, ?ric.  That's what I figured.  I asked because the PEPs page doesn't appear to reflect the change:

http://www.python.org/dev/peps/

I checked to be sure it fixed it before I submitted the patch.  That's why I asked about auto-rebuilding.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12307>
_______________________________________

From report at bugs.python.org  Sun Nov 27 01:21:44 2011
From: report at bugs.python.org (Julian Berman)
Date: Sun, 27 Nov 2011 00:21:44 +0000
Subject: [issue13437] Provide links to the source code for every module in the
	documentation
In-Reply-To: <1321748971.83.0.182041155467.issue13437@psf.upfronthosting.co.za>
Message-ID: <1322353304.47.0.371102522026.issue13437@psf.upfronthosting.co.za>


Julian Berman <Julian+Python.org at GrayVines.com> added the comment:

Well, if there's opposition I don't know how strongly I feel about this then, but I generally agree with you Ezio, if there's an occasion where 1) applies fixing the docs is certainly reasonable. If I'm checking the source though, it's not necessarily since the documentation is unclear, just that it's often easier to read code than English.

But, I guess if no one else feels it'd be helpful feel free to close this then.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13437>
_______________________________________

From report at bugs.python.org  Sun Nov 27 01:29:42 2011
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sun, 27 Nov 2011 00:29:42 +0000
Subject: [issue5319] stdout error at interpreter shutdown fails to return OS
	error status
In-Reply-To: <1235065081.04.0.732738239861.issue5319@psf.upfronthosting.co.za>
Message-ID: <1322353782.86.0.96261719965.issue5319@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/issue5319>
_______________________________________

From report at bugs.python.org  Sun Nov 27 01:29:50 2011
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sun, 27 Nov 2011 00:29:50 +0000
Subject: [issue13444] closed stdout causes error on stderr when the
	interpreter unconditionally flushes on shutdown
In-Reply-To: <1321888700.56.0.103830046171.issue13444@psf.upfronthosting.co.za>
Message-ID: <1322353790.99.0.0608492441034.issue13444@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/issue13444>
_______________________________________

From report at bugs.python.org  Sun Nov 27 01:30:41 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 27 Nov 2011 00:30:41 +0000
Subject: [issue13475] Add '-p'/'--path0' command line option to override
	sys.path[0] initialisation
In-Reply-To: <1322181994.22.0.955887054946.issue13475@psf.upfronthosting.co.za>
Message-ID: <1322353841.73.0.186396123132.issue13475@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Zbigniew posted a nice summary of some of the issues sys.path[0] autoinitialisation can cause to python-dev: http://mail.python.org/pipermail/python-dev/2011-November/114668.html

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13475>
_______________________________________

From report at bugs.python.org  Sun Nov 27 01:39:38 2011
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sun, 27 Nov 2011 00:39:38 +0000
Subject: [issue7111] abort when stderr is closed
In-Reply-To: <1255335800.65.0.921782203194.issue7111@psf.upfronthosting.co.za>
Message-ID: <1322354378.57.0.274556801654.issue7111@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/issue7111>
_______________________________________

From report at bugs.python.org  Sun Nov 27 02:08:18 2011
From: report at bugs.python.org (Meador Inge)
Date: Sun, 27 Nov 2011 01:08:18 +0000
Subject: [issue12618] py_compile cannot create files in current directory
In-Reply-To: <1311406971.17.0.312082121474.issue12618@psf.upfronthosting.co.za>
Message-ID: <1322356098.87.0.116895434666.issue12618@psf.upfronthosting.co.za>


Meador Inge <meadori at gmail.com> added the comment:

> we don?t know what people do with symlinks and relative paths out 
> there, so I?d prefer adding a safe special case* rather than always 
> calling abspath.  What do you think?

?ric, I agree.  I didn't know about the strange symlink + relative path 
behavior with 'os.path.normpath', but [1] cleared me up.  With that in
mind the special casing is OK.  I have attached an updated patch with
a unit test.

Also, this is not an issue for Python 2.7.  The 2.7 implementation
assumes any directories mentioned in the path already exist.  So, I
removed 2.7 from the affected versions.

[1] http://mail.python.org/pipermail/python-dev/2005-December/058452.html

----------
versions:  -Python 2.7
Added file: http://bugs.python.org/file23789/issue12618-1.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12618>
_______________________________________

From report at bugs.python.org  Sun Nov 27 02:36:23 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Sun, 27 Nov 2011 01:36:23 +0000
Subject: [issue13405] Add DTrace probes
In-Reply-To: <1321299726.66.0.343368151185.issue13405@psf.upfronthosting.co.za>
Message-ID: <1322357783.49.0.697522778944.issue13405@psf.upfronthosting.co.za>


Changes by Jes?s Cea Avi?n <jcea at jcea.es>:


----------
hgrepos: +92

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13405>
_______________________________________

From report at bugs.python.org  Sun Nov 27 03:08:18 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 27 Nov 2011 02:08:18 +0000
Subject: [issue2771] Test issue
In-Reply-To: <1210005645.74.0.283923986194.issue2771@psf.upfronthosting.co.za>
Message-ID: <E1RUUAD-0005zD-L8@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset fc1e01fe7f30 by Antoine Pitrou in branch 'default':
test hook with issue #2771.
http://hg.python.org/test/rev/fc1e01fe7f30

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2771>
_______________________________________

From report at bugs.python.org  Sun Nov 27 03:19:35 2011
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sun, 27 Nov 2011 02:19:35 +0000
Subject: [issue13400] packaging: build command should have options to control
	byte-compilation
In-Reply-To: <1321281623.21.0.854677924579.issue13400@psf.upfronthosting.co.za>
Message-ID: <1322360375.56.0.330196804527.issue13400@psf.upfronthosting.co.za>


Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com> added the comment:

I suggest to not use "pyc" and "pyo" in options, because ".pyc" and ".pyo" filename extensions are specific to a subset of Python implementations. Jython uses "$py.class" filename extension (module$py.class for module.py).

You could use --byte-compile, --no-byte-compile and --optimize-bytecode (or --optimize-byte-code) for both build and build_py commands.

Do settings from setup.cfg affect byte-compilation?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13400>
_______________________________________

From report at bugs.python.org  Sun Nov 27 03:26:02 2011
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sun, 27 Nov 2011 02:26:02 +0000
Subject: [issue13473] Add tests for files byte-compiled by distutils[2]
In-Reply-To: <1322145911.61.0.528651769931.issue13473@psf.upfronthosting.co.za>
Message-ID: <1322360762.64.0.596685719.issue13473@psf.upfronthosting.co.za>


Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com> added the comment:

What exactly do you consider to backport to distutils?

----------
nosy: +Arfrever

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13473>
_______________________________________

From report at bugs.python.org  Sun Nov 27 04:06:49 2011
From: report at bugs.python.org (Erik Tollerud)
Date: Sun, 27 Nov 2011 03:06:49 +0000
Subject: [issue13487] inspect.getmodule fails when module imports change
	sys.modules
Message-ID: <1322363209.24.0.0935380803772.issue13487@psf.upfronthosting.co.za>


New submission from Erik Tollerud <erik.tollerud at gmail.com>:

The inspect.getmodule function crashes if packages are installed that futz with sys.modules while they are being tested for module status or the like.  I'm not actually sure which packages are doing this, but the symptom is the for loop over sys.modules raises an Exception because it is modified while the loop is running.

This is *not* a problem in Python 2.x because sys.modules.items() returns a copy of the dictionary instead of an iterator, and 3.x changes that behavior.  The comment above the for loop makes it clear that the expected behavior is a copy rather than an iterator, so the attached patch corrects the problem by simply wrapping the items() call in list().

----------
components: Library (Lib)
files: getmodulefix.patch
keywords: patch
messages: 148438
nosy: Erik.Tollerud
priority: normal
severity: normal
status: open
title: inspect.getmodule fails when module imports change sys.modules
versions: Python 3.1, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file23790/getmodulefix.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13487>
_______________________________________

From report at bugs.python.org  Sun Nov 27 04:10:58 2011
From: report at bugs.python.org (Ilya Sandler)
Date: Sun, 27 Nov 2011 03:10:58 +0000
Subject: [issue13120] Default nosigint option to pdb.Pdb() prevents use in
	non-main thread
In-Reply-To: <1317935848.16.0.589862913408.issue13120@psf.upfronthosting.co.za>
Message-ID: <1322363458.63.0.77529451573.issue13120@psf.upfronthosting.co.za>


Ilya Sandler <ilya.sandler at gmail.com> added the comment:

I confirm the bug. But I don't think disabling Ctrl-C (SIGINT) handling by default is a good idea. Proper Ctrl-C support seems like a fundamental feature for a command line debugger. 

However, I think the bug is easily fixable w/o changing SIGINT handling. Basically, just put try/except around signal.signal, catch the ValueError and proceed. Would this approach solve your problem?

Patch attached.

PS. and here is a small program demonstrating the bug (just run it and execute "c" command at pdb prompt)

 import threading
 import pdb

 def start_pdb():
    pdb.Pdb().set_trace()
    x = 1
    y = 1

 t = threading.Thread( target=start_pdb)
 t.start()

----------
keywords: +patch
nosy: +isandler
Added file: http://bugs.python.org/file23791/thread_sigint.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13120>
_______________________________________

From report at bugs.python.org  Sun Nov 27 04:13:56 2011
From: report at bugs.python.org (Eric Snow)
Date: Sun, 27 Nov 2011 03:13:56 +0000
Subject: [issue13487] inspect.getmodule fails when module imports change
	sys.modules
In-Reply-To: <1322363209.24.0.0935380803772.issue13487@psf.upfronthosting.co.za>
Message-ID: <1322363636.81.0.495798192605.issue13487@psf.upfronthosting.co.za>


Changes by Eric Snow <ericsnowcurrently at gmail.com>:


----------
nosy: +eric.snow

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13487>
_______________________________________

From report at bugs.python.org  Sun Nov 27 05:15:32 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Sun, 27 Nov 2011 04:15:32 +0000
Subject: [issue13488] Some old preprocessors have problem with "#define" not
	in the first colum
Message-ID: <1322367332.5.0.427316218308.issue13488@psf.upfronthosting.co.za>


New submission from Jes?s Cea Avi?n <jcea at jcea.es>:

While working in dtrace probes, I have discovered that some old C preprocessors don't recognize "#define" if not in the first column.

File "Include/dynamic_annotations.h" has quite a few indented "#define". This is neither necessary neither regular practice in other files.

I delete the extra unneeded spaces.

----------
assignee: jcea
messages: 148440
nosy: jcea
priority: normal
severity: normal
status: open
title: Some old preprocessors have problem with "#define" not in the first colum
type: compile error
versions: Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13488>
_______________________________________

From report at bugs.python.org  Sun Nov 27 05:16:15 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Sun, 27 Nov 2011 04:16:15 +0000
Subject: [issue13488] Some old preprocessors have problem with "#define" not
	in the first column
In-Reply-To: <1322367332.5.0.427316218308.issue13488@psf.upfronthosting.co.za>
Message-ID: <1322367375.35.0.727075453017.issue13488@psf.upfronthosting.co.za>


Changes by Jes?s Cea Avi?n <jcea at jcea.es>:


----------
title: Some old preprocessors have problem with "#define" not in the first colum -> Some old preprocessors have problem with "#define" not in the first column

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13488>
_______________________________________

From report at bugs.python.org  Sun Nov 27 05:17:38 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 27 Nov 2011 04:17:38 +0000
Subject: [issue13488] Some old preprocessors have problem with "#define" not
	in the first column
In-Reply-To: <1322367332.5.0.427316218308.issue13488@psf.upfronthosting.co.za>
Message-ID: <E1RUWBM-0006OI-Vy@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 05979ae431fb by Jesus Cea in branch '3.2':
Closes issue #13488: Some old preprocessors have problem with #define not in the first column
http://hg.python.org/cpython/rev/05979ae431fb

New changeset 3a44640682c3 by Jesus Cea in branch 'default':
MERGE: Closes issue #13488: Some old preprocessors have problem with #define not in the first column
http://hg.python.org/cpython/rev/3a44640682c3

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13488>
_______________________________________

From report at bugs.python.org  Sun Nov 27 05:18:28 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Sun, 27 Nov 2011 04:18:28 +0000
Subject: [issue13488] Some old preprocessors have problem with "#define" not
	in the first column
In-Reply-To: <1322367332.5.0.427316218308.issue13488@psf.upfronthosting.co.za>
Message-ID: <1322367508.4.0.754345225237.issue13488@psf.upfronthosting.co.za>


Changes by Jes?s Cea Avi?n <jcea at jcea.es>:


----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13488>
_______________________________________

From report at bugs.python.org  Sun Nov 27 05:33:02 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Sun, 27 Nov 2011 04:33:02 +0000
Subject: [issue13405] Add DTrace probes
In-Reply-To: <1321299726.66.0.343368151185.issue13405@psf.upfronthosting.co.za>
Message-ID: <1322368382.02.0.221503004977.issue13405@psf.upfronthosting.co.za>


Changes by Jes?s Cea Avi?n <jcea at jcea.es>:


Added file: http://bugs.python.org/file23792/d7c58422eada.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13405>
_______________________________________

From report at bugs.python.org  Sun Nov 27 05:35:56 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Sun, 27 Nov 2011 04:35:56 +0000
Subject: [issue13405] Add DTrace probes
In-Reply-To: <1321299726.66.0.343368151185.issue13405@psf.upfronthosting.co.za>
Message-ID: <1322368556.01.0.723102722622.issue13405@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

Preview of the 3.3 patch. Includes work from issue #13488.

Work to do:

- "line" probe.

- "jstack()" helper.

- Instance names work, but using internal undocumented API. Change that. Probably keeping an "encoded" version of the name for each type. Memory use increase should be linear with number of types, not number of instances. Think about it.

- Verify memory use increase with "co->co_filename_encoded" and "co->co_name_encoded".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13405>
_______________________________________

From report at bugs.python.org  Sun Nov 27 06:01:50 2011
From: report at bugs.python.org (Shawn Ligocki)
Date: Sun, 27 Nov 2011 05:01:50 +0000
Subject: [issue13489] collections.Counter doc does not list added version
Message-ID: <1322370110.24.0.847856523325.issue13489@psf.upfronthosting.co.za>


New submission from Shawn Ligocki <sligocki at gmail.com>:

collections.Counter doc does not list added version:

http://docs.python.org/library/collections.html

It appears to only have been added in 2.7 (while the rest of the doc says it is valid since 2.4)

----------
assignee: docs at python
components: Documentation
messages: 148443
nosy: docs at python, sligocki
priority: normal
severity: normal
status: open
title: collections.Counter doc does not list added version
versions: Python 2.6, Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13489>
_______________________________________

From report at bugs.python.org  Sun Nov 27 06:18:25 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 27 Nov 2011 05:18:25 +0000
Subject: [issue13489] collections.Counter doc does not list added version
In-Reply-To: <1322370110.24.0.847856523325.issue13489@psf.upfronthosting.co.za>
Message-ID: <1322371105.19.0.0418949125885.issue13489@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

I see the note just after the sausage example and in the table at the top of the page, from the link you provided.

----------
nosy: +ezio.melotti
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed
versions:  -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13489>
_______________________________________

From report at bugs.python.org  Sun Nov 27 07:43:40 2011
From: report at bugs.python.org (Shawn Ligocki)
Date: Sun, 27 Nov 2011 06:43:40 +0000
Subject: [issue13489] collections.Counter doc does not list added version
In-Reply-To: <1322370110.24.0.847856523325.issue13489@psf.upfronthosting.co.za>
Message-ID: <1322376220.39.0.738602997173.issue13489@psf.upfronthosting.co.za>


Shawn Ligocki <sligocki at gmail.com> added the comment:

Ah, I see, it seems like that would be better suited directly after the section title, don't you?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13489>
_______________________________________

From report at bugs.python.org  Sun Nov 27 07:56:35 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 27 Nov 2011 06:56:35 +0000
Subject: [issue13489] collections.Counter doc does not list added version
In-Reply-To: <1322370110.24.0.847856523325.issue13489@psf.upfronthosting.co.za>
Message-ID: <1322376995.69.0.154408627167.issue13489@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

The convention is to put the note at the end of the section.  For this specific case the section about Counter is immediately followed by the documentation of its methods, so it's indeed hard to notice.  Maybe a different CSS would make this more evident.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13489>
_______________________________________

From report at bugs.python.org  Sun Nov 27 10:24:22 2011
From: report at bugs.python.org (holger krekel)
Date: Sun, 27 Nov 2011 09:24:22 +0000
Subject: [issue13490] broken downloads counting on pypi.python.org
Message-ID: <1322385862.72.0.235563901981.issue13490@psf.upfronthosting.co.za>


New submission from holger krekel <holger.krekel at gmail.com>:

Seems like pypi.python.org does not properly maintain download counters anymore, at least for a few packages i looked at like pytest,execnet,tox,nose.

----------
components: None
messages: 148447
nosy: hpk
priority: normal
severity: normal
status: open
title: broken downloads counting on pypi.python.org
type: behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13490>
_______________________________________

From report at bugs.python.org  Sun Nov 27 11:33:48 2011
From: report at bugs.python.org (Nebelhom)
Date: Sun, 27 Nov 2011 10:33:48 +0000
Subject: [issue13491] sqlite3 code adjustments
Message-ID: <1322390027.54.0.855055968281.issue13491@psf.upfronthosting.co.za>


New submission from Nebelhom <nebelhom at googlemail.com>:

The code examples for the sqlite3 library were in some cases non-functional.

With the help of Petri Lehtinen from core-mentorship, the following fixes are suggested.

NOTE: Last issue is not resolved yet, but suggestions have been made. Could you please review and decide what to do. The remaining issues have suggested fixes in the patch.

-------------------------------------------------------

Connection.create_function(name, num_params, func)

    Creates a user-defined function that you can later use from within SQL statements under the function name name. num_params is the number of parameters the function accepts, and func is a Python callable that is called as the SQL function.

    The function can return any of the types supported by SQLite: bytes, str, int, float and None.

    Example:

    import sqlite3
    import hashlib

    def md5sum(t):
        return hashlib.md5(t).hexdigest()

    con = sqlite3.connect(":memory:")
    con.create_function("md5", 1, md5sum)
    cur = con.cursor()
    cur.execute("select md5(?)", ("foo",))
    print(cur.fetchone()[0])

This script raises error:

Traceback (most recent call last):
  File "sqlexample.py", line 12, in <module>
    cur.execute("select md5(?)", ("foo",))
sqlite3.OperationalError: user-defined function raised exception

When md5sum is then run separately, the following traceback is given

>>> md5sum(("foo",))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "sqlexample.py", line 7, in md5sum
    return hashlib.md5(t).hexdigest()
TypeError: object supporting the buffer API required


Suggested fix:

Change ("foo") to (b"foo")

--------------------------------------------------------

Connection.text_factory?

    Using this attribute you can control what objects are returned for the TEXT data type. By default, this attribute is set to str and the sqlite3 module will return Unicode objects for TEXT. If you want to return bytestrings instead, you can set it to bytes.

    For efficiency reasons, there?s also a way to return str objects only for non-ASCII data, and bytes otherwise. To activate it, set this attribute to sqlite3.OptimizedUnicode.

    You can also set it to any other callable that accepts a single bytestring parameter and returns the resulting object.

    See the following example code for illustration:

    import sqlite3

    con = sqlite3.connect(":memory:")
    cur = con.cursor()

    # Create the table
    con.execute("create table person(lastname, firstname)")

    AUSTRIA = "\xd6sterreich"

    # by default, rows are returned as Unicode
    cur.execute("select ?", (AUSTRIA,))
    row = cur.fetchone()
    assert row[0] == AUSTRIA

    # but we can make sqlite3 always return bytestrings ...
    con.text_factory = str
    cur.execute("select ?", (AUSTRIA,))
    row = cur.fetchone()
    assert type(row[0]) == str
    # the bytestrings will be encoded in UTF-8, unless you stored garbage in the
    # database ...
    assert row[0] == AUSTRIA.encode("utf-8")

    # we can also implement a custom text_factory ...
    # here we implement one that will ignore Unicode characters that cannot be
    # decoded from UTF-8
    con.text_factory = lambda x: str(x, "utf-8", "ignore")
    cur.execute("select ?", ("this is latin1 and would normally create errors" +
                             "\xe4\xf6\xfc".encode("latin1"),))
    row = cur.fetchone()
    assert type(row[0]) == str

    # sqlite3 offers a built-in optimized text_factory that will return bytestring
    # objects, if the data is in ASCII only, and otherwise return unicode objects
    con.text_factory = sqlite3.OptimizedUnicode
    cur.execute("select ?", (AUSTRIA,))
    row = cur.fetchone()
    assert type(row[0]) == str

    cur.execute("select ?", ("Germany",))
    row = cur.fetchone()
    assert type(row[0]) == str

The code example returns the following error traceback

Traceback (most recent call last):
  File "sqlexample.py", line 23, in <module>
    assert row[0] == AUSTRIA.encode("utf-8")
AssertionError

Suggested fixes:
- #Create table... -> removed as not used
- all "assert type ... str" changed to "assert type ... bytes"
- # we can also implement... code block removed
- add ":meth:`[parameters]` needs to be a bytes type otherwise a TypeError will be raised." to the doc

-----------------------------------------------------------------------------
Cursor.executemany(sql, seq_of_parameters)

    Executes an SQL command against all parameter sequences or mappings found in the sequence sql. The sqlite3 module also allows using an iterator yielding parameters instead of a sequence.

    Here?s a shorter example using a generator:

    import sqlite3

    def char_generator():
        import string
        for c in string.letters[:26]:
            yield (c,)

    con = sqlite3.connect(":memory:")
    cur = con.cursor()
    cur.execute("create table characters(c)")

    cur.executemany("insert into characters(c) values (?)", char_generator())

    cur.execute("select c from characters")
    print(cur.fetchall())

Traceback (most recent call last):
  File "sqlexample.py", line 12, in <module>
    cur.executemany("insert into characters(c) values (?)", char_generator())
  File "sqlexample.py", line 5, in char_generator
    for c in string.letters[:26]:
AttributeError: 'module' object has no attribute 'letters'

suggested fixes
- import string outside function
- string.letters changed to string.ascii_letters_lowercase

-------------------------------------------------------------------------------

11.6.5.3. Converting SQLite values to custom Python types?

Writing an adapter lets you send custom Python types to SQLite. But to make it really useful we need to make the Python to SQLite to Python roundtrip work.

Enter converters.

Let?s go back to the Point class. We stored the x and y coordinates separated via semicolons as strings in SQLite.

First, we?ll define a converter function that accepts the string as a parameter and constructs a Point object from it.

Note

Converter functions always get called with a string, no matter under which data type you sent the value to SQLite.

def convert_point(s):
    x, y = map(float, s.split(";"))
    return Point(x, y)

Now you need to make the sqlite3 module know that what you select from the database is actually a point. There are two ways of doing this:

    * Implicitly via the declared type
    * Explicitly via the column name

Both ways are described in section Module functions and constants, in the entries for the constants PARSE_DECLTYPES and PARSE_COLNAMES.

The following example illustrates both approaches.

import sqlite3

class Point:
    def __init__(self, x, y):
        self.x, self.y = x, y

    def __repr__(self):
        return "(%f;%f)" % (self.x, self.y)

def adapt_point(point):
    return "%f;%f" % (point.x, point.y)

def convert_point(s):
    x, y = list(map(float, s.split(";")))
    return Point(x, y)

# Register the adapter
sqlite3.register_adapter(Point, adapt_point)

# Register the converter
sqlite3.register_converter("point", convert_point)

p = Point(4.0, -3.2)

#########################
# 1) Using declared types
con = sqlite3.connect(":memory:", detect_types=sqlite3.PARSE_DECLTYPES)
cur = con.cursor()
cur.execute("create table test(p point)")

cur.execute("insert into test(p) values (?)", (p,))
cur.execute("select p from test")
print("with declared types:", cur.fetchone()[0])
cur.close()
con.close()

#######################
# 1) Using column names
con = sqlite3.connect(":memory:", detect_types=sqlite3.PARSE_COLNAMES)
cur = con.cursor()
cur.execute("create table test(p)")

cur.execute("insert into test(p) values (?)", (p,))
cur.execute('select p as "p [point]" from test')
print("with column names:", cur.fetchone()[0])
cur.close()
con.close()

The given code gives the following error:

Traceback (most recent call last):
  File "sqlexample.py", line 32, in <module>
    cur.execute("select p from test")
  File "sqlexample.py", line 14, in convert_point
    x, y = list(map(float, s.split(";")))
TypeError: Type str doesn't support the buffer API

suggested fixes:

def adapt_point(point):
   return ("%f;%f" % (point.x, point.y)).encode('ascii')

def convert_point(s):
   x, y = list(map(float, s.split(b";")))
   return Point(x, y)

------------------------------------------------------------------------------

11.6.7.2. Accessing columns by name instead of by index?

One useful feature of the sqlite3 module is the built-in sqlite3.Row class designed to be used as a row factory.

Rows wrapped with this class can be accessed both by index (like tuples) and case-insensitively by name:

import sqlite3

con = sqlite3.connect("mydb")
con.row_factory = sqlite3.Row

cur = con.cursor()
cur.execute("select name_last, age from people")
for row in cur:
    assert row[0] == row["name_last"]
    assert row["name_last"] == row["nAmE_lAsT"]
    assert row[1] == row["age"]
    assert row[1] == row["AgE"]

Gives following error:

Traceback (most recent call last):
  File "sqlexample.py", line 7, in <module>
    cur.execute("select name_last, age from people")
sqlite3.OperationalError: no such table: people

"Same error in 11.6.3 Cursor.execute() description"

Suggested fixes:
- None yet. I feel these should be standalone examples out of the box. the sqlite3 includes have a "createdb.py" file which would create the tablem but it is not referenced in the documentary. I do not know the reasoning behind this, but I would like to have standalone examples in these cases.

----------
assignee: docs at python
components: Documentation
files: sqlite_code_update.patch
keywords: patch
messages: 148448
nosy: Nebelhom, docs at python
priority: normal
severity: normal
status: open
title: sqlite3 code adjustments
versions: Python 3.3
Added file: http://bugs.python.org/file23793/sqlite_code_update.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13491>
_______________________________________

From report at bugs.python.org  Sun Nov 27 11:57:34 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sun, 27 Nov 2011 10:57:34 +0000
Subject: [issue7111] abort when stderr is closed
In-Reply-To: <1255335800.65.0.921782203194.issue7111@psf.upfronthosting.co.za>
Message-ID: <1322391454.34.0.832001251191.issue7111@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

(No Rietveld link):

+is_valid_fd(int fd)
[...]
+    dummy_fd = dup(fd);
+    if (dummy_fd < 0)
+        return 0;
+    close(dummy_fd);

Why not use fstat() instead (does Windows have fstat()? And dup()?).

+    @unittest.skipIf(os.name == 'nt', "test needs POSIX semantics")
+    def test_no_stdin(self):

It would maybe be more direct with skipUnless(os.name == 'posix').

Finally, it's not that important, but it could maybe be possible to factorize the code, i.e. make a helper function that takes a list of streams and defines the preexec() function and code to test those streams, and then just call:

def test_no_stdin(self):
    out, err = self._test_with_closed_streams(['stdin'])
    [...]

def test_no_streams(self):
    out, err = self._test_with_closed_streams(['stdin', 'stdout', 'stderr'])
    [...]

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7111>
_______________________________________

From report at bugs.python.org  Sun Nov 27 12:51:35 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 27 Nov 2011 11:51:35 +0000
Subject: [issue13415] del os.environ[key] ignores errors
In-Reply-To: <1321481687.96.0.070295281604.issue13415@psf.upfronthosting.co.za>
Message-ID: <E1RUdGg-0004FN-2m@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 26275a1c229c by Charles-Fran?ois Natali in branch '3.2':
Issue #13415: Test in configure if unsetenv() has a return value or not.
http://hg.python.org/cpython/rev/26275a1c229c

New changeset bceb6aea8554 by Charles-Fran?ois Natali in branch '3.2':
Issue #13415: Skip test_os.test_unset_error on FreeBSD and OS X.
http://hg.python.org/cpython/rev/bceb6aea8554

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13415>
_______________________________________

From report at bugs.python.org  Sun Nov 27 13:05:51 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 27 Nov 2011 12:05:51 +0000
Subject: [issue13415] del os.environ[key] ignores errors
In-Reply-To: <1321481687.96.0.070295281604.issue13415@psf.upfronthosting.co.za>
Message-ID: <E1RUdUT-0005bV-W3@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 11bbeaf03894 by Charles-Fran?ois Natali in branch '2.7':
Issue #13415: Test in configure if unsetenv() has a return value or not.
http://hg.python.org/cpython/rev/11bbeaf03894

New changeset 99f5a0475ead by Charles-Fran?ois Natali in branch '2.7':
Issue #13415: Skip test_os.test_unset_error on FreeBSD and OS X.
http://hg.python.org/cpython/rev/99f5a0475ead

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13415>
_______________________________________

From report at bugs.python.org  Sun Nov 27 16:04:29 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Sun, 27 Nov 2011 15:04:29 +0000
Subject: [issue12567] curses implementation of Unicode is wrong in Python 3
In-Reply-To: <1310682817.11.0.980195084883.issue12567@psf.upfronthosting.co.za>
Message-ID: <1322406269.78.0.314384899327.issue12567@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

I am still concerned about the compilation warning in OpenIndiana buildbots :-(

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12567>
_______________________________________

From report at bugs.python.org  Sun Nov 27 17:57:28 2011
From: report at bugs.python.org (Darren Dale)
Date: Sun, 27 Nov 2011 16:57: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: <1322413048.25.0.536385158287.issue11610@psf.upfronthosting.co.za>


Darren Dale <dsdale24 at gmail.com> added the comment:

I'll bump this one last time.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11610>
_______________________________________

From report at bugs.python.org  Sun Nov 27 18:18:55 2011
From: report at bugs.python.org (Meador Inge)
Date: Sun, 27 Nov 2011 17:18:55 +0000
Subject: [issue13487] inspect.getmodule fails when module imports change
	sys.modules
In-Reply-To: <1322363209.24.0.0935380803772.issue13487@psf.upfronthosting.co.za>
Message-ID: <1322414335.16.0.0842852842207.issue13487@psf.upfronthosting.co.za>


Changes by Meador Inge <meadori at gmail.com>:


----------
nosy: +meador.inge

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13487>
_______________________________________

From report at bugs.python.org  Sun Nov 27 18:19:28 2011
From: report at bugs.python.org (Meador Inge)
Date: Sun, 27 Nov 2011 17:19:28 +0000
Subject: [issue13120] Default nosigint option to pdb.Pdb() prevents use in
	non-main thread
In-Reply-To: <1317935848.16.0.589862913408.issue13120@psf.upfronthosting.co.za>
Message-ID: <1322414368.54.0.171234024008.issue13120@psf.upfronthosting.co.za>


Changes by Meador Inge <meadori at gmail.com>:


----------
nosy: +meador.inge

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13120>
_______________________________________

From report at bugs.python.org  Sun Nov 27 18:41:18 2011
From: report at bugs.python.org (Catalin Iacob)
Date: Sun, 27 Nov 2011 17:41:18 +0000
Subject: [issue9116] test_capi.test_no_FatalError_infinite_loop crash on
	Windows
In-Reply-To: <1277827107.42.0.0793977492373.issue9116@psf.upfronthosting.co.za>
Message-ID: <1322415678.16.0.888226572073.issue9116@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/issue9116>
_______________________________________

From report at bugs.python.org  Sun Nov 27 18:41:56 2011
From: report at bugs.python.org (Catalin Iacob)
Date: Sun, 27 Nov 2011 17:41:56 +0000
Subject: [issue5619] Pass MS CRT debug flags into subprocesses
In-Reply-To: <1238472783.0.0.132667741337.issue5619@psf.upfronthosting.co.za>
Message-ID: <1322415716.87.0.651366402357.issue5619@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/issue5619>
_______________________________________

From report at bugs.python.org  Sun Nov 27 18:42:18 2011
From: report at bugs.python.org (Catalin Iacob)
Date: Sun, 27 Nov 2011 17:42:18 +0000
Subject: [issue11732] Skip decorator for tests requiring manual intervention
	on Windows
In-Reply-To: <1301604811.48.0.519862680053.issue11732@psf.upfronthosting.co.za>
Message-ID: <1322415738.37.0.54559011081.issue11732@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/issue11732>
_______________________________________

From report at bugs.python.org  Sun Nov 27 19:06:28 2011
From: report at bugs.python.org (Catalin Iacob)
Date: Sun, 27 Nov 2011 18:06:28 +0000
Subject: [issue11732] Skip decorator for tests requiring manual intervention
	on Windows
In-Reply-To: <1301604811.48.0.519862680053.issue11732@psf.upfronthosting.co.za>
Message-ID: <1322417188.56.0.617274525736.issue11732@psf.upfronthosting.co.za>


Catalin Iacob <iacobcatalin at gmail.com> added the comment:

To avoid messing with system registry settings it sounds like WerRegisterRuntimeExceptionModule could also work, at least on Windows7 http://msdn.microsoft.com/en-us/library/windows/desktop1/dd408167%28v=VS.85%29.aspx

There could be a dll which would do nothing when receiving the crash report for expected crashes (test_capi and test_faulthandler). WerRegisterRuntimeExceptionModule doesn't exist in the headers of the SDK that comes with VS2008 but it could be retrieved at runtime with GetProcAddress. It's more work than the registry setting but seems cleaner since it avoids changing system settings.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11732>
_______________________________________

From report at bugs.python.org  Sun Nov 27 19:10:14 2011
From: report at bugs.python.org (Brian Curtin)
Date: Sun, 27 Nov 2011 18:10:14 +0000
Subject: [issue11732] Skip decorator for tests requiring manual intervention
	on Windows
In-Reply-To: <1301604811.48.0.519862680053.issue11732@psf.upfronthosting.co.za>
Message-ID: <1322417414.96.0.37498448882.issue11732@psf.upfronthosting.co.za>


Brian Curtin <brian at python.org> added the comment:

That would certainly be preferable when available on Windows 7. I'll look into how we can incorporate that.

Thanks for the idea!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11732>
_______________________________________

From report at bugs.python.org  Sun Nov 27 19:27:52 2011
From: report at bugs.python.org (Meador Inge)
Date: Sun, 27 Nov 2011 18:27:52 +0000
Subject: [issue7611] shlex not posix compliant when parsing "foo#bar"
In-Reply-To: <1262248963.08.0.673944744724.issue7611@psf.upfronthosting.co.za>
Message-ID: <1322418472.06.0.268850915269.issue7611@psf.upfronthosting.co.za>


Meador Inge <meadori at gmail.com> added the comment:

Here a some of the relevant links from POSIX 2008:

   1. Shell Command Language - http://pubs.opengroup.org/onlinepubs/9699919799/idx/shell.html
   3. Shell Command Language Rationale - http://pubs.opengroup.org/onlinepubs/9699919799/xrat/V4_xcu_chap02.html

Sections 2.3 (http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_03) and 2.10 (http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_10) of [1] are particularly relevant.

----------
nosy: +meador.inge

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7611>
_______________________________________

From report at bugs.python.org  Sun Nov 27 21:00:46 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 27 Nov 2011 20:00:46 +0000
Subject: [issue13120] Default nosigint option to pdb.Pdb() prevents use in
	non-main thread
In-Reply-To: <1317935848.16.0.589862913408.issue13120@psf.upfronthosting.co.za>
Message-ID: <1322424046.42.0.795531516672.issue13120@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +georg.brandl
stage:  -> patch review
versions: +Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13120>
_______________________________________

From report at bugs.python.org  Sun Nov 27 21:07:26 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 27 Nov 2011 20:07:26 +0000
Subject: [issue13490] broken downloads counting on pypi.python.org
In-Reply-To: <1322385862.72.0.235563901981.issue13490@psf.upfronthosting.co.za>
Message-ID: <1322424446.25.0.911175781331.issue13490@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13490>
_______________________________________

From report at bugs.python.org  Sun Nov 27 21:09:10 2011
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 27 Nov 2011 20:09:10 +0000
Subject: [issue13120] Default nosigint option to pdb.Pdb() prevents use in
	non-main thread
In-Reply-To: <1317935848.16.0.589862913408.issue13120@psf.upfronthosting.co.za>
Message-ID: <1322424550.81.0.929418676711.issue13120@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Patch seems fine to me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13120>
_______________________________________

From report at bugs.python.org  Sun Nov 27 21:42:45 2011
From: report at bugs.python.org (Matthew Woodcraft)
Date: Sun, 27 Nov 2011 20:42:45 +0000
Subject: [issue13475] Add '-p'/'--path0' command line option to override
	sys.path[0] initialisation
In-Reply-To: <1322181994.22.0.955887054946.issue13475@psf.upfronthosting.co.za>
Message-ID: <1322426565.32.0.719281433091.issue13475@psf.upfronthosting.co.za>


Matthew Woodcraft <matthew at woodcraft.me.uk> added the comment:

The proposed --nopath0 option is something I've wished I had in the past.

If this is added, it would be good if it could be given a single-letter form too, because it's an option that would be useful in #! lines (they don't reliably support using more than one command-line argument, and single-letter switches can be combined while long-form ones can't).

----------
nosy: +mattheww

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13475>
_______________________________________

From report at bugs.python.org  Sun Nov 27 22:46:57 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sun, 27 Nov 2011 21:46:57 +0000
Subject: [issue13487] inspect.getmodule fails when module imports change
	sys.modules
In-Reply-To: <1322363209.24.0.0935380803772.issue13487@psf.upfronthosting.co.za>
Message-ID: <1322430417.18.0.344605838663.issue13487@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

You are certainly right, but I wonder how this can happen.
Are there modules which import something just by looking at them?
Or is is some race condition due to another running thread?

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13487>
_______________________________________

From report at bugs.python.org  Sun Nov 27 23:14:18 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 27 Nov 2011 22:14:18 +0000
Subject: [issue7111] abort when stderr is closed
In-Reply-To: <1322391454.34.0.832001251191.issue7111@psf.upfronthosting.co.za>
Message-ID: <1322431756.3284.1.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> +is_valid_fd(int fd)
> [...]
> +    dummy_fd = dup(fd);
> +    if (dummy_fd < 0)
> +        return 0;
> +    close(dummy_fd);
> 
> Why not use fstat() instead (does Windows have fstat()? And dup()?).

Windows has dup(), but no fstat().

> +    @unittest.skipIf(os.name == 'nt', "test needs POSIX semantics")
> +    def test_no_stdin(self):
> 
> It would maybe be more direct with skipUnless(os.name == 'posix').

Hmm, indeed.

> Finally, it's not that important, but it could maybe be possible to
> factorize the code, i.e. make a helper function that takes a list of
> streams and defines the preexec() function and code to test those
> streams, and then just call:

Ah, indeed perhaps.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7111>
_______________________________________

From report at bugs.python.org  Sun Nov 27 23:25:41 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 27 Nov 2011 22:25:41 +0000
Subject: [issue7111] abort when stderr is closed
In-Reply-To: <1255335800.65.0.921782203194.issue7111@psf.upfronthosting.co.za>
Message-ID: <1322432741.45.0.212792100211.issue7111@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Updated patch.

----------
Added file: http://bugs.python.org/file23794/nostdio2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7111>
_______________________________________

From report at bugs.python.org  Sun Nov 27 23:48:20 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 27 Nov 2011 22:48:20 +0000
Subject: [issue13490] broken downloads counting on pypi.python.org
In-Reply-To: <1322385862.72.0.235563901981.issue13490@psf.upfronthosting.co.za>
Message-ID: <1322434100.12.0.354618380604.issue13490@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Thanks for the report; this is now fixed.

Please use the PyPI bug tracker for such reports in the future, which can be found by following "Bug reports" on pypi.python.org, to http://sourceforge.net/tracker/?group_id=66150&atid=513503

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13490>
_______________________________________

From report at bugs.python.org  Mon Nov 28 00:26:52 2011
From: report at bugs.python.org (Meador Inge)
Date: Sun, 27 Nov 2011 23:26:52 +0000
Subject: [issue13120] Default nosigint option to pdb.Pdb() prevents use in
	non-main thread
In-Reply-To: <1317935848.16.0.589862913408.issue13120@psf.upfronthosting.co.za>
Message-ID: <1322436412.3.0.282881587889.issue13120@psf.upfronthosting.co.za>


Meador Inge <meadori at gmail.com> added the comment:

Normally a test case is needed.  I tried the following:

diff --git a/Lib/test/test_pdb.py b/Lib/test/test_pdb.py
--- a/Lib/test/test_pdb.py
+++ b/Lib/test/test_pdb.py
@@ -595,6 +595,25 @@ def test_pdb_run_with_code_object():
     (Pdb) continue
     """
 
+def test_pdb_continue_in_thread():
+    """Testing the ability to continue from a non-main thread.
+
+    >>> import threading
+    >>>
+    >>> def start_pdb():
+    ...     import pdb
+    ...     pdb.Pdb().set_trace()
+    ...     x = 1
+    ...     y = 1
+    ...
+
+    >>> with PdbTestInput(['continue']):
+    ...    t = threading.Thread(target=start_pdb)
+    ...    t.start()
+    > <doctest test.test_pdb.test_pdb_continue_in_thread[1]>(4)start_pdb()
+    -> x = 1
+    (Pdb) continue
+"""

but 'doctests' doesn't seem to play nicely with threading.  The pdb testsuite fails with:


[meadori at motherbrain cpython]$ ./python -m test test_pdb
[1/1] test_pdb
**********************************************************************
File "/home/meadori/code/python/cpython/Lib/test/test_pdb.py", line 610, in test.test_pdb.test_pdb_continue_in_thread
Failed example:
    with PdbTestInput(['continue']):
       t = threading.Thread(target=start_pdb)
       t.start()
Expected:
    > <doctest test.test_pdb.test_pdb_continue_in_thread[1]>(4)start_pdb()
    -> x = 1
    (Pdb) continue
Got nothing
**********************************************************************
File "/home/meadori/code/python/cpython/Lib/test/test_pdb.py", line 34, in test.test_pdb.test_pdb_displayhook
Failed example:
    def test_function(foo, bar):
        import pdb; pdb.Pdb(nosigint=True).set_trace()
        pass
Expected nothing
Got:
    > <doctest test.test_pdb.test_pdb_continue_in_thread[1]>(4)start_pdb()
Exception in thread Thread-1:

It looks like the output is going to the wrong test.

Anyone else have test ideas?  If not, then I guess it is OK to commit as is.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13120>
_______________________________________

From report at bugs.python.org  Mon Nov 28 00:55:01 2011
From: report at bugs.python.org (A.M. Kuchling)
Date: Sun, 27 Nov 2011 23:55:01 +0000
Subject: [issue13443] wrong links and examples in the functional HOWTO
In-Reply-To: <1321850404.45.0.767133152656.issue13443@psf.upfronthosting.co.za>
Message-ID: <1322438101.35.0.713724350459.issue13443@psf.upfronthosting.co.za>


A.M. Kuchling <lists at amk.ca> added the comment:

Yes, linking to the functional module was to point people to a module that might be useful, even if it's not in the stdlib.  A numeric processing or socket handling HOWTO would also pretty much have to link to non-stdlib sources.  The purpose of documentation is to be useful to the reader, so I think if linking to something external would be reasonably useful, we should do it.

Another motivation for linking was to provide alternative explanations; if the reader finds the Functional HOWTO boring or too superficial or too complicated, maybe an alternative discussion like Mertz's "Text Processing" will fit their brain better.  (At least until those alternative sources become so outdated that they're useless...)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13443>
_______________________________________

From report at bugs.python.org  Mon Nov 28 02:14:54 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Mon, 28 Nov 2011 01:14:54 +0000
Subject: [issue13405] Add DTrace probes
In-Reply-To: <1321299726.66.0.343368151185.issue13405@psf.upfronthosting.co.za>
Message-ID: <1322442894.92.0.881858681527.issue13405@psf.upfronthosting.co.za>


Changes by Jes?s Cea Avi?n <jcea at jcea.es>:


Added file: http://bugs.python.org/file23795/01f206595d16.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13405>
_______________________________________

From report at bugs.python.org  Mon Nov 28 02:15:38 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Mon, 28 Nov 2011 01:15:38 +0000
Subject: [issue13405] Add DTrace probes
In-Reply-To: <1321299726.66.0.343368151185.issue13405@psf.upfronthosting.co.za>
Message-ID: <1322442938.57.0.751456666492.issue13405@psf.upfronthosting.co.za>


Changes by Jes?s Cea Avi?n <jcea at jcea.es>:


Removed file: http://bugs.python.org/file23792/d7c58422eada.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13405>
_______________________________________

From report at bugs.python.org  Mon Nov 28 02:17:45 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Mon, 28 Nov 2011 01:17:45 +0000
Subject: [issue13405] Add DTrace probes
In-Reply-To: <1321299726.66.0.343368151185.issue13405@psf.upfronthosting.co.za>
Message-ID: <1322443065.82.0.980417068461.issue13405@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

New 3.3 version.

- Use the cached UTF8 of strings inside the interpreter, instead of managing the details manually.

- "line" probe works, even with "computed-gotos" optimization.

The only missing feature now, compared with 2.7 version, is the "stack" helper. Working on it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13405>
_______________________________________

From report at bugs.python.org  Mon Nov 28 02:34:57 2011
From: report at bugs.python.org (Meador Inge)
Date: Mon, 28 Nov 2011 01:34:57 +0000
Subject: [issue11107] Cache constant "slice" instances
In-Reply-To: <1296761121.69.0.66743926851.issue11107@psf.upfronthosting.co.za>
Message-ID: <1322444097.27.0.824209993019.issue11107@psf.upfronthosting.co.za>


Changes by Meador Inge <meadori at gmail.com>:


----------
nosy: +meador.inge

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11107>
_______________________________________

From report at bugs.python.org  Mon Nov 28 02:38:15 2011
From: report at bugs.python.org (Meador Inge)
Date: Mon, 28 Nov 2011 01:38:15 +0000
Subject: [issue12627] Implement PEP 394: The "python" Command on Unix-Like
	Systems
In-Reply-To: <1311474695.62.0.740113282168.issue12627@psf.upfronthosting.co.za>
Message-ID: <1322444295.05.0.942983179572.issue12627@psf.upfronthosting.co.za>


Changes by Meador Inge <meadori at gmail.com>:


----------
nosy: +meador.inge

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12627>
_______________________________________

From report at bugs.python.org  Mon Nov 28 02:44:23 2011
From: report at bugs.python.org (Meador Inge)
Date: Mon, 28 Nov 2011 01:44:23 +0000
Subject: [issue2775] Implement PEP 3108
In-Reply-To: <1210097469.77.0.880435072777.issue2775@psf.upfronthosting.co.za>
Message-ID: <1322444663.02.0.835532645285.issue2775@psf.upfronthosting.co.za>


Changes by Meador Inge <meadori at gmail.com>:


----------
nosy: +meador.inge

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2775>
_______________________________________

From report at bugs.python.org  Mon Nov 28 05:08:36 2011
From: report at bugs.python.org (Ilya Sandler)
Date: Mon, 28 Nov 2011 04:08:36 +0000
Subject: [issue13120] Default nosigint option to pdb.Pdb() prevents use in
	non-main thread
In-Reply-To: <1317935848.16.0.589862913408.issue13120@psf.upfronthosting.co.za>
Message-ID: <1322453316.63.0.422194515257.issue13120@psf.upfronthosting.co.za>


Ilya Sandler <ilya.sandler at gmail.com> added the comment:

I think stuff like this can only be tested out-of-process.

So I added an out-of-process test to test_pdb.py. The test passes with the fixed pdb.py. (and fails with the original one).

Patch for the test attached.

----------
Added file: http://bugs.python.org/file23796/test_pdb.py.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13120>
_______________________________________

From report at bugs.python.org  Mon Nov 28 07:23:54 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 28 Nov 2011 06:23:54 +0000
Subject: [issue13415] del os.environ[key] ignores errors
In-Reply-To: <1321481687.96.0.070295281604.issue13415@psf.upfronthosting.co.za>
Message-ID: <E1RUud6-0005rz-Pl@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset bf51e32b2a81 by Victor Stinner in branch 'default':
Issue #13415: test_curses skips unencodable characters
http://hg.python.org/cpython/rev/bf51e32b2a81

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13415>
_______________________________________

From report at bugs.python.org  Mon Nov 28 07:31:06 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 28 Nov 2011 06:31:06 +0000
Subject: [issue12567] curses implementation of Unicode is wrong in Python 3
In-Reply-To: <1310682817.11.0.980195084883.issue12567@psf.upfronthosting.co.za>
Message-ID: <1322461866.07.0.473008683406.issue12567@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Compile output on OpenSolaris:

Consider setting $PYTHONHOME to <prefix>[:<exec_prefix>]
ld: fatal: file /usr/local/lib/libncursesw.so: wrong ELF class: ELFCLASS32
ld: fatal: file processing errors. No output written to build/lib.solaris-2.11-i86pc-3.3-pydebug/readline.so
collect2: ld returned 1 exit status
/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Modules/_cursesmodule.c:279: error: expected declaration specifiers or '...' before 'cchar_t'
/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Modules/_cursesmodule.c: In function 'PyCurses_ConvertToCchar_t':
/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Modules/_cursesmodule.c:298: error: 'wch' undeclared (first use in this function)
/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Modules/_cursesmodule.c:298: error: (Each undeclared identifier is reported only once
/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Modules/_cursesmodule.c:298: error: for each function it appears in.)
/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Modules/_cursesmodule.c: In function 'PyCursesWindow_AddCh':
/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Modules/_cursesmodule.c:584: error: 'cchar_t' undeclared (first use in this function)
/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Modules/_cursesmodule.c:584: error: expected ';' before 'wch'
/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Modules/_cursesmodule.c:618: error: 'wch' undeclared (first use in this function)
/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Modules/_cursesmodule.c:618: error: too many arguments to function 'PyCurses_ConvertToCchar_t'
/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Modules/_cursesmodule.c:623: warning: implicit declaration of function 'mvwadd_wch'
/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Modules/_cursesmodule.c:625: warning: implicit declaration of function 'wadd_wch'
/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Modules/_cursesmodule.c: In function 'PyCursesWindow_AddStr':
/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Modules/_cursesmodule.c:702: warning: implicit declaration of function 'mvwaddwstr'
/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Modules/_cursesmodule.c:704: warning: implicit declaration of function 'waddwstr'
/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Modules/_cursesmodule.c: In function 'PyCursesWindow_AddNStr':
/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Modules/_cursesmodule.c:779: warning: implicit declaration of function 'mvwaddnwstr'
/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Modules/_cursesmodule.c:781: warning: implicit declaration of function 'waddnwstr'
/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Modules/_cursesmodule.c: In function 'PyCursesWindow_Get_WCh':
/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Modules/_cursesmodule.c:1187: warning: implicit declaration of function 'wget_wch'
/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Modules/_cursesmodule.c:1194: warning: implicit declaration of function 'mvwget_wch'
/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Modules/_cursesmodule.c: In function 'PyCursesWindow_InsStr':
/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Modules/_cursesmodule.c:1468: warning: implicit declaration of function 'mvwins_wstr'
/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Modules/_cursesmodule.c:1470: warning: implicit declaration of function 'wins_wstr'
/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Modules/_cursesmodule.c: In function 'PyCursesWindow_InsNStr':
/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Modules/_cursesmodule.c:1546: warning: implicit declaration of function 'mvwins_nwstr'
/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Modules/_cursesmodule.c:1548: warning: implicit declaration of function 'wins_nwstr'
/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Modules/_cursesmodule.c: In function 'PyCurses_Unget_Wch':
/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Modules/_cursesmodule.c:3130: warning: implicit declaration of function 'unget_wch'
ld: fatal: file /usr/local/lib/libpanelw.so: wrong ELF class: ELFCLASS32
ld: fatal: file /usr/local/lib/libncursesw.so: wrong ELF class: ELFCLASS32
ld: fatal: file processing errors. No output written to build/lib.solaris-2.11-i86pc-3.3-pydebug/_curses_panel.so
collect2: ld returned 1 exit status

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12567>
_______________________________________

From report at bugs.python.org  Mon Nov 28 07:33:13 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 28 Nov 2011 06:33:13 +0000
Subject: [issue13415] del os.environ[key] ignores errors
In-Reply-To: <1321481687.96.0.070295281604.issue13415@psf.upfronthosting.co.za>
Message-ID: <1322461993.9.0.925471255376.issue13415@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
Removed message: http://bugs.python.org/msg148467

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13415>
_______________________________________

From report at bugs.python.org  Mon Nov 28 07:33:48 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 28 Nov 2011 06:33:48 +0000
Subject: [issue12567] curses implementation of Unicode is wrong in Python 3
In-Reply-To: <1310682817.11.0.980195084883.issue12567@psf.upfronthosting.co.za>
Message-ID: <1322462028.25.0.41876407884.issue12567@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

New changeset bf51e32b2a81 by Victor Stinner in branch 'default':
Issue #13415: test_curses skips unencodable characters
http://hg.python.org/cpython/rev/bf51e32b2a81

(Oops, I copy-pasted the issue number from my previous commit, and the issue number was wrong...)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12567>
_______________________________________

From report at bugs.python.org  Mon Nov 28 09:42:53 2011
From: report at bugs.python.org (=?utf-8?b?U8OpYmFzdGllbiBTYWJsw6k=?=)
Date: Mon, 28 Nov 2011 08:42:53 +0000
Subject: [issue2286] Stack overflow exception caused by test_marshal on
	Windows x64
In-Reply-To: <1205499475.78.0.0465561571315.issue2286@psf.upfronthosting.co.za>
Message-ID: <1322469773.72.0.0200141487774.issue2286@psf.upfronthosting.co.za>


S?bastien Sabl? <sable at users.sourceforge.net> added the comment:

Thanks Terry, I am aware of that.
We are working on making Python work with VS2010 in issue 13210.

I will check with the py3k branch soon and report here if the same problem applies.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2286>
_______________________________________

From report at bugs.python.org  Mon Nov 28 10:18:32 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 28 Nov 2011 09:18:32 +0000
Subject: [issue13481] Use an accurate clock in timeit
In-Reply-To: <1322265721.78.0.0567796730825.issue13481@psf.upfronthosting.co.za>
Message-ID: <1322471912.57.0.461390632563.issue13481@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

I think this should be rejected.

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13481>
_______________________________________

From report at bugs.python.org  Mon Nov 28 10:24:31 2011
From: report at bugs.python.org (Michael Kraus)
Date: Mon, 28 Nov 2011 09:24:31 +0000
Subject: [issue13492] ./configure --with-system-ffi=LIBFFI-PATH
Message-ID: <1322472271.69.0.0807066602711.issue13492@psf.upfronthosting.co.za>


New submission from Michael Kraus <krausmichel at gmail.com>:

It would be very helpful to have the ability to specify a LIBFFI-PATH during Python configuration via

./configure --with-system-ffi=LIBFFI-PATH

We are using the Intel compiler to build Python, NumPy, SciPy, and Cython on a SuSE Linux Enterprise Server. Libffi uses some 128bit int type which is not defined by the Intel compiler, thus can't be build with it. 

Unfortunately, the ./configure script, if run with --with-system-ffi looks for the ffi includes only in the standard directories (/usr/include, etc.). On our cluster, we are not allowed to install into the main system, we can only add modules. As there is no libffi coming with SLES and we cannot install it into the standard directories, the configure script won't find it. Thus the above request.

Best regards,
Michael

----------
components: Build
messages: 148472
nosy: michael.kraus
priority: normal
severity: normal
status: open
title: ./configure --with-system-ffi=LIBFFI-PATH
type: feature request
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/issue13492>
_______________________________________

From report at bugs.python.org  Mon Nov 28 11:56:46 2011
From: report at bugs.python.org (Yevgen Yampolskiy)
Date: Mon, 28 Nov 2011 10:56:46 +0000
Subject: [issue10131] deepcopying an xml.dom.minidom.Document generates an
	invalid XML document
In-Reply-To: <1287322940.78.0.0838139062813.issue10131@psf.upfronthosting.co.za>
Message-ID: <1322477806.68.0.93002444264.issue10131@psf.upfronthosting.co.za>


Yevgen Yampolskiy <genij.math at gmail.com> added the comment:

Marian, I have no doubts that the patch cures THIS issue. 
The problem is that it cures the wrong thing.
It is _reconstruct function that needs to be fixed (somebody changed order of 'if' statements between 2.6 and 2.7 releases)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10131>
_______________________________________

From report at bugs.python.org  Mon Nov 28 12:29:13 2011
From: report at bugs.python.org (python_hu)
Date: Mon, 28 Nov 2011 11:29:13 +0000
Subject: [issue13493] using python embed on AIX 6.1,Modules import error!
Message-ID: <1322479753.88.0.634847584065.issue13493@psf.upfronthosting.co.za>


New submission from python_hu <nari_hu at 163.com>:

Using python api embed on AIX 6.1,Modules import error,need help!!!!!
I have compile Python2.5.5 on Aix 6.1 using condigure:
 ./configure --with-gcc="xlc_r -q64" --with-cxx="xlC_r -q64" --disable-ipv6 AR="ar -X64"
when i run Python,and import math module,it works well:

ibm1:python2.5>python
Python 2.5.5 (r255:77872, Nov 28 2011, 13:32:10) [C] on aix6
Type "help", "copyright", "credits" or "license" for more information.
>>> import math
>>> 

But when i using in my C++ program,it works erro,the follow is mt code :
//{{C++

#include <stdio.h>
#include "Python.h"
#include <dlfcn.h> 

int main( int argc, char **argv )
{
             Py_Main(argc, argv); 
}

//}}

When i run this code.it has erro like that:
ibm1:pytest>pytest
Python 2.5.5 (r255:77872, Nov 28 2011, 13:32:10) [C] on aix6
Type "help", "copyright", "credits" or "license" for more information.
>>> import math
_PyImport_GetDynLoadFunc142:/usr/local/lib/python2.5/lib-dynload/math.so,flags=2_____
_PyImport_GetDynLoadFunc_erro:/usr/local/lib/python2.5/lib-dynload/math.so
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ImportError:    0509-130 Symbol resolution failed /usr/local/lib/python2.5/lib-dynload/math.so because:
        0509-136   Symbol PyArg_Parse (number 0) is not exported from
                   dependent module pytest.
        0509-136   Symbol PyArg_ParseTuple (number 1) is not exported from
                   dependent module pytest.
        0509-136   Symbol Py_BuildValue (number 2) is not exported from
                   dependent module pytest.
        0509-136   Symbol PyDict_GetItemString (number 3) is not exported from
                   dependent module pytest.
        0509-136   Symbol PyErr_NoMemory (number 4) is not exported from
                   dependent module pytest.
        0509-136   Symbol PyErr_Occurred (number 5) is not exported from
                   dependent module pytest.
        0509-021 Additional errors occurred but are not reported.
        0509-192 Examine .loader section symbols with the
                 'dump -Tv' command.
                
>>>

----------
components: None
messages: 148474
nosy: python_hu
priority: normal
severity: normal
status: open
title: using python embed on AIX 6.1,Modules import error!
type: crash
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13493>
_______________________________________

From report at bugs.python.org  Mon Nov 28 13:06:08 2011
From: report at bugs.python.org (Weeble)
Date: Mon, 28 Nov 2011 12:06:08 +0000
Subject: [issue444582] Finding programs in PATH, adding shutil.which
Message-ID: <1322481968.62.0.970563141534.issue444582@psf.upfronthosting.co.za>


Weeble <clockworksaint at gmail.com> added the comment:

I'm not sure what rules are used by Windows to process the PATH string, but I think they are similar to the rules used to parse the command-line into argv in a C/C++ program: http://msdn.microsoft.com/en-us/library/17w5ykft.aspx

I have tested various arrangements of double-quotes in path elements. It appears the quotes can appear anywhere, not just at the start and end of entries. As far as I can tell, *all* they do is toggle the interpretation of the semicolon character between a separator and a character in the directory path. Note in particular: quotes may surround an entire path, segments of a path, fragments of segments of a path, or even may be completely empty. Any number of quotes can appear in a single path entry. There doesn't even need to be an even number of quotes - it seems that an odd number of quotes are treated the same as if a final quote was appended to the very end of the PATH string.

Running my attached test batch file, I see these results:

c:\Users\weeble>pathtest
PATH=
FAIL

PATH=c:\Users\weeble\foo;bar
FAIL

PATH=c:\Users\weeble\"foo;bar"
SUCCESS

PATH="c:\Users\weeble\foo;bar"
SUCCESS

PATH=c:\Users\weeble\"foo;"bar
SUCCESS

PATH=c:\Users\weeble\foo";"bar
SUCCESS

PATH=c:\Users\weeble\""foo";"bar""
SUCCESS

PATH=
FAIL

PATH=c:\Users\weeble\foo";bar
SUCCESS

----------
nosy: +weeble
Added file: http://bugs.python.org/file23797/pathtest.bat

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue444582>
_______________________________________

From report at bugs.python.org  Mon Nov 28 14:06:15 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 28 Nov 2011 13:06:15 +0000
Subject: [issue13493] using python embed on AIX 6.1,Modules import error!
In-Reply-To: <1322479753.88.0.634847584065.issue13493@psf.upfronthosting.co.za>
Message-ID: <1322485575.51.0.456303285839.issue13493@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

It may be related to issue941346.  Can you try with a newer version of Python? 2.5 is not maintained anymore.

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13493>
_______________________________________

From report at bugs.python.org  Mon Nov 28 14:49:20 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 28 Nov 2011 13:49:20 +0000
Subject: [issue13473] Add tests for files byte-compiled by distutils[2]
In-Reply-To: <1322145911.61.0.528651769931.issue13473@psf.upfronthosting.co.za>
Message-ID: <1322488160.35.0.79409518188.issue13473@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

See http://bugs.python.org/issue12119#msg146943

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13473>
_______________________________________

From report at bugs.python.org  Mon Nov 28 14:55:59 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 28 Nov 2011 13:55:59 +0000
Subject: [issue13400] packaging: build command should have options to control
	byte-compilation
In-Reply-To: <1321281623.21.0.854677924579.issue13400@psf.upfronthosting.co.za>
Message-ID: <1322488559.96.0.127039487383.issue13400@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> I suggest to not use "pyc" and "pyo" in options, because ".pyc" and ".pyo" filename extensions
> are specific to a subset of Python implementations. Jython uses "$py.class" filename extension
> (module$py.class for module.py).
But these are extension modules, not Python modules byte-compiled for caching, are they?

> You could use --byte-compile, --no-byte-compile and --optimize-bytecode (or --optimize-byte-code)
> for both build and build_py commands.
I like the first two names, but still think that --optimize-bytecode might make people imply that the option is dependent on (or implying) --byte-compile.  Maybe it?s just me; I did not read the source for these options closely and was under this misconception for months.  OTOH, even with one maybe possibly ambiguous option name, I can still make the help text clearer (i.e. ?byte-compile Python modules? and ?byte-compile Python modules with optimizations?).

(We?re spending a lot of thoughts for a very marginally useful feature (.pyo files).)

> Do settings from setup.cfg affect byte-compilation?
Yes.  Like any command options, --(no-)compile and --optimize can be given in config files or on the command-line.

BTW, why don?t you want byte-compiled files on your system?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13400>
_______________________________________

From report at bugs.python.org  Mon Nov 28 14:57:12 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 28 Nov 2011 13:57:12 +0000
Subject: [issue13486] msvc9compiler.py doesn't properly generate manifest
	files.
In-Reply-To: <1322344783.33.0.460870481781.issue13486@psf.upfronthosting.co.za>
Message-ID: <1322488632.88.0.143442697604.issue13486@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +mhammond

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13486>
_______________________________________

From report at bugs.python.org  Mon Nov 28 14:59:50 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 28 Nov 2011 13:59:50 +0000
Subject: [issue12618] py_compile cannot create files in current directory
In-Reply-To: <1311406971.17.0.312082121474.issue12618@psf.upfronthosting.co.za>
Message-ID: <1322488790.65.0.991958162152.issue12618@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> I have attached an updated patch with a unit test.
LGTM.

> Also, this is not an issue for Python 2.7.  The 2.7 implementation assumes any
> directories mentioned in the path already exist.
Cool.  The test can still be committed in that branch too.

----------
assignee:  -> meador.inge
versions: +Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12618>
_______________________________________

From report at bugs.python.org  Mon Nov 28 15:01:09 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 28 Nov 2011 14:01:09 +0000
Subject: [issue13494] 'cast' any value to a Boolean?
Message-ID: <1322488868.96.0.430179402239.issue13494@psf.upfronthosting.co.za>


New submission from Mark Dickinson <dickinsm at gmail.com>:

Docs nit:  at http://docs.python.org/dev/library/stdtypes.html#boolean-values we have

"""
The built-in function bool() can be used to cast any value to a Boolean ...
"""

It's a little unusual to talk about casting in Python.  Any objections to replacing 'cast' with 'convert'?

----------
assignee: docs at python
components: Documentation
messages: 148480
nosy: docs at python, mark.dickinson
priority: normal
severity: normal
status: open
title: 'cast' any value to a Boolean?
versions: Python 2.7, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13494>
_______________________________________

From report at bugs.python.org  Mon Nov 28 15:02:16 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 28 Nov 2011 14:02:16 +0000
Subject: [issue13494] 'cast' any value to a Boolean?
In-Reply-To: <1322488868.96.0.430179402239.issue13494@psf.upfronthosting.co.za>
Message-ID: <1322488936.84.0.862474836788.issue13494@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

+1

----------
nosy: +ezio.melotti
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13494>
_______________________________________

From report at bugs.python.org  Mon Nov 28 15:08:49 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 28 Nov 2011 14:08:49 +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: <1322489329.05.0.461700591225.issue12307@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

1b7fed04108c should help make figure out that it needs to rebuild.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12307>
_______________________________________

From report at bugs.python.org  Mon Nov 28 15:27:12 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 28 Nov 2011 14:27:12 +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: <1322490432.31.0.682370429156.issue12307@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Rebuilt!  (Another glitch: plain text PEPs really should have an HTML title.  If you have time.. :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12307>
_______________________________________

From report at bugs.python.org  Mon Nov 28 15:36:08 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 28 Nov 2011 14:36:08 +0000
Subject: [issue6135] subprocess seems to use local 8-bit encoding and gives no
	choice
In-Reply-To: <1243494524.57.0.870766192683.issue6135@psf.upfronthosting.co.za>
Message-ID: <1322490968.07.0.350397117331.issue6135@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Is subprocess affected by PYTHONIOENCODING?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6135>
_______________________________________

From report at bugs.python.org  Mon Nov 28 15:37:08 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 28 Nov 2011 14:37:08 +0000
Subject: [issue10318] "make altinstall" installs many files with incorrect
	shebangs
In-Reply-To: <1288926610.35.0.932494150274.issue10318@psf.upfronthosting.co.za>
Message-ID: <1322491028.45.0.79992607693.issue10318@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Can I removed the shebangs in the 3.3 stdlib or do I need to go through with the PEP 8 patch on python-dev first?

----------
versions:  -Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10318>
_______________________________________

From report at bugs.python.org  Mon Nov 28 16:04:08 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 28 Nov 2011 15:04:08 +0000
Subject: [issue13491] Fixes for sqlite3 doc
In-Reply-To: <1322390027.54.0.855055968281.issue13491@psf.upfronthosting.co.za>
Message-ID: <1322492648.72.0.621901435496.issue13491@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

It is very helpful that you review the docs.  Some obvious fixes were made when moving to Python 3 (print, etc.) but apparently the examples were not run.  Sphinx can let us run the code blocks in reST files as doctests, but it is currently not done because the docs are built with a Python 2 version.

I have reviewed your patch on our code review tool; I did not check your message (a patch is much easier :).

> I feel these should be standalone examples out of the box. the sqlite3 includes have a
> "createdb.py" file which would create the tables but it is not referenced in the
> documenta[tion]. I do not know the reasoning behind this, but I would like to have standalone
> examples in these cases.

I think the examples do not stand alone because their author wanted to create and populate a database with many entries, to demonstrate querying, and it was easier to write one script once than to either clutter the examples with long table creation code or having examples with so few rows that it would not be realistic/interesting.  To help people wanting to run the examples in the docs, we could explain that createdb.py needs to be run first.

The createdb script and other sqlite3 doc examples were added when sqlite3 was added in Python 2.5; I?m adding the module author and then-doc lead (hi Gerhard and Fred), maybe they can shed more light on this.

----------
nosy: +eric.araujo, fdrake, ghaering, petri.lehtinen
title: sqlite3 code adjustments -> Fixes for sqlite3 doc
versions: +Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13491>
_______________________________________

From report at bugs.python.org  Mon Nov 28 16:08:05 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 28 Nov 2011 15:08:05 +0000
Subject: [issue13487] inspect.getmodule fails when module imports change
	sys.modules
In-Reply-To: <1322363209.24.0.0935380803772.issue13487@psf.upfronthosting.co.za>
Message-ID: <1322492885.39.0.410627352075.issue13487@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Maybe it can be caused by an installation happening during the loop.  I agree with Erik?s reading of the comment and patch, and don?t think a test is needed.

----------
nosy: +eric.araujo
stage:  -> patch review
type:  -> behavior
versions:  -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13487>
_______________________________________

From report at bugs.python.org  Mon Nov 28 16:10:52 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 28 Nov 2011 15:10:52 +0000
Subject: [issue13493] Import error with embedded python on AIX 6.1
In-Reply-To: <1322479753.88.0.634847584065.issue13493@psf.upfronthosting.co.za>
Message-ID: <1322493052.95.0.867014485237.issue13493@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
components:  -None
stage:  -> test needed
title: using python embed on AIX 6.1,Modules import error! -> Import error with embedded python on AIX 6.1
type: crash -> behavior
versions: +Python 2.7 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13493>
_______________________________________

From report at bugs.python.org  Mon Nov 28 16:23:00 2011
From: report at bugs.python.org (=?utf-8?b?U8OpYmFzdGllbiBTYWJsw6k=?=)
Date: Mon, 28 Nov 2011 15:23:00 +0000
Subject: [issue13210] Support Visual Studio 2010
In-Reply-To: <1318942521.44.0.961979099616.issue13210@psf.upfronthosting.co.za>
Message-ID: <1322493780.48.0.839518292028.issue13210@psf.upfronthosting.co.za>


S?bastien Sabl? <sable at users.sourceforge.net> added the comment:

OK Brian, I checked your clone and I will keep an eye on it.

I have done almost the same thing for the moment. My patch queue includes some additional corrections for a few more bugs that prevented me from completely running the test suite (crash dumps).

I will start working on Python 'default' probably tomorrow.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13210>
_______________________________________

From report at bugs.python.org  Mon Nov 28 16:31:31 2011
From: report at bugs.python.org (Meador Inge)
Date: Mon, 28 Nov 2011 15:31:31 +0000
Subject: [issue13492] ./configure --with-system-ffi=LIBFFI-PATH
In-Reply-To: <1322472271.69.0.0807066602711.issue13492@psf.upfronthosting.co.za>
Message-ID: <1322494291.78.0.413232369923.issue13492@psf.upfronthosting.co.za>


Changes by Meador Inge <meadori at gmail.com>:


----------
nosy: +meador.inge
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13492>
_______________________________________

From report at bugs.python.org  Mon Nov 28 16:32:27 2011
From: report at bugs.python.org (Meador Inge)
Date: Mon, 28 Nov 2011 15:32:27 +0000
Subject: [issue13494] 'cast' any value to a Boolean?
In-Reply-To: <1322488868.96.0.430179402239.issue13494@psf.upfronthosting.co.za>
Message-ID: <1322494347.23.0.588335551056.issue13494@psf.upfronthosting.co.za>


Meador Inge <meadori at gmail.com> added the comment:

+1

----------
nosy: +meador.inge

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13494>
_______________________________________

From report at bugs.python.org  Mon Nov 28 16:36:07 2011
From: report at bugs.python.org (Brian Curtin)
Date: Mon, 28 Nov 2011 15:36:07 +0000
Subject: [issue13210] Support Visual Studio 2010
In-Reply-To: <1318942521.44.0.961979099616.issue13210@psf.upfronthosting.co.za>
Message-ID: <1322494567.16.0.628570599511.issue13210@psf.upfronthosting.co.za>


Brian Curtin <brian at python.org> added the comment:

If you want to clone from that repo, use the "vs2010" branch.

hg clone http://hg.python.org/sandbox/vs2010port/
hg up vs2010

>From there, you can post patches here that I can integrate for you.

----------
assignee:  -> brian.curtin

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13210>
_______________________________________

From report at bugs.python.org  Mon Nov 28 16:39:18 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 28 Nov 2011 15:39:18 +0000
Subject: [issue12618] py_compile cannot create files in current directory
In-Reply-To: <1311406971.17.0.312082121474.issue12618@psf.upfronthosting.co.za>
Message-ID: <E1RV3Ib-0002pX-46@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 661fb211f220 by Meador Inge in branch '3.2':
Issue #12618: py_compile cannot create files in current directory
http://hg.python.org/cpython/rev/661fb211f220

New changeset e3647275f468 by Meador Inge in branch 'default':
Issue #12618: py_compile cannot create files in current directory
http://hg.python.org/cpython/rev/e3647275f468

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12618>
_______________________________________

From report at bugs.python.org  Mon Nov 28 16:40:41 2011
From: report at bugs.python.org (Meador Inge)
Date: Mon, 28 Nov 2011 15:40:41 +0000
Subject: [issue12618] py_compile cannot create files in current directory
In-Reply-To: <1311406971.17.0.312082121474.issue12618@psf.upfronthosting.co.za>
Message-ID: <1322494841.19.0.898697309247.issue12618@psf.upfronthosting.co.za>


Meador Inge <meadori at gmail.com> added the comment:

> Cool.  The test can still be committed in that branch too.

The regression test for this issue was already committed for 2.7 in bcc7bf3963cc as a part of creating the unit test baseline.  I just committed the bug fix to 3.2 and default.

Thanks for the fix Sjoerd.

----------
resolution:  -> fixed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12618>
_______________________________________

From report at bugs.python.org  Mon Nov 28 16:41:28 2011
From: report at bugs.python.org (Meador Inge)
Date: Mon, 28 Nov 2011 15:41:28 +0000
Subject: [issue12618] py_compile cannot create files in current directory
In-Reply-To: <1311406971.17.0.312082121474.issue12618@psf.upfronthosting.co.za>
Message-ID: <1322494888.79.0.927553987413.issue12618@psf.upfronthosting.co.za>


Changes by Meador Inge <meadori at gmail.com>:


----------
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12618>
_______________________________________

From report at bugs.python.org  Mon Nov 28 16:44:48 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 28 Nov 2011 15:44:48 +0000
Subject: [issue13210] Support Visual Studio 2010
In-Reply-To: <1318942521.44.0.961979099616.issue13210@psf.upfronthosting.co.za>
Message-ID: <1322495088.51.0.917466191404.issue13210@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

A tip to make Mercurial download only a subset of all the changesets in the repo:

  hg clone URI -r branch

or

  hg clone URI#branch

(The difference is that in the second form, URI#branch will be recorded in the .hg/hgrc file and subsequent pulls will only pull from that branch.)

bandwith-is-a-scarce-resource?ly yours

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13210>
_______________________________________

From report at bugs.python.org  Mon Nov 28 16:47:44 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 28 Nov 2011 15:47:44 +0000
Subject: [issue6135] subprocess seems to use local 8-bit encoding and gives no
	choice
In-Reply-To: <1322490968.07.0.350397117331.issue6135@psf.upfronthosting.co.za>
Message-ID: <28145389.jGBGLVKe7I@dsk000552>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> Is subprocess affected by PYTHONIOENCODING?

Yes, as any Python process.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6135>
_______________________________________

From report at bugs.python.org  Mon Nov 28 16:48:51 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 28 Nov 2011 15:48:51 +0000
Subject: [issue6135] subprocess seems to use local encoding and give no choice
In-Reply-To: <1243494524.57.0.870766192683.issue6135@psf.upfronthosting.co.za>
Message-ID: <1322495331.47.0.213050755663.issue6135@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

So the users can control the encoding, and this is a doc bug.

----------
title: subprocess seems to use local 8-bit encoding and gives no choice -> subprocess seems to use local encoding and give no choice

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6135>
_______________________________________

From report at bugs.python.org  Mon Nov 28 17:00:44 2011
From: report at bugs.python.org (R. David Murray)
Date: Mon, 28 Nov 2011 16:00:44 +0000
Subject: [issue6135] subprocess seems to use local encoding and give no choice
In-Reply-To: <1243494524.57.0.870766192683.issue6135@psf.upfronthosting.co.za>
Message-ID: <1322496044.96.0.283133324502.issue6135@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

If you decide this is only a doc bug, please see also related issue 12832.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6135>
_______________________________________

From report at bugs.python.org  Mon Nov 28 17:05:03 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 28 Nov 2011 16:05:03 +0000
Subject: [issue12832] The documentation for the print function should
	explain/point to how to control the sys.stdout encoding
In-Reply-To: <1314191894.1.0.666645625262.issue12832@psf.upfronthosting.co.za>
Message-ID: <1322496303.96.0.303846070038.issue12832@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Thanks for the patch.  It was reviewed on our code review tool; if you did not get an email (there are glitches), follow the link on the right of your patch in the list of files.

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12832>
_______________________________________

From report at bugs.python.org  Mon Nov 28 17:06:47 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 28 Nov 2011 16:06:47 +0000
Subject: [issue6135] subprocess seems to use local encoding and give no choice
In-Reply-To: <1243494524.57.0.870766192683.issue6135@psf.upfronthosting.co.za>
Message-ID: <1322496407.81.0.792382419226.issue6135@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> So the users can control the encoding, and this is a doc bug.

Not really. People can control the encoding in the child process (and only if it's a Python 3 process of course).
They can't control the encoding in the parent's subprocess pipes and that's what the request (& patch) is about.

----------
versions: +Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6135>
_______________________________________

From report at bugs.python.org  Mon Nov 28 17:15:09 2011
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Mon, 28 Nov 2011 16:15:09 +0000
Subject: [issue13400] packaging: build command should have options to control
	byte-compilation
In-Reply-To: <1321281623.21.0.854677924579.issue13400@psf.upfronthosting.co.za>
Message-ID: <1322496909.68.0.820560221731.issue13400@psf.upfronthosting.co.za>


Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com> added the comment:

Jython's *$py.class files are byte-compiled modules, not extension modules.

There should be a way to disable generation of *.pyo files on command line even if setup.cfg enables it.

IMHO it would make more sense if --optimize-bytecode was dependant on --byte-compile option:
--no-byte-compile                      -> No *.pyc and *.pyo
--byte-compile --optimize-bytecode=0   -> Only *.pyc
--byte-compile --optimize-bytecode=0,1 -> *.pyc and *.pyo (with docstrings)
--byte-compile --optimize-bytecode=0,2 -> *.pyc and *.pyo (without docstrings)
--byte-compile --optimize-bytecode=1   -> Only *.pyo (with docstrings)
--byte-compile --optimize-bytecode=2   -> Only *.pyo (without docstrings)
--byte-compile --optimize-bytecode=1,2 -> Error

Byte-compiled files in Gentoo are generated separately, after installation.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13400>
_______________________________________

From report at bugs.python.org  Mon Nov 28 17:24:48 2011
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Mon, 28 Nov 2011 16:24:48 +0000
Subject: [issue12119] distutils and python -B
In-Reply-To: <1305822053.61.0.184404379566.issue12119@psf.upfronthosting.co.za>
Message-ID: <1322497488.47.0.662334354234.issue12119@psf.upfronthosting.co.za>


Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com> added the comment:

Please don't backport this change to distutils without backporting --no-compile options to "build" command in distutils (issue #13400). Otherwise users would lose possibility of disabling byte-compilation during running this command.

distutils tests could use locally modified environment with PYTHONDONTWRITEBYTECODE variable removed.

----------
nosy: +Arfrever

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12119>
_______________________________________

From report at bugs.python.org  Mon Nov 28 17:24:56 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 28 Nov 2011 16:24:56 +0000
Subject: [issue13400] packaging: build command should have options to control
	byte-compilation
In-Reply-To: <1321281623.21.0.854677924579.issue13400@psf.upfronthosting.co.za>
Message-ID: <1322497496.37.0.634641921828.issue13400@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> Jython's *$py.class files are byte-compiled modules, not extension modules.
Thanks for the data point.  Agreed distutils[2] should not say ?pyc? and ?pyo? then.

> There should be a way to disable generation of *.pyo files on command line even if
> setup.cfg enables it.
There is.  The precedence of options is: stdlib distutils.cfg < (overriden by) user .pydistutils.cfg < local setup.cfg < options on the command line.  Pass --no-compile --optimize=0 to never ever byte-compile (or pass --no-user-cfg and rely on the defaults).

> IMHO it would make more sense if --optimize-bytecode was dependant on --byte-compile option:
It was also my expectation, as I told.  The scheme that you propose keeps all current possibilities, it?s nice!  What do you think about conflating two options into one?

> --no-byte-compile         -> No *.pyc or *.pyo
> --byte-compile            -> Only *.pyc
> --byte-compile=0          -> Only *.pyc
> --byte-compile=0,1        -> *.pyc and *.pyo (level 1)
(etc.)
There may be a technical hurdle to overcome (not sure the option parsing system will allow 0 or more arg), but I?m asking for human interface feedback first.  (I?m just trying to make the list of options a bit smaller to reduce the overload, but if it feels complicated I won?t do it.)

> Byte-compiled files in Gentoo are generated separately, after installation.
Are you using standard py_compile or compileall modules or your own scripts?  I?ve seen that Debian for example has its own scripts and I?m sad to see no feature requests upstreamed to us instead.

----------
assignee: tarek -> eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13400>
_______________________________________

From report at bugs.python.org  Mon Nov 28 17:26:13 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 28 Nov 2011 16:26:13 +0000
Subject: [issue12119] distutils and python -B
In-Reply-To: <1305822053.61.0.184404379566.issue12119@psf.upfronthosting.co.za>
Message-ID: <1322497573.2.0.813962711015.issue12119@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> Please don't backport this change to distutils without backporting --no-compile options to
> "build" command in distutils (issue #13400).
The feature freeze on distutils rules this out.

> Otherwise users would lose possibility of disabling byte-compilation during running this command.
python setup.py build build_py --no-compile --optimize=0

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12119>
_______________________________________

From report at bugs.python.org  Mon Nov 28 17:36:22 2011
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Mon, 28 Nov 2011 16:36:22 +0000
Subject: [issue13400] packaging: build command should have options to control
	byte-compilation
In-Reply-To: <1321281623.21.0.854677924579.issue13400@psf.upfronthosting.co.za>
Message-ID: <1322498182.46.0.631604678821.issue13400@psf.upfronthosting.co.za>


Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com> added the comment:

--byte-compile=arguments is a good idea.

(Gentoo uses py_compile and compileall modules.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13400>
_______________________________________

From report at bugs.python.org  Mon Nov 28 17:46:32 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 28 Nov 2011 16:46:32 +0000
Subject: [issue13400] packaging: build command should have options to control
	byte-compilation
In-Reply-To: <1321281623.21.0.854677924579.issue13400@psf.upfronthosting.co.za>
Message-ID: <1322498792.52.0.042301190335.issue13400@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Thanks for all the feedback!  So, for anyone interested in contributing, two patches are needed:

One that changes the existing options to use the new names and parsing behavior (--no-compile, --compile[=0,1,2]) and adds tests for the erroneous --compile=1,2 (other combinations are already covered).

A second one to add --no-compile and --compile to build, make build_py take its default values from build, and add tests to see if this works.

As usual, I?m available for help here, on the core-mentorship list or in private email.  (I don?t plan to do this myself in the short term because it?s a minor feature, I have an alpha to release and I have to keep the easiest things for new contributors.)

----------
dependencies: +Add tests for files byte-compiled by distutils[2]

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13400>
_______________________________________

From report at bugs.python.org  Mon Nov 28 17:46:56 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 28 Nov 2011 16:46:56 +0000
Subject: [issue13492] ./configure --with-system-ffi=LIBFFI-PATH
In-Reply-To: <1322472271.69.0.0807066602711.issue13492@psf.upfronthosting.co.za>
Message-ID: <1322498816.54.0.278291726592.issue13492@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +amaury.forgeotdarc, belopolsky
versions:  -Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13492>
_______________________________________

From report at bugs.python.org  Mon Nov 28 19:03:07 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Mon, 28 Nov 2011 18:03:07 +0000
Subject: [issue7111] abort when stderr is closed
In-Reply-To: <1322432741.45.0.212792100211.issue7111@psf.upfronthosting.co.za>
Message-ID: <CAH_1eM1PhB3O+sa9L=NWXHtBnKXDucfo8COTvhFeH0ThvpszQw@mail.gmail.com>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

> Updated patch.
>

LGTM.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7111>
_______________________________________

From report at bugs.python.org  Mon Nov 28 19:07:05 2011
From: report at bugs.python.org (Eric Snow)
Date: Mon, 28 Nov 2011 18:07:05 +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: <1322503625.12.0.895091854101.issue12307@psf.upfronthosting.co.za>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

Thanks, ?ric.  That looks good.  I'll keep that HTML title thing in mind.  :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12307>
_______________________________________

From report at bugs.python.org  Mon Nov 28 19:16:24 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 28 Nov 2011 18:16:24 +0000
Subject: [issue7111] abort when stderr is closed
In-Reply-To: <1255335800.65.0.921782203194.issue7111@psf.upfronthosting.co.za>
Message-ID: <E1RV5kd-0002az-3R@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset f15943505db0 by Antoine Pitrou in branch '3.2':
Issue #7111: Python can now be run without a stdin, stdout or stderr stream.
http://hg.python.org/cpython/rev/f15943505db0

New changeset c86fb10eaf68 by Antoine Pitrou in branch 'default':
Issue #7111: Python can now be run without a stdin, stdout or stderr stream.
http://hg.python.org/cpython/rev/c86fb10eaf68

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7111>
_______________________________________

From report at bugs.python.org  Mon Nov 28 19:22:27 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 28 Nov 2011 18:22:27 +0000
Subject: [issue7111] abort when stderr is closed
In-Reply-To: <1255335800.65.0.921782203194.issue7111@psf.upfronthosting.co.za>
Message-ID: <1322504547.56.0.541199334752.issue7111@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Thanks, committed.

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7111>
_______________________________________

From report at bugs.python.org  Mon Nov 28 19:37:46 2011
From: report at bugs.python.org (Erik Tollerud)
Date: Mon, 28 Nov 2011 18:37:46 +0000
Subject: [issue13487] inspect.getmodule fails when module imports change
	sys.modules
In-Reply-To: <1322363209.24.0.0935380803772.issue13487@psf.upfronthosting.co.za>
Message-ID: <1322505466.7.0.0919997171362.issue13487@psf.upfronthosting.co.za>


Erik Tollerud <erik.tollerud at gmail.com> added the comment:

The package that triggers it for me is the py (http://pypi.python.org/pypi/py) package - when in gets imported, it does some trick with sys.modules that is in place to get around some pickling restriction, but that means sys.modules is altered during the import of the `py` package... and that triggers the exception.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13487>
_______________________________________

From report at bugs.python.org  Mon Nov 28 19:48:01 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Mon, 28 Nov 2011 18:48:01 +0000
Subject: [issue13093] Redundant code in PyUnicode_EncodeDecimal()
In-Reply-To: <1317569955.86.0.21646060057.issue13093@psf.upfronthosting.co.za>
Message-ID: <1322506081.98.0.917944959115.issue13093@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

A 2.7 OS X buildbot segfaults in test_unicode since 0cd197f13400 :

http://www.python.org/dev/buildbot/all/builders/AMD64 Snow Leopard 2 2.7/builds/409/steps/test/logs/stdio

"""
test_unicode
make: *** [buildbottest] Segmentation fault
program finished with exit code 2
"""

----------
nosy: +neologix
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13093>
_______________________________________

From report at bugs.python.org  Mon Nov 28 19:52:48 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 28 Nov 2011 18:52:48 +0000
Subject: [issue13487] inspect.getmodule fails when module imports change
	sys.modules
In-Reply-To: <1322363209.24.0.0935380803772.issue13487@psf.upfronthosting.co.za>
Message-ID: <1322506368.13.0.662665390545.issue13487@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

When a package is imported sys.modules changes... nothing special here.
But it's true true that py.std, for example, is a "lazy" module with a special __getattr__ that will import submodules.

Patch looks good to me as well.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13487>
_______________________________________

From report at bugs.python.org  Mon Nov 28 19:54:19 2011
From: report at bugs.python.org (Stefan Behnel)
Date: Mon, 28 Nov 2011 18:54:19 +0000
Subject: [issue11379] Remove "lightweight" from minidom description
In-Reply-To: <1299093908.17.0.828802315354.issue11379@psf.upfronthosting.co.za>
Message-ID: <1322506459.35.0.757622498929.issue11379@psf.upfronthosting.co.za>


Stefan Behnel <scoder at users.sourceforge.net> added the comment:

Ok, so, what do we make of this? I proposed improvements to the wording in the documentation, which make it much clearer for users what they are buying into when they start using minidom. I still think that "factually correct" but clearly misleading documentation is not helpful and that it needs fixing. Here is an updated phrasing that I hope we can settle on:

"""
:mod:`xml.dom.minidom` --- Pure Python DOM implementation

[...]

:mod:`xml.dom.minidom` is a pure Python implementation of the Document Object Model interface, as known from other programming languages. It is intended to provide a smaller and simpler API than the full W3C DOM.

Note that MiniDOM has a several times larger memory footprint than :mod:`xml.etree.ElementTree`, the light-weight Python XML library in the standard library. If you do not need a (mostly) compliant W3C DOM implementation, but a fast and memory friendly XML tree implementation with an easy to learn API, use that instead.
"""

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11379>
_______________________________________

From report at bugs.python.org  Mon Nov 28 20:27:10 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 28 Nov 2011 19:27:10 +0000
Subject: [issue12119] distutils and python -B
In-Reply-To: <1305822053.61.0.184404379566.issue12119@psf.upfronthosting.co.za>
Message-ID: <1322508430.84.0.221645191601.issue12119@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/issue12119>
_______________________________________

From report at bugs.python.org  Mon Nov 28 20:56:58 2011
From: report at bugs.python.org (Roger Serwy)
Date: Mon, 28 Nov 2011 19:56:58 +0000
Subject: [issue13495] IDLE: Regression - Two ColorDelegator instances loaded
Message-ID: <1322510218.36.0.927250562508.issue13495@psf.upfronthosting.co.za>


New submission from Roger Serwy <roger.serwy at gmail.com>:

Two instances of ColorDelegator are in the percolator chain. This is a regression from 2.x.

The problem can be found in __init__ of EditorWindow in EditorWindow.py.

Calling "io.loadfile" eventually calls "filename_change_hook" (See IOBinding.py's "set_filename"). The "filename_change_hook" calls "ResetColorizer" which brings up an instance of ColorDelegator. Then, the self.color reference is overwritten by a new ColorDelegator instance and added to the percolator chain.

The attached patch fixes the problem.

----------
components: IDLE
files: colorbug.patch
keywords: patch
messages: 148513
nosy: ned.deily, serwy
priority: normal
severity: normal
status: open
title: IDLE: Regression - Two ColorDelegator instances loaded
type: behavior
versions: Python 3.1, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file23798/colorbug.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13495>
_______________________________________

From report at bugs.python.org  Mon Nov 28 22:00:48 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 28 Nov 2011 21:00:48 +0000
Subject: [issue13434] time.xmlrpc.com dead
In-Reply-To: <1321717486.33.0.411354256352.issue13434@psf.upfronthosting.co.za>
Message-ID: <E1RV8Ji-00041h-5q@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset da148f0d86bd by Antoine Pitrou in branch '3.2':
Issue #13434: skip the time.xmlrpc.com test, and reenable the buildbot test.
http://hg.python.org/cpython/rev/da148f0d86bd

New changeset 1330beac9ec9 by Antoine Pitrou in branch 'default':
Merge test_xmlrpc_net fixes (issue #13434)
http://hg.python.org/cpython/rev/1330beac9ec9

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13434>
_______________________________________

From report at bugs.python.org  Mon Nov 28 22:01:52 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 28 Nov 2011 21:01:52 +0000
Subject: [issue13434] time.xmlrpc.com dead
In-Reply-To: <1321717486.33.0.411354256352.issue13434@psf.upfronthosting.co.za>
Message-ID: <1322514112.55.0.322294418732.issue13434@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13434>
_______________________________________

From report at bugs.python.org  Mon Nov 28 23:00:24 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 28 Nov 2011 22:00:24 +0000
Subject: [issue13093] Redundant code in PyUnicode_EncodeDecimal()
In-Reply-To: <1317569955.86.0.21646060057.issue13093@psf.upfronthosting.co.za>
Message-ID: <1322517624.92.0.129026561809.issue13093@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> A 2.7 OS X buildbot segfaults in test_unicode since 0cd197f13400
> http://www.python.org/dev/buildbot/all/builders/AMD64 Snow Leopard 2 2.7/builds/409/steps/test/logs/stdio

Hum, I'm unable to reproduce the crash on Linux or Mac OS X Tiger.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13093>
_______________________________________

From report at bugs.python.org  Mon Nov 28 23:28:07 2011
From: report at bugs.python.org (Ned Deily)
Date: Mon, 28 Nov 2011 22:28:07 +0000
Subject: [issue13093] Redundant code in PyUnicode_EncodeDecimal()
In-Reply-To: <1317569955.86.0.21646060057.issue13093@psf.upfronthosting.co.za>
Message-ID: <1322519287.77.0.1110811278.issue13093@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

I am able to reproduce the problem on 2.7 OS X 10.7 64-bit. unicode._encodedecimal is gobbling up memory.  Looks like length is incorrect.

Breakpoint 1, unicode_encodedecimal (self=0x0, args=0x1007ce0d0) at /Users/nad/Projects/PyDev/active/temp/u27-clang/Modules/_testcapimodule.c:1122
1122	    decimal = PyBytes_FromStringAndSize(NULL, decimal_length);
(gdb) p length
$1 = 4294967299
Current language:  auto; currently minimal
(gdb) p unicode
$2 = (Py_UNICODE *) 0x101827ab8
(gdb) p errors
$3 = 0x0

----------
nosy: +ned.deily
resolution: fixed -> 
stage: committed/rejected -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13093>
_______________________________________

From report at bugs.python.org  Mon Nov 28 23:34:32 2011
From: report at bugs.python.org (Daniel Sturm)
Date: Mon, 28 Nov 2011 22:34:32 +0000
Subject: [issue13496] bisect module: Overflow at index computation
Message-ID: <1322519672.22.0.173147243777.issue13496@psf.upfronthosting.co.za>


New submission from Daniel Sturm <voodoon42 at gmail.com>:

The mid index computation in _bisectmodule.c in both internal_bisect_right and internal_bisect_left is done with:

mid = (lo + hi) / 2; // all three variables Py_ssize_t

which is  susceptible to overflows for large arrays, which would lead to undefined behavior (and in practice almost certainly a crash with a negative index)

The fix is trivial - mid = lo + (hi - lo) / 2; - but since I'm just starting to look into the code base I may be missing some undocumented assertions that guarantee this can't happen.

----------
components: Extension Modules
messages: 148517
nosy: Voo
priority: normal
severity: normal
status: open
title: bisect module: Overflow at index computation
type: behavior
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13496>
_______________________________________

From report at bugs.python.org  Mon Nov 28 23:37:01 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 28 Nov 2011 22:37:01 +0000
Subject: [issue13496] bisect module: Overflow at index computation
In-Reply-To: <1322519672.22.0.173147243777.issue13496@psf.upfronthosting.co.za>
Message-ID: <1322519821.49.0.211075706718.issue13496@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +mark.dickinson, rhettinger
versions: +Python 2.7, Python 3.2, Python 3.3 -Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13496>
_______________________________________

From report at bugs.python.org  Mon Nov 28 23:39:23 2011
From: report at bugs.python.org (Mark Hammond)
Date: Mon, 28 Nov 2011 22:39:23 +0000
Subject: [issue13486] msvc9compiler.py doesn't properly generate manifest
	files.
In-Reply-To: <1322344783.33.0.460870481781.issue13486@psf.upfronthosting.co.za>
Message-ID: <1322519963.32.0.67313966686.issue13486@psf.upfronthosting.co.za>


Mark Hammond <skippy.hammond at gmail.com> added the comment:

A manifest seems to be currently created fine - can you provide steps to reproduce the problem you see?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13486>
_______________________________________

From report at bugs.python.org  Mon Nov 28 23:40:21 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 28 Nov 2011 22:40:21 +0000
Subject: [issue13481] Use an accurate clock in timeit
In-Reply-To: <1322265721.78.0.0567796730825.issue13481@psf.upfronthosting.co.za>
Message-ID: <1322520021.95.0.587171658447.issue13481@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Are CLOCK_MONOTONIC_RAW, CLOCK_MONOTONIC and CLOCK_REALTIME more accurate than gettimeofday (time.time)?

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13481>
_______________________________________

From report at bugs.python.org  Tue Nov 29 00:04:31 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 28 Nov 2011 23:04:31 +0000
Subject: [issue13496] bisect module: Overflow at index computation
In-Reply-To: <1322519672.22.0.173147243777.issue13496@psf.upfronthosting.co.za>
Message-ID: <1322521471.43.0.713785920562.issue13496@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

This looks like a reasonable suggestion.

----------
assignee:  -> rhettinger
priority: normal -> low

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13496>
_______________________________________

From report at bugs.python.org  Tue Nov 29 00:28:01 2011
From: report at bugs.python.org (Frank Wierzbicki)
Date: Mon, 28 Nov 2011 23:28:01 +0000
Subject: [issue13465] A Jython section in the dev guide would be great
In-Reply-To: <1322074015.2.0.311635199294.issue13465@psf.upfronthosting.co.za>
Message-ID: <1322522881.29.0.605083477487.issue13465@psf.upfronthosting.co.za>


Frank Wierzbicki <fwierzbicki at gmail.com> added the comment:

I'll take a look at the dev guide this week and see how much it differs from what I'd want to do and report back here. If it doesn't make sense to include a Jython page here I can either copy content over or link to the CPython dev guide from the Jython one.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13465>
_______________________________________

From report at bugs.python.org  Tue Nov 29 00:32:10 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 28 Nov 2011 23:32:10 +0000
Subject: [issue3786] _curses,
	_curses_panel & _multiprocessing can't be build in 2.6b3 w/ SunStudio
	12
In-Reply-To: <1220608521.1.0.66106932182.issue3786@psf.upfronthosting.co.za>
Message-ID: <1322523130.5.0.10669088844.issue3786@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

EKIT.patch is not correct: it fails to find mvwchgat() on Linux, whereas the function is present. The test program is not linked to curses nor ncurses.

<< Solaris has both traditional System V curses and an XPG4-compatible
curses that does include mvwchgat.  The traditional system V curses is
the default, for backward compatibility.

...

- rebuild readline to use XPG4 curses, and then rebuild every single
  application that links against readline.  Then build Python, using
  the -I and -L/-R flags to get XPG4 curses for the entire Python build.

- modify the setup.py for the _curses module so that
  logic is added for Solaris to look for the XPG4 curses only during
  the build of the _curses module. >>

Link _curses module to a different curses library than the library used by readline may lead to crash: see issue #7384.

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3786>
_______________________________________

From report at bugs.python.org  Tue Nov 29 00:32:16 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 28 Nov 2011 23:32:16 +0000
Subject: [issue3786] _curses,
	_curses_panel & _multiprocessing can't be build in 2.6b3 w/ SunStudio
	12
In-Reply-To: <1220608521.1.0.66106932182.issue3786@psf.upfronthosting.co.za>
Message-ID: <1322523136.58.0.541256560912.issue3786@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
versions: +Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3786>
_______________________________________

From report at bugs.python.org  Tue Nov 29 00:34:03 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 28 Nov 2011 23:34:03 +0000
Subject: [issue3786] _curses,
	_curses_panel & _multiprocessing can't be build in 2.6b3 w/ SunStudio
	12
In-Reply-To: <1220608521.1.0.66106932182.issue3786@psf.upfronthosting.co.za>
Message-ID: <1322523243.37.0.237937645387.issue3786@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy:  -pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3786>
_______________________________________

From report at bugs.python.org  Tue Nov 29 00:44:30 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 28 Nov 2011 23:44:30 +0000
Subject: [issue10278] add time.wallclock() method
In-Reply-To: <1288624210.23.0.0497533122542.issue10278@psf.upfronthosting.co.za>
Message-ID: <1322523870.75.0.83931417406.issue10278@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

wallclock-2.patch: implement wallclock() using the new clock_getime(CLOCK_MONOTONIC) function (or other, depending on the OS).

I removed description on how the function is implemented from the doc.

----------
Added file: http://bugs.python.org/file23799/wallclock-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10278>
_______________________________________

From report at bugs.python.org  Tue Nov 29 00:45:42 2011
From: report at bugs.python.org (Tim Peters)
Date: Mon, 28 Nov 2011 23:45:42 +0000
Subject: [issue13496] bisect module: Overflow at index computation
In-Reply-To: <1322519672.22.0.173147243777.issue13496@psf.upfronthosting.co.za>
Message-ID: <1322523942.31.0.838759156554.issue13496@psf.upfronthosting.co.za>


Tim Peters <tim.peters at gmail.com> added the comment:

FWIW, I doubt there's a real issue here.  Objects in Python consume a lot more than a byte or two of memory, so the index range of a Python list is generally a lot less than ssize_t allows for.  In other words, quantify "large" in "large arrays".  How large can a Python list actually be, relative to ssize_t?  Similar reasoning accounts for why we never worry about overflow when mucking with refcounts:  the size of a refcount member  exceeds the maximum number of references that could exist.

----------
nosy: +tim_one

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13496>
_______________________________________

From report at bugs.python.org  Tue Nov 29 00:46:55 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 28 Nov 2011 23:46:55 +0000
Subject: [issue12822] NewGIL should use CLOCK_MONOTONIC if possible.
In-Reply-To: <1314085416.99.0.752578807259.issue12822@psf.upfronthosting.co.za>
Message-ID: <1322524015.81.0.447493963693.issue12822@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> The patch is ok on the principle, but we do need a check
> that CLOCK_MONOTONIC is supported at build time.

timemodule.c is now using "#ifdef CLOCK_MONOTONIC".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12822>
_______________________________________

From report at bugs.python.org  Tue Nov 29 00:50:44 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 28 Nov 2011 23:50:44 +0000
Subject: [issue13093] Redundant code in PyUnicode_EncodeDecimal()
In-Reply-To: <1317569955.86.0.21646060057.issue13093@psf.upfronthosting.co.za>
Message-ID: <E1RVAyA-0002ux-Nh@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 3ecddf168f1f by Victor Stinner in branch '2.7':
Issue #13093: Fix _testcapi.unicode_encodedecimal()
http://hg.python.org/cpython/rev/3ecddf168f1f

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13093>
_______________________________________

From report at bugs.python.org  Tue Nov 29 00:51:43 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 28 Nov 2011 23:51:43 +0000
Subject: [issue13093] Redundant code in PyUnicode_EncodeDecimal()
In-Reply-To: <1317569955.86.0.21646060057.issue13093@psf.upfronthosting.co.za>
Message-ID: <1322524303.54.0.480753927177.issue13093@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> Looks like length is incorrect.

Oh ok, _testcapimodule.c is "sssize_t" safe in Python 3, not in Python 2. Can you please try with the last tip?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13093>
_______________________________________

From report at bugs.python.org  Tue Nov 29 00:52:37 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 28 Nov 2011 23:52:37 +0000
Subject: [issue12822] NewGIL should use CLOCK_MONOTONIC if possible.
In-Reply-To: <1314085416.99.0.752578807259.issue12822@psf.upfronthosting.co.za>
Message-ID: <1322524357.02.0.239871549142.issue12822@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Marc-Andre is right, a runtime check is probably also needed.
(for example with mismatching kernel/libc)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12822>
_______________________________________

From report at bugs.python.org  Tue Nov 29 00:54:45 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 28 Nov 2011 23:54:45 +0000
Subject: [issue12822] NewGIL should use CLOCK_MONOTONIC if possible.
In-Reply-To: <1314085416.99.0.752578807259.issue12822@psf.upfronthosting.co.za>
Message-ID: <1322524485.53.0.627157936316.issue12822@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

pthread_condattr_setclock() result should be checked.

"The pthread_condattr_setclock() function may fail if:

EINVAL The value specified by clock_id does not refer to a known clock, or is a CPU-time clock."

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12822>
_______________________________________

From report at bugs.python.org  Tue Nov 29 01:08:33 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 29 Nov 2011 00:08:33 +0000
Subject: [issue10278] add time.wallclock() method
In-Reply-To: <1288624210.23.0.0497533122542.issue10278@psf.upfronthosting.co.za>
Message-ID: <1322525313.67.0.00247237872081.issue10278@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

As discussed elsewhere, there should be a fallback when clock_gettime() fails for the given clock.

----------
stage: committed/rejected -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10278>
_______________________________________

From report at bugs.python.org  Tue Nov 29 01:25:37 2011
From: report at bugs.python.org (Daniel Sturm)
Date: Tue, 29 Nov 2011 00:25:37 +0000
Subject: [issue13496] bisect module: Overflow at index computation
In-Reply-To: <1322519672.22.0.173147243777.issue13496@psf.upfronthosting.co.za>
Message-ID: <1322526337.44.0.820205723098.issue13496@psf.upfronthosting.co.za>


Daniel Sturm <voodoon42 at gmail.com> added the comment:

TBH I saw this more as an opportunity to get used to the whole system, how to create a patch, etc. :) Should've made it clearer at the start that this is unlikely to ever be a problem, sorry (didn't see a way to set priority to low myself).


If my math isn't completely off, the highest possible value here is 
hi + (hi - 1) so this only occurs if hi > (MAX_SSIZE_T + 1) / 2. So this would only work out if we had such an array containing only a handful different objects. And then that's me assuming that a list is actually a thin wrapper around an array of PyObject*.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13496>
_______________________________________

From report at bugs.python.org  Tue Nov 29 02:16:20 2011
From: report at bugs.python.org (Ned Deily)
Date: Tue, 29 Nov 2011 01:16:20 +0000
Subject: [issue13093] Redundant code in PyUnicode_EncodeDecimal()
In-Reply-To: <1317569955.86.0.21646060057.issue13093@psf.upfronthosting.co.za>
Message-ID: <1322529380.45.0.363744715276.issue13093@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

That fixes it.

----------
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13093>
_______________________________________

From report at bugs.python.org  Tue Nov 29 02:22:32 2011
From: report at bugs.python.org (Meador Inge)
Date: Tue, 29 Nov 2011 01:22:32 +0000
Subject: [issue13492] ./configure --with-system-ffi=LIBFFI-PATH
In-Reply-To: <1322472271.69.0.0807066602711.issue13492@psf.upfronthosting.co.za>
Message-ID: <1322529752.45.0.0730296594452.issue13492@psf.upfronthosting.co.za>


Meador Inge <meadori at gmail.com> added the comment:

Also see issue4130.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13492>
_______________________________________

From report at bugs.python.org  Tue Nov 29 03:29:02 2011
From: report at bugs.python.org (Meador Inge)
Date: Tue, 29 Nov 2011 02:29:02 +0000
Subject: [issue12945] ctypes works incorrectly with _swappedbytes_ = 1
In-Reply-To: <1315576489.44.0.807779711581.issue12945@psf.upfronthosting.co.za>
Message-ID: <1322533742.29.0.144936038024.issue12945@psf.upfronthosting.co.za>


Meador Inge <meadori at gmail.com> added the comment:

Without seeing a specific example of what you are trying to do, it is hard to tell whether ctypes would be a good fit.  I am closing this issue since the original questions have been answered.  Please open a new issue if you think ctypes could be modified to support your use cases.

----------
resolution:  -> invalid
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12945>
_______________________________________

From report at bugs.python.org  Tue Nov 29 03:33:45 2011
From: report at bugs.python.org (Meador Inge)
Date: Tue, 29 Nov 2011 02:33:45 +0000
Subject: [issue13096] ctypes: segfault with large POINTER type names
In-Reply-To: <1317700059.13.0.375039668353.issue13096@psf.upfronthosting.co.za>
Message-ID: <1322534025.62.0.259841432926.issue13096@psf.upfronthosting.co.za>


Changes by Meador Inge <meadori at gmail.com>:


----------
assignee:  -> meador.inge

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13096>
_______________________________________

From report at bugs.python.org  Tue Nov 29 03:34:19 2011
From: report at bugs.python.org (Meador Inge)
Date: Tue, 29 Nov 2011 02:34:19 +0000
Subject: [issue13097] ctypes: segfault with large number of callback arguments
In-Reply-To: <1317700637.71.0.186696346618.issue13097@psf.upfronthosting.co.za>
Message-ID: <1322534059.33.0.0921648146491.issue13097@psf.upfronthosting.co.za>


Changes by Meador Inge <meadori at gmail.com>:


----------
assignee:  -> meador.inge

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13097>
_______________________________________

From report at bugs.python.org  Tue Nov 29 03:38:48 2011
From: report at bugs.python.org (Meador Inge)
Date: Tue, 29 Nov 2011 02:38:48 +0000
Subject: [issue11427] ctypes from_buffer no longer accepts bytes
In-Reply-To: <1299481885.21.0.0627562040827.issue11427@psf.upfronthosting.co.za>
Message-ID: <1322534328.98.0.688106758078.issue11427@psf.upfronthosting.co.za>


Meador Inge <meadori at gmail.com> added the comment:

benrg, any further interest in this?  If so, please comment on my last reply.  Otherwise, I am closing this issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11427>
_______________________________________

From report at bugs.python.org  Tue Nov 29 03:43:36 2011
From: report at bugs.python.org (python_hu)
Date: Tue, 29 Nov 2011 02:43:36 +0000
Subject: [issue13493] Import error with embedded python on AIX 6.1
In-Reply-To: <1322479753.88.0.634847584065.issue13493@psf.upfronthosting.co.za>
Message-ID: <1322534616.24.0.343225556485.issue13493@psf.upfronthosting.co.za>


python_hu <nari_hu at 163.com> added the comment:

thanks a lot. as your surggest,i try python2.7.2,but when i build it on AIX 6.1, it can not compile success,breaked by xlc_c console. 
Informations:


checking size of double... 8
checking size of long double... 8
checking whether byte ordering is bigendian... yes
checking assembler .cfi pseudo-op support... no
checking whether .eh_frame section should be read-only... no
checking for __attribute__((visibility("hidden")))... no
xlc_r: 1501-210 (W) command option t contains an incorrect subargument



  xlc(1)                     IBM (2008)                      xlc(1)



  NAME
         xlc, xlc++, xlC, cc, c89, c99, xlCcore, xlc++core and
         related commands - invoke the IBM XL C/C++ compiler.


  SYNTAX
         <invocation-command> [ <option> | <inputfile> ] ...


  DESCRIPTION
         The invocation commands compile C and C++ source files.
         The commands and their recommended uses are described
         below.

         Invocations                   Usage (supported standards)
         _________________________________________________________

         xlc, xlc_r, xlc_r4,           Compile C source files.
         xlc_r7, xlc128, xlc128_r,     (ANSI C89, ISO C99,
         xlc128_r4, xlc128_r7          IBM language extensions)

         xlc++, xlc++_r, xlc++_r4,     Compile C++ source files.
         xlc++_r7, xlc++128,
         xlc++128_r, xlc++128_r4,
         xlc++128_r7, xlC, xlC_r,
         xlC_r4, xlC_r7, xlC128,
         xlC128_r, xlC128_r4,
:

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13493>
_______________________________________

From report at bugs.python.org  Tue Nov 29 03:43:47 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Tue, 29 Nov 2011 02:43:47 +0000
Subject: [issue13494] 'cast' any value to a Boolean?
In-Reply-To: <1322488868.96.0.430179402239.issue13494@psf.upfronthosting.co.za>
Message-ID: <1322534627.93.0.868198292393.issue13494@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

'bool' is just one of many conversion functions that convert their argument to the type they designate. Does this doc problem only exist for 'bool' or also for 'int', 'float' and others?

----------
nosy: +eli.bendersky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13494>
_______________________________________

From report at bugs.python.org  Tue Nov 29 03:50:19 2011
From: report at bugs.python.org (python_hu)
Date: Tue, 29 Nov 2011 02:50:19 +0000
Subject: [issue13493] Import error with embedded python on AIX 6.1
In-Reply-To: <1322479753.88.0.634847584065.issue13493@psf.upfronthosting.co.za>
Message-ID: <1322535019.3.0.603186787718.issue13493@psf.upfronthosting.co.za>


python_hu <nari_hu at 163.com> added the comment:

By the way,i have compared the "configure.in" with Python-2.7_shared_AIX.diff in Issue941346,and can not find any modification of building share library on AIX in Python 2.7.2' source code.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13493>
_______________________________________

From report at bugs.python.org  Tue Nov 29 04:01:18 2011
From: report at bugs.python.org (Meador Inge)
Date: Tue, 29 Nov 2011 03:01:18 +0000
Subject: [issue13096] ctypes: segfault with large POINTER type names
In-Reply-To: <1317700059.13.0.375039668353.issue13096@psf.upfronthosting.co.za>
Message-ID: <1322535678.43.0.269206122732.issue13096@psf.upfronthosting.co.za>


Meador Inge <meadori at gmail.com> added the comment:

Here is a small patch against tip.  OK?

----------
keywords: +patch
stage: needs patch -> patch review
Added file: http://bugs.python.org/file23800/issue13096.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13096>
_______________________________________

From report at bugs.python.org  Tue Nov 29 04:20:18 2011
From: report at bugs.python.org (vterron)
Date: Tue, 29 Nov 2011 03:20:18 +0000
Subject: [issue13223] pydoc removes 'self' in HTML for method docstrings with
	example code
In-Reply-To: <1319050782.47.0.924539258184.issue13223@psf.upfronthosting.co.za>
Message-ID: <1322536818.94.0.172949901767.issue13223@psf.upfronthosting.co.za>


Changes by vterron <quintanar at gmail.com>:


Removed file: http://bugs.python.org/file23477/issue13223.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13223>
_______________________________________

From report at bugs.python.org  Tue Nov 29 04:23:38 2011
From: report at bugs.python.org (vterron)
Date: Tue, 29 Nov 2011 03:23:38 +0000
Subject: [issue13223] pydoc removes 'self' in HTML for method docstrings with
	example code
In-Reply-To: <1319050782.47.0.924539258184.issue13223@psf.upfronthosting.co.za>
Message-ID: <1322537018.56.0.24188891749.issue13223@psf.upfronthosting.co.za>


vterron <quintanar at gmail.com> added the comment:

Patch updated with the test cases. I have added a third class to Lib/test/pydoc_mod.py and updated two of the existing cases, test_text_doc and test_html_doc, accordingly.

The news entry could be: "Issue #13223: Fix pydoc.writedoc so that the HTML documentation for methods that use 'self' in the example code is generated correctly."

----------
Added file: http://bugs.python.org/file23801/issue13223.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13223>
_______________________________________

From report at bugs.python.org  Tue Nov 29 06:02:21 2011
From: report at bugs.python.org (vterron)
Date: Tue, 29 Nov 2011 05:02:21 +0000
Subject: [issue13223] pydoc removes 'self' in HTML for method docstrings with
	example code
In-Reply-To: <1319050782.47.0.924539258184.issue13223@psf.upfronthosting.co.za>
Message-ID: <1322542941.15.0.631551091731.issue13223@psf.upfronthosting.co.za>


Changes by vterron <quintanar at gmail.com>:


Added file: http://bugs.python.org/file23802/issue13223_python2.7.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13223>
_______________________________________

From report at bugs.python.org  Tue Nov 29 07:04:57 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 29 Nov 2011 06:04:57 +0000
Subject: [issue4502] Allowing get_pre_input_hook from Readline
In-Reply-To: <1228268977.11.0.20813106029.issue4502@psf.upfronthosting.co.za>
Message-ID: <1322546697.88.0.350505405452.issue4502@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
components: +Extension Modules -Library (Lib)
stage:  -> test needed
versions: +Python 3.3 -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4502>
_______________________________________

From report at bugs.python.org  Tue Nov 29 07:06:45 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 29 Nov 2011 06:06:45 +0000
Subject: [issue6766] Cannot modify dictionaries inside dictionaries using
	Managers from multiprocessing
In-Reply-To: <1251049590.58.0.809281249474.issue6766@psf.upfronthosting.co.za>
Message-ID: <1322546805.04.0.370753754019.issue6766@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
stage:  -> needs patch
versions: +Python 2.7 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6766>
_______________________________________

From report at bugs.python.org  Tue Nov 29 07:07:44 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 29 Nov 2011 06:07:44 +0000
Subject: [issue12771] 2to3 -d adds extra whitespace
In-Reply-To: <1313593187.97.0.649094225681.issue12771@psf.upfronthosting.co.za>
Message-ID: <1322546864.69.0.00234651389697.issue12771@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +benjamin.peterson
stage:  -> test needed
type:  -> behavior
versions: +Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12771>
_______________________________________

From report at bugs.python.org  Tue Nov 29 07:09:07 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 29 Nov 2011 06:09:07 +0000
Subject: [issue6167] Tkinter.Scrollbar: the activate method needs to return a
	value, and set should take only two args
In-Reply-To: <1243887092.8.0.492821608561.issue6167@psf.upfronthosting.co.za>
Message-ID: <1322546947.86.0.562042968024.issue6167@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy:  -BreamoreBoy
versions: +Python 3.3 -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6167>
_______________________________________

From report at bugs.python.org  Tue Nov 29 07:10:33 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 29 Nov 2011 06:10:33 +0000
Subject: [issue11113] html.entities mapping dicts need updating?
In-Reply-To: <1296791035.1.0.458454998569.issue11113@psf.upfronthosting.co.za>
Message-ID: <1322547033.54.0.828442524205.issue11113@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
assignee:  -> ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11113>
_______________________________________

From report at bugs.python.org  Tue Nov 29 07:12:09 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 29 Nov 2011 06:12:09 +0000
Subject: [issue11001] Various obvious errors in cookies documentation
In-Reply-To: <1295908065.55.0.221906287574.issue11001@psf.upfronthosting.co.za>
Message-ID: <1322547129.94.0.812461319454.issue11001@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
keywords: +easy
nosy: +petri.lehtinen
stage:  -> patch review
versions: +Python 3.3 -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11001>
_______________________________________

From report at bugs.python.org  Tue Nov 29 07:14:21 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 29 Nov 2011 06:14:21 +0000
Subject: [issue5815] locale.getdefaultlocale() missing corner case
In-Reply-To: <1240424446.58.0.284100987299.issue5815@psf.upfronthosting.co.za>
Message-ID: <1322547261.62.0.597594427254.issue5815@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
keywords: +easy
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/issue5815>
_______________________________________

From report at bugs.python.org  Tue Nov 29 07:16:10 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 29 Nov 2011 06:16:10 +0000
Subject: [issue3665] Support \u and \U escapes in regexes
In-Reply-To: <1219610032.28.0.862215531927.issue3665@psf.upfronthosting.co.za>
Message-ID: <1322547370.06.0.614285410575.issue3665@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +mrabarnett

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3665>
_______________________________________

From report at bugs.python.org  Tue Nov 29 07:18:01 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 29 Nov 2011 06:18:01 +0000
Subject: [issue10052] Python/dtoa.c:158: #error "Failed to find an exact-width
	32-bit integer type" (FreeBSD 4.11 + gcc 2.95.4)
In-Reply-To: <1286609205.46.0.0704666326351.issue10052@psf.upfronthosting.co.za>
Message-ID: <1322547481.02.0.969640197582.issue10052@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
stage:  -> patch review
versions:  -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10052>
_______________________________________

From report at bugs.python.org  Tue Nov 29 07:20:35 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 29 Nov 2011 06:20:35 +0000
Subject: [issue7238] frame.f_lineno doesn't get updated after local trace
	function assigned to it
In-Reply-To: <1256836618.71.0.0275056583438.issue7238@psf.upfronthosting.co.za>
Message-ID: <1322547635.16.0.923910074834.issue7238@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ncoghlan
versions: +Python 3.3 -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7238>
_______________________________________

From report at bugs.python.org  Tue Nov 29 07:23:27 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 29 Nov 2011 06:23:27 +0000
Subject: [issue12790] doctest.testmod does not run tests in functools.partial
	functions
In-Reply-To: <1313812473.15.0.9197967798.issue12790@psf.upfronthosting.co.za>
Message-ID: <1322547807.81.0.354344441235.issue12790@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
components: +Library (Lib)
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12790>
_______________________________________

From report at bugs.python.org  Tue Nov 29 07:24:40 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 29 Nov 2011 06:24:40 +0000
Subject: [issue8065] Memory leak in readline.get_current_history_length
In-Reply-To: <1267784862.24.0.455687340788.issue8065@psf.upfronthosting.co.za>
Message-ID: <1322547880.98.0.469113318629.issue8065@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
versions:  -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8065>
_______________________________________

From report at bugs.python.org  Tue Nov 29 07:25:47 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 29 Nov 2011 06:25:47 +0000
Subject: [issue12919] Control what module is imported first
In-Reply-To: <1315331616.23.0.265275073086.issue12919@psf.upfronthosting.co.za>
Message-ID: <1322547947.35.0.426240119672.issue12919@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12919>
_______________________________________

From report at bugs.python.org  Tue Nov 29 07:26:02 2011
From: report at bugs.python.org (Eric Snow)
Date: Tue, 29 Nov 2011 06:26:02 +0000
Subject: [issue1877] unhelpful error when calling "python <dirname>"
In-Reply-To: <1200840488.22.0.553950533734.issue1877@psf.upfronthosting.co.za>
Message-ID: <1322547962.98.0.907452102736.issue1877@psf.upfronthosting.co.za>


Changes by Eric Snow <ericsnowcurrently at gmail.com>:


----------
nosy: +eric.snow

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1877>
_______________________________________

From report at bugs.python.org  Tue Nov 29 07:32:39 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 29 Nov 2011 06:32:39 +0000
Subject: [issue1040439] Missing documentation on How To Link With libpython
Message-ID: <1322548359.94.0.711040844101.issue1040439@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy:  -BreamoreBoy
stage:  -> needs patch
versions: +Python 2.7, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1040439>
_______________________________________

From report at bugs.python.org  Tue Nov 29 07:33:51 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 29 Nov 2011 06:33:51 +0000
Subject: [issue6753] Python 3.1.1 test_cmd_line fails on Fedora 11
In-Reply-To: <1250849471.77.0.183054552926.issue6753@psf.upfronthosting.co.za>
Message-ID: <1322548431.8.0.735423519225.issue6753@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Is this still an issue?

----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6753>
_______________________________________

From report at bugs.python.org  Tue Nov 29 07:34:28 2011
From: report at bugs.python.org (Eric Snow)
Date: Tue, 29 Nov 2011 06:34:28 +0000
Subject: [issue6816] Provide CPython command line functionality via runpy
	module
In-Reply-To: <1251802599.29.0.539498266032.issue6816@psf.upfronthosting.co.za>
Message-ID: <1322548468.34.0.0623832166691.issue6816@psf.upfronthosting.co.za>


Changes by Eric Snow <ericsnowcurrently at gmail.com>:


----------
nosy: +eric.snow

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6816>
_______________________________________

From report at bugs.python.org  Tue Nov 29 07:35:46 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 29 Nov 2011 06:35:46 +0000
Subject: [issue5654] Add C hook in PyDict_SetItem for debuggers
In-Reply-To: <1238604905.42.0.578461685574.issue5654@psf.upfronthosting.co.za>
Message-ID: <1322548546.38.0.218608007569.issue5654@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
stage:  -> needs patch
type:  -> feature request
versions: +Python 3.3 -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5654>
_______________________________________

From report at bugs.python.org  Tue Nov 29 07:36:21 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 29 Nov 2011 06:36:21 +0000
Subject: [issue7074] Turtle module crashes python
In-Reply-To: <1254872370.89.0.72942382773.issue7074@psf.upfronthosting.co.za>
Message-ID: <1322548581.19.0.383700761248.issue7074@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
versions: +Python 3.3 -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7074>
_______________________________________

From report at bugs.python.org  Tue Nov 29 07:37:39 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 29 Nov 2011 06:37:39 +0000
Subject: [issue6899] Base.replace breaks tree
In-Reply-To: <1252831841.16.0.893335369907.issue6899@psf.upfronthosting.co.za>
Message-ID: <1322548659.78.0.631689547929.issue6899@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
stage:  -> patch review
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6899>
_______________________________________

From report at bugs.python.org  Tue Nov 29 07:40:08 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 29 Nov 2011 06:40:08 +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: <1322548808.5.0.922779361944.issue11374@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11374>
_______________________________________

From report at bugs.python.org  Tue Nov 29 08:00:03 2011
From: report at bugs.python.org (Ben Wolfson)
Date: Tue, 29 Nov 2011 07:00:03 +0000
Subject: [issue12014] str.format parses replacement field incorrectly
In-Reply-To: <1304646359.82.0.599761597998.issue12014@psf.upfronthosting.co.za>
Message-ID: <1322550003.15.0.695527443624.issue12014@psf.upfronthosting.co.za>


Ben Wolfson <wolfson at gmail.com> added the comment:

I just noticed that the patch labelled strformat-as-document is actually the same as the other one, owing to my incompetence. Anyway, as far as I can tell the patches would have to be reworked in the light of recent changes anyway. I am willing to do this if there's actually interest. Otherwise, is there anything else I can do here? Is it necessary to write a PEP or take this to python-ideas or something?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12014>
_______________________________________

From report at bugs.python.org  Tue Nov 29 08:05:39 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 29 Nov 2011 07:05:39 +0000
Subject: [issue13493] Import error with embedded python on AIX 6.1
In-Reply-To: <1322479753.88.0.634847584065.issue13493@psf.upfronthosting.co.za>
Message-ID: <1322550339.48.0.624399338948.issue13493@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Is the man page really displayed during compilation? It's a bit weird that the CC compiler behaves this way. Is this common behavior on AIX?

By the way, you are already in the "make" command;  the output you show is made during compilation of the "_ctypes" module, by the script Modules/_ctypes/libffi/configure.  Can you try and see which part of the script displays the man page?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13493>
_______________________________________

From report at bugs.python.org  Tue Nov 29 08:19:49 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 29 Nov 2011 07:19:49 +0000
Subject: [issue3932] HTMLParser cannot handle '&' and non-ascii characters in
	attribute names
In-Reply-To: <1222086790.7.0.800001604957.issue3932@psf.upfronthosting.co.za>
Message-ID: <1322551189.53.0.768213989216.issue3932@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

I'll change this in a doc issue then.

Any suggestions about the wording?
Adding "Passing unicode strings is suggested/advised/preferred." in the .feed() section is a bit vague, and mentioning the problem (with str it might break in some corner cases) while keeping a positive tone is somewhat difficult.

----------
components: +Documentation -Library (Lib)
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3932>
_______________________________________

From report at bugs.python.org  Tue Nov 29 08:30:32 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Tue, 29 Nov 2011 07:30:32 +0000
Subject: [issue1040439] Missing documentation on How To Link With libpython
Message-ID: <1322551832.97.0.949689005852.issue1040439@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/issue1040439>
_______________________________________

From report at bugs.python.org  Tue Nov 29 08:36:27 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 29 Nov 2011 07:36:27 +0000
Subject: [issue5654] Add C hook in PyDict_SetItem for debuggers
In-Reply-To: <1238604905.42.0.578461685574.issue5654@psf.upfronthosting.co.za>
Message-ID: <1322552187.36.0.450699836782.issue5654@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Can this be closed?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5654>
_______________________________________

From report at bugs.python.org  Tue Nov 29 09:02:24 2011
From: report at bugs.python.org (python_hu)
Date: Tue, 29 Nov 2011 08:02:24 +0000
Subject: [issue13493] Import error with embedded python on AIX 6.1
In-Reply-To: <1322479753.88.0.634847584065.issue13493@psf.upfronthosting.co.za>
Message-ID: <1322553744.96.0.453186271729.issue13493@psf.upfronthosting.co.za>


python_hu <nari_hu at 163.com> added the comment:

Sorry,it just a common behave of xlC_r,we can ignore it.

So i sucess build libpython2.7.so using --enable-shared:

./configure --enable-shared --with-gcc="xlc_r -q64" --with-cxx="xlC_r -q64" --disable-ipv6 AR="ar -X64"

I make install python2.7.2,but when i run python2.7,it crashed. why  python2.7 can not load libpython2.7.so? libpython2.7.so has been installed at /usr/local/lib

informations:


# ls
2to3                  idle                  python2.5-config
autoconf              ifnames               python2.5-config-bak
autoheader            m4                    python2.6
autom4te              oraenv                python2.6-config
autoreconf            pydoc                 python2.7
autoscan              python                python2.7-config
autoupdate            python-config         smtpd.py
coraenv               python-config-bak     tclsh8.4
dbhome                python2.5             wish8.4
# python2.7
exec():509-036 can not load program python2.7 because of
        0509-150 can not load sub module libpython2.7.so
        0509-022 can not load  libpython2.7.so
        0509-026 system erro: file or dir do noe exists;
#

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13493>
_______________________________________

From report at bugs.python.org  Tue Nov 29 09:07:27 2011
From: report at bugs.python.org (Eric Snow)
Date: Tue, 29 Nov 2011 08:07:27 +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: <1322554047.58.0.804324555024.issue11374@psf.upfronthosting.co.za>


Changes by Eric Snow <ericsnowcurrently at gmail.com>:


----------
nosy: +eric.snow

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11374>
_______________________________________

From report at bugs.python.org  Tue Nov 29 09:22:09 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Tue, 29 Nov 2011 08:22:09 +0000
Subject: [issue13481] Use an accurate clock in timeit
In-Reply-To: <1322520021.95.0.587171658447.issue13481@psf.upfronthosting.co.za>
Message-ID: <CAH_1eM0R_a6nbHEHW9B2UVUVFwriL=+AqsiKvcLtUTCbpKk7Kg@mail.gmail.com>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

> Are CLOCK_MONOTONIC_RAW, CLOCK_MONOTONIC and CLOCK_REALTIME more accurate than gettimeofday (time.time)?

Actually, on Linux gettimeofday() returns CLOCK_REALTIME.
As for CLOCK_MONOTONIC{_RAW}, they're guaranteed not to go backward
(NTP and such).
But I think Antoine was referring to CPU time vs wall clock time (but
see comments above while this is probably a bad idea).

> I think this should be rejected.

Agreed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13481>
_______________________________________

From report at bugs.python.org  Tue Nov 29 09:29:15 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 29 Nov 2011 08:29:15 +0000
Subject: [issue13493] Import error with embedded python on AIX 6.1
In-Reply-To: <1322479753.88.0.634847584065.issue13493@psf.upfronthosting.co.za>
Message-ID: <1322555355.71.0.079073775234.issue13493@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

I'm sorry I don't know much about AIX. How are shared libraries searched? is /usr/local/lib a standard place for them?

After a couple of google search I suggest the following command:
   LIBPATH=/usr/local/lib:/usr/lib python2.7

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13493>
_______________________________________

From report at bugs.python.org  Tue Nov 29 09:43:04 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 29 Nov 2011 08:43:04 +0000
Subject: [issue11113] html.entities mapping dicts need updating?
In-Reply-To: <1296791035.1.0.458454998569.issue11113@psf.upfronthosting.co.za>
Message-ID: <1322556184.55.0.779951108031.issue11113@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

http://www.w3.org/TR/html5/named-character-references.html lists 2152 HTML 5 entities (see also attached file for a dict generated from that table).
Currently html.entities only has 252 entities, organized in 3 dicts:
  1) name -> intvalue (e.g. 'amp': 0x0026);
  2) intvalue -> name (e.g. 0x0026: 'amp');
  3) name -> char (e.g. 'amp': '&');

In HTML 5, some of the entities map to a sequence of 2 characters, for example &NotEqualTilde; corresponds to [U+2242, U+0338] (i.e. MINUS TILDE + COMBINING LONG SOLIDUS OVERLAY).

This means that:
  1) the current approach of having a dict with name -> intvalue doesn't work anymore, and a name -> valuelist should be used instead;
  2) the reverse dict for this would have to use tuples as keys, but I'm not sure how useful would that be (producing entities is not a common case, especially "unusual" ones like these).
  3) The name -> char dict might still be useful, and can easily become a name -> str dict in order to deal with the multichar entities;

Since 1) is not backward-compatible the HTML5 entities should probably go in a separate dict.

Also note that the entities are case-sensitive and some of them include different spellings (e.g. both 'amp' and 'AMP' map to '&'), so the reverse dict won't work too well.  Having '&' -> 'amp' seems better than '&' -> 'AMP', but this might not be obvious for all the entities and requires some extra logic in the code to get it right.

----------
Added file: http://bugs.python.org/file23803/entities_dict.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11113>
_______________________________________

From report at bugs.python.org  Tue Nov 29 11:40:22 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 29 Nov 2011 10:40:22 +0000
Subject: [issue13481] Use an accurate clock in timeit
In-Reply-To: <1322265721.78.0.0567796730825.issue13481@psf.upfronthosting.co.za>
Message-ID: <1322563222.02.0.90268116207.issue13481@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Ok, closing.

----------
resolution:  -> rejected
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13481>
_______________________________________

From report at bugs.python.org  Tue Nov 29 11:43:11 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 29 Nov 2011 10:43:11 +0000
Subject: [issue5654] Add C hook in PyDict_SetItem for debuggers
In-Reply-To: <1238604905.42.0.578461685574.issue5654@psf.upfronthosting.co.za>
Message-ID: <1322563391.99.0.00936382197668.issue5654@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I see no reason to close until benchmark results prove it decreases real-life performance. Looking at the patch, the cost in the normal case is a single pointer comparison with NULL, something very cheap.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5654>
_______________________________________

From report at bugs.python.org  Tue Nov 29 11:48:09 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 29 Nov 2011 10:48:09 +0000
Subject: [issue13475] Add '-p'/'--path0' command line option to override
	sys.path[0] initialisation
In-Reply-To: <1322181994.22.0.955887054946.issue13475@psf.upfronthosting.co.za>
Message-ID: <1322563689.93.0.868711779496.issue13475@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

I realised "-P" is available for use as the short form of the "suppress sys.path[0] initialisation" option.

So "-p" would override the calculation of sys.path[0], while "-P" would switch it off completely (similar to the way "-S" and "-E" switch off other aspects of the normal initialisation process).

Whether or not to provide "--path0" and "--nopath0" as long form alternatives would then be a separate question.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13475>
_______________________________________

From report at bugs.python.org  Tue Nov 29 12:21:47 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 29 Nov 2011 11:21:47 +0000
Subject: [issue12919] Control what module is imported first
In-Reply-To: <1315331616.23.0.265275073086.issue12919@psf.upfronthosting.co.za>
Message-ID: <1322565707.53.0.259885608178.issue12919@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I don't think conflating two orthogonal needs in a single "feature" like that is a good idea. This will become one of these obscure implementation details which complicate the code for no real benefit. If there's a need to "customize the first import" then a proper proposal should be made rather than a quick hack.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12919>
_______________________________________

From report at bugs.python.org  Tue Nov 29 12:29:15 2011
From: report at bugs.python.org (Garrett Cooper)
Date: Tue, 29 Nov 2011 11:29:15 +0000
Subject: [issue13497] Fix for broken nice test on non-broken platforms with
	pedantic compilers
Message-ID: <1322566155.29.0.23147421321.issue13497@psf.upfronthosting.co.za>


New submission from Garrett Cooper <yanegomi at gmail.com>:

Was poking around config.log and I saw that gcc was complaining of some undefined built-in symbols for the broken nice test in configure. This patch fixes that.

----------
files: configure-fix-broken-broken-nice-test.patch
keywords: patch
messages: 148554
nosy: yaneurabeya
priority: normal
severity: normal
status: open
title: Fix for broken nice test on non-broken platforms with pedantic compilers
type: compile error
versions: Python 3.4
Added file: http://bugs.python.org/file23804/configure-fix-broken-broken-nice-test.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13497>
_______________________________________

From report at bugs.python.org  Tue Nov 29 12:42:50 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 29 Nov 2011 11:42:50 +0000
Subject: [issue13497] Fix for broken nice test on non-broken platforms with
	pedantic compilers
In-Reply-To: <1322566155.29.0.23147421321.issue13497@psf.upfronthosting.co.za>
Message-ID: <1322566970.15.0.332810258143.issue13497@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
stage:  -> patch review
versions: +Python 2.7, Python 3.2, Python 3.3 -Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13497>
_______________________________________

From report at bugs.python.org  Tue Nov 29 12:47:22 2011
From: report at bugs.python.org (Garrett Cooper)
Date: Tue, 29 Nov 2011 11:47:22 +0000
Subject: [issue13497] Fix for broken nice test on non-broken platforms with
	pedantic compilers
In-Reply-To: <1322566155.29.0.23147421321.issue13497@psf.upfronthosting.co.za>
Message-ID: <1322567242.74.0.989020710352.issue13497@psf.upfronthosting.co.za>


Garrett Cooper <yanegomi at gmail.com> added the comment:

Other potential issues are provided below:

configure:9015: checking if PTHREAD_SCOPE_SYSTEM is supported
configure:9038: gcc -pthread -o conftest -I/usr/include/edit   conftest.c  >&5
conftest.c: In function 'main':
conftest.c:101: warning: incompatible implicit declaration of built-in function 'exit'
configure:9038: $? = 0

configure:9079: checking if --enable-ipv6 is specified
configure:9119: gcc -pthread -o conftest -I/usr/include/edit   conftest.c  >&5
conftest.c: In function 'main':
conftest.c:102: warning: incompatible implicit declaration of built-in function 'exit'
configure:9119: $? = 0

configure:12462: checking whether wchar_t is signed
configure:12482: gcc -pthread -o conftest -I/usr/include/edit   conftest.c  -lutil >&5
conftest.c: In function 'main':
conftest.c:272: warning: incompatible implicit declaration of built-in function 'exit'
configure:12482: $? = 0

configure:12800: checking whether right shift extends the sign bit
configure:12818: gcc -pthread -o conftest -I/usr/include/edit   conftest.c  -lutil >&5
conftest.c: In function 'main':
conftest.c:273: warning: incompatible implicit declaration of built-in function 'exit'
configure:12818: $? = 0

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13497>
_______________________________________

From report at bugs.python.org  Tue Nov 29 13:50:45 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 29 Nov 2011 12:50:45 +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: <1322571045.82.0.958223705822.issue11374@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

.pyo files are used if sys.dont_write_bytecode is false and sys.flags.optimize is >= 1 (IOW, true).

For Python 3.2 and 3.3, imp.cache_from_source should be used to get the right paths (see PEP 3147).

Before you put more work into this, it would be nice to get confirmation from one import expert that the bug is valid: I know the import system only superficially, and I?m not sure that package/__init__.pyc / .pyo is supported by import (if not, then pkgutil should also not support it).

----------
nosy: +barry, ncoghlan, pje

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11374>
_______________________________________

From report at bugs.python.org  Tue Nov 29 14:03:40 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 29 Nov 2011 13:03:40 +0000
Subject: [issue13462] Improve code and tests for Mixin2to3
In-Reply-To: <1322066341.39.0.436349182896.issue13462@psf.upfronthosting.co.za>
Message-ID: <1322571820.83.0.872491639587.issue13462@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Thanks, I?ll adapt the code for older Pythons.

Bumped down, I won?t do this for d2 1.0a3.

----------
priority: release blocker -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13462>
_______________________________________

From report at bugs.python.org  Tue Nov 29 14:05:47 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 29 Nov 2011 13:05:47 +0000
Subject: [issue11379] Remove "lightweight" from minidom description
In-Reply-To: <1299093908.17.0.828802315354.issue11379@psf.upfronthosting.co.za>
Message-ID: <1322571947.99.0.425607072672.issue11379@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Is memory footprint something important enough to put in the doc?  Ease of use is IMO more important, but then it becomes subjective..

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11379>
_______________________________________

From report at bugs.python.org  Tue Nov 29 14:09:58 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 29 Nov 2011 13:09:58 +0000
Subject: [issue13223] pydoc removes 'self' in HTML for method docstrings with
	example code
In-Reply-To: <1319050782.47.0.924539258184.issue13223@psf.upfronthosting.co.za>
Message-ID: <1322572198.99.0.277058087803.issue13223@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Patch looks good to me.  Ezio, do you have time to review too?

(I had forgotten that there were tests checking the exact HTML output.  This won?t be fun when we overhaul pydoc to make it generate sensible HTML.)

----------
nosy: +eric.araujo
stage: test needed -> patch review
versions: +Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13223>
_______________________________________

From report at bugs.python.org  Tue Nov 29 14:12:30 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 29 Nov 2011 13:12:30 +0000
Subject: [issue6753] Python 3.1.1 test_cmd_line fails on Fedora 11
In-Reply-To: <1250849471.77.0.183054552926.issue6753@psf.upfronthosting.co.za>
Message-ID: <1322572350.79.0.238525068933.issue6753@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


Removed file: http://bugs.python.org/file14760/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6753>
_______________________________________

From report at bugs.python.org  Tue Nov 29 14:14:09 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 29 Nov 2011 13:14:09 +0000
Subject: [issue6753] Python 3.1.1 test_cmd_line fails on Fedora 11
In-Reply-To: <1250849471.77.0.183054552926.issue6753@psf.upfronthosting.co.za>
Message-ID: <1322572449.07.0.758756941507.issue6753@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

A lot of bugs related to encodings has been fixed. The bug was seen on Python 3.1, whereas the current development version is 3.3. We have a Fedora buildbot and many Fedora users, none reported such error recently. I consider this issue as fixed.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6753>
_______________________________________

From report at bugs.python.org  Tue Nov 29 14:17:09 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 29 Nov 2011 13:17:09 +0000
Subject: [issue6899] Base.replace breaks tree
In-Reply-To: <1252831841.16.0.893335369907.issue6899@psf.upfronthosting.co.za>
Message-ID: <1322572629.05.0.993470437356.issue6899@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
versions: +Python 2.7, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6899>
_______________________________________

From report at bugs.python.org  Tue Nov 29 14:19:48 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 29 Nov 2011 13:19:48 +0000
Subject: [issue11427] ctypes from_buffer no longer accepts bytes
In-Reply-To: <1299481885.21.0.0627562040827.issue11427@psf.upfronthosting.co.za>
Message-ID: <1322572788.41.0.126449593927.issue11427@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

.from_buffer() expects a modifiable buffer, bytes type is immutable. If .from_buffer() accepted an immutable buffer, it was a bug and the bug was fixed.

If you want to use bytes, use .from_buffer_copy() instead of .from_buffer().

----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11427>
_______________________________________

From report at bugs.python.org  Tue Nov 29 14:39:50 2011
From: report at bugs.python.org (Stefan Behnel)
Date: Tue, 29 Nov 2011 13:39:50 +0000
Subject: [issue11379] Remove "lightweight" from minidom description
In-Reply-To: <1299093908.17.0.828802315354.issue11379@psf.upfronthosting.co.za>
Message-ID: <1322573990.15.0.344504923607.issue11379@psf.upfronthosting.co.za>


Stefan Behnel <scoder at users.sourceforge.net> added the comment:

I find a factor of an order of magnitude worth mentioning, because it prevents certain kinds of usages.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11379>
_______________________________________

From report at bugs.python.org  Tue Nov 29 14:41:14 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 29 Nov 2011 13:41:14 +0000
Subject: [issue9196] Improve docs for string interpolation "%s" re Unicode
	strings
In-Reply-To: <1278572830.17.0.148747735024.issue9196@psf.upfronthosting.co.za>
Message-ID: <1322574074.29.0.0239596275808.issue9196@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

More info on this thread: http://mail.python.org/pipermail/python-dev/2006-December/070237.html

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9196>
_______________________________________

From report at bugs.python.org  Tue Nov 29 14:42:03 2011
From: report at bugs.python.org (R. David Murray)
Date: Tue, 29 Nov 2011 13:42:03 +0000
Subject: [issue13498] os.makedirs exist_ok documentation is incorrect,
	as is some of the behavior
Message-ID: <1322574123.12.0.756700598965.issue13498@psf.upfronthosting.co.za>


New submission from R. David Murray <rdmurray at bitdance.com>:

The documentation for os.makedirs says:

  If the target directory with the same mode as specified already exists, raises an OSError exception if exist_ok is False, otherwise no exception is raised.

This is not correct.  If the file exists but the mode is different than that specified (or defaulted) after applying the umask, then an error is raised regardless of the value of exist_ok.  The above wording also implies that if the directory exists but has a different mode, that the mode will be changed.  Again, this is not what the code does.

It's not clear how useful this raise behavior is, but reading the original issue that added this option it is clearly intentional.  The documented behavior does seem useful, but if it actually reset the mode that would be a fairly significant behavior change, and would not be a good idea if the user had not specified a mode.  However, at the very least exists_ok should not raise if no mode was specified in the call.

The error message raised is also wrong in this case, since it says that the error is that the file already exists when we've said that that is OK.  A custom error message for this case would be better.

----------
assignee: docs at python
components: Documentation, Library (Lib)
keywords: easy
messages: 148564
nosy: docs at python, r.david.murray
priority: normal
severity: normal
stage: needs patch
status: open
title: os.makedirs exist_ok documentation is incorrect, as is some of the behavior
type: behavior
versions: Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13498>
_______________________________________

From report at bugs.python.org  Tue Nov 29 14:46:54 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 29 Nov 2011 13:46:54 +0000
Subject: [issue11379] Remove "lightweight" from minidom description
In-Reply-To: <1299093908.17.0.828802315354.issue11379@psf.upfronthosting.co.za>
Message-ID: <1322574414.38.0.328404703738.issue11379@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Usually we don't talk about performance in the doc, and in my personal experience I didn't notice any major difference between the different implementations (but than again I haven't used them much).
Talking about the other implementations and their advantages/disadvantages is fine, but things like "MiniDOM has a several times larger memory footprint" seems like FUD to me (see also http://docs.python.org/dev/documenting/style.html#affirmative-tone).

----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11379>
_______________________________________

From report at bugs.python.org  Tue Nov 29 14:49:08 2011
From: report at bugs.python.org (Fred L. Drake, Jr.)
Date: Tue, 29 Nov 2011 13:49:08 +0000
Subject: [issue11379] Remove "lightweight" from minidom description
In-Reply-To: <1299093908.17.0.828802315354.issue11379@psf.upfronthosting.co.za>
Message-ID: <1322574548.83.0.103950845174.issue11379@psf.upfronthosting.co.za>


Fred L. Drake, Jr. <fred at fdrake.net> added the comment:

Removing "Lightweight" and changing the first paragraph to (something like)

:mod:`xml.dom.minidom` is an implementation of the Document Object Model
interface.  The API is slightly simpler than the full W3C DOM, but the
implementation has a significantly higher memory footprint than
:mod:`xml.dom.etree`.

would be entirely reasonable.

(I don't think it's wrong to discuss relative memory footprints in comparison to other modules in the standard library.)

----------
nosy: +fdrake

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11379>
_______________________________________

From report at bugs.python.org  Tue Nov 29 15:03:40 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 29 Nov 2011 14:03:40 +0000
Subject: [issue13496] bisect module: Overflow at index computation
In-Reply-To: <1322519672.22.0.173147243777.issue13496@psf.upfronthosting.co.za>
Message-ID: <1322575420.88.0.360814868035.issue13496@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Given that we typically need at least 4 bytes just for the PyObject * pointer for each item in a list, I guess real lists are safe.

But how about list-like objects, implementing __len__ and __getitem__?  The following appears to run forever on my machine:



class SquaresList(object):
    def __init__(self, length):
        self._length = length

    def __len__(self):
        return self._length

    def __getitem__(self, index):
        if not 0 <= index <= self._length:
            raise IndexError
        return index**2


import bisect, sys

squareslist = SquaresList(sys.maxsize)
print bisect.bisect(squareslist, (sys.maxsize - 3)**2)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13496>
_______________________________________

From report at bugs.python.org  Tue Nov 29 15:05:05 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 29 Nov 2011 14:05:05 +0000
Subject: [issue1040439] Missing documentation on how to link with libpython
Message-ID: <1322575505.82.0.151090701844.issue1040439@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I did not found all these Google hist.  Most of the links on the first page for ?link libpython? are bug reports which are rejected by maintainers.  Related: http://mail.python.org/pipermail/python-dev/2006-February/060549.html

So, what do people link with libpython for?

----------
nosy: +eric.araujo
title: Missing documentation on How To Link With libpython -> Missing documentation on how to link with libpython

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1040439>
_______________________________________

From report at bugs.python.org  Tue Nov 29 15:05:45 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 29 Nov 2011 14:05:45 +0000
Subject: [issue13496] bisect module: Overflow at index computation
In-Reply-To: <1322519672.22.0.173147243777.issue13496@psf.upfronthosting.co.za>
Message-ID: <1322575545.32.0.97693146398.issue13496@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Very good point, Mark.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13496>
_______________________________________

From report at bugs.python.org  Tue Nov 29 15:12:25 2011
From: report at bugs.python.org (Stefan Behnel)
Date: Tue, 29 Nov 2011 14:12:25 +0000
Subject: [issue11379] Remove "lightweight" from minidom description
In-Reply-To: <1299093908.17.0.828802315354.issue11379@psf.upfronthosting.co.za>
Message-ID: <1322575945.15.0.823673439388.issue11379@psf.upfronthosting.co.za>


Stefan Behnel <scoder at users.sourceforge.net> added the comment:

I don't think "FUD" is a suitable term for the rather minidom-friendly wording in my last proposal. Seriously, minidom is widely known for being extremely slow and extremely memory hungry. And that is backed by basically any benchmark that has ever been done on the subject. If 4DOM, which Martin cites, is really worse in terms of performance (I never used it), it must truly be the only existing species of that kind.

Still, here's a cleaned up version of Fred's proposal that I could live with:

"""
:mod:`xml.dom.minidom` --- Pure Python DOM implementation

:mod:`xml.dom.minidom` is an implementation of the Document Object Model interface.  The API is (intentionally) slightly simpler than the full W3C DOM, but the implementation has a significantly higher memory footprint than the XML tree library in :mod:`xml.etree.ElementTree`.
"""

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11379>
_______________________________________

From report at bugs.python.org  Tue Nov 29 15:13:36 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Tue, 29 Nov 2011 14:13:36 +0000
Subject: [issue13499] uuid documentation example uses invalid REPL/doctest
	syntax
Message-ID: <1322576016.96.0.843898665466.issue13499@psf.upfronthosting.co.za>


New submission from Petri Lehtinen <petri at digip.org>:

See http://docs.python.org/library/uuid.html#example.

Comments are output lines, i.e. not prefixed with >>>, which breaks the ">>>" button that makes the example copy-pasteable.

----------
assignee: docs at python
components: Documentation
keywords: easy
messages: 148571
nosy: docs at python, petri.lehtinen
priority: normal
severity: normal
status: open
title: uuid documentation example uses invalid REPL/doctest syntax
versions: Python 2.7, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13499>
_______________________________________

From report at bugs.python.org  Tue Nov 29 15:14:31 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 29 Nov 2011 14:14:31 +0000
Subject: [issue11379] Remove "lightweight" from minidom description
In-Reply-To: <1322575945.15.0.823673439388.issue11379@psf.upfronthosting.co.za>
Message-ID: <1322575767.3292.0.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> I don't think "FUD" is a suitable term for the rather minidom-friendly
> wording in my last proposal. Seriously, minidom is widely known for
> being extremely slow and extremely memory hungry. And that is backed
> by basically any benchmark that has ever been done on the subject.

If it's both slow and memory-hungry, perhaps use the more generic
"performance" instead of "memory footprint"?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11379>
_______________________________________

From report at bugs.python.org  Tue Nov 29 15:44:29 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Tue, 29 Nov 2011 14:44:29 +0000
Subject: [issue1040439] Missing documentation on how to link with libpython
Message-ID: <1322577869.86.0.916744711715.issue1040439@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

?ric, this is for embedding a Python interpreter in a C/C++ application. I tend to agree that the official doc page (http://docs.python.org/extending/embedding.html) on this topic is somewhat lacking in the area of the configuration/compilation procedure. There's some info scattered around the web in tutorials, though.

So I'd say it's a valid issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1040439>
_______________________________________

From report at bugs.python.org  Tue Nov 29 15:56:22 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 29 Nov 2011 14:56:22 +0000
Subject: [issue13496] bisect module: Overflow at index computation
In-Reply-To: <1322519672.22.0.173147243777.issue13496@psf.upfronthosting.co.za>
Message-ID: <1322578582.29.0.934642888125.issue13496@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

[x]range is enough to trigger the bug::
   bisect.bisect(range(sys.maxsize), sys.maxsize-3)

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13496>
_______________________________________

From report at bugs.python.org  Tue Nov 29 15:56:41 2011
From: report at bugs.python.org (Garrett Cooper)
Date: Tue, 29 Nov 2011 14:56:41 +0000
Subject: [issue13500] Hitting EOF gets cmd.py into a infinite EOF on return
	loop
Message-ID: <1322578601.01.0.207872314852.issue13500@psf.upfronthosting.co.za>


New submission from Garrett Cooper <yanegomi at gmail.com>:

Pressing <enter> produces no output with cmd.py whenever ^D has been entered in; after I enter in ^D it gets into an infinite loop spewing out messages via cmd.Cmd.default() about EOF because self.lastcmd isn't being reset properly.

The attached patch fixes that usability nit to be more intuitive (I debated about changing 'EOF' to 0x10, but that's probably less intuitive..).

----------
components: Library (Lib)
files: python-cmd-reset-lastcmd-on-EOF.patch
keywords: patch
messages: 148575
nosy: yaneurabeya
priority: normal
severity: normal
status: open
title: Hitting EOF gets cmd.py into a infinite EOF on return loop
type: behavior
versions: Python 3.4
Added file: http://bugs.python.org/file23805/python-cmd-reset-lastcmd-on-EOF.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13500>
_______________________________________

From report at bugs.python.org  Tue Nov 29 16:09:16 2011
From: report at bugs.python.org (Barry A. Warsaw)
Date: Tue, 29 Nov 2011 15:09:16 +0000
Subject: [issue11374] pkgutil.extend_path do not recognize py{c,o} file
In-Reply-To: <1322571045.82.0.958223705822.issue11374@psf.upfronthosting.co.za>
Message-ID: <20111129100908.7089f4eb@resist.wooz.org>


Barry A. Warsaw <barry at python.org> added the comment:

On Nov 29, 2011, at 12:50 PM, ?ric Araujo wrote:

>Before you put more work into this, it would be nice to get confirmation from
>one import expert that the bug is valid: I know the import system only
>superficially, and I?m not sure that package/__init__.pyc / .pyo is supported
>by import (if not, then pkgutil should also not support it).

It's an interesting question.  Under Python 2, I'd say yes, it should support
source-less imports, just as Python does.  Under Python 3, with PEP 3147, I'm
not so sure:

$ cat > foo.py
print('hello world')
$ cat > bar.py
import foo
$ ls
bar.py	foo.py
$ python3 bar.py
hello world
$ ls
bar.py	foo.py	__pycache__/
$ ls __pycache__/
foo.cpython-32.pyc
$ rm -f foo.py
$ python3 bar.py
Traceback (most recent call last):
  File "bar.py", line 1, in <module>
    import foo
ImportError: No module named foo

Then:

$ mv __pycache__/foo.cpython-32.pyc foo.pyc
$ ls
bar.py	foo.pyc  __pycache__/
$ python3 bar.py
hello world

So Python 3 source-less imports are still supported, but only when legacy
.pyc/.pyo locations are explicitly used.

My inclination is then -0 on extend_path() supporting .pyc/.pyo but only
*outside* the context of PEP 3147.  I.e. do not use imp.cache_from_source().

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11374>
_______________________________________

From report at bugs.python.org  Tue Nov 29 16:19:02 2011
From: report at bugs.python.org (Garrett Cooper)
Date: Tue, 29 Nov 2011 15:19:02 +0000
Subject: [issue13501] Make libedit support more generic;
	port readline / libedit to FreeBSD
Message-ID: <1322579942.3.0.601983912656.issue13501@psf.upfronthosting.co.za>


New submission from Garrett Cooper <yanegomi at gmail.com>:

The attached patch enables libedit support in a generic way via configure.in, so I can pass in --with-readline=editline, --with-readline=readline, --with-readline=yes, or --with[out]-readline[=no] and it will do one of the following:

1. Enable editline support.
2. Enable readline support.
3. Enable default OS support (editline on OSX, readline otherwise).
4. Explicitly disable readline support.

Tested functional via cmd.py and with basic poking around via the readline module.

The attached patch was created against the 2.7 branch, but I'll produce a patch against 'trunk' sometime later on this week.

PS. The only quirk I found was the fact that FreeBSD 9's libedit lied when it reports the number of available history items. Hrmmm..

----------
components: Library (Lib)
files: python-port-readline-module-to-libedit-on-freebsd.patch
keywords: patch
messages: 148577
nosy: yaneurabeya
priority: normal
severity: normal
status: open
title: Make libedit support more generic; port readline / libedit to FreeBSD
type: feature request
versions: Python 2.7, Python 3.4
Added file: http://bugs.python.org/file23806/python-port-readline-module-to-libedit-on-freebsd.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13501>
_______________________________________

From report at bugs.python.org  Tue Nov 29 16:21:11 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 29 Nov 2011 15:21:11 +0000
Subject: [issue13501] Make libedit support more generic;
	port readline / libedit to FreeBSD
In-Reply-To: <1322579942.3.0.601983912656.issue13501@psf.upfronthosting.co.za>
Message-ID: <1322580071.08.0.228931906474.issue13501@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
components: +Build
nosy: +ned.deily, ronaldoussoren
stage:  -> patch review
versions: +Python 3.3 -Python 2.7, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13501>
_______________________________________

From report at bugs.python.org  Tue Nov 29 16:26:35 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 29 Nov 2011 15:26:35 +0000
Subject: [issue11379] Remove "lightweight" from minidom description
In-Reply-To: <1299093908.17.0.828802315354.issue11379@psf.upfronthosting.co.za>
Message-ID: <1322580395.84.0.75986901515.issue11379@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

> Seriously, minidom is widely known for being extremely slow and 
> extremely memory hungry. And that is backed by basically any benchmark 
> that has ever been done on the subject.

Do you have any link?
My point is that if you say thing like "significantly/several times higher memory footprint than X" you are basically scaring the users away from the module.  If for an average documents it takes, say, 30-50MB of memory, it seems perfectly reasonable to me, even if ElementTree takes 3-5MB.  I would actually consider 100-200MB still ok too, unless I have to parse lot of documents or I'm running low of memory for other reasons.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11379>
_______________________________________

From report at bugs.python.org  Tue Nov 29 16:31:56 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 29 Nov 2011 15:31:56 +0000
Subject: [issue12759] "(?P=)" input for Tools/scripts/redemo.py raises
	unnhandled exception
In-Reply-To: <1313495654.73.0.277709437369.issue12759@psf.upfronthosting.co.za>
Message-ID: <1322580716.44.0.997961529336.issue12759@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
assignee:  -> ezio.melotti
stage: test needed -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12759>
_______________________________________

From report at bugs.python.org  Tue Nov 29 16:33:05 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 29 Nov 2011 15:33:05 +0000
Subject: [issue11379] Remove "lightweight" from minidom description
In-Reply-To: <1322580395.84.0.75986901515.issue11379@psf.upfronthosting.co.za>
Message-ID: <1322580480.3292.7.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> My point is that if you say thing like "significantly/several times
> higher memory footprint than X" you are basically scaring the users
> away from the module.

Only those users who know they'll be processing significantly large
documents.
I don't think "scaring away people" is a good enough reason *not* to
document performance characteristics. For example, we already mention
that string joining is faster than repeated concatenation; I haven't
heard anyone complain that it scared people away from string
concatenation. And while it's true that we shouldn't try to document
performance characteristics *too precisely*, it is still a good thing to
document the most outstanding facts (for examples, C accelerator modules
are clearly superior in performance to pure Python modules; should we
shy away from documenting that, and instead present it as some kind of
neutral choice?).

And, of course, if minidom gets some serious performance attention, the
claims will have to be revisited. But given the amount of attention
minidom gets at all, it sounds rather implausible.

> If for an average documents it takes, say, 30-50MB of memory, it seems
> perfectly reasonable to me, even if ElementTree takes 3-5MB.  I would
> actually consider 100-200MB still ok too

Some use cases would not really like a 100-200MB memory consumption, or
even 50MB. Think a long-running daemon, for instance.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11379>
_______________________________________

From report at bugs.python.org  Tue Nov 29 16:37:31 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 29 Nov 2011 15:37:31 +0000
Subject: [issue13487] inspect.getmodule fails when module imports change
	sys.modules
In-Reply-To: <1322363209.24.0.0935380803772.issue13487@psf.upfronthosting.co.za>
Message-ID: <1322581051.38.0.41972465611.issue13487@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
assignee:  -> eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13487>
_______________________________________

From report at bugs.python.org  Tue Nov 29 17:15:07 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 29 Nov 2011 16:15:07 +0000
Subject: [issue13467] Typo in doc for library/sysconfig
In-Reply-To: <1322102306.14.0.426447482004.issue13467@psf.upfronthosting.co.za>
Message-ID: <E1RVQKn-0001IU-QZ@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset a7d38a969132 by ?ric Araujo in branch '3.2':
Fix typo (#13467)
http://hg.python.org/cpython/rev/a7d38a969132

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13467>
_______________________________________

From report at bugs.python.org  Tue Nov 29 17:15:07 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 29 Nov 2011 16:15:07 +0000
Subject: [issue13487] inspect.getmodule fails when module imports change
	sys.modules
In-Reply-To: <1322363209.24.0.0935380803772.issue13487@psf.upfronthosting.co.za>
Message-ID: <E1RVQKn-0001IU-Qf@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 2ef359d7a2e9 by ?ric Araujo in branch '3.2':
Fix inspect.getmodule to use a copy of sys.modules for iteration (#13487).
http://hg.python.org/cpython/rev/2ef359d7a2e9

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13487>
_______________________________________

From report at bugs.python.org  Tue Nov 29 17:18:09 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 29 Nov 2011 16:18:09 +0000
Subject: [issue13467] Typo in doc for library/sysconfig
In-Reply-To: <1322102306.14.0.426447482004.issue13467@psf.upfronthosting.co.za>
Message-ID: <1322583489.61.0.0281132133409.issue13467@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Done for 3.2 and 3.3, will backport to 2.7 later.

----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13467>
_______________________________________

From report at bugs.python.org  Tue Nov 29 17:19:20 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 29 Nov 2011 16:19:20 +0000
Subject: [issue13487] inspect.getmodule fails when module imports change
	sys.modules
In-Reply-To: <1322363209.24.0.0935380803772.issue13487@psf.upfronthosting.co.za>
Message-ID: <1322583560.27.0.208335195553.issue13487@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Committed, thanks.

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13487>
_______________________________________

From report at bugs.python.org  Tue Nov 29 17:26:23 2011
From: report at bugs.python.org (Stefan Behnel)
Date: Tue, 29 Nov 2011 16:26:23 +0000
Subject: [issue11379] Remove "lightweight" from minidom description
In-Reply-To: <1322580395.84.0.75986901515.issue11379@psf.upfronthosting.co.za>
Message-ID: <4ED507A2.5000004@users.sourceforge.net>


Stefan Behnel <scoder at users.sourceforge.net> added the comment:

Ezio Melotti, 29.11.2011 16:26:
>> Seriously, minidom is widely known for being extremely slow and
>> extremely memory hungry. And that is backed by basically any benchmark
>> that has ever been done on the subject.
>
> Do you have any link?

I just did a quick Google search for "python minidom benchmark" and found 
these:

http://www.opensourcetutorials.com/tutorials/Server-Side-Coding/Python/xml-matters/page2.html

http://effbot.org/zone/celementtree.htm#benchmarks

http://blog.ianbicking.org/2008/03/30/python-html-parser-performance/

Note that all three authors risk being biased, but given how similar the 
results are, I tend to believe them.

Stefan

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11379>
_______________________________________

From report at bugs.python.org  Tue Nov 29 17:45:18 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 29 Nov 2011 16:45:18 +0000
Subject: [issue11379] Remove "lightweight" from minidom description
In-Reply-To: <4ED507A2.5000004@users.sourceforge.net>
Message-ID: <1322584811.3292.8.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> I just did a quick Google search for "python minidom benchmark" and found 
> these:
> 
> http://www.opensourcetutorials.com/tutorials/Server-Side-Coding/Python/xml-matters/page2.html
> 
> http://effbot.org/zone/celementtree.htm#benchmarks
> 
> http://blog.ianbicking.org/2008/03/30/python-html-parser-performance/
> 
> Note that all three authors risk being biased, but given how similar the 
> results are, I tend to believe them.

Thanks for the links. The performance gap looks significant enough to be
mentioned, at least generically.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11379>
_______________________________________

From report at bugs.python.org  Tue Nov 29 17:55:31 2011
From: report at bugs.python.org (benrg)
Date: Tue, 29 Nov 2011 16:55:31 +0000
Subject: [issue11427] ctypes from_buffer no longer accepts bytes
In-Reply-To: <1299481885.21.0.0627562040827.issue11427@psf.upfronthosting.co.za>
Message-ID: <1322585731.6.0.182068099911.issue11427@psf.upfronthosting.co.za>


benrg <benrudiak at gmail.com> added the comment:

I am still interested in this for the same reason I was interested in this in the first place; nothing has changed. I guess I will reiterate, and try to expand.

The problem is that ctypes tries to enforce const correctness (inconsistently), but it has no way to declare its objects as const, and assumes they are all non-const. This is the worst possible combination. It would make sense to have no notion of const and never try to enforce it (like K&R C), and it would make sense to have constness and try to enforce it (like C++). But the present situation is like a compiler that treats string literals as const char[], and doesn't allow casting away const, but doesn't allow the use of the const keyword in user code, so there's no way to pass a string literal as a function argument because the necessary type can't be expressed. Instead you have to copy the literal to a char array and pass that.

Calling C functions is inherently unsafe. Calling C functions could always corrupt the Python heap or otherwise screw around with state that the Python environment thinks that it owns. All I want is some means to assert that my code is not going to do that, as a way of getting around the limited type system that can't provide those sorts of guarantees. More broadly, what I want from ctypes is a way to do the sorts of things that I can do in C. If I can call foo(&bar + 17) in C, I want to be able to make that call in Python.

I wasn't using (c_type*N).from_buffer because I wanted to. I was using it after wasting literally hours trying to find some other way to get ctypes to agree to pass a pointer into the buffer of a Python object to an external function (which was not going to alter it, I promise). This should be easy; instead it's nearly impossible. I don't want to wrestle with random un-overridable attempts to enforce correctness when calling a language where that can never be enforced. I just want to call my C function.

I'm pretty sure that I verified that this code worked in 3.1.3 before opening this bug, but it's been a while. I could try to reproduce it, but I think this functionality should be present regardless. You can call it a feature request instead of a regression if you want.

----------
resolution: invalid -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11427>
_______________________________________

From report at bugs.python.org  Tue Nov 29 18:37:48 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 29 Nov 2011 17:37:48 +0000
Subject: [issue1040439] Missing documentation on how to link with libpython
Message-ID: <1322588268.86.0.288784549722.issue1040439@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

There is (outdated, incomplete and clumsy) documentation about using distutils.sysconfig from the command-line. I'll try to work on a small patch. It will probably be Unix-only, though.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1040439>
_______________________________________

From report at bugs.python.org  Tue Nov 29 18:57:49 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 29 Nov 2011 17:57:49 +0000
Subject: [issue11427] ctypes from_buffer no longer accepts bytes
In-Reply-To: <1299481885.21.0.0627562040827.issue11427@psf.upfronthosting.co.za>
Message-ID: <1322589469.34.0.265240935939.issue11427@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> I just want to call my C function.

You can use something else than ctypes_array.from_buffer(buffer). ctypes_array.from_buffer() creates a read-write object which can be used to modify the buffer. You cannot pass a read-only object to ctypes_array.from_buffer().

> I'm pretty sure that I verified that this code worked in 3.1.3 before
> opening this bug, but it's been a while.

If it was possible, it was a bug. You cannot modify a read-only object, like bytes, because it would lead to inconsistent object and may lead your program to a crash, even if you don't call C functions.

Example in pure Python:

>>> import ctypes
>>> T=(ctypes.c_uint8*4)
>>> B=bytearray(4)
>>> x=T.from_buffer(B)
>>> B
bytearray(b'\x00\x00\x00\x00')
>>> x[0]=9
>>> x[2]=100
>>> B
bytearray(b'\t\x00d\x00')
>>> list(x)                                                                                                                                             
[9, 0, 100, 0]

B is modified when x[index] is modified.

--

A bug tracker is not the right place to ask help with ctypes.

----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11427>
_______________________________________

From report at bugs.python.org  Tue Nov 29 19:04:14 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 29 Nov 2011 18:04:14 +0000
Subject: [issue1040439] Missing documentation on how to link with libpython
Message-ID: <1322589854.57.0.707804233468.issue1040439@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Attached patch rewrites the offending paragraphs.

----------
keywords: +patch
stage: needs patch -> patch review
Added file: http://bugs.python.org/file23807/docembed.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1040439>
_______________________________________

From report at bugs.python.org  Tue Nov 29 19:16:20 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 29 Nov 2011 18:16:20 +0000
Subject: [issue1040439] Missing documentation on how to link with libpython
Message-ID: <1322590580.96.0.709804112969.issue1040439@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Updated markup.

----------
Added file: http://bugs.python.org/file23808/docembed.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1040439>
_______________________________________

From report at bugs.python.org  Tue Nov 29 19:16:31 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 29 Nov 2011 18:16:31 +0000
Subject: [issue1040439] Missing documentation on how to link with libpython
Message-ID: <1322590591.98.0.410060463288.issue1040439@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


Removed file: http://bugs.python.org/file23807/docembed.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1040439>
_______________________________________

From report at bugs.python.org  Tue Nov 29 19:29:43 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Tue, 29 Nov 2011 18:29:43 +0000
Subject: [issue1040439] Missing documentation on how to link with libpython
Message-ID: <1322591383.74.0.354358502098.issue1040439@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

Antoine, this is a big improvement - LGTM.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1040439>
_______________________________________

From report at bugs.python.org  Tue Nov 29 19:35:59 2011
From: report at bugs.python.org (Ned Deily)
Date: Tue, 29 Nov 2011 18:35:59 +0000
Subject: [issue13501] Make libedit support more generic;
	port readline / libedit to FreeBSD
In-Reply-To: <1322579942.3.0.601983912656.issue13501@psf.upfronthosting.co.za>
Message-ID: <1322591759.89.0.781878837528.issue13501@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


----------
assignee:  -> ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13501>
_______________________________________

From report at bugs.python.org  Tue Nov 29 19:45:42 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 29 Nov 2011 18:45:42 +0000
Subject: [issue13471] setting access time beyond Jan. 2038 on remote share
	failes on Win7 x64
In-Reply-To: <1322142567.98.0.834575465366.issue13471@psf.upfronthosting.co.za>
Message-ID: <1322592342.91.0.973410353869.issue13471@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> I thought that time_t was 64 bits on Windows

On Windows 64 bits, sizeof(time_t) is 64 bits and time.ctime(910692730085) works (return a string with year 2128).

It looks like Thorsten Simons is running Windows 32 bits.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13471>
_______________________________________

From report at bugs.python.org  Tue Nov 29 19:48:15 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 29 Nov 2011 18:48:15 +0000
Subject: [issue13501] Make libedit support more generic;
	port readline / libedit to FreeBSD
In-Reply-To: <1322579942.3.0.601983912656.issue13501@psf.upfronthosting.co.za>
Message-ID: <1322592495.12.0.603600667101.issue13501@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/issue13501>
_______________________________________

From report at bugs.python.org  Tue Nov 29 19:59:38 2011
From: report at bugs.python.org (Roger Serwy)
Date: Tue, 29 Nov 2011 18:59:38 +0000
Subject: [issue3573] IDLE hangs when passing invalid command line args
	(directory(ies) instead of file(s))
In-Reply-To: <1218929546.33.0.178143371283.issue3573@psf.upfronthosting.co.za>
Message-ID: <1322593178.44.0.67387387064.issue3573@psf.upfronthosting.co.za>


Roger Serwy <roger.serwy at gmail.com> added the comment:

I can confirm that using "idle -e <dir>" still causes a hang on Windows using 3.2.2 and on Ubuntu using 2.7.1 and 3.2

The given patch fixes the problem on those platforms.

----------
nosy: +serwy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3573>
_______________________________________

From report at bugs.python.org  Tue Nov 29 20:02:16 2011
From: report at bugs.python.org (Stefan Behnel)
Date: Tue, 29 Nov 2011 19:02:16 +0000
Subject: [issue11379] Remove "lightweight" from minidom description
In-Reply-To: <1299093908.17.0.828802315354.issue11379@psf.upfronthosting.co.za>
Message-ID: <1322593336.53.0.81931729438.issue11379@psf.upfronthosting.co.za>


Stefan Behnel <scoder at users.sourceforge.net> added the comment:

Given that the links were generally somewhat dated and used Py2.x instead of the post-PEP393 Py3.3, here is another little benchmark, comparing the parser performance of minidom to lxml.etree (latest), ElementTree and cElementTree (stdlib) in a recent Py3.3 build (e66b7c62eec0), everything properly optimised for my platform (Linux 64bit). I used os.fork() to start a new process after importing everything and reading the file a couple of times, and before parsing. The memory usage is measured inside of the forked child using the resource module's ru_maxrss value, so it correlates with the growth of CPython's memory heap after parsing, thus giving an estimate of the maximum amount of memory used during parsing and tree building.

Parsing hamlet.xml in English, 274KB:

Memory usage: 7284
xml.etree.ElementTree.parse done in 0.104 seconds
Memory usage: 14240 (+6956)
xml.etree.cElementTree.parse done in 0.022 seconds
Memory usage: 9736 (+2452)
lxml.etree.parse done in 0.014 seconds
Memory usage: 11028 (+3744)
minidom tree read in 0.152 seconds
Memory usage: 30360 (+23076)

Parsing the old testament in English (ot.xml, 3.4MB) into memory:

Memory usage: 20444
xml.etree.ElementTree.parse done in 0.385 seconds
Memory usage: 46088 (+25644)
xml.etree.cElementTree.parse done in 0.056 seconds
Memory usage: 32628 (+12184)
lxml.etree.parse done in 0.041 seconds
Memory usage: 37500 (+17056)
minidom tree read in 0.672 seconds
Memory usage: 110428 (+89984)

A 25MB XML file with Slavic Unicode text content:

Memory usage: 57368
xml.etree.ElementTree.parse done in 3.274 seconds
Memory usage: 223720 (+166352)
xml.etree.cElementTree.parse done in 0.459 seconds
Memory usage: 154012 (+96644)
lxml.etree.parse done in 0.454 seconds
Memory usage: 135720 (+78352)
minidom tree read in 6.193 seconds
Memory usage: 604860 (+547492)

And a contrived 4.5MB XML file with lot more structure than data:

Memory usage: 13308
xml.etree.ElementTree.parse done in 4.178 seconds
Memory usage: 222088 (+208780)
xml.etree.cElementTree.parse done in 0.478 seconds
Memory usage: 103056 (+89748)
lxml.etree.parse done in 0.199 seconds
Memory usage: 101860 (+88552)
minidom tree read in 8.705 seconds
Memory usage: 810964 (+797656)

Things to note: The factor of 5-10 for the memory overhead compared to cET depends heavily on the data. Also, minidom is consistently slower by more than a factor of 10 compared to the fastest parser (apparently the one in libxml2/lxml.etree, both of which surely can't be said to provide less features than the DOM that minidom implements).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11379>
_______________________________________

From report at bugs.python.org  Tue Nov 29 20:11:32 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 29 Nov 2011 19:11:32 +0000
Subject: [issue5654] Add C hook in PyDict_SetItem for debuggers
In-Reply-To: <1238604905.42.0.578461685574.issue5654@psf.upfronthosting.co.za>
Message-ID: <1322593892.27.0.977834287136.issue5654@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> the cost in the normal case is a single pointer comparison with NULL,
> something very cheap.

The Linux kernel patchs dynamically the code: disabling a probe writes NOP instruction in memory to avoid the cost of the test. Probes are completly disabled by default.

See kernel markers (introduced in Linux 2.6.24) and the more recent kernel tracepoints (introduced in Linux 2.6.28).
http://lwn.net/Articles/300992/

> If something like this goes in, it should be #ifdef'd out
> by default

I agree.

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5654>
_______________________________________

From report at bugs.python.org  Tue Nov 29 20:27:38 2011
From: report at bugs.python.org (Florent Xicluna)
Date: Tue, 29 Nov 2011 19:27:38 +0000
Subject: [issue11379] Remove "lightweight" from minidom description
In-Reply-To: <1299093908.17.0.828802315354.issue11379@psf.upfronthosting.co.za>
Message-ID: <1322594858.62.0.318991916672.issue11379@psf.upfronthosting.co.za>


Changes by Florent Xicluna <florent.xicluna at gmail.com>:


----------
nosy: +flox
type:  -> performance

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11379>
_______________________________________

From report at bugs.python.org  Tue Nov 29 20:28:06 2011
From: report at bugs.python.org (Florent Xicluna)
Date: Tue, 29 Nov 2011 19:28:06 +0000
Subject: [issue11379] Remove "lightweight" from minidom description
In-Reply-To: <1299093908.17.0.828802315354.issue11379@psf.upfronthosting.co.za>
Message-ID: <1322594886.05.0.410612632616.issue11379@psf.upfronthosting.co.za>


Changes by Florent Xicluna <florent.xicluna at gmail.com>:


----------
components: +XML

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11379>
_______________________________________

From report at bugs.python.org  Tue Nov 29 20:29:55 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 29 Nov 2011 19:29:55 +0000
Subject: [issue10278] add time.wallclock() method
In-Reply-To: <1288624210.23.0.0497533122542.issue10278@psf.upfronthosting.co.za>
Message-ID: <1322594995.28.0.16898060828.issue10278@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Version 3 of the patch: check for clock_gettime() failure. Try CLOCK_MONOTONIC_RAW, or try CLOCK_MONOTONIC, or use time.time().

----------
Added file: http://bugs.python.org/file23809/wallclock-3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10278>
_______________________________________

From report at bugs.python.org  Tue Nov 29 20:51:40 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Tue, 29 Nov 2011 19:51:40 +0000
Subject: [issue13500] Hitting EOF gets cmd.py into a infinite EOF on return
	loop
In-Reply-To: <1322578601.01.0.207872314852.issue13500@psf.upfronthosting.co.za>
Message-ID: <1322596300.1.0.919452571565.issue13500@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

Could you provide an step-by-step procedure to try this?.

----------
nosy: +jcea
versions: +Python 3.3 -Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13500>
_______________________________________

From report at bugs.python.org  Tue Nov 29 20:57:27 2011
From: report at bugs.python.org (Stefan Behnel)
Date: Tue, 29 Nov 2011 19:57:27 +0000
Subject: [issue11379] Remove "lightweight" from minidom description
In-Reply-To: <1299093908.17.0.828802315354.issue11379@psf.upfronthosting.co.za>
Message-ID: <1322596647.5.0.369930925821.issue11379@psf.upfronthosting.co.za>


Stefan Behnel <scoder at users.sourceforge.net> added the comment:

Hmm, looks like I messed up the last example. I accidentally left in the formatting whitespace, thus growing the file to 6.2 MB. Removing that, I get this for the (now really) 4.5 MB XML file with lots of structure and very little data:

Memory usage: 11600
xml.etree.ElementTree.parse done in 3.374 seconds
Memory usage: 203420 (+191820)
xml.etree.cElementTree.parse done in 0.192 seconds
Memory usage: 36444 (+24844)
lxml.etree.parse done in 0.131 seconds
Memory usage: 62648 (+51048)
minidom tree read in 5.935 seconds
Memory usage: 527684 (+516084)

It's actually surprising how much of a difference trailing whitespace content makes in minidom (from 2MB on disk to 300MB in memory???), most likely due to the usage of dedicated DOM text nodes in the tree.

PS: I think the "XML/performance" tags on this bug would hint at a separate ticket. This is really meant as a documentation bug.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11379>
_______________________________________

From report at bugs.python.org  Tue Nov 29 20:59:17 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 29 Nov 2011 19:59:17 +0000
Subject: [issue13471] setting access time beyond Jan. 2038 on remote share
	failes on Win7 x64
In-Reply-To: <1322142567.98.0.834575465366.issue13471@psf.upfronthosting.co.za>
Message-ID: <1322596757.98.0.242498144672.issue13471@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

> > I thought that time_t was 64 bits on Windows
time_t *is* 64bit by default since Visual Studio 8, even with the 32bit compiler:
http://msdn.microsoft.com/en-us/library/1f4c8f33(v=vs.80).aspx

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13471>
_______________________________________

From report at bugs.python.org  Tue Nov 29 21:04:45 2011
From: report at bugs.python.org (Garrett Cooper)
Date: Tue, 29 Nov 2011 20:04:45 +0000
Subject: [issue13500] Hitting EOF gets cmd.py into a infinite EOF on return
	loop
In-Reply-To: <1322578601.01.0.207872314852.issue13500@psf.upfronthosting.co.za>
Message-ID: <1322597085.53.0.375939873101.issue13500@psf.upfronthosting.co.za>


Garrett Cooper <yanegomi at gmail.com> added the comment:

Sure -- the repro steps are pretty easy:

1. Startup an interactive python shell.
2. Enter in the following code:

{{{
import cmd
class Foo(cmd.Cmd):
    def do_bar(self, arg):
        """bar"""

Foo().cmdloop()
}}}

3. You will be greeted with the standard `(Cmd)' prompt.
4. Press enter. Nothing will be printed out (it will continue on to the next line).
5. Enter in Control-D, you will be greeted with `Unknown syntax: EOF' error message from cmd.Cmd.default(..).
6. Press enter multiple times.

Expected output:

- Since a do_EOF handler isn't installed in 5., I expect to see the `Unknown syntax: EOF' error print out on the console. I don't want to delve into whether or not this should or shouldn't be printed out in this ticket.
- Every time I press <enter> I should be greeted with the prompt, and not the `Unknown syntax: EOF` error.

Actual output:
- I see `Unknown syntax: EOF' error, and every time I press <enter> it displays the error beforementioned error.

Example:

{{{
>>> import cmd
>>> class Foo(cmd.Cmd):
...     def do_bar(self, arg):
...         """bar"""
... 
>>> Foo().cmdloop()
(Cmd) 
(Cmd) 
bar   help  
(Cmd) help bar
bar
(Cmd) ^D*** Unknown syntax: EOF
(Cmd) 
*** Unknown syntax: EOF
(Cmd) 
*** Unknown syntax: EOF
}}}

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13500>
_______________________________________

From report at bugs.python.org  Tue Nov 29 21:08:08 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Tue, 29 Nov 2011 20:08:08 +0000
Subject: [issue13405] Add DTrace probes
In-Reply-To: <1321299726.66.0.343368151185.issue13405@psf.upfronthosting.co.za>
Message-ID: <1322597288.91.0.80701349233.issue13405@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Please let us know when you consider your patch ready for review.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13405>
_______________________________________

From report at bugs.python.org  Tue Nov 29 21:36:12 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 29 Nov 2011 20:36:12 +0000
Subject: [issue13471] setting access time beyond Jan. 2038 on remote share
	failes on Win7 x64
In-Reply-To: <1322142567.98.0.834575465366.issue13471@psf.upfronthosting.co.za>
Message-ID: <1322598972.81.0.700460463461.issue13471@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> time_t *is* 64bit by default since Visual Studio 8

Ah? The issue was reported on a version compiled with Visual Studio 8. Notice "MSC v.1500" in:

> Using Python '3.2.2 (default, Sep  4 2011, 09:07:29)
> [MSC v.1500 64 bit (AMD64)]' on Windows 7 Professional SP1:

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13471>
_______________________________________

From report at bugs.python.org  Tue Nov 29 21:42:30 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 29 Nov 2011 20:42:30 +0000
Subject: [issue12892] UTF-16 and UTF-32 codecs should reject (lone) surrogates
In-Reply-To: <1315133370.95.0.855318807974.issue12892@psf.upfronthosting.co.za>
Message-ID: <1322599350.13.0.163750536411.issue12892@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Python 3.3 has a strange behaviour:

>>> '\uDBFF\uDFFF'.encode('utf-16-le').decode('utf-16-le')
'\U0010ffff'
>>> '\U0010ffff'.encode('utf-16-le').decode('utf-16-le')
'\U0010ffff'

I would expect text.decode(encoding).encode(encoding)==text or an encode or decode error.

So I agree that the encoder should reject lone surogates.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12892>
_______________________________________

From report at bugs.python.org  Tue Nov 29 21:45:16 2011
From: report at bugs.python.org (R. David Murray)
Date: Tue, 29 Nov 2011 20:45:16 +0000
Subject: [issue13502] Documentation for Event.wait return value is either
	wrong or incomplete
Message-ID: <1322599516.14.0.0239672713193.issue13502@psf.upfronthosting.co.za>


New submission from R. David Murray <rdmurray at bitdance.com>:

The documentation for Event.wait says:

  This method returns the internal flag on exit, so it will always return True except if a timeout is given and the operation times out.

In fact, however, if the thread that sets the flag immediately clears it, wait will return False.  Antoine looking at the code says that this appears to be intentional, and that would make sense since originally wait returned no value.

My use case is one thread waiting on another to complete a work loop.  Normally the worker thread goes to sleep after clearing the flag, but sometimes it immediately starts a new work loop.  In either case I want the monitoring loop to take an action when the work loop completes, and raise an error if the wait times out.  It looked to me like Event.wait would work in the scenario.

----------
assignee: docs at python
components: Documentation
messages: 148604
nosy: docs at python, pitrou, r.david.murray, tim_one
priority: normal
severity: normal
stage: needs patch
status: open
title: Documentation for Event.wait return value is either wrong or incomplete
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13502>
_______________________________________

From report at bugs.python.org  Tue Nov 29 21:48:33 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Tue, 29 Nov 2011 20:48:33 +0000
Subject: [issue13483] Use VirtualAlloc to allocate memory arenas
In-Reply-To: <1322313162.87.0.914810161445.issue13483@psf.upfronthosting.co.za>
Message-ID: <1322599713.77.0.0140691590909.issue13483@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

The patch looks good to me.

To study Microsoft's malloc, see VC\crt\src\malloc.c. Typically, it uses HeapAlloc from the CRT heap, unless it's in 32-bit mode, and __active_heap is either __V6_HEAP or __V5_HEAP. This is determined at startup by __heap_select, inspecting an environment variable __MSVCRT_HEAP_SELECT. If that's not set, the CRT heap is used.

The CRT heap, in turn, is created with HeapCreate (no flags).

As an alternative approach, Python could consider completely dropping obmalloc on Windows, and using a Windows Low Fragementation Heap (LFH) instead, with HEAP_NO_SERIALIZE (as the heap would be protected by the GIL).

If we take the route proposed by this patch, I recommend also dropping all other CRT malloc() calls in Python, and make allocations from the process heap instead (that's a separate issue, though).

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13483>
_______________________________________

From report at bugs.python.org  Tue Nov 29 21:50:57 2011
From: report at bugs.python.org (R. David Murray)
Date: Tue, 29 Nov 2011 20:50:57 +0000
Subject: [issue13502] Documentation for Event.wait return value is either
	wrong or incomplete
In-Reply-To: <1322599516.14.0.0239672713193.issue13502@psf.upfronthosting.co.za>
Message-ID: <1322599857.5.0.788259659048.issue13502@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Thinking about it, if the flag's state if the wait does not expire is not guaranteed to be True, then what I really need is some way to know, when the wait call completes, whether or not it terminated because of a timeout or not.  I can always query the value of the flag separately if its value can in any case be changed by another thread.

I am perhaps using the wrong tool, I'll have to look at the docs further.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13502>
_______________________________________

From report at bugs.python.org  Tue Nov 29 21:53:08 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 29 Nov 2011 20:53:08 +0000
Subject: [issue3573] IDLE hangs when passing invalid command line args
	(directory(ies) instead of file(s))
In-Reply-To: <1218929546.33.0.178143371283.issue3573@psf.upfronthosting.co.za>
Message-ID: <1322599988.69.0.201831274101.issue3573@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
priority: normal -> high

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3573>
_______________________________________

From report at bugs.python.org  Tue Nov 29 21:55:07 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 29 Nov 2011 20:55:07 +0000
Subject: [issue13496] bisect module: Overflow at index computation
In-Reply-To: <1322519672.22.0.173147243777.issue13496@psf.upfronthosting.co.za>
Message-ID: <1322600107.63.0.985100944541.issue13496@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

The fix is trivial.  I'll do it soonish.

----------
priority: low -> normal

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13496>
_______________________________________

From report at bugs.python.org  Tue Nov 29 21:55:54 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 29 Nov 2011 20:55:54 +0000
Subject: [issue13502] Documentation for Event.wait return value is either
	wrong or incomplete
In-Reply-To: <1322599516.14.0.0239672713193.issue13502@psf.upfronthosting.co.za>
Message-ID: <1322600154.01.0.466604364798.issue13502@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Ok, so digging a bit, the feature dates back to issue1674032. 
Interestingly, the OP in that issue had already envisioned that race condition and had precisely proposed the feature to avoid it: ?Note that in the above case, the event could be cleared between the return from x.wait and the execution of x.isSet (in another thread), and so this would operate as though x.wait had just timed out?.

So I'm changing my mind and saying it seems desireable to return True if the wait succeeded before the timeout's end, even though the flag may have been reset in the meantime.
In 3.2, Condition.wait also returns a boolean, meaning the check in Event.wait can be atomic.

----------
nosy: +neologix

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13502>
_______________________________________

From report at bugs.python.org  Tue Nov 29 21:56:10 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 29 Nov 2011 20:56:10 +0000
Subject: [issue12919] Control what module is imported first
In-Reply-To: <1315331616.23.0.265275073086.issue12919@psf.upfronthosting.co.za>
Message-ID: <1322600170.95.0.102729604431.issue12919@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

I concur with Antoine.

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12919>
_______________________________________

From report at bugs.python.org  Tue Nov 29 22:00:43 2011
From: report at bugs.python.org (R. David Murray)
Date: Tue, 29 Nov 2011 21:00:43 +0000
Subject: [issue13502] Event.wait sometimes returns False even when no timeout
	has occurred
In-Reply-To: <1322599516.14.0.0239672713193.issue13502@psf.upfronthosting.co.za>
Message-ID: <1322600443.98.0.00911991237771.issue13502@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Changing the title and component to reflect Antoine's new understanding :)

----------
components: +Library (Lib) -Documentation
title: Documentation for Event.wait return value is either wrong or incomplete -> Event.wait sometimes returns False even when no timeout has occurred

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13502>
_______________________________________

From report at bugs.python.org  Tue Nov 29 22:02:09 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 29 Nov 2011 21:02:09 +0000
Subject: [issue13483] Use VirtualAlloc to allocate memory arenas
In-Reply-To: <1322599713.77.0.0140691590909.issue13483@psf.upfronthosting.co.za>
Message-ID: <1322600223.3292.23.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> The patch looks good to me.
> 
> To study Microsoft's malloc, see VC\crt\src\malloc.c. Typically, it
> uses HeapAlloc from the CRT heap, unless it's in 32-bit mode, and
> __active_heap is either __V6_HEAP or __V5_HEAP. This is determined at
> startup by __heap_select, inspecting an environment variable
> __MSVCRT_HEAP_SELECT. If that's not set, the CRT heap is used.

Ah, right, I guessed it was using HeapAlloc indeed. What would be more
interesting is how HeapAlloc works :)

I think it would be nice to know whether the patch has a chance of being
useful before committing it. I did it as a thought experiment after the
similar change was committed for Unix, but I'm not an expert in Windows
internals. Perhaps HeapAlloc deals fine with fragmentation? Tim, Brian,
do you know anything about this?

> As an alternative approach, Python could consider completely dropping
> obmalloc on Windows, and using a Windows Low Fragementation Heap (LFH)
> instead, with HEAP_NO_SERIALIZE (as the heap would be protected by the
> GIL).

I'm not sure that would serve the same purpose as obmalloc, which
(AFAIU) is very fast at the expense of compacity.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13483>
_______________________________________

From report at bugs.python.org  Tue Nov 29 22:04:02 2011
From: report at bugs.python.org (Tim Golden)
Date: Tue, 29 Nov 2011 21:04:02 +0000
Subject: [issue13483] Use VirtualAlloc to allocate memory arenas
In-Reply-To: <1322600223.3292.23.camel@localhost.localdomain>
Message-ID: <4ED548BB.7030308@timgolden.me.uk>


Tim Golden <mail at timgolden.me.uk> added the comment:

'fraid not. I've never had to dig into the allocation stuff at this level.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13483>
_______________________________________

From report at bugs.python.org  Tue Nov 29 22:13:32 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 29 Nov 2011 21:13:32 +0000
Subject: [issue12892] UTF-16 and UTF-32 codecs should reject (lone) surrogates
In-Reply-To: <1315133370.95.0.855318807974.issue12892@psf.upfronthosting.co.za>
Message-ID: <1322601212.61.0.973206867095.issue12892@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Patch rejecting surrogates in UTF-16 and UTF-32 encoders.

I don't think that Python 2.7 and 3.2 should be changed in a minor version.

----------
dependencies:  -Refactor code using unicode_encode_call_errorhandler() in unicodeobject.c
keywords: +patch
Added file: http://bugs.python.org/file23810/utf_16_32_surrogates.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12892>
_______________________________________

From report at bugs.python.org  Tue Nov 29 22:15:37 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 29 Nov 2011 21:15:37 +0000
Subject: [issue12892] UTF-16 and UTF-32 codecs should reject (lone) surrogates
In-Reply-To: <1315133370.95.0.855318807974.issue12892@psf.upfronthosting.co.za>
Message-ID: <1322601337.71.0.908789490581.issue12892@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Hum, my patch doesn't call the error handler.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12892>
_______________________________________

From report at bugs.python.org  Tue Nov 29 22:24:22 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Tue, 29 Nov 2011 21:24:22 +0000
Subject: [issue11113] html.entities mapping dicts need updating?
In-Reply-To: <1322556184.55.0.779951108031.issue11113@psf.upfronthosting.co.za>
Message-ID: <4ED54D84.8050908@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

>   1) the current approach of having a dict with name -> intvalue doesn't work anymore, and a name -> valuelist should be used instead;
>   2) the reverse dict for this would have to use tuples as keys, but I'm not sure how useful would that be (producing entities is not a common case, especially "unusual" ones like these).
>   3) The name -> char dict might still be useful, and can easily become a name -> str dict in order to deal with the multichar entities;
> 
> Since 1) is not backward-compatible the HTML5 entities should probably go in a separate dict.

+1 for a separate dict; -1 for a value list. The right value type is
'str'; name2codepoint ought to be deprecated (it's a left-over from
when the str type wasn't unicode in 2.x).

As for the reverse mapping: I'd add a dictionary that is reverse to
entitydefs (i.e. with str keys). That some keys then have two characters
is no real issue: applications that want to use this dictionary can
either ignore them, or follow the approach of always checking
Unicode combining characters - I'd expect that all "second" characters
are indeed combining.

OTOH, it's easy enough to create an inverted dictionary yourself
when you need it, and not every three-line function needs to be
in the standard library. It might actually be more useful to compile
the values into a regular expression which you can then use to
find out whether characters can be escaped using entity references.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11113>
_______________________________________

From report at bugs.python.org  Tue Nov 29 22:38:44 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 29 Nov 2011 21:38:44 +0000
Subject: [issue13471] setting access time beyond Jan. 2038 on remote share
	failes on Win7 x64
In-Reply-To: <1322142567.98.0.834575465366.issue13471@psf.upfronthosting.co.za>
Message-ID: <1322602724.81.0.295549041432.issue13471@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

It's probably SAMBA which does not support time_t above 32bit.
st_atime=910692730085 corresponds to a FILE_TIME of 0x7fffffffffffffff

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13471>
_______________________________________

From report at bugs.python.org  Tue Nov 29 22:40:35 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Tue, 29 Nov 2011 21:40:35 +0000
Subject: [issue5654] Add C hook in PyDict_SetItem for debuggers
In-Reply-To: <1238604905.42.0.578461685574.issue5654@psf.upfronthosting.co.za>
Message-ID: <1322602835.77.0.480781457241.issue5654@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

I think it's besides the point of this patch to ifdef it out. If John wants a version of Python with this enabled, he can well enough build one without our permission. So it would be useful only if it was always available, and perhaps properly integrated into pdb.

IOW, I'm +1 for the patch. Having actual benchmarks would demonstrating the (expected) outcome (i.e. no measurable effect) would still be required to advance this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5654>
_______________________________________

From report at bugs.python.org  Tue Nov 29 22:43:26 2011
From: report at bugs.python.org (Shawn Ligocki)
Date: Tue, 29 Nov 2011 21:43:26 +0000
Subject: [issue13489] collections.Counter doc does not list added version
In-Reply-To: <1322370110.24.0.847856523325.issue13489@psf.upfronthosting.co.za>
Message-ID: <1322603006.91.0.31084203182.issue13489@psf.upfronthosting.co.za>


Shawn Ligocki <sligocki at gmail.com> added the comment:

It doesn't seem like the styling is the issue, but the placement. You say that the standard style is to put this at the end of the section, is there somewhere it would be appropriate to bring this up for discussion? I think it would be much more intuitive if it was always placed right after the section name.

----------
keywords: +patch
Added file: http://bugs.python.org/file23811/collections.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13489>
_______________________________________

From report at bugs.python.org  Tue Nov 29 22:50:30 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 29 Nov 2011 21:50:30 +0000
Subject: [issue13471] setting access time beyond Jan. 2038 on remote share
	failes on Win7 x64
In-Reply-To: <1322142567.98.0.834575465366.issue13471@psf.upfronthosting.co.za>
Message-ID: <1322603430.32.0.142447020076.issue13471@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

I found this samba bug: https://bugzilla.samba.org/show_bug.cgi?id=7785
It is fixed since Samba version 3.5.8.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13471>
_______________________________________

From report at bugs.python.org  Tue Nov 29 23:08:42 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 29 Nov 2011 22:08:42 +0000
Subject: [issue13489] collections.Counter doc does not list added version
In-Reply-To: <1322370110.24.0.847856523325.issue13489@psf.upfronthosting.co.za>
Message-ID: <1322604522.05.0.559578813968.issue13489@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

FWIW, the version added is also prominently shown at the top of the page:
http://docs.python.org/library/collections.html#module-collections

I don't think the CSS should be changed or that versionadded should become more prominent -- this is usually one of the least important parts of the documentation for a function or class.

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13489>
_______________________________________

From report at bugs.python.org  Tue Nov 29 23:13:23 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Tue, 29 Nov 2011 22:13:23 +0000
Subject: [issue13483] Use VirtualAlloc to allocate memory arenas
In-Reply-To: <1322600223.3292.23.camel@localhost.localdomain>
Message-ID: <4ED55901.6080000@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> I think it would be nice to know whether the patch has a chance of being
> useful before committing it. I did it as a thought experiment after the
> similar change was committed for Unix, but I'm not an expert in Windows
> internals. Perhaps HeapAlloc deals fine with fragmentation?

Unfortunately, the implementation of HeapAlloc isn't really documented.
If Reactos is right, it looks like this: http://bit.ly/t2NPHh

Blocks < 1024 bytes are allocated from per-size free lists.

Blocks < Heap->VirtualMemoryThreshold are allocated through the free
list for variable-sized blocks of the heap.

Other blocks are allocated through  ZwAllocateVirtualMemory, adding
sizeof(HEAP_VIRTUAL_ALLOC_ENTRY) in the beginning. I think this header
will cause malloc() to allocate one extra page in front of an arena.

>> As an alternative approach, Python could consider completely dropping
>> obmalloc on Windows, and using a Windows Low Fragementation Heap (LFH)
>> instead, with HEAP_NO_SERIALIZE (as the heap would be protected by the
>> GIL).
> 
> I'm not sure that would serve the same purpose as obmalloc, which
> (AFAIU) is very fast at the expense of compacity.

I'd expect that LFH heaps are also very fast. The major difference I can
see is that blocks in the LFH heap still have an 8-byte header (possibly
more on a 64-bit system). So I wouldn't expect any speed savings, but
(possibly relevant) memory savings from obmalloc.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13483>
_______________________________________

From report at bugs.python.org  Tue Nov 29 23:37:00 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 29 Nov 2011 22:37:00 +0000
Subject: [issue6715] xz compressor support
In-Reply-To: <1250502444.31.0.107447392137.issue6715@psf.upfronthosting.co.za>
Message-ID: <E1RVWIM-0005fc-Dt@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 74d182cf0187 by Nadeem Vawda in branch 'default':
Issue #6715: Add module for compression using the LZMA algorithm.
http://hg.python.org/cpython/rev/74d182cf0187

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6715>
_______________________________________

From report at bugs.python.org  Tue Nov 29 23:39:18 2011
From: report at bugs.python.org (Brian Curtin)
Date: Tue, 29 Nov 2011 22:39:18 +0000
Subject: [issue13483] Use VirtualAlloc to allocate memory arenas
In-Reply-To: <1322313162.87.0.914810161445.issue13483@psf.upfronthosting.co.za>
Message-ID: <1322606358.86.0.309778315902.issue13483@psf.upfronthosting.co.za>


Brian Curtin <brian at python.org> added the comment:

> Tim, Brian, do you know anything about this?

Unfortunately, no. It's on my todo list of things to understand but I don't see that happening in the near future.

I'm willing to run tests or benchmarks for this issue, but that's likely the most I can provide.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13483>
_______________________________________

From report at bugs.python.org  Wed Nov 30 00:08:20 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Tue, 29 Nov 2011 23:08:20 +0000
Subject: [issue6715] xz compressor support
In-Reply-To: <1250502444.31.0.107447392137.issue6715@psf.upfronthosting.co.za>
Message-ID: <1322608100.04.0.540340974238.issue6715@psf.upfronthosting.co.za>


Nadeem Vawda <nadeem.vawda at gmail.com> added the comment:

The patch has been committed. I'm leaving this issue open for a while
longer, until more of the buildbots are building and testing the module.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6715>
_______________________________________

From report at bugs.python.org  Wed Nov 30 00:12:57 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 29 Nov 2011 23:12:57 +0000
Subject: [issue13483] Use VirtualAlloc to allocate memory arenas
In-Reply-To: <1322606358.86.0.309778315902.issue13483@psf.upfronthosting.co.za>
Message-ID: <1322608071.3292.25.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

Le mardi 29 novembre 2011 ? 22:39 +0000, Brian Curtin a ?crit :
> Brian Curtin <brian at python.org> added the comment:
> 
> > Tim, Brian, do you know anything about this?
> 
> Unfortunately, no. It's on my todo list of things to understand but I
> don't see that happening in the near future.
> 
> I'm willing to run tests or benchmarks for this issue, but that's
> likely the most I can provide.

Benchmarks would be nice indeed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13483>
_______________________________________

From report at bugs.python.org  Wed Nov 30 00:19:03 2011
From: report at bugs.python.org (=?utf-8?q?Per_=C3=98yvind_Karlsen?=)
Date: Tue, 29 Nov 2011 23:19:03 +0000
Subject: [issue6715] xz compressor support
In-Reply-To: <1250502444.31.0.107447392137.issue6715@psf.upfronthosting.co.za>
Message-ID: <1322608743.24.0.918854393638.issue6715@psf.upfronthosting.co.za>


Per ?yvind Karlsen <peroyvind at mandriva.org> added the comment:

Not meaning to sound petty, but wouldn't it be common etiquette to retain some original copyright notice from original code intact..?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6715>
_______________________________________

From report at bugs.python.org  Wed Nov 30 01:09:16 2011
From: report at bugs.python.org (Irmen de Jong)
Date: Wed, 30 Nov 2011 00:09:16 +0000
Subject: [issue13503] improved efficiency of bytearray pickling by using bytes
	type instead of str
Message-ID: <1322611756.83.0.989666994675.issue13503@psf.upfronthosting.co.za>


New submission from Irmen de Jong <irmen at razorvine.net>:

Pickling of bytearrays is quite inefficient right now, because bytearray's __reduce__ encodes the bytes of the bytearray into a str. A pickle made from a bytearray is quite a bit larger than necessary because of this, and it also takes a lot more processing to create it and to convert it back into the actual bytearray when unpickling (because it uses bytearray's str based initializer with encoding).

I've attached a patch (both for the default 3.x branch and the 2.7 branch) that changes this to use the bytes type instead. A pickle made from a bytearray with this patch applied now utilizes the BINBYTES/BINSTRING pickle opcodes which are a lot more efficient than BINUNICODE that is used now. The reconstruction of the bytearray now uses bytearray's initializer that takes a bytes object.

I don't think additional unit tests are needed because test_bytes already performs pickle tests on bytearrays.

A bit more info can be found in my recent post on comp.lang.python about this, see http://mail.python.org/pipermail/python-list/2011-November/1283668.html

----------
components: Interpreter Core
files: bytearray3x.patch
keywords: easy, needs review, patch
messages: 148627
nosy: alexandre.vassalotti, irmen, pitrou
priority: normal
severity: normal
stage: patch review
status: open
title: improved efficiency of bytearray pickling by using bytes type instead of str
type: performance
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file23812/bytearray3x.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13503>
_______________________________________

From report at bugs.python.org  Wed Nov 30 01:09:36 2011
From: report at bugs.python.org (Irmen de Jong)
Date: Wed, 30 Nov 2011 00:09:36 +0000
Subject: [issue13503] improved efficiency of bytearray pickling by using bytes
	type instead of str
In-Reply-To: <1322611756.83.0.989666994675.issue13503@psf.upfronthosting.co.za>
Message-ID: <1322611776.74.0.142242318242.issue13503@psf.upfronthosting.co.za>


Changes by Irmen de Jong <irmen at razorvine.net>:


Added file: http://bugs.python.org/file23813/bytearray27.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13503>
_______________________________________

From report at bugs.python.org  Wed Nov 30 01:15:43 2011
From: report at bugs.python.org (Irmen de Jong)
Date: Wed, 30 Nov 2011 00:15:43 +0000
Subject: [issue13503] improved efficiency of bytearray pickling by using bytes
	type instead of str
In-Reply-To: <1322611756.83.0.989666994675.issue13503@psf.upfronthosting.co.za>
Message-ID: <1322612143.53.0.394394681471.issue13503@psf.upfronthosting.co.za>


Irmen de Jong <irmen at razorvine.net> added the comment:

btw I'm aware of PEP-3154 but I don't think this particular patch requires a pickle protocol bump.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13503>
_______________________________________

From report at bugs.python.org  Wed Nov 30 01:31:23 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 30 Nov 2011 00:31:23 +0000
Subject: [issue13504] Meta-issue for "Invent with Python" IDLE feedback
Message-ID: <1322613083.36.0.200533745275.issue13504@psf.upfronthosting.co.za>


New submission from Nick Coghlan <ncoghlan at gmail.com>:

This is a meta-issue for the following blog post: http://inventwithpython.com/blog/2011/11/29/the-things-i-hate-about-idle-that-i-wish-someone-would-fix/

There are a bunch of good ideas there that should be split out into a number of separate bug reports and feature requests. This meta-bug is just a quick and dirty way to suggest doing so, and giving people a place to collaborate on the task.

----------
components: IDLE
messages: 148629
nosy: ncoghlan
priority: normal
severity: normal
status: open
title: Meta-issue for "Invent with Python" IDLE feedback
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13504>
_______________________________________

From report at bugs.python.org  Wed Nov 30 01:35:47 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 30 Nov 2011 00:35:47 +0000
Subject: [issue13504] Meta-issue for "Invent with Python" IDLE feedback
In-Reply-To: <1322613083.36.0.200533745275.issue13504@psf.upfronthosting.co.za>
Message-ID: <1322613347.27.0.881854051007.issue13504@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

If you decide to work on one of the problems or feature requests mentioned in that post:

1. Create a separate, appropriately titled, tracker issue
2. Add that issue to the Dependencies field on this one.
3. Add a comment here to map the point number from the blog post to the relevant tracker issue number (so that issues don't get doubled up).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13504>
_______________________________________

From report at bugs.python.org  Wed Nov 30 01:40:00 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 30 Nov 2011 00:40:00 +0000
Subject: [issue13504] Meta-issue for "Invent with Python" IDLE feedback
In-Reply-To: <1322613083.36.0.200533745275.issue13504@psf.upfronthosting.co.za>
Message-ID: <1322613600.04.0.783575974073.issue13504@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Also add dependencies and links for any already known issues. For example:

#10747 covers point 16) (re. version numbers in Windows shortcuts)

----------
dependencies: +Include version info in Windows shortcuts

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13504>
_______________________________________

From report at bugs.python.org  Wed Nov 30 02:54:33 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 30 Nov 2011 01:54:33 +0000
Subject: [issue6715] xz compressor support
In-Reply-To: <1322608743.24.0.918854393638.issue6715@psf.upfronthosting.co.za>
Message-ID: <1322617767.3292.26.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Not meaning to sound petty, but wouldn't it be common etiquette to
> retain some original copyright notice from original code intact..?

It seemed to me that Nadeem had rewritten everything from scratch. Is
there any code of yours in the current module?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6715>
_______________________________________

From report at bugs.python.org  Wed Nov 30 03:07:08 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 30 Nov 2011 02:07:08 +0000
Subject: [issue13503] improved efficiency of bytearray pickling by using bytes
	type instead of str
In-Reply-To: <1322611756.83.0.989666994675.issue13503@psf.upfronthosting.co.za>
Message-ID: <1322618828.87.0.23381690286.issue13503@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Since it's a performance improvement, it's Python 3.3-only.

The patch looks ok but there's an unrelated issue. If I first pickle a bytearray under 3.3 using protocol 2:

>>> b = bytearray(b'xyz')
>>> pickle.dumps(b, protocol=2)
b'\x80\x02c__builtin__\nbytearray\nq\x00c__builtin__\nbytes\nq\x01]q\x02(KxKyKze\x85q\x03Rq\x04\x85q\x05Rq\x06.'

and then unpickle it under 2.7, I get:

>>> pickle.loads(b'\x80\x02c__builtin__\nbytearray\nq\x00c__builtin__\nbytes\nq\x01]q\x02(KxKyKze\x85q\x03Rq\x04\x85q\x05Rq\x06.')
bytearray(b'[120, 121, 122]')

... which is wrong. It seems pickling bytes objects with protocol 2 and unpickling them with Python 2.x is broken.

----------
versions:  -Python 2.7, Python 3.1, Python 3.2, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13503>
_______________________________________

From report at bugs.python.org  Wed Nov 30 03:14:17 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 30 Nov 2011 02:14:17 +0000
Subject: [issue13503] improved efficiency of bytearray pickling by using bytes
	type instead of str
In-Reply-To: <1322611756.83.0.989666994675.issue13503@psf.upfronthosting.co.za>
Message-ID: <1322619257.11.0.030719197178.issue13503@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

The irony is that with protocol < 3, bytes should piggy-back on bytearray and not the reverse (since the bytearray constructor has the same semantics under 2.x and 3.x).

It also means that the latin1 encoding solution should probably be kept for protocol < 3. Using __reduce_ex__ should allow for such combination, AFAIK. I think a separate issue should be opened for bytes.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13503>
_______________________________________

From report at bugs.python.org  Wed Nov 30 03:21:48 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 30 Nov 2011 02:21:48 +0000
Subject: [issue13505] Bytes objects pickled in 3.x with protocol <=2 are
	unpickled incorrectly in 2.x
Message-ID: <1322619707.99.0.479265394652.issue13505@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

In Python 3.2:

>>> pickle.dumps(b'xyz', protocol=2)
b'\x80\x02c__builtin__\nbytes\nq\x00]q\x01(KxKyKze\x85q\x02Rq\x03.'

In Python 2.7:

>>> pickle.loads(b'\x80\x02c__builtin__\nbytes\nq\x00]q\x01(KxKyKze\x85q\x02Rq\x03.')
'[120, 121, 122]'

The problem is that the bytes() constructor argument is a list of ints, which gives a different result when reconstructed under 2.x where bytes is an alias of str:

>>> pickletools.dis(pickle.dumps(b'xyz', protocol=2))
    0: \x80 PROTO      2
    2: c    GLOBAL     '__builtin__ bytes'
   21: q    BINPUT     0
   23: ]    EMPTY_LIST
   24: q    BINPUT     1
   26: (    MARK
   27: K        BININT1    120
   29: K        BININT1    121
   31: K        BININT1    122
   33: e        APPENDS    (MARK at 26)
   34: \x85 TUPLE1
   35: q    BINPUT     2
   37: R    REDUCE
   38: q    BINPUT     3
   40: .    STOP
highest protocol among opcodes = 2

Bytearray objects use a different trick: they pass a (unicode string, encoding) pair which has the same constructor semantics under 2.x and 3.x. Additionally, such encoding is statistically more efficient: a list of 1-byte ints will take 2 bytes per encoded char, while a latin1-to-utf8 transcoded string (BINUNICODE uses utf-8) will take on average 1.5 bytes per encoded char (assuming a 50% probability of higher-than-127 bytes).

>>> pickletools.dis(pickle.dumps(bytearray(b'xyz'), protocol=2))
    0: \x80 PROTO      2
    2: c    GLOBAL     '__builtin__ bytearray'
   25: q    BINPUT     0
   27: X    BINUNICODE 'xyz'
   35: q    BINPUT     1
   37: X    BINUNICODE 'latin-1'
   49: q    BINPUT     2
   51: \x86 TUPLE2
   52: q    BINPUT     3
   54: R    REDUCE
   55: q    BINPUT     4
   57: .    STOP
highest protocol among opcodes = 2

----------
components: Library (Lib)
messages: 148635
nosy: alexandre.vassalotti, irmen, pitrou
priority: high
severity: normal
status: open
title: Bytes objects pickled in 3.x with protocol <=2 are unpickled incorrectly in 2.x
type: behavior
versions: Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13505>
_______________________________________

From report at bugs.python.org  Wed Nov 30 03:33:46 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 30 Nov 2011 02:33:46 +0000
Subject: [issue10747] Include version info in Windows shortcuts
In-Reply-To: <1292932439.68.0.958376446451.issue10747@psf.upfronthosting.co.za>
Message-ID: <1322620426.86.0.138300219913.issue10747@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
nosy: +terry.reedy
versions: +Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10747>
_______________________________________

From report at bugs.python.org  Wed Nov 30 03:41:04 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 30 Nov 2011 02:41:04 +0000
Subject: [issue13504] Meta-issue for "Invent with Python" IDLE feedback
In-Reply-To: <1322613083.36.0.200533745275.issue13504@psf.upfronthosting.co.za>
Message-ID: <1322620864.67.0.170424329861.issue13504@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13504>
_______________________________________

From report at bugs.python.org  Wed Nov 30 03:51:05 2011
From: report at bugs.python.org (Marco Scataglini)
Date: Wed, 30 Nov 2011 02:51:05 +0000
Subject: [issue13506] IDLE sys.path does not contain Current Working Directory
Message-ID: <1322621465.07.0.137768445913.issue13506@psf.upfronthosting.co.za>


New submission from Marco Scataglini <atlantide at gmx.com>:

The IDLE shell sys.path does not contains any entry for the Current Working Directory ('' or '.' or '.\'); without it, when changing the CWD with os.chdir(), the shell cannot find, execute or import scripts or module in it.

I can start the standard Python interactive shell and os.chdir to any dev or test directories and import or call scripts and modules, or I can cd first to any of those directories from any shell (sh, batch, cmd.com), then start Python interactive shell and import or call scripts and modules, because there is the CWD available in the sys.path as ''.

I tried to manually add it to IDLE:

from cli by calling idle.py or idle.pyw with "-cimport sys;sys.path.insert(0,"");del sys"

or by making a IDLESTARTUP.py script

import sys
sys.path.insert(0,"")
del sys

and setting the IDLESTARTUP env var pointing at it

but these work in adding the CWD to sys.path only for the first run (start) of IDLE shell; but when it get restarted (ex.: the Shell/Restart Shell toolbar option) the CWD get reset without the CWD entry, and again it has the same problem

I also tried to cd from shell (sh, bash, cmd.com) first and then start IDLE and it worked for importing and calling modules and scripts in the specific dev/test directory, but it failed to import or call other standard scripts that actually are in the sys.path (ex.: win32ui).

This is needed to use IDLE to develop and test new scripts and modules not yet ready to be included into the standard libraries and paths, so momentarily modifying the path as above that also does not survive restarts made within the application, or permanently modifying the path statically to include any dev and test dir by adding the absolute path(s ) to env var PYTHONPATH are both not correct way.

And anyway it is not consistent with the behavior of the standard Python interactive shell that includes the CWD in sys.path (as '' right at the beginning), therefore os.chdir('to any non in sys.path dirs') works correctly in contrast with IDLE shell behavior... and who knows what else it breaks.

I am not an expert on python environment, but I have 20+ years professional experience in many other high profile QA dev and testing project (just Google me), so I just thing it should be fixed, since I see this problem since 2008 and I know others that have the same issue for long time before that.
I assure you inconsistency in IDLE and Python like that separate production products from hack toys and I know for a fact are alienating both novices and veterans, because first it makes it difficult to use IDLE for basic learning and second, because it get you skeptical to trust the rest of Python will behave differently and correctly for main development, since its main IDE distributed with the language does not.

If there is anything that I don't see just let me know,
thanks.

----------
components: IDLE
messages: 148636
nosy: MarcoScataglini
priority: normal
severity: normal
status: open
title: IDLE sys.path does not contain Current Working Directory
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13506>
_______________________________________

From report at bugs.python.org  Wed Nov 30 04:05:40 2011
From: report at bugs.python.org (Roger Serwy)
Date: Wed, 30 Nov 2011 03:05:40 +0000
Subject: [issue13504] Meta-issue for "Invent with Python" IDLE feedback
In-Reply-To: <1322613083.36.0.200533745275.issue13504@psf.upfronthosting.co.za>
Message-ID: <1322622340.83.0.894599136169.issue13504@psf.upfronthosting.co.za>


Changes by Roger Serwy <roger.serwy at gmail.com>:


----------
nosy: +serwy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13504>
_______________________________________

From report at bugs.python.org  Wed Nov 30 04:51:07 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Wed, 30 Nov 2011 03:51:07 +0000
Subject: [issue13405] Add DTrace probes
In-Reply-To: <1321299726.66.0.343368151185.issue13405@psf.upfronthosting.co.za>
Message-ID: <1322625067.26.0.366680809258.issue13405@psf.upfronthosting.co.za>


Changes by Jes?s Cea Avi?n <jcea at jcea.es>:


Added file: http://bugs.python.org/file23814/3968bb3e698f.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13405>
_______________________________________

From report at bugs.python.org  Wed Nov 30 04:51:28 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Wed, 30 Nov 2011 03:51:28 +0000
Subject: [issue13405] Add DTrace probes
In-Reply-To: <1321299726.66.0.343368151185.issue13405@psf.upfronthosting.co.za>
Message-ID: <1322625088.27.0.134817091082.issue13405@psf.upfronthosting.co.za>


Changes by Jes?s Cea Avi?n <jcea at jcea.es>:


Removed file: http://bugs.python.org/file23795/01f206595d16.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13405>
_______________________________________

From report at bugs.python.org  Wed Nov 30 04:55:33 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Wed, 30 Nov 2011 03:55:33 +0000
Subject: [issue13405] Add DTrace probes
In-Reply-To: <1321299726.66.0.343368151185.issue13405@psf.upfronthosting.co.za>
Message-ID: <1322625333.97.0.0330454178441.issue13405@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

Stack trace helper done for the case that the filenames and the function names are ascii. Pending the case we have latin1 and unicode characters.

In the process I have learned more about the implementation details of PEP-393 that I would like to know :-).

Code ready for general testing. I want to do same changes before asking for review.

I know that 2.7 patch is not going to be integrated in mainline but would you consider reviewing it?. I would adopt the changes proposed, and integrate them also in 3.3 version, before the formal review.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13405>
_______________________________________

From report at bugs.python.org  Wed Nov 30 04:59:35 2011
From: report at bugs.python.org (Zachary Richey)
Date: Wed, 30 Nov 2011 03:59:35 +0000
Subject: [issue12832] The documentation for the print function should
	explain/point to how to control the sys.stdout encoding
In-Reply-To: <1314191894.1.0.666645625262.issue12832@psf.upfronthosting.co.za>
Message-ID: <1322625575.95.0.418725543545.issue12832@psf.upfronthosting.co.za>


Zachary Richey <mach1723 at gmail.com> added the comment:

I've reworded the patch and fixed the issues in the patch pointed out by eric.araujo.

----------
Added file: http://bugs.python.org/file23815/functions_print_doc_2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12832>
_______________________________________

From report at bugs.python.org  Wed Nov 30 05:59:53 2011
From: report at bugs.python.org (Marco Scataglini)
Date: Wed, 30 Nov 2011 04:59:53 +0000
Subject: [issue13506] IDLE sys.path does not contain Current Working Directory
In-Reply-To: <1322621465.07.0.137768445913.issue13506@psf.upfronthosting.co.za>
Message-ID: <1322629193.49.0.496182551174.issue13506@psf.upfronthosting.co.za>


Changes by Marco Scataglini <atlantide at gmx.com>:


----------
nosy: +kbk

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13506>
_______________________________________

From report at bugs.python.org  Wed Nov 30 06:33:09 2011
From: report at bugs.python.org (Meador Inge)
Date: Wed, 30 Nov 2011 05:33:09 +0000
Subject: [issue13505] Bytes objects pickled in 3.x with protocol <=2 are
	unpickled incorrectly in 2.x
In-Reply-To: <1322619707.99.0.479265394652.issue13505@psf.upfronthosting.co.za>
Message-ID: <1322631189.64.0.79118695057.issue13505@psf.upfronthosting.co.za>


Changes by Meador Inge <meadori at gmail.com>:


----------
nosy: +meador.inge
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13505>
_______________________________________

From report at bugs.python.org  Wed Nov 30 08:07:07 2011
From: report at bugs.python.org (Marco Scataglini)
Date: Wed, 30 Nov 2011 07:07:07 +0000
Subject: [issue13506] IDLE sys.path does not contain Current Working Directory
In-Reply-To: <1322621465.07.0.137768445913.issue13506@psf.upfronthosting.co.za>
Message-ID: <1322636827.64.0.350529177917.issue13506@psf.upfronthosting.co.za>


Marco Scataglini <atlantide at gmx.com> added the comment:

... I think it could be fixed by adding

sys.path.insert(0,"")

on the # process sys.argv and sys.path: section in PyShell.py after (~about) line 1383

            sys.path.insert(0, dir)
	sys.path.insert(0,"")        <----HERE
    # check the IDLE settings configuration (but command line overrides)

(Unified diff/patch file attached)

----------
Added file: http://bugs.python.org/file23816/PyShell.py - Udiff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13506>
_______________________________________

From report at bugs.python.org  Wed Nov 30 08:27:17 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Wed, 30 Nov 2011 07:27:17 +0000
Subject: [issue13405] Add DTrace probes
In-Reply-To: <1322625333.97.0.0330454178441.issue13405@psf.upfronthosting.co.za>
Message-ID: <4ED5DAD4.6090203@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> I know that 2.7 patch is not going to be integrated in mainline but would you consider reviewing it?

I personally won't. If there are things that will apply to 2.7 as well,
you surely can backport them also, no?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13405>
_______________________________________

From report at bugs.python.org  Wed Nov 30 08:44:31 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Wed, 30 Nov 2011 07:44:31 +0000
Subject: [issue13502] Documentation for Event.wait return value is either
	wrong or incomplete
In-Reply-To: <1322600154.01.0.466604364798.issue13502@psf.upfronthosting.co.za>
Message-ID: <CAH_1eM3GhXAMbwD+__3ojjdXF5yMVf54QwyD3BjkS5j4t59vug@mail.gmail.com>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

> So I'm changing my mind and saying it seems desireable to return True if the wait succeeded before the timeout's end, even though the flag may have been reset in the meantime.

Agreed. What matters is that the event has been signaled, not that
it's currently signaled.

----------
title: Event.wait sometimes returns False even when no timeout has occurred -> Documentation for Event.wait return value is either wrong or incomplete

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13502>
_______________________________________

From report at bugs.python.org  Wed Nov 30 08:53:10 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Wed, 30 Nov 2011 07:53:10 +0000
Subject: [issue12014] str.format parses replacement field incorrectly
In-Reply-To: <1304646359.82.0.599761597998.issue12014@psf.upfronthosting.co.za>
Message-ID: <1322639590.75.0.71007469402.issue12014@psf.upfronthosting.co.za>


Petri Lehtinen <petri at digip.org> added the comment:

> I just noticed that the patch labelled strformat-as-document is
> actually the same as the other one, owing to my incompetence.

All three patches look different to me.

> Anyway, as far as I can tell the patches would have to be reworked
> in the light of recent changes anyway. I am willing to do this if
> there's actually interest. Otherwise, is there anything else I can
> do here? Is it necessary to write a PEP or take this to python-ideas
> or something?

There's still interest, at least from me :)

In my opinion we should have the documented behavior (integer or identifier as field_name), AND braces should be disallowed inside the format string, with the exception of one level of nesting in the format_spec part.

This should probably be taken to python-dev once more, as the previous discussion didn't reach consesus, except that the current approach is bad and something needs to be done.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12014>
_______________________________________

From report at bugs.python.org  Wed Nov 30 09:04:31 2011
From: report at bugs.python.org (Roger Serwy)
Date: Wed, 30 Nov 2011 08:04:31 +0000
Subject: [issue13506] IDLE sys.path does not contain Current Working Directory
In-Reply-To: <1322621465.07.0.137768445913.issue13506@psf.upfronthosting.co.za>
Message-ID: <1322640271.22.0.46161027743.issue13506@psf.upfronthosting.co.za>


Roger Serwy <roger.serwy at gmail.com> added the comment:

+1

The proposed patch works as described. 

I do agree with Marco that IDLE does need some more QA.

----------
nosy: +serwy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13506>
_______________________________________

From report at bugs.python.org  Wed Nov 30 09:28:25 2011
From: report at bugs.python.org (Thorsten Simons)
Date: Wed, 30 Nov 2011 08:28:25 +0000
Subject: [issue13471] setting access time beyond Jan. 2038 on remote share
	failes on Win7 x64
In-Reply-To: <1322142567.98.0.834575465366.issue13471@psf.upfronthosting.co.za>
Message-ID: <1322641705.93.0.966451691009.issue13471@psf.upfronthosting.co.za>


Thorsten Simons <th at snomis.de> added the comment:

Gentlemen,

thank you for your contribution - the information about the Samba fix solved the problem!

----------
resolution:  -> works for me
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13471>
_______________________________________

From report at bugs.python.org  Wed Nov 30 09:30:09 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Wed, 30 Nov 2011 08:30:09 +0000
Subject: [issue13471] setting access time beyond Jan. 2038 on remote share
	failes on Win7 x64
In-Reply-To: <1322142567.98.0.834575465366.issue13471@psf.upfronthosting.co.za>
Message-ID: <1322641809.74.0.271637028101.issue13471@psf.upfronthosting.co.za>


Changes by Petri Lehtinen <petri at digip.org>:


----------
resolution: works for me -> invalid
stage:  -> committed/rejected

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13471>
_______________________________________

From report at bugs.python.org  Wed Nov 30 10:11:11 2011
From: report at bugs.python.org (Ned Deily)
Date: Wed, 30 Nov 2011 09:11:11 +0000
Subject: [issue13504] Meta-issue for "Invent with Python" IDLE feedback
In-Reply-To: <1322613083.36.0.200533745275.issue13504@psf.upfronthosting.co.za>
Message-ID: <1322644271.43.0.115000959258.issue13504@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

#10364 covers point 7 (make .py default added extension on save)

----------
dependencies: +IDLE: make .py default added extension on save
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13504>
_______________________________________

From report at bugs.python.org  Wed Nov 30 11:07:59 2011
From: report at bugs.python.org (Ned Deily)
Date: Wed, 30 Nov 2011 10:07:59 +0000
Subject: [issue13507] Modify OS X installer builds to package liblzma for the
	new lzma module
Message-ID: <1322647679.29.0.297920473861.issue13507@psf.upfronthosting.co.za>


New submission from Ned Deily <nad at acm.org>:

Since AFAIK Apple does not currently ship a version of liblzma with Mac OS X, the OS X installer build script should be modified to build and link a version in support of the new lzma module (Issue6715).

Mac/BuildScript/build-installer.py

http://tukaani.org/xz/

----------
assignee: ned.deily
components: Build, Macintosh
messages: 148646
nosy: nadeem.vawda, ned.deily, ronaldoussoren
priority: normal
severity: normal
stage: needs patch
status: open
title: Modify OS X installer builds to package liblzma for the new lzma module
type: feature request
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13507>
_______________________________________

From report at bugs.python.org  Wed Nov 30 11:11:03 2011
From: report at bugs.python.org (Ned Deily)
Date: Wed, 30 Nov 2011 10:11:03 +0000
Subject: [issue6715] xz compressor support
In-Reply-To: <1250502444.31.0.107447392137.issue6715@psf.upfronthosting.co.za>
Message-ID: <1322647863.39.0.188263011328.issue6715@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

I've opened Issue13507 to track adding liblzma to the OS X installer builds.

----------
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6715>
_______________________________________

From report at bugs.python.org  Wed Nov 30 13:17:44 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 30 Nov 2011 12:17:44 +0000
Subject: [issue13097] ctypes: segfault with large number of callback arguments
In-Reply-To: <1317700637.71.0.186696346618.issue13097@psf.upfronthosting.co.za>
Message-ID: <1322655464.22.0.599827464716.issue13097@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/issue13097>
_______________________________________

From report at bugs.python.org  Wed Nov 30 13:20:04 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 30 Nov 2011 12:20:04 +0000
Subject: [issue13097] ctypes: segfault with large number of callback arguments
In-Reply-To: <1317700637.71.0.186696346618.issue13097@psf.upfronthosting.co.za>
Message-ID: <1322655604.23.0.598398075147.issue13097@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Right, alloca() could be replaced by some malloc(), but is it really useful?  After all, when a C function calls back to Python, all arguments needs to be pushed to the stack anyway.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13097>
_______________________________________

From report at bugs.python.org  Wed Nov 30 13:21:01 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 30 Nov 2011 12:21:01 +0000
Subject: [issue9116] test_capi.test_no_FatalError_infinite_loop crash on
	Windows
In-Reply-To: <1277827107.42.0.0793977492373.issue9116@psf.upfronthosting.co.za>
Message-ID: <1322655661.98.0.853678603529.issue9116@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/issue9116>
_______________________________________

From report at bugs.python.org  Wed Nov 30 13:40:22 2011
From: report at bugs.python.org (python_hu)
Date: Wed, 30 Nov 2011 12:40:22 +0000
Subject: [issue13493] Import error with embedded python on AIX 6.1
In-Reply-To: <1322479753.88.0.634847584065.issue13493@psf.upfronthosting.co.za>
Message-ID: <1322656822.82.0.0114460249261.issue13493@psf.upfronthosting.co.za>


python_hu <nari_hu at 163.com> added the comment:

Thank Amaury,you are right.
So python2.7 share library compile finished,and python2.7 works,and then
I write a test program,to test libpython2.7.so share library,but it dumped!

code:
-----------------------
#include <stdio.h>^M
#include "Python.h"^M
#include <dlfcn.h> ^M
^M
int main( int argc, char **argv )^M
{^M

 Py_Initialize(); 
if(!Py_IsInitialized())
{
        printf("py initialized fail!");
        return -1;
}

void* handle = dlopen("/usr/local/lib/python2.6/lib-dynload/time.so", 2);
if (handle == NULL) {
       const char *error = dlerror();
       if (error == NULL)
            error = "unknown dlopen() error";
           printf("erro=%s\n",error);
          return NULL;
}
if(!Py_IsInitialized())
{
        printf("py initialized fail!");
        return -1;
}

printf("hi,python!\n");

PyRun_SimpleString("from time import time,ctime\nprint 'Today is',ctime(time())\n");

Py_Finalize();
}
----------------------------------------------------

This code can compile sucess,but run core dump:

ibm1:mmi>pytest
hi,python!
Fatal Python error: Interpreter not initialized (version mismatch?)

The core dump file:
---------------------------------------------------------
IOT/Abort trap in pthread_kill at 0x900000000e23450 ($t1)
0x900000000e23450 (pthread_kill+0xb0) e8410028          ld   r2,0x28(r1)
(dbx) run
hi,python!
Fatal Python error: Interpreter not initialized (version mismatch?)

IOT/Abort trap in pthread_kill at 0x900000000e23450 ($t1)
0x900000000e23450 (pthread_kill+0xb0) e8410028          ld   r2,0x28(r1)
(dbx) where
pthread_kill(??, ??) at 0x900000000e23450
_p_raise(??) at 0x900000000e22cc8
raise.raise(??) at 0x90000000002b10c
abort() at 0x900000000094544
pythonrun.Py_FatalError(msg = "init%.200s"), line 1675 in "pythonrun.c"
modsupport.Py_InitModule4_64(name = (nil), methods = 0x09001000a0b467d8, doc = (invalid char ptr (0x2f7573722f6c6f63)), passthrough = 0x616c2f6c69622f70, module_api_version = 0), line 38 in "modsupport.c"
inittime(), line 825 in "timemodule.c"
importdl._PyImport_LoadDynamicModule(name = (nil), pathname = "", fp = 0x0000000000000004), line 53 in "importdl.c"
import.load_module(name = "", fp = 0x0fffffffffffd8d8, buf = "^O\377\377\377\377\377\316p^I", type = 150994944, loader = 0x0000000110016e90), line 1830 in "import.c"
import.import_submodule(mod = 0x0900000005d0ebc4, subname = "", fullname = "^I"), line 2592 in "import.c"
import.load_next(mod = 0x0000000000000005, altmod = (nil), p_name = 0x0900000005dcba27, buf = "", p_buflen = 0x09001000a0b2f9d0), line 2412 in "import.c"
import.import_module_level(name = (nil), globals = 0x000000011008c328, locals = 0x000000011008c328, fromlist = 0x000000011013d608, level = -1), line 2133 in "import.c"
import.PyImport_ImportModuleLevel(name = "", globals = (nil), locals = 0x0900000005dcba20, fromlist = 0x09001000a0b2f9d0, level = 268435455), line 2185 in "import.c"
bltinmodule.builtin___import__(self = 0x0fffffffffffd970, args = 0x0000000000000060, kwds = 0x0fffffffffffd980), line 48 in "bltinmodule.c"
methodobject.PyCFunction_Call(func = 0x0fffffffffffd9f0, arg = 0x09001000a0b467d8, kw = 0x0fffffffffffda00), line 85 in "methodobject.c"
abstract.PyObject_Call(func = 0x0900000005cb9ae4, arg = 0x09001000a0b467d8, kw = 0x0fffffffffffda90), line 2492 in "abstract.c"
ceval.PyEval_CallObjectWithKeywords(func = 0x0000000000000004, arg = 0x00000001100992d0, kw = 0x000000011008c328), line 3619 in "ceval.c"
ceval.PyEval_EvalFrameEx(f = 0x0fffffffffffdda0, throwflag = 0), line 2159 in "ceval.c"
ceval.PyEval_EvalCodeEx(co = (nil), globals = 0x000000011000ca50, locals = 0x0fffffffffffdee4, args = 0x000000011019a740, argcount = 1, kws = 0x09001000a0075420, kwcount = -1159983106, defs = 0xbadc0ffee0ddf00d, defcount = 0, closure = (nil)), line 3000 in "ceval.c"
ceval.PyEval_EvalCode(co = 0x0900000005d578cc, globals = 0x488842281006e148, locals = (nil)), line 541 in "ceval.c"
pythonrun.run_mod(mod = 0x0fffffffffffdff0, filename = "^I\377\377\377\360", globals = 0x0900000000028c20, locals = 0x09001000a0b467d8, flags = 0xbadc0ffee0ddf00d, arena = 0x09001000a0075420), line 1351 in "pythonrun.c"
pythonrun.PyRun_StringFlags(str = "\350A", start = -1159983106, globals = 0xbadc0ffee0ddf00d, locals = 0xbadc0ffee0ddf00d, flags = 0xbadc0ffee0ddf00d), line 1314 in "pythonrun.c"
pythonrun.PyRun_SimpleStringFlags(command = "sucess!", flags = 0x0000000000000001), line 967 in "pythonrun.c"
main.main(argc = 1, argv = 0x0fffffffffffe190), line 42 in "main.cpp"
(dbx) 
---------------------------------------
the line 38 in "modsupport.c":
    if (!Py_IsInitialized())
        Py_FatalError("Interpreter not initialized (version mismatch?)");
it looks like "Py_IsInitialized()" is false,but in my main(),the "Py_IsInitialized()" return true.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13493>
_______________________________________

From report at bugs.python.org  Wed Nov 30 13:40:44 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 30 Nov 2011 12:40:44 +0000
Subject: [issue7652] Merge C version of decimal into py3k.
In-Reply-To: <1262860972.65.0.690079130991.issue7652@psf.upfronthosting.co.za>
Message-ID: <1322656844.5.0.664303563845.issue7652@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> Just to clarify, no decision has yet been made on *whether*
> the cdecimal work should be integrated into py3k;
> we'll consult python-dev on this once we've got a working branch
> and performance information.

So, what is the status today?

_decimal looks to be huge. Does Python really need yet another multiprecision library? There is already gmpy and bigfloat, based on the heavily optimized GMP library, for example. Is it a license issue? Can't we reuse GMP/MPFR to offer a Decimal API?

_decimal should maybe first be distributed as a third party library until it is really well tested and its API is really stable, until we can decide to integrate it. The patch adds __setattr__ to the Decimal class.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7652>
_______________________________________

From report at bugs.python.org  Wed Nov 30 13:45:29 2011
From: report at bugs.python.org (Berker Peksag)
Date: Wed, 30 Nov 2011 12:45:29 +0000
Subject: [issue13504] Meta-issue for "Invent with Python" IDLE feedback
In-Reply-To: <1322613083.36.0.200533745275.issue13504@psf.upfronthosting.co.za>
Message-ID: <1322657129.07.0.321587315368.issue13504@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


----------
nosy: +berkerpeksag

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13504>
_______________________________________

From report at bugs.python.org  Wed Nov 30 13:59:43 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 30 Nov 2011 12:59:43 +0000
Subject: [issue13493] Import error with embedded python on AIX 6.1
In-Reply-To: <1322479753.88.0.634847584065.issue13493@psf.upfronthosting.co.za>
Message-ID: <1322657983.23.0.504977235412.issue13493@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

> dlopen("/usr/local/lib/python2.6/lib-dynload/time.so", 2);

You are trying to open a .so from another Python installation.
It won't work: it is certainly linked to another Python VM, which is not initialized.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13493>
_______________________________________

From report at bugs.python.org  Wed Nov 30 14:03:29 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 30 Nov 2011 13:03:29 +0000
Subject: [issue7652] Merge C version of decimal into py3k.
In-Reply-To: <1262860972.65.0.690079130991.issue7652@psf.upfronthosting.co.za>
Message-ID: <1322658209.73.0.41865435677.issue7652@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> Does Python really need yet another multiprecision library?

It's not really another library:  it's a reimplementation of the existing decimal library in C.  The decimal library is *hugely* valuable to the financial world, but its slowness is a major concern.  _decimal would help to address that concern.

> Can't we reuse GMP/MPFR to offer a Decimal API?

Nope: those are for binary floating-point.  Shoehorning decimal semantics on top of a binary floating-point library is a really bad idea.  (Actually, that's a part of why decimal.py is slow---it's using Python's *binary* integers to store *decimal* coefficients, so that even simple addition is now a quadratic operation, thanks to the binary <-> decimal conversions involved.)

> _decimal should maybe first be distributed as a third party library until it is really well tested and its API is > really stable.

My take is that this has already happened.

The only problem from my perspective is getting someone to find time to review such a massive patch.  I've been wondering whether we could get away with some kind of 'statistical' review:  do a large-scale review, and then instead of having someone go through every line of C code, pick a few representative sections at random and review those.  If those code portions make it through the review unscathed, declare the code good and merge it in.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7652>
_______________________________________

From report at bugs.python.org  Wed Nov 30 15:20:51 2011
From: report at bugs.python.org (=?utf-8?b?U8OpYmFzdGllbiBTYWJsw6k=?=)
Date: Wed, 30 Nov 2011 14:20:51 +0000
Subject: [issue11732] Skip decorator for tests requiring manual intervention
	on Windows
In-Reply-To: <1301604811.48.0.519862680053.issue11732@psf.upfronthosting.co.za>
Message-ID: <1322662851.23.0.195423288907.issue11732@psf.upfronthosting.co.za>


Changes by S?bastien Sabl? <sable at users.sourceforge.net>:


----------
nosy: +sable

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11732>
_______________________________________

From report at bugs.python.org  Wed Nov 30 15:22:26 2011
From: report at bugs.python.org (=?utf-8?q?Per_=C3=98yvind_Karlsen?=)
Date: Wed, 30 Nov 2011 14:22:26 +0000
Subject: [issue6715] xz compressor support
In-Reply-To: <1250502444.31.0.107447392137.issue6715@psf.upfronthosting.co.za>
Message-ID: <1322662946.55.0.470501742068.issue6715@psf.upfronthosting.co.za>


Per ?yvind Karlsen <peroyvind at mandriva.org> added the comment:

Ah, I thought that he had reused most of the original C code in _lzmamodule.c not replaced by python code, but I see that not being the case now (only slight fragments;).

Oh well, I thought that I'd still earned a note with some slight credit at least, but I guess I won't go postal or anything in lack of either.. :p

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6715>
_______________________________________

From report at bugs.python.org  Wed Nov 30 15:28:43 2011
From: report at bugs.python.org (=?utf-8?b?U8OpYmFzdGllbiBTYWJsw6k=?=)
Date: Wed, 30 Nov 2011 14:28:43 +0000
Subject: [issue7833] bdist_wininst installers fail to load extensions built
	with Issue4120 patch
In-Reply-To: <1265062373.01.0.461114831555.issue7833@psf.upfronthosting.co.za>
Message-ID: <1322663323.81.0.610174559129.issue7833@psf.upfronthosting.co.za>


Changes by S?bastien Sabl? <sable at users.sourceforge.net>:


----------
nosy: +sable

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7833>
_______________________________________

From report at bugs.python.org  Wed Nov 30 15:46:09 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 30 Nov 2011 14:46:09 +0000
Subject: [issue6715] xz compressor support
In-Reply-To: <1250502444.31.0.107447392137.issue6715@psf.upfronthosting.co.za>
Message-ID: <1322664369.17.0.77604544672.issue6715@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

> Oh well, I thought that I'd still earned a note with some slight credit
at least

I completely agree.  Sometimes people get credit for simple bug fixes (count me among them) so the author of the first working implementation deserves some recognition IMO.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6715>
_______________________________________

From report at bugs.python.org  Wed Nov 30 15:49:19 2011
From: report at bugs.python.org (Roger Serwy)
Date: Wed, 30 Nov 2011 14:49:19 +0000
Subject: [issue13504] Meta-issue for "Invent with Python" IDLE feedback
In-Reply-To: <1322613083.36.0.200533745275.issue13504@psf.upfronthosting.co.za>
Message-ID: <1322664559.96.0.249164977208.issue13504@psf.upfronthosting.co.za>


Roger Serwy <roger.serwy at gmail.com> added the comment:

#2704 covers point 1 (In the shell window, if you click anywhere but on the current line and move the cursor there, the window stops handling key strokes.)

#3851 covers point 1.1) "Pressing the Home key moves the cursor before the >>> prompt, which then makes the keyboard unresponsive."

#7136 covers point 5) "Opening a file editor window or a shell window isn?t clear."

#6804 and #6858 are also related to point 7 "It?s too easy to forget the .py extension when saving a file."

#694339 covers point 13) "The Indent Region and Dedent Region lines use the keyboard shortcut Ctrl-] and Ctrl-[, even though nobody uses that because you can indent the region by pressing tab."

#5150 is related to point 14) "Get rid of the Format > ?Strip trailing whitespace? option from the menu"

#10747 covers point 16) "The Windows shortcuts for IDLE don?t have the version in their name."

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13504>
_______________________________________

From report at bugs.python.org  Wed Nov 30 15:54:33 2011
From: report at bugs.python.org (=?utf-8?q?Lo=C3=AFc_Minier?=)
Date: Wed, 30 Nov 2011 14:54:33 +0000
Subject: [issue13508] ctypes' find_library breaks with ARM ABIs
Message-ID: <1322664873.68.0.763423976883.issue13508@psf.upfronthosting.co.za>


New submission from Lo?c Minier <lool at dooz.org>:

Hi,

This bug was originally reported at 
https://bugs.launchpad.net/bugs/898172

ctypes/utils.py provides a find_library function which amongst other things will scan the ldconfig -p output on linux to find libraries by name.  It applies some logic to filter out incompatible libraries, however the logic is mainly based on uname output which is incorrect.

We noticed because the new Debian/Ubuntu armhf ports have a slightly different ldconfig -p output than the armel ports; one gets ",hard-float" in the output, e.g.:
        ld-linux.so.3 (libc6,hard-float) => /lib/arm-linux-gnueabihf/ld-linux.so.3

there's provision in find_library to allow for certain strings when uname returns certain names:
             mach_map = {
                 'x86_64-64': 'libc6,x86-64',
                 'ppc64-64': 'libc6,64bit',
                 'sparc64-64': 'libc6,64bit',
                 's390x-64': 'libc6,64bit',
                 'ia64-64': 'libc6,IA-64',

but this is incorrect for multiple reasons:
a) this requires setting utsname properly before running a 32-bits python on a 64-bits kernel (e.g. "linux32 ./foo.py" instead of just "./foo.py"); this shouldn't be needed and breaks 32-bits userspace installations with a 64-bits kernel
b) uname output can be anything really, e.g. i486, i586, i686 etc. on 32-bits x86, or armv5l, armv6l, armv7l etc. on ARM
c) uname output doesn't indicate userspace ABI, a single kernel can support multiple ABIs; for instance ARM kernels can support EABI and OABI (old ABI) syscall ABIs at the same time, and even with the same syscall ABI like EABI the userspace calling conventions might allow for multiple ABIs to be present on the filesystem -- for instance soft-float and hard-float userspace calling conventions

I've attached a patch to ctypes/utils.py in the Launchpad bug which I'll also attach here.  It will work for either soft-float or hard-float, but not if "ldconfig -p" lists both types of libraries (as will be the case with biarch or multiarch systems).

It is extremely hard to reproduce correct glibc semantics in find_library, and a linux implementation would necessarily become extremely glibc and linux specific.  One possible way is to look at /proc/$pid/maps output to find information about the ABI of the currently running program, and then ask the runtime linker (ld.so) to check whether a given library is compatible or not (--verify).  Another way would be to run ldd on sys.executable to find the runtime linker or libc.  This is all extremely fragile and linux andglibc specific, and will likely fail in special cases.

Finally, one needs to wonder whether offering "find_library" as an API isn't calling for trouble; dlopen() requires one to state which SOVER should be used, e.g. dlopen("libmagic.so.1"), not dlopen("magic").  Allowing the first SOVER to be used means that the behavior is not determinstic and also means that people wont think of binary compatibility when implementing ctypes-based bindings.  I would personally prefer if this API was deprecated and if we recommended for upstreams to use ctypes.cdll.LoadLibrary("libmagic.so.1") constructs.

Cheers,

----------
components: ctypes
messages: 148656
nosy: lool
priority: normal
severity: normal
status: open
title: ctypes' find_library breaks with ARM ABIs
type: behavior
versions: Python 2.6, Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13508>
_______________________________________

From report at bugs.python.org  Wed Nov 30 15:55:38 2011
From: report at bugs.python.org (=?utf-8?q?Lo=C3=AFc_Minier?=)
Date: Wed, 30 Nov 2011 14:55:38 +0000
Subject: [issue13508] ctypes' find_library breaks with ARM ABIs
In-Reply-To: <1322664873.68.0.763423976883.issue13508@psf.upfronthosting.co.za>
Message-ID: <1322664938.14.0.73684810776.issue13508@psf.upfronthosting.co.za>


Changes by Lo?c Minier <lool at dooz.org>:


----------
keywords: +patch
Added file: http://bugs.python.org/file23817/ctypes-arm.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13508>
_______________________________________

From report at bugs.python.org  Wed Nov 30 15:57:51 2011
From: report at bugs.python.org (Meador Inge)
Date: Wed, 30 Nov 2011 14:57:51 +0000
Subject: [issue13508] ctypes' find_library breaks with ARM ABIs
In-Reply-To: <1322664873.68.0.763423976883.issue13508@psf.upfronthosting.co.za>
Message-ID: <1322665071.69.0.043511249338.issue13508@psf.upfronthosting.co.za>


Changes by Meador Inge <meadori at gmail.com>:


----------
nosy: +meador.inge
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13508>
_______________________________________

From report at bugs.python.org  Wed Nov 30 15:58:28 2011
From: report at bugs.python.org (=?utf-8?q?Lo=C3=AFc_Minier?=)
Date: Wed, 30 Nov 2011 14:58:28 +0000
Subject: [issue13508] ctypes' find_library breaks with ARM ABIs
In-Reply-To: <1322664873.68.0.763423976883.issue13508@psf.upfronthosting.co.za>
Message-ID: <1322665108.32.0.414886836156.issue13508@psf.upfronthosting.co.za>


Lo?c Minier <lool at dooz.org> added the comment:

While I'm at it, find_library also tries creating temp files when running gcc and other issues mention trouble running gcc or propose running ld:
http://bugs.python.org/issue9998
http://bugs.python.org/issue5289

IMHO, calling binutils/gcc is troublesome, it's not necessarily installed on production systems and creating tempfiles when running a program just to locate a library is fragile at best.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13508>
_______________________________________

From report at bugs.python.org  Wed Nov 30 16:09:21 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 30 Nov 2011 15:09:21 +0000
Subject: [issue6715] xz compressor support
In-Reply-To: <1250502444.31.0.107447392137.issue6715@psf.upfronthosting.co.za>
Message-ID: <1322665761.41.0.1232441577.issue6715@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Nadeem: Instead of duplicating the list of archiving/compression modules in each doc, what about only linking to the shutil doc for archives and the archiving.rst file?  (I can make the patch, just wanted feedback first)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6715>
_______________________________________

From report at bugs.python.org  Wed Nov 30 16:11:45 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Wed, 30 Nov 2011 15:11:45 +0000
Subject: [issue6715] xz compressor support
In-Reply-To: <1250502444.31.0.107447392137.issue6715@psf.upfronthosting.co.za>
Message-ID: <1322665905.62.0.731537676382.issue6715@psf.upfronthosting.co.za>


Nadeem Vawda <nadeem.vawda at gmail.com> added the comment:

>> Not meaning to sound petty, but wouldn't it be common etiquette to
>> retain some original copyright notice from original code intact..?
>
> It seemed to me that Nadeem had rewritten everything from scratch. Is
> there any code of yours in the current module?

That is correct. Based on my experience with the bz2 module, rewriting
from scratch seemed to make more sense.

>> Oh well, I thought that I'd still earned a note with some slight
> credit at least
>
> I completely agree.  Sometimes people get credit for simple bug fixes
> (count me among them) so the author of the first working implementation
> deserves some recognition IMO.

Of course. How does this look?

    diff --git a/Misc/ACKS b/Misc/ACKS
    --- a/Misc/ACKS
    +++ b/Misc/ACKS
    @@ -502,6 +502,7 @@
     Peter van Kampen
     Rafe Kaplan
     Jacob Kaplan-Moss
    +Per ?yvind Karlsen
     Lou Kates
     Hiroaki Kawai
     Sebastien Keim
    diff --git a/Misc/NEWS b/Misc/NEWS
    --- a/Misc/NEWS
    +++ b/Misc/NEWS
    @@ -400,6 +400,7 @@
     -------
 
     - Issue #6715: Add a module 'lzma' for compression using the LZMA algorithm.
    +  Thanks to Per ?yvind Karlsen for the initial implementation.
 
     - Issue #13487: Make inspect.getmodule robust against changes done to
       sys.modules while it is iterating over it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6715>
_______________________________________

From report at bugs.python.org  Wed Nov 30 16:12:08 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 30 Nov 2011 15:12:08 +0000
Subject: [issue5411] add xz compression support to shutil
In-Reply-To: <1236081386.1.0.884971889723.issue5411@psf.upfronthosting.co.za>
Message-ID: <1322665928.73.0.964116177309.issue5411@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

distutils2/packaging now just uses the shutil functions.  I?ll make a patch for shutil after tarfile is updated.

----------
assignee: tarek -> eric.araujo
components: +Library (Lib) -Distutils2
title: add xz compression support to distutils -> add xz compression support to shutil
versions: +Python 3.3 -3rd party

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5411>
_______________________________________

From report at bugs.python.org  Wed Nov 30 16:12:25 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 30 Nov 2011 15:12:25 +0000
Subject: [issue5689] Support xz compression in tarfile module
In-Reply-To: <1238861315.81.0.348941469726.issue5689@psf.upfronthosting.co.za>
Message-ID: <1322665945.34.0.938927011649.issue5689@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Python now has an lzma module.  Lars, do you have the time to update your patch or should I do it?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5689>
_______________________________________

From report at bugs.python.org  Wed Nov 30 16:18:53 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Wed, 30 Nov 2011 15:18:53 +0000
Subject: [issue6715] xz compressor support
In-Reply-To: <1250502444.31.0.107447392137.issue6715@psf.upfronthosting.co.za>
Message-ID: <1322666333.65.0.423322976194.issue6715@psf.upfronthosting.co.za>


Nadeem Vawda <nadeem.vawda at gmail.com> added the comment:

> Instead of duplicating the list of archiving/compression modules in
> each doc, what about only linking to the shutil doc for archives and
> the archiving.rst file?

Sure, go ahead. I actually hadn't realized that each section of the
library docs had a "sub-index" page like that until now...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6715>
_______________________________________

From report at bugs.python.org  Wed Nov 30 16:19:07 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Wed, 30 Nov 2011 15:19:07 +0000
Subject: [issue5411] add xz compression support to shutil
In-Reply-To: <1236081386.1.0.884971889723.issue5411@psf.upfronthosting.co.za>
Message-ID: <1322666347.57.0.558384135881.issue5411@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/issue5411>
_______________________________________

From report at bugs.python.org  Wed Nov 30 16:25:09 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 30 Nov 2011 15:25:09 +0000
Subject: [issue12832] The documentation for the print function should
	explain/point to how to control the sys.stdout encoding
In-Reply-To: <1314191894.1.0.666645625262.issue12832@psf.upfronthosting.co.za>
Message-ID: <1322666709.15.0.533641376377.issue12832@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Thanks.  Here?s another take: I think the wording is better, but it?s longer.  I removed the reference to sys.stdin, which you don?t print to: I haven?t checked if the doc for the input function should talk about the encoding too.

----------
assignee: docs at python -> eric.araujo
Added file: http://bugs.python.org/file23818/print-encoding.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12832>
_______________________________________

From report at bugs.python.org  Wed Nov 30 16:25:41 2011
From: report at bugs.python.org (=?utf-8?b?U8OpYmFzdGllbiBTYWJsw6k=?=)
Date: Wed, 30 Nov 2011 15:25:41 +0000
Subject: [issue13210] Support Visual Studio 2010
In-Reply-To: <1318942521.44.0.961979099616.issue13210@psf.upfronthosting.co.za>
Message-ID: <1322666741.16.0.303860454753.issue13210@psf.upfronthosting.co.za>


S?bastien Sabl? <sable at users.sourceforge.net> added the comment:

I have started working on python default branch.
My patch queue is available here:
https://bitbucket.org/sablefr/py3kvs2010/

The result is the following so far:
323 tests OK.
8 tests failed:
    test_distutils test_fileio test_gettext test_io test_os
    test_packaging test_pep3151 test_support
4 tests altered the execution environment:
    test_multiprocessing test_site test_subprocess test_sysconfig
27 tests skipped:
    test_crypt test_curses test_dbm_gnu test_dbm_ndbm test_devpoll
    test_epoll test_fcntl test_fork1 test_gdb test_grp test_ioctl
    test_kqueue test_nis test_openpty test_ossaudiodev test_pipes
    test_poll test_posix test_pty test_pwd test_readline test_resource
    test_syslog test_threadsignals test_wait3 test_wait4
    test_zipfile64
2 skips unexpected on win32:
    test_gdb test_readline

Most errors seem related to errno.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13210>
_______________________________________

From report at bugs.python.org  Wed Nov 30 16:27:04 2011
From: report at bugs.python.org (Brian Curtin)
Date: Wed, 30 Nov 2011 15:27:04 +0000
Subject: [issue13210] Support Visual Studio 2010
In-Reply-To: <1318942521.44.0.961979099616.issue13210@psf.upfronthosting.co.za>
Message-ID: <1322666824.41.0.987038806794.issue13210@psf.upfronthosting.co.za>


Brian Curtin <brian at python.org> added the comment:

Again, rather than work off of the default branch and duplicate effort, can you work off of the vs2010 branch on http://hg.python.org/sandbox/vs2010port/?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13210>
_______________________________________

From report at bugs.python.org  Wed Nov 30 16:44:02 2011
From: report at bugs.python.org (Darren Dale)
Date: Wed, 30 Nov 2011 15:44:02 +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: <1322667842.62.0.490605424332.issue11610@psf.upfronthosting.co.za>


Darren Dale <dsdale24 at gmail.com> added the comment:

Here is a new patch addressing comments raised in review. It supersedes previous patch submissions.

----------
Added file: http://bugs.python.org/file23819/abc_descriptor.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11610>
_______________________________________

From report at bugs.python.org  Wed Nov 30 16:49:09 2011
From: report at bugs.python.org (Ben Wolfson)
Date: Wed, 30 Nov 2011 15:49:09 +0000
Subject: [issue12014] str.format parses replacement field incorrectly
In-Reply-To: <1304646359.82.0.599761597998.issue12014@psf.upfronthosting.co.za>
Message-ID: <1322668149.56.0.0391499458123.issue12014@psf.upfronthosting.co.za>


Ben Wolfson <wolfson at gmail.com> added the comment:

"All three patches look different to me."

Yeah, I verified that later; I'm not sure what made me think otherwise except that I eyeballed them sloppily. (It's still true that they'd need to target a different file for 3.3 now.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12014>
_______________________________________

From report at bugs.python.org  Wed Nov 30 16:57:24 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 30 Nov 2011 15:57:24 +0000
Subject: [issue6715] xz compressor support
In-Reply-To: <1250502444.31.0.107447392137.issue6715@psf.upfronthosting.co.za>
Message-ID: <1322668644.06.0.0190381772157.issue6715@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

--- a/Misc/NEWS
    +++ b/Misc/NEWS
    @@ -400,6 +400,7 @@
     -------
 
     - Issue #6715: Add a module 'lzma' for compression using the LZMA algorithm.
    +  Thanks to Per ?yvind Karlsen for the initial implementation.

The entry in Misc/ACKS, Doc/whatsnew/3.3.rst and the commit message should be enough.  Lately I?ve noticed some attributions in NEWS, but it?s usually not done (as redundant).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6715>
_______________________________________

From report at bugs.python.org  Wed Nov 30 17:05:24 2011
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 30 Nov 2011 16:05: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: <1322669124.22.0.17489025754.issue7652@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

Binary versus decimal
---------------------

> There is already gmpy and bigfloat, based on the heavily optimized GMP library,
> for example. Is it a license issue? Can't we reuse GMP/MPFR to offer a Decimal API?

_decimal is a PEP-399 compliant C implementation of decimal.py. The underlying
standard is Cowlishaw/IBM's "General Decimal Arithmetic Specification".

decimal.py is used for standard-conforming financial calculations. There is
no way to implement this in a reasonable manner using a binary floating
point library.

Additionally, _decimal is also heavily optimized. In fact, for small
precisions the module has the same speed as gmpy!


Soundness and code size
-----------------------

> _decimal should maybe first be distributed as a third party library until
> it is really well tested and its API is really stable, until we can decide
> to integrate it.

Except for a different directory structure, the cdecimal module is
identical to this patch. cdecimal has been distributed for almost
two years now and has been on pypi for a year.

There have been many downloads from financial institutions, stock
exchanges and also research institutes. I know for a fact from
a private email correspondence that libmpdec is used in a billing
application of a large national NIC.

cdecimal *appears* to be huge because it has a test suite that
actually provides 100% code coverage. Indeed this means that even
every possible malloc failure is simulated together with an assertion
that the result of the function is (NaN, Malloc_error).

The test suite now tests against both decimal.py and decNumber.
It has found several small issues in decimal.py, a bug in
netlib's dtoa.c, a bug in gmp and a bug in CompCert.

The latest tests against decNumber have found 18 issues in decNumber
(that I haven't reported yet).

In the past 8 months, regression tests for cdecimal-2.3 have been
running trillions of test cases both with and without Valgrind.


Review
------
The patch could be audited by focusing on basearith.c, cdecimal.c
and mpdecimal.c. cdecimal.c is a long but simple wrapper around
libmpdec. mpdecimal.c contains all functions of the specification.
I contend that for a C programmer mpdecimal.c is not significantly
harder to read than decimal.py.

The tricky algorithms (newtondiv, invroot, sqrt-via-invroot
and ln) have mechanical proofs in ACL2.


An initial audit could certainly disregard convolute.c, crt.c,
difradix2.c, fnt.c, numbertheory.c, transpose.c and umodarith.h.

These are only needed for the number theoretic transform that kicks
in at around 22000 digits.


Context type safety
-------------------

> The patch adds __setattr__ to the Decimal class.

Making the context more strictly typed has instantly found a bug
in one of decimal.py's docstring tests:

# This doctest has always passed:
>>> c = Context(ExtendedContext)

# But the operation is meaningless:
>>> c
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python2.7/decimal.py", line 3708, in __repr__
    % vars(self))
TypeError: %d format: a number is required, not Context
>>>


What is the concern about __setattr__? For *setting* contexts, speed
is not so important (for reading contexts it is).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7652>
_______________________________________

From report at bugs.python.org  Wed Nov 30 17:08:44 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 30 Nov 2011 16:08:44 +0000
Subject: [issue6715] xz compressor support
In-Reply-To: <1250502444.31.0.107447392137.issue6715@psf.upfronthosting.co.za>
Message-ID: <1322669324.64.0.161660540612.issue6715@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

what about a mention in lzmamodule.c?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6715>
_______________________________________

From report at bugs.python.org  Wed Nov 30 17:11:36 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 30 Nov 2011 16:11:36 +0000
Subject: [issue6715] xz compressor support
In-Reply-To: <1250502444.31.0.107447392137.issue6715@psf.upfronthosting.co.za>
Message-ID: <1322669496.14.0.283906941588.issue6715@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> I actually hadn't realized that each section of the library docs had a "sub-index" page like that
That?s multiple-entry navigation :)  You can jump to a module page, or use the index, or use the search, or browse and see the sub-indexes.

As the docs for zlib, gzip, bz2, lzma, zipfile and tarfile are in the archiving subsection, there?s already a link to the subsection index, so I just removed the ?See also zlib, etc.? lines (except for the link from zlib to gzip).  I added a link from archiving.rst to shutil and more links and reST targets in shutil.

----------
Added file: http://bugs.python.org/file23820/archiving-modules-links.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6715>
_______________________________________

From report at bugs.python.org  Wed Nov 30 17:40:10 2011
From: report at bugs.python.org (Jason Roberts)
Date: Wed, 30 Nov 2011 16:40:10 +0000
Subject: [issue13509] On uninstallation,
	distutils bdist_wininst fails to run post install script
Message-ID: <1322671210.14.0.984491104845.issue13509@psf.upfronthosting.co.za>


New submission from Jason Roberts <jason.roberts at duke.edu>:

Historically (i.e. Python 2.6.1 and earlier) bdist_wininst would run the post install script at both installation and uninstallation. The script would be invoked with a -install argument on installation and a -remove argument on uninstallation. This stopped working in Python 2.6.2 and has not worked since.

This regression appears to have been introduced in r69094. That checkin rewrote Run_RemoveScript and associated functions in PC/bdist_wininst/install.c. The rewrite changed how the Python DLL was loaded during the remove scenario.

Previously Run_RemoveScript itself called Win32 LoadLibrary on the DLL name parsed from the wininst log file. Now Run_RemoveScript calls run_installscript instead, which ultimately calls LoadPythonDll, which calls LoadLibrary on the pythondll global variable. But nothing initializes that variable during the remove scenario and LoadLibrary fails. Ultimately run_installscript silently fails and the removal proceeds to uninstall files and registry keys, with no notification to the user that the post install script was not run.

A possible solution is to initialize pythondll in Run_RemoveScript to the DLL name parsed from the wininst log file, e.g. by inserting the following code prior to the call to run_installscript:

        strncpy(pythondll, dllname, scriptname - 1 - dllname);
        pythondll[scriptname - 1 - dllname] = '\0';

I tested this and it seemed to work fine.

I believe this problem affects all Python releases following and including 2.6.2. The version history seems to show that r69094 was propagated to all of those releases. Presumably nobody found it because post install scripts on removal are not widely used. They are, however, critical for my application (at least if I want it to clean up properly on removal) so I would appreciate this being fixed. As it stands, I have to build a private patched copy of wininst-9.0.exe to work around this problem.

----------
assignee: tarek
components: Distutils
messages: 148672
nosy: eric.araujo, jasonjroberts, mhammond, tarek
priority: normal
severity: normal
status: open
title: On uninstallation, distutils bdist_wininst fails to run post install script
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13509>
_______________________________________

From report at bugs.python.org  Wed Nov 30 17:42:52 2011
From: report at bugs.python.org (Brian Curtin)
Date: Wed, 30 Nov 2011 16:42:52 +0000
Subject: [issue13509] On uninstallation,
	distutils bdist_wininst fails to run post install script
In-Reply-To: <1322671210.14.0.984491104845.issue13509@psf.upfronthosting.co.za>
Message-ID: <1322671372.09.0.509792359021.issue13509@psf.upfronthosting.co.za>


Changes by Brian Curtin <brian at python.org>:


----------
components: +Windows
nosy: +brian.curtin
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13509>
_______________________________________

From report at bugs.python.org  Wed Nov 30 17:48:01 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 30 Nov 2011 16:48:01 +0000
Subject: [issue13276] distutils bdist_wininst created installer does not run
	the postinstallation script on uninstalling
In-Reply-To: <1319729455.78.0.312367178712.issue13276@psf.upfronthosting.co.za>
Message-ID: <1322671681.82.0.681912032676.issue13276@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +brian.curtin, jasonjroberts
stage:  -> test needed
versions: +Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13276>
_______________________________________

From report at bugs.python.org  Wed Nov 30 17:48:08 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 30 Nov 2011 16:48:08 +0000
Subject: [issue13509] On uninstallation,
	distutils bdist_wininst fails to run post install script
In-Reply-To: <1322671210.14.0.984491104845.issue13509@psf.upfronthosting.co.za>
Message-ID: <1322671688.89.9.22232528222e-05.issue13509@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Thanks for the diagnosis.  Please contribute to the existing bug report.

----------
resolution:  -> duplicate
stage: needs patch -> committed/rejected
status: open -> closed
superseder:  -> distutils bdist_wininst created installer does not run the postinstallation script on uninstalling

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13509>
_______________________________________

From report at bugs.python.org  Wed Nov 30 17:54:07 2011
From: report at bugs.python.org (Jason Roberts)
Date: Wed, 30 Nov 2011 16:54:07 +0000
Subject: [issue13276] distutils bdist_wininst created installer does not run
	the postinstallation script on uninstalling
In-Reply-To: <1319729455.78.0.312367178712.issue13276@psf.upfronthosting.co.za>
Message-ID: <1322672047.77.0.617287815745.issue13276@psf.upfronthosting.co.za>


Jason Roberts <jason.roberts at duke.edu> added the comment:

Sorry, I opened issue13509 after somehow not finding this one. Here is my text from issue13509. Thanks for looking at this problem...

Historically (i.e. Python 2.6.1 and earlier) bdist_wininst would run the post install script at both installation and uninstallation. The script would be invoked with a -install argument on installation and a -remove argument on uninstallation. This stopped working in Python 2.6.2 and has not worked since.

This regression appears to have been introduced in r69094. That checkin rewrote Run_RemoveScript and associated functions in PC/bdist_wininst/install.c. The rewrite changed how the Python DLL was loaded during the remove scenario.

Previously Run_RemoveScript itself called Win32 LoadLibrary on the DLL name parsed from the wininst log file. Now Run_RemoveScript calls run_installscript instead, which ultimately calls LoadPythonDll, which calls LoadLibrary on the pythondll global variable. But nothing initializes that variable during the remove scenario and LoadLibrary fails. Ultimately run_installscript silently fails and the removal proceeds to uninstall files and registry keys, with no notification to the user that the post install script was not run.

A possible solution is to initialize pythondll in Run_RemoveScript to the DLL name parsed from the wininst log file, e.g. by inserting the following code prior to the call to run_installscript:

        strncpy(pythondll, dllname, scriptname - 1 - dllname);
        pythondll[scriptname - 1 - dllname] = '\0';

I tested this and it seemed to work fine.

I believe this problem affects all Python releases following and including 2.6.2. The version history seems to show that r69094 was propagated to all of those releases. Presumably nobody found it because post install scripts on removal are not widely used. They are, however, critical for my application (at least if I want it to clean up properly on removal) so I would appreciate this being fixed. As it stands, I have to build a private patched copy of wininst-9.0.exe to work around this problem.

----------
versions: +Python 2.6, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13276>
_______________________________________

From report at bugs.python.org  Wed Nov 30 18:04:30 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 30 Nov 2011 17:04:30 +0000
Subject: [issue6715] xz compressor support
In-Reply-To: <1322668644.06.0.0190381772157.issue6715@psf.upfronthosting.co.za>
Message-ID: <1322672363.3512.0.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> The entry in Misc/ACKS, Doc/whatsnew/3.3.rst and the commit message
> should be enough.  Lately I?ve noticed some attributions in NEWS, but
> it?s usually not done (as redundant).

I generally add attributions in NEWS since that's where most people
learn about changes (for changes which aren't in whatsnew).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6715>
_______________________________________

From report at bugs.python.org  Wed Nov 30 18:17:18 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 30 Nov 2011 17:17:18 +0000
Subject: [issue13276] bdist_wininst-created installer does not run the
	postinstallation script when uninstalling
In-Reply-To: <1319729455.78.0.312367178712.issue13276@psf.upfronthosting.co.za>
Message-ID: <1322673438.41.0.720360894649.issue13276@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

(2.6 and 3.1 don?t get bug fixes anymore.)

----------
title: distutils bdist_wininst created installer does not run the postinstallation script on uninstalling -> bdist_wininst-created installer does not run the postinstallation script when uninstalling
versions:  -Python 2.6, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13276>
_______________________________________

From report at bugs.python.org  Wed Nov 30 18:17:45 2011
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 30 Nov 2011 17:17:45 +0000
Subject: [issue7652] Merge C version of decimal into py3k.
In-Reply-To: <1322658209.73.0.41865435677.issue7652@psf.upfronthosting.co.za>
Message-ID: <20111130171736.GA25619@sleipnir.bytereef.org>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

Mark Dickinson <report at bugs.python.org> wrote:
> The only problem from my perspective is getting someone to find time to review such a massive patch.  I've been wondering whether we could get away with some kind of 'statistical' review:  do a large-scale review, and then instead of having someone go through every line of C code, pick a few representative sections at random and review those.  If those code portions make it through the review unscathed, declare the code good and merge it in.

The regex module is in a somewhat similar situation. If I'm interpreting this

http://mail.python.org/pipermail/python-dev/2011-August/113240.html

dialogue correctly, a complete audit down to the last line isn't
always necessary.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7652>
_______________________________________

From report at bugs.python.org  Wed Nov 30 18:27:11 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 30 Nov 2011 17:27:11 +0000
Subject: [issue7652] Merge C version of decimal into py3k.
In-Reply-To: <1262860972.65.0.690079130991.issue7652@psf.upfronthosting.co.za>
Message-ID: <1322674031.72.0.378301025813.issue7652@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> If I'm interpreting this
> http://mail.python.org/pipermail/python-dev/2011-August/113240.html
> dialogue correctly, a complete audit down to the last line isn't
> always necessary.

It is also helped by the fact you are a core developer and we trust you to be here to do maintenance :)
I'd add that decimal is a fairly specialized module and the implications of a new engine are not as wide-reaching as a new regex engine. Especially if the pure Python version is still there.

I think it's still probably a good idea to probe python-dev, if that hasn't already happened.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7652>
_______________________________________

From report at bugs.python.org  Wed Nov 30 18:42:30 2011
From: report at bugs.python.org (Peter Otten)
Date: Wed, 30 Nov 2011 17:42:30 +0000
Subject: [issue13510] Clarify that readlines() is not needed to iterate over a
	file
Message-ID: <1322674949.97.0.856520026774.issue13510@psf.upfronthosting.co.za>


New submission from Peter Otten <__peter__ at web.de>:

I've been looking at code on the tutor mailing list for some time, and

for line in file.readlines(): ...

is a common idiom there. I suppose this is because the readlines() method is easily discoverable while the proper way (iterate over the file object directly) is not.

A note added to the readlines() documentation might help:

"""
You don't need the readlines() method to loop over the lines of a file.
for line in file: process(line)
consumes less memory and is often faster.
"""

----------
assignee: docs at python
components: Documentation
messages: 148679
nosy: docs at python, potten
priority: normal
severity: normal
status: open
title: Clarify that readlines() is not needed to iterate over a file
type: feature request

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13510>
_______________________________________

From report at bugs.python.org  Wed Nov 30 19:09:19 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 30 Nov 2011 18:09:19 +0000
Subject: [issue13510] Clarify that readlines() is not needed to iterate over a
	file
In-Reply-To: <1322674949.97.0.856520026774.issue13510@psf.upfronthosting.co.za>
Message-ID: <1322676559.36.0.63787854267.issue13510@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +eric.araujo, ezio.melotti
stage:  -> needs patch
versions: +Python 2.7, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13510>
_______________________________________

From report at bugs.python.org  Wed Nov 30 20:10:02 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 30 Nov 2011 19:10:02 +0000
Subject: [issue7652] Merge C version of decimal into py3k.
In-Reply-To: <1262860972.65.0.690079130991.issue7652@psf.upfronthosting.co.za>
Message-ID: <1322680202.37.0.682034140644.issue7652@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

We've been wanting this for a long time.

Strong +1 from me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7652>
_______________________________________

From report at bugs.python.org  Wed Nov 30 21:07:41 2011
From: report at bugs.python.org (Ray)
Date: Wed, 30 Nov 2011 20:07:41 +0000
Subject: [issue13511] ./configure --includedir, --libdir accept multiple
Message-ID: <1322683661.17.0.138081414237.issue13511@psf.upfronthosting.co.za>


New submission from Ray <rpqpro at hotmail.com>:

For ./configure, --includedir and --libdir both cannot handle multiple packages. 

e.g. 

/configure --includedir=/home/user/.local/sqlite3-3.7.9/include --includedir=/home/user/.local/readline-6.2/include --libdir=/home/user/.local/sqlite3-3.7.9/lib --libdir=/home/user/.local/readline-6.2/lib

and 

/configure --includedir="/home/user/.local/sqlite3-3.7.9/include /home/user/.local/readline-6.2/include" --libdir="/home/user/.local/sqlite3-3.7.9/lib /home/user/.local/readline-6.2/lib"

The only way I could get the desired functionality was to set CFLAGS and LDFLAGS:

export CFLAGS="-I/home/user/.local/readline-6.2/include/ -I/home/user/.local/sqlite3-3.7.9/include/" && export LDFLAGS="-L/home/user/.local/readline-6.2/lib/ -L/home/user/.local/sqlite3-3.7.9/lib/"

----------
assignee: ronaldoussoren
components: Build, Installation, Macintosh
messages: 148681
nosy: ronaldoussoren, rpq
priority: normal
severity: normal
status: open
title: ./configure --includedir, --libdir accept multiple
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13511>
_______________________________________

From report at bugs.python.org  Wed Nov 30 21:18:17 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 30 Nov 2011 20:18: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: <1322684297.37.0.536529451298.issue7652@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

I can help with the review. Is http://bugs.python.org/review/7652/show a good starting point?  I already have some comments.

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7652>
_______________________________________

From report at bugs.python.org  Wed Nov 30 21:24:09 2011
From: report at bugs.python.org (Ray)
Date: Wed, 30 Nov 2011 20:24:09 +0000
Subject: [issue13511] ./configure --includedir, --libdir accept multiple
In-Reply-To: <1322683661.17.0.138081414237.issue13511@psf.upfronthosting.co.za>
Message-ID: <1322684649.62.0.6019552243.issue13511@psf.upfronthosting.co.za>


Ray <rpqpro at hotmail.com> added the comment:

I should mention, I had to modify setup.py in order for the export line in my original post to work on my linux machine.

----------
keywords: +patch
Added file: http://bugs.python.org/file23821/setup.py.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13511>
_______________________________________

From report at bugs.python.org  Wed Nov 30 21:25:11 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 30 Nov 2011 20:25:11 +0000
Subject: [issue1040439] Missing documentation on how to link with libpython
Message-ID: <E1RVqiM-0006Dx-EG@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 2c05b8a6cdd1 by Antoine Pitrou in branch '3.2':
Issue #1040439: better document how to compile and link an embedded Python interpreter.
http://hg.python.org/cpython/rev/2c05b8a6cdd1

New changeset 528abe272856 by Antoine Pitrou in branch 'default':
Issue #1040439: better document how to compile and link an embedded Python interpreter.
http://hg.python.org/cpython/rev/528abe272856

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1040439>
_______________________________________

From report at bugs.python.org  Wed Nov 30 21:38:59 2011
From: report at bugs.python.org (Ray)
Date: Wed, 30 Nov 2011 20:38:59 +0000
Subject: [issue1040439] Missing documentation on how to link with libpython
Message-ID: <1322685539.27.0.844666346033.issue1040439@psf.upfronthosting.co.za>


Ray <rpqpro at hotmail.com> added the comment:

I think mentioning that you can export CFLAGS and LDFLAGS would be particularly useful.  I was able to compile some of the missing packages that were deemed 'missing' at the end of 'make' by updating setup.py and having CFLAGS and LDFLAGS point to the desired packages' directories...  Unfortunately for linux, the ability to specify *multiple* lib/ and include/ paths using this method is currently not available unless you modify setup.py.  I opened a ticket in relation to this: Issue13511 if anyone cares.

----------
nosy: +rpq

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1040439>
_______________________________________

From report at bugs.python.org  Wed Nov 30 21:48:01 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 30 Nov 2011 20:48:01 +0000
Subject: [issue1040439] Missing documentation on how to link with libpython
In-Reply-To: <1322685539.27.0.844666346033.issue1040439@psf.upfronthosting.co.za>
Message-ID: <1322685774.3512.4.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> I think mentioning that you can export CFLAGS and LDFLAGS would be
> particularly useful.  I was able to compile some of the missing
> packages that were deemed 'missing' at the end of 'make' by updating
> setup.py and having CFLAGS and LDFLAGS point to the desired packages'
> directories...

Unless I'm missing something, this is slightly off-topic for this issue,
which is about using Python as an embedded interpreter, not compiling
it. Embedding Python assumes it has already been built.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1040439>
_______________________________________

From report at bugs.python.org  Wed Nov 30 22:10:28 2011
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 30 Nov 2011 21:10:28 +0000
Subject: [issue7652] Merge C version of decimal into py3k.
In-Reply-To: <1322674031.72.0.378301025813.issue7652@psf.upfronthosting.co.za>
Message-ID: <20111130211026.GA26523@sleipnir.bytereef.org>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

Antoine Pitrou <report at bugs.python.org> wrote:
> It is also helped by the fact you are a core developer and we trust you to
> be here to do maintenance :)

Sure. The specification doesn't really change, so the work will hopefully
be limited. :)

> I think it's still probably a good idea to probe python-dev, if that
> hasn't already happened.

Yes, I'm planning to do that.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7652>
_______________________________________

From report at bugs.python.org  Wed Nov 30 22:12:37 2011
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 30 Nov 2011 21:12:37 +0000
Subject: [issue7652] Merge C version of decimal into py3k.
In-Reply-To: <1322680202.37.0.682034140644.issue7652@psf.upfronthosting.co.za>
Message-ID: <20111130211236.GB26523@sleipnir.bytereef.org>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

Raymond Hettinger <report at bugs.python.org> wrote:
> We've been wanting this for a long time.
> 
> Strong +1 from me.

Thank you, Raymond!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7652>
_______________________________________

From report at bugs.python.org  Wed Nov 30 22:13:43 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 30 Nov 2011 21:13:43 +0000
Subject: [issue7652] Merge C version of decimal into py3k.
In-Reply-To: <1262860972.65.0.690079130991.issue7652@psf.upfronthosting.co.za>
Message-ID: <1322687623.99.0.114212452981.issue7652@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> (Actually, that's a part of why decimal.py is slow---it's
> using Python's *binary* integers to store *decimal* coefficients,
> so that even simple addition is now a quadratic operation,
> thanks to the binary <-> decimal conversions involved.)

Oh, I forgot this minor detail (base 2 vs base 10).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7652>
_______________________________________

From report at bugs.python.org  Wed Nov 30 22:15:44 2011
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 30 Nov 2011 21:15:44 +0000
Subject: [issue7652] Merge C version of decimal into py3k.
In-Reply-To: <1322684297.37.0.536529451298.issue7652@psf.upfronthosting.co.za>
Message-ID: <20111130211543.GC26523@sleipnir.bytereef.org>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

Amaury Forgeot d'Arc <report at bugs.python.org> wrote:
> I can help with the review. Is http://bugs.python.org/review/7652/show a
> good starting point? I already have some comments.

Yes, that would be great. Apart from two or three changes that I still
need to push patch set 4 is the latest version.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7652>
_______________________________________

From report at bugs.python.org  Wed Nov 30 22:26:39 2011
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 30 Nov 2011 21:26: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: <1322688399.11.0.463953859843.issue7652@psf.upfronthosting.co.za>


Changes by Stefan Krah <stefan-usenet at bytereef.org>:


Added file: http://bugs.python.org/file23822/bba956250186.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7652>
_______________________________________

From report at bugs.python.org  Wed Nov 30 22:28:33 2011
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 30 Nov 2011 21:28:33 +0000
Subject: [issue7652] Merge C version of decimal into py3k.
In-Reply-To: <20111130211543.GC26523@sleipnir.bytereef.org>
Message-ID: <20111130212832.GA26668@sleipnir.bytereef.org>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

Stefan Krah <report at bugs.python.org> wrote:
> Yes, that would be great. Apart from two or three changes that I still
> need to push patch set 4 is the latest version.

Hmm, no. I'll create a slightly newer patch from Oct. 1st.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7652>
_______________________________________

From report at bugs.python.org  Wed Nov 30 23:18:42 2011
From: report at bugs.python.org (Nebelhom)
Date: Wed, 30 Nov 2011 22:18:42 +0000
Subject: [issue13504] Meta-issue for "Invent with Python" IDLE feedback
In-Reply-To: <1322613083.36.0.200533745275.issue13504@psf.upfronthosting.co.za>
Message-ID: <1322691522.36.0.691845818802.issue13504@psf.upfronthosting.co.za>


Changes by Nebelhom <nebelhom at googlemail.com>:


----------
nosy: +Nebelhom

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13504>
_______________________________________

From report at bugs.python.org  Wed Nov 30 23:48:26 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 30 Nov 2011 22:48:26 +0000
Subject: [issue13505] Bytes objects pickled in 3.x with protocol <=2 are
	unpickled incorrectly in 2.x
In-Reply-To: <1322619707.99.0.479265394652.issue13505@psf.upfronthosting.co.za>
Message-ID: <1322693306.83.0.574617247119.issue13505@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

After a bit of testing, my idea was flawed, as str() doesn't accept an encoding parameter in 2.x: `str(u'foo', 'latin1')` simply raises a TypeError.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13505>
_______________________________________

From report at bugs.python.org  Wed Nov 30 23:54:26 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 30 Nov 2011 22:54:26 +0000
Subject: [issue13510] Clarify that readlines() is not needed to iterate over a
	file
In-Reply-To: <1322674949.97.0.856520026774.issue13510@psf.upfronthosting.co.za>
Message-ID: <1322693666.58.0.787455210926.issue13510@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

This current line is
"Read and return a list of lines from the stream. hint can be specified to control the number of lines read: no more lines will be read if the total size (in bytes/characters) of all lines so far exceeds hint."

I would like to see added
"Since a file is a line iterator, file.readlines() == list(file). To save time and space, iterate over lines of a file with for line in file: process(line)."
(with code markup for the two snippets).

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13510>
_______________________________________