From report at bugs.python.org  Sat Jan  1 00:15:27 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 31 Dec 2010 23:15:27 +0000
Subject: [issue10786] unittest.TextTextRunner does not respect redirected
	stderr
In-Reply-To: <1293519479.07.0.371916485658.issue10786@psf.upfronthosting.co.za>
Message-ID: <1293837327.19.0.392334811384.issue10786@psf.upfronthosting.co.za>


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

Since the current behavior matches the current doc,

"class unittest.TextTestRunner(stream=sys.stderr, descriptions=True, verbosity=1, runnerclass=None, warnings=None) 
A basic test runner implementation which prints results on standard error. ..."

this is a feature change request, not a bug report. Hence, the change should not be backported, lest it surprise someone. One could even question whether the change should be introduced now, but is does seem rather minor.

That aside, the doc needs to be changed and a version-changed note added. Something like

"class unittest.TextTestRunner(stream=None, descriptions=True, verbosity=1, runnerclass=None, warnings=None) 
A basic test runner implementation. If *stream* is the default None, results go to standard error. ...
Version changed 3.2: default stream determined when class is instantiated rather than when imported."

----------
nosy: +terry.reedy
type: behavior -> feature request
versions:  -Python 2.7, Python 3.1

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

From report at bugs.python.org  Sat Jan  1 00:34:40 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 31 Dec 2010 23:34:40 +0000
Subject: [issue10787] [random.gammavariate] Add the expression of the
	distribution in a comprehensive form for random.gammavariate
In-Reply-To: <1293554918.75.0.546382725998.issue10787@psf.upfronthosting.co.za>
Message-ID: <1293838480.78.0.794511656666.issue10787@psf.upfronthosting.co.za>


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

>From reading the Wikipedia article, I might conclude that beta = 1/theta, but from reading random.py, beta=theta. I think this much should be clarified, but without giving the formula in a hard to read text form. Perhaps the random doc should give reference to the much more complete numpy.random (and Wikipedia and/or Mathworld) entries rather than merely 'any statistics text' (many of which will not describe all).

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

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

From report at bugs.python.org  Sat Jan  1 01:37:41 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 01 Jan 2011 00:37:41 +0000
Subject: [issue10789] Lock.acquire documentation is misleading
In-Reply-To: <1293644478.45.0.40426107256.issue10789@psf.upfronthosting.co.za>
Message-ID: <1293842261.45.0.624055406573.issue10789@psf.upfronthosting.co.za>


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

Since threading is written in Python, one might expect Lock to be written in Python and its methods to accept keywords. However, threading.py (3.2) has
  _acquire_lock = _thread.acquire_lock
  Lock = _aquire_lock
so threading.Lock objects are C-coded _thread.lock objects and hence *might* not accept keyword args.

In 3.1:
lock.acquire([waitflag]) # same 2.7
Lock.acquire(blocking=True) # [blocking=1] in 2.7
Indeed the first is correct.

>>> from threading import Lock
>>> l=Lock()
>>> l.acquire(blocking=True)
Traceback (most recent call last):
  File "<pyshell#2>", line 1, in <module>
    l.acquire(blocking=True)
TypeError: acquire() takes no keyword arguments
>>> l.acquire(True)
True

r87596, r87596

In 3.2:
lock.acquire(waitflag=1, timeout=-1) 
Lock.acquire(blocking=True, timeout=-1)
The edit in 3.2 is actually correct 

>>> from threading import Lock
>>> l=Lock()
>>> l.acquire(blocking=True)
True
>>> l.acquire(timeout=1)
False

_thread.lock.acquire now accepts keywords.

----------
assignee: docs at python -> terry.reedy
nosy: +terry.reedy
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Sat Jan  1 01:49:36 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 01 Jan 2011 00:49:36 +0000
Subject: [issue10794] Infinite recursion while garbage collecting loops
	indefinitely
In-Reply-To: <1293670287.34.0.585233901325.issue10794@psf.upfronthosting.co.za>
Message-ID: <1293842976.48.0.421722332935.issue10794@psf.upfronthosting.co.za>


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

2.6 is finished except for possible security patches.
This should be verified in a current release, preferably 3.2

----------
nosy: +terry.reedy
stage:  -> needs patch
versions: +Python 2.7 -Python 2.6

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

From report at bugs.python.org  Sat Jan  1 01:59:58 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 01 Jan 2011 00:59:58 +0000
Subject: [issue9370] Add reader redirect from test package docs to unittest
	module
In-Reply-To: <1279968547.11.0.280770421062.issue9370@psf.upfronthosting.co.za>
Message-ID: <1293843598.89.0.0766859295765.issue9370@psf.upfronthosting.co.za>


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

Yeah, I think I wrote this issue based on the diff that added the new note at the top, rather than looking at the existing intro text that already references unittest and doctest.

No need to change anything after all.

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

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

From report at bugs.python.org  Sat Jan  1 03:18:05 2011
From: report at bugs.python.org (Gregory P. Smith)
Date: Sat, 01 Jan 2011 02:18:05 +0000
Subject: [issue10794] Infinite recursion while garbage collecting loops
	indefinitely
In-Reply-To: <1293842976.48.0.421722332935.issue10794@psf.upfronthosting.co.za>
Message-ID: <AANLkTi=L58aQiiO-KgiphkNX2o9T0SZELC-DT38ei=yv@mail.gmail.com>


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

it happens on 3.2 (py3k head).

----------
Added file: http://bugs.python.org/file20208/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10794>
_______________________________________
-------------- next part --------------
it happens on 3.2 (py3k head).<br>

From report at bugs.python.org  Sat Jan  1 03:18:20 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 01 Jan 2011 02:18:20 +0000
Subject: [issue6285] Silent abort on XP help document display
In-Reply-To: <1245022007.21.0.85627036232.issue6285@psf.upfronthosting.co.za>
Message-ID: <1293848300.12.0.586934190316.issue6285@psf.upfronthosting.co.za>


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


Removed file: http://bugs.python.org/file20199/z6285.diff

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

From report at bugs.python.org  Sat Jan  1 03:34:58 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 01 Jan 2011 02:34:58 +0000
Subject: [issue6285] Silent abort on XP help document display
In-Reply-To: <1245022007.21.0.85627036232.issue6285@psf.upfronthosting.co.za>
Message-ID: <1293849298.22.0.505949419049.issue6285@psf.upfronthosting.co.za>


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

I verified the bug by creating a copy of idlelib/help.txt, making the new help entry, testing it, deleting the copy, and retesting -- IDLE silently disappears. (A copy is necessary because IDLE checks that the file exists and gives a similar message as in the patch before posting the new menu item.) I decided that since a file can get renamed, moved, or deleted for various reasons, failure to open it should be caught.

I them tested my patch, found and fixed an typo-error (yes, testing is good even for simple patches!), found and fixed another bug in one of the two functions, and committed.
r87598, r97599, r87600

----------
resolution:  -> fixed
status: open -> closed
Added file: http://bugs.python.org/file20209/z6285.diff

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

From report at bugs.python.org  Sat Jan  1 03:47:50 2011
From: report at bugs.python.org (Matthew Barnett)
Date: Sat, 01 Jan 2011 02:47:50 +0000
Subject: [issue2636] Regexp 2.7 (modifications to current re 2.2.2)
In-Reply-To: <1208260672.14.0.711874677361.issue2636@psf.upfronthosting.co.za>
Message-ID: <1293850070.06.0.515374623847.issue2636@psf.upfronthosting.co.za>


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

Just to check, does this still work with your changes of msg124959?

    regex.search(r'\d{4}(\s*\w)?\W*((?!\d)\w){2}', "9999XX")

For me it fails to match!

----------

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

From report at bugs.python.org  Sat Jan  1 03:56:02 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 01 Jan 2011 02:56:02 +0000
Subject: [issue6285] Silent abort on XP help document display
In-Reply-To: <1245022007.21.0.85627036232.issue6285@psf.upfronthosting.co.za>
Message-ID: <1293850562.58.0.411551344349.issue6285@psf.upfronthosting.co.za>


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

Bug and fix also apply to missing Idlelib/help.txt.
r87601 News entry for 3.2. Thanks Scott.

----------

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

From report at bugs.python.org  Sat Jan  1 05:26:25 2011
From: report at bugs.python.org (Jacques Grove)
Date: Sat, 01 Jan 2011 04:26:25 +0000
Subject: [issue2636] Regexp 2.7 (modifications to current re 2.2.2)
In-Reply-To: <1208260672.14.0.711874677361.issue2636@psf.upfronthosting.co.za>
Message-ID: <1293855985.11.0.926953019033.issue2636@psf.upfronthosting.co.za>


Jacques Grove <aquarapid at gmail.com> added the comment:

You're correct, after the change:

regex.search(r'\d{4}(\s*\w)?\W*((?!\d)\w){2}', "9999XX")

doesn't match (i.e. as before commit 7abd9f9bb1).

I was, however, just trying to narrow down which part of the code change killed the performance on my regression tests :-)

Happy new year to all out there.

----------

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

From report at bugs.python.org  Sat Jan  1 06:12:15 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Sat, 01 Jan 2011 05:12:15 +0000
Subject: [issue10801] zipfile.ZipFile().extractall() header mismatch for
	non-ASCII characters
In-Reply-To: <1293802719.05.0.954235124812.issue10801@psf.upfronthosting.co.za>
Message-ID: <1293858735.98.0.169427732164.issue10801@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

I'll try to produce a test in the next hour or two

----------
nosy: +eli.bendersky

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

From report at bugs.python.org  Sat Jan  1 08:54:17 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Sat, 01 Jan 2011 07:54:17 +0000
Subject: [issue10801] zipfile.ZipFile().extractall() header mismatch for
	non-ASCII characters
In-Reply-To: <1293802719.05.0.954235124812.issue10801@psf.upfronthosting.co.za>
Message-ID: <1293868457.88.0.271569862304.issue10801@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

I'm attaching a patch with a test for Martin's fix. I had trouble programmatically generating a "bad" zip for this bug, since it has different encodings for the header and filename (probably created by WinZip?). So I created a directory in test/ and placed the problematic zipfile M.Z. submitted in there, and wrote an appropriate test in test_zipfile.py

I verified the test fails on py3k trunk before Martin's fix, and succeeds after it, both by running the test file directly and through regrtest.

Note: Tested only on Ubuntu

----------
Added file: http://bugs.python.org/file20210/issue10801_test.1.patch

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

From report at bugs.python.org  Sat Jan  1 08:56:35 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Sat, 01 Jan 2011 07:56:35 +0000
Subject: [issue10801] zipfile.ZipFile().extractall() header mismatch for
	non-ASCII characters
In-Reply-To: <1293802719.05.0.954235124812.issue10801@psf.upfronthosting.co.za>
Message-ID: <1293868595.11.0.379380681324.issue10801@psf.upfronthosting.co.za>


Changes by Eli Bendersky <eliben at gmail.com>:


Removed file: http://bugs.python.org/file20210/issue10801_test.1.patch

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

From report at bugs.python.org  Sat Jan  1 08:56:51 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Sat, 01 Jan 2011 07:56:51 +0000
Subject: [issue10801] zipfile.ZipFile().extractall() header mismatch for
	non-ASCII characters
In-Reply-To: <1293802719.05.0.954235124812.issue10801@psf.upfronthosting.co.za>
Message-ID: <1293868611.33.0.339093967609.issue10801@psf.upfronthosting.co.za>


Changes by Eli Bendersky <eliben at gmail.com>:


Added file: http://bugs.python.org/file20211/issue10801_test.1.patch

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

From report at bugs.python.org  Sat Jan  1 10:53:22 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sat, 01 Jan 2011 09:53:22 +0000
Subject: [issue1674555] sys.path in tests contains system directories
Message-ID: <1293875602.13.0.877472937574.issue1674555@psf.upfronthosting.co.za>


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

I find the solution (running every test in a subprocess) a bit too drastic for the problem. How about a modified approach: run regrtest with -S, and have it create a subprocess for test_site only?

----------

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

From report at bugs.python.org  Sat Jan  1 11:10:03 2011
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 01 Jan 2011 10:10:03 +0000
Subject: [issue10801] zipfile.ZipFile().extractall() header mismatch for
	non-ASCII characters
In-Reply-To: <1293802719.05.0.954235124812.issue10801@psf.upfronthosting.co.za>
Message-ID: <1293876603.72.0.0526888372784.issue10801@psf.upfronthosting.co.za>


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

Committed patch and test in r87604.

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

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

From report at bugs.python.org  Sat Jan  1 11:35:59 2011
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 01 Jan 2011 10:35:59 +0000
Subject: [issue10801] zipfile.ZipFile().extractall() header mismatch for
	non-ASCII characters
In-Reply-To: <1293802719.05.0.954235124812.issue10801@psf.upfronthosting.co.za>
Message-ID: <1293878159.38.0.63682215922.issue10801@psf.upfronthosting.co.za>


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

OK, looks like there is a problem on some buildbots: 

http://www.python.org/dev/buildbot/all/builders/AMD64%20Gentoo%20Wide%203.x/builds/863/steps/test/logs/stdio

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

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

From report at bugs.python.org  Sat Jan  1 12:13:22 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Sat, 01 Jan 2011 11:13:22 +0000
Subject: [issue444582] Finding programs in PATH, adding shutil.which
Message-ID: <1293880402.97.0.467379228282.issue444582@psf.upfronthosting.co.za>


Sandro Tosi <sandro.tosi at gmail.com> added the comment:

Hi Jan, are you still going to work on this feature?

Hi ?ric, what are we going to do: include Jan's patch when ready or Trent's `which` tool on google code?

Cheers,
Sandro

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

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

From report at bugs.python.org  Sat Jan  1 12:33:48 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Sat, 01 Jan 2011 11:33:48 +0000
Subject: [issue8626] TypeError: rsplit() takes no keyword arguments
In-Reply-To: <1273069691.09.0.629182954336.issue8626@psf.upfronthosting.co.za>
Message-ID: <1293881628.22.0.198995502027.issue8626@psf.upfronthosting.co.za>


Sandro Tosi <sandro.tosi at gmail.com> added the comment:

That's interesting: do we have a place where we explain how to read the doc? I mean, a place were we can provide example/explain how we write docs, so f.e.:

  str.rsplit([sep[, maxsplit]])  

is a description for a method that could accept 2 optional arguments, none of them keyargs or

  str.encode(encoding="utf-8", errors="strict")

is a description for a method that could take 2 optional args, and they are also keyargs (yeah, I know it's kinda bad-worded, but just to give the idea).

If you think it's overkill, let's just close this bug (after all, we have all the doc written our way ;)).

Cheers,
Sandro

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

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

From report at bugs.python.org  Sat Jan  1 13:16:58 2011
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 01 Jan 2011 12:16:58 +0000
Subject: [issue10801] zipfile.ZipFile().extractall() header mismatch for
	non-ASCII characters
In-Reply-To: <1293802719.05.0.954235124812.issue10801@psf.upfronthosting.co.za>
Message-ID: <1293884218.47.0.152476374163.issue10801@psf.upfronthosting.co.za>


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

OK, I think r87606 fixed it: it doesn't extract the files, instead calls only open().

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

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

From report at bugs.python.org  Sat Jan  1 13:44:59 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Sat, 01 Jan 2011 12:44:59 +0000
Subject: [issue10801] zipfile.ZipFile().extractall() header mismatch for
	non-ASCII characters
In-Reply-To: <1293802719.05.0.954235124812.issue10801@psf.upfronthosting.co.za>
Message-ID: <1293885899.34.0.733504139683.issue10801@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

Georg, did you figure out the root cause of the problem on that buildbot? Seeing it fails in open(targetpath, "wb"), extracting the file may have failed if the bot had no write permissions to the current directory, but the ascii encoding error is not what I'd expect in such a case.

----------

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

From report at bugs.python.org  Sat Jan  1 13:47:41 2011
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 01 Jan 2011 12:47:41 +0000
Subject: [issue10801] zipfile.ZipFile().extractall() header mismatch for
	non-ASCII characters
In-Reply-To: <1293802719.05.0.954235124812.issue10801@psf.upfronthosting.co.za>
Message-ID: <1293886061.34.0.79052667336.issue10801@psf.upfronthosting.co.za>


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

Well, it looks like the filesystem encoding is set to ASCII on these machines.

----------

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

From report at bugs.python.org  Sat Jan  1 16:37:47 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Sat, 01 Jan 2011 15:37:47 +0000
Subject: [issue10130] Create epub format docs and offer them on the download
	page
In-Reply-To: <1293282928.77.0.893563694653.issue10130@psf.upfronthosting.co.za>
Message-ID: <1293896267.86.0.685473627544.issue10130@psf.upfronthosting.co.za>


Sandro Tosi <sandro.tosi at gmail.com> added the comment:

Hi, I've updated the patch, to also mention the 'epub' target in Dco/README.txt but mainly to fix an HTML error in indexcontent.html that prevents the epub to be correctly generated.

----------
Added file: http://bugs.python.org/file20212/issue10130-v2-py3k.patch

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

From report at bugs.python.org  Sat Jan  1 18:07:35 2011
From: report at bugs.python.org (David Kremer)
Date: Sat, 01 Jan 2011 17:07:35 +0000
Subject: [issue10787] [random.gammavariate] Add the expression of the
	distribution in a comprehensive form for random.gammavariate
In-Reply-To: <1293554918.75.0.546382725998.issue10787@psf.upfronthosting.co.za>
Message-ID: <1293901655.08.0.506373781301.issue10787@psf.upfronthosting.co.za>


David Kremer <david.kremer.dk at gmail.com> added the comment:

Yes I agree. Actually the parameters in the python code alpha, beta are corresponding respectively to k, theta in the first equation of [http://en.wikipedia.org/wiki/Gamma_distribution].

----------

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

From report at bugs.python.org  Sat Jan  1 18:52:22 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 01 Jan 2011 17:52:22 +0000
Subject: [issue8626] TypeError: rsplit() takes no keyword arguments
In-Reply-To: <1273069691.09.0.629182954336.issue8626@psf.upfronthosting.co.za>
Message-ID: <1293904342.23.0.658929935891.issue8626@psf.upfronthosting.co.za>


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

The description for the function directive is at http://docs.python.org/dev/documenting/markup.html  However, I?m not sure whether the doc is accurate, since there was a switch from spam([style]) to spam(style=None) some time ago, for example in r73291.

Let?s continue the discussion on the other bug.

----------
nosy: +eric.araujo
resolution:  -> duplicate
stage:  -> committed/rejected
status: open -> closed
superseder:  -> Document lack of support for keyword arguments in C functions

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

From report at bugs.python.org  Sat Jan  1 19:01:44 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 01 Jan 2011 18:01:44 +0000
Subject: [issue10789] Lock.acquire documentation is misleading
In-Reply-To: <1293644478.45.0.40426107256.issue10789@psf.upfronthosting.co.za>
Message-ID: <1293904904.38.0.978898695015.issue10789@psf.upfronthosting.co.za>


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

I think this commit should be reverted:  Arguments with default values no longer use brackets, see for example r73291.  More info on #8350.

----------
nosy: +eric.araujo, georg.brandl

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

From report at bugs.python.org  Sat Jan  1 19:21:47 2011
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 01 Jan 2011 18:21:47 +0000
Subject: [issue10789] Lock.acquire documentation is misleading
In-Reply-To: <1293644478.45.0.40426107256.issue10789@psf.upfronthosting.co.za>
Message-ID: <1293906107.6.0.891329430459.issue10789@psf.upfronthosting.co.za>


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

No, that's not true.  Arguments that can't be given as kwargs are presented with brackets.

However, the default value now isn't indicated anywhere; it should be added to the main text.

----------

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

From report at bugs.python.org  Sat Jan  1 21:24:40 2011
From: report at bugs.python.org (Meador Inge)
Date: Sat, 01 Jan 2011 20:24:40 +0000
Subject: [issue10044] small int optimization
In-Reply-To: <1286452590.11.0.255060275257.issue10044@psf.upfronthosting.co.za>
Message-ID: <1293913480.05.0.496910014187.issue10044@psf.upfronthosting.co.za>


Meador Inge <meadori at gmail.com> added the comment:

> How is the compiler supposed to know whether a and b belong to the same
> array when compiling ptr_compare?

I agree with Mark, it doesn't need to know.  However, many compilers [1,2] support whole program optimization and could in theory figure the address out using that technique.

[1] GCC -flto - http://gcc.gnu.org/onlinedocs/gcc-4.5.2/gcc/Optimize-Options.html#Optimize-Options
[2] VC++ LTCG - http://msdn.microsoft.com/en-us/library/xbf3tbeh.aspx

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

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

From report at bugs.python.org  Sat Jan  1 22:26:40 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Sat, 01 Jan 2011 21:26:40 +0000
Subject: [issue8013] time.asctime segfaults when given a time in the far future
In-Reply-To: <1267031714.43.0.416052646257.issue8013@psf.upfronthosting.co.za>
Message-ID: <1293917200.24.0.72732918191.issue8013@psf.upfronthosting.co.za>


Sandro Tosi <sandro.tosi at gmail.com> added the comment:

Hi Alexander, can you confirm this bug is MacOs specific? I tried with python2.6 on a Debian sid @64 bit but I can't replicate it. Also, do you see it only on 2.6? if so, I doubt that it will ever be fixed; f.e. on release2.7 branch I have:

Python 2.7.1+ (release27-maint, Dec 31 2010, 20:16:57) 
[GCC 4.4.5] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import time
>>> time.asctime(time.gmtime(1e12))
'Fri Sep 27 01:46:40 33658\n'

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

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

From report at bugs.python.org  Sat Jan  1 22:31:38 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 01 Jan 2011 21:31:38 +0000
Subject: [issue10789] Lock.acquire documentation is misleading
In-Reply-To: <1293644478.45.0.40426107256.issue10789@psf.upfronthosting.co.za>
Message-ID: <1293917498.3.0.576268153405.issue10789@psf.upfronthosting.co.za>


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

OK, I will add defaults in the texts and condense them a bit at the same time. Will post patches for review.

"Arguments that can't be given as kwargs are presented with brackets."
I think this should be stated in the introduction to the Lib manual, along with any other conventions a reader should know. If you agree, one of us can open an issue for this.

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

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

From report at bugs.python.org  Sat Jan  1 22:52:54 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 01 Jan 2011 21:52:54 +0000
Subject: [issue10242] unittest's assertItemsEqual() method makes too many
	assumptions about its input
In-Reply-To: <1288416372.65.0.387803067469.issue10242@psf.upfronthosting.co.za>
Message-ID: <1293918774.98.0.297588902104.issue10242@psf.upfronthosting.co.za>


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

The improved output format in 3.2 still needs to be backported to 2.7.

----------
priority: normal -> low
versions:  -Python 3.2

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

From report at bugs.python.org  Sat Jan  1 23:19:35 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Sat, 01 Jan 2011 22:19:35 +0000
Subject: [issue8278] os.utime doesn't allow a atime (Last Access) which is 27
	years in the future.
In-Reply-To: <1270107966.42.0.283455861085.issue8278@psf.upfronthosting.co.za>
Message-ID: <1293920375.68.0.682495455944.issue8278@psf.upfronthosting.co.za>


Sandro Tosi <sandro.tosi at gmail.com> added the comment:

Hi Amaury, Martin ack'ed the patch: is there something else you want to do?

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

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

From report at bugs.python.org  Sat Jan  1 23:32:05 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Sat, 01 Jan 2011 22:32:05 +0000
Subject: [issue4662] posix module lacks several DeprecationWarning's
In-Reply-To: <1229276083.72.0.194776097767.issue4662@psf.upfronthosting.co.za>
Message-ID: <1293921125.51.0.782333516384.issue4662@psf.upfronthosting.co.za>


Sandro Tosi <sandro.tosi at gmail.com> added the comment:

The patch no longer applies cleanly to 2.7 head (but it should be trivial to update it).

Martin, Benjamin: as this targets 2.7, do you think the patch is acceptable in that branch or it's too late?

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

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

From report at bugs.python.org  Sat Jan  1 23:32:17 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Sat, 01 Jan 2011 22:32:17 +0000
Subject: [issue4662] posix module lacks several DeprecationWarning's
In-Reply-To: <1229276083.72.0.194776097767.issue4662@psf.upfronthosting.co.za>
Message-ID: <1293921137.84.0.501344756659.issue4662@psf.upfronthosting.co.za>


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


----------
versions:  -Python 2.7

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

From report at bugs.python.org  Sat Jan  1 23:32:26 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Sat, 01 Jan 2011 22:32:26 +0000
Subject: [issue4662] posix module lacks several DeprecationWarning's
In-Reply-To: <1229276083.72.0.194776097767.issue4662@psf.upfronthosting.co.za>
Message-ID: <1293921146.46.0.322327237355.issue4662@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Sat Jan  1 23:36:37 2011
From: report at bugs.python.org (Ned Deily)
Date: Sat, 01 Jan 2011 22:36:37 +0000
Subject: [issue8013] time.asctime segfaults when given a time in the far future
In-Reply-To: <1267031714.43.0.416052646257.issue8013@psf.upfronthosting.co.za>
Message-ID: <1293921397.78.0.431492628484.issue8013@psf.upfronthosting.co.za>


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

It's still a problem on OS X at least and is 64-bit related:

$ arch -i386 /usr/local/bin/python3.2 -c 'import time;print(time.asctime(time.gmtime(1e12)))'
Traceback (most recent call last):
  File "<string>", line 1, in <module>
ValueError: timestamp out of range for platform time_t
$ arch -x86_64 /usr/local/bin/python3.2 -c 'import time;print(time.asctime(time.gmtime(1e12)))'
Segmentation fault

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

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

From report at bugs.python.org  Sat Jan  1 23:38:17 2011
From: report at bugs.python.org (Ned Deily)
Date: Sat, 01 Jan 2011 22:38:17 +0000
Subject: [issue8013] time.asctime segfaults when given a time in the far future
In-Reply-To: <1267031714.43.0.416052646257.issue8013@psf.upfronthosting.co.za>
Message-ID: <1293921497.42.0.337762124058.issue8013@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Sat Jan  1 23:47:41 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Sat, 01 Jan 2011 22:47:41 +0000
Subject: [issue8013] time.asctime segfaults when given a time in the far future
In-Reply-To: <1267031714.43.0.416052646257.issue8013@psf.upfronthosting.co.za>
Message-ID: <1293922061.49.0.360678003018.issue8013@psf.upfronthosting.co.za>


Sandro Tosi <sandro.tosi at gmail.com> added the comment:

Hi Ned, thanks for the fast check! I tried to applied the patch (it failed, so it required a bit of manual editing) but when compiling I got:


/home/morph/python-dev/py3k/Modules/timemodule.c: In function ?time_asctime?:
/home/morph/python-dev/py3k/Modules/timemodule.c:626: warning: implicit declaration of function ?PyString_FromStringAndSize?
/home/morph/python-dev/py3k/Modules/timemodule.c:626: warning: return makes pointer from integer without a cast
*** WARNING: renaming "time" since importing it failed: build/lib.linux-x86_64-3.2/time.cpython-32m.so: undefined symbol: PyString_FromStringAndSize

and my knowledge of C ends there :)

Alexander, would you like to revamp your patch? ;)

----------

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

From report at bugs.python.org  Sat Jan  1 23:53:36 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Sat, 01 Jan 2011 22:53:36 +0000
Subject: [issue7716] IPv6 detection,
	don't assume existence of /usr/xpg4/bin/grep
In-Reply-To: <1263666299.94.0.843434843075.issue7716@psf.upfronthosting.co.za>
Message-ID: <1293922416.79.0.771081657081.issue7716@psf.upfronthosting.co.za>


Sandro Tosi <sandro.tosi at gmail.com> added the comment:

Hi, I think the best way to test this patch is to apply the fix and then compile python on a Solaris system (which I don't have): is someone owning a Solaris would run this test?

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

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

From report at bugs.python.org  Sat Jan  1 23:58:59 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sat, 01 Jan 2011 22:58:59 +0000
Subject: [issue4662] posix module lacks several DeprecationWarning's
In-Reply-To: <1229276083.72.0.194776097767.issue4662@psf.upfronthosting.co.za>
Message-ID: <1293922739.78.0.322523869972.issue4662@psf.upfronthosting.co.za>


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

I think the policy is that it is ok to add more 3k warnings to 2.7; these are not considered new features (or explicitly exempted, or some such).

----------

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

From report at bugs.python.org  Sun Jan  2 00:29:25 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 01 Jan 2011 23:29:25 +0000
Subject: [issue4662] posix module lacks several DeprecationWarning's
In-Reply-To: <1229276083.72.0.194776097767.issue4662@psf.upfronthosting.co.za>
Message-ID: <1293924565.92.0.633860899572.issue4662@psf.upfronthosting.co.za>


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

Some of these warnings are incorrect, too; os.popen() and fdopen() remain in Python 3.

----------

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

From report at bugs.python.org  Sun Jan  2 00:59:45 2011
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 01 Jan 2011 23:59:45 +0000
Subject: [issue8350] Document lack of support for keyword arguments in C
	functions
In-Reply-To: <1270764159.26.0.287104770145.issue8350@psf.upfronthosting.co.za>
Message-ID: <1293926385.15.0.881737245563.issue8350@psf.upfronthosting.co.za>


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

Hmm, it may indeed be the best option to add a new directive option to say "this function does not take keyword args".  It would result in some form of unobtrusive but noticeable output in HTML.

It is a bit of an effort to add it everywhere it's necessary, but the most important instances (e.g. string methods) can be covered quickly, and it's fairly easy to grep the other instances (namely, grepping for METH_O and METH_VARARGS without METH_KEYWORDS).

----------

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

From report at bugs.python.org  Sun Jan  2 01:01:13 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 02 Jan 2011 00:01:13 +0000
Subject: [issue8350] Document lack of support for keyword arguments in C
	functions
In-Reply-To: <1293926385.15.0.881737245563.issue8350@psf.upfronthosting.co.za>
Message-ID: <1293926467.3701.0.camel@localhost.localdomain>


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

> Hmm, it may indeed be the best option to add a new directive option to
> say "this function does not take keyword args".  It would result in
> some form of unobtrusive but noticeable output in HTML.

Isn't it kind of a CPython-specific detail, though?

----------

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

From report at bugs.python.org  Sun Jan  2 01:03:44 2011
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 02 Jan 2011 00:03:44 +0000
Subject: [issue8350] Document lack of support for keyword arguments in C
	functions
In-Reply-To: <1270764159.26.0.287104770145.issue8350@psf.upfronthosting.co.za>
Message-ID: <1293926624.39.0.129138863842.issue8350@psf.upfronthosting.co.za>


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

Yes.  It's still an important detail; the explanation could say, "In CPython, this function does not take keyword args" and furthermore it's not really clear to me how much of the library reference applies to all Python implementations anyway.

----------

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

From report at bugs.python.org  Sun Jan  2 01:07:50 2011
From: report at bugs.python.org (kai zhu)
Date: Sun, 02 Jan 2011 00:07:50 +0000
Subject: [issue10802] python3.2 AFTER b2 release has subprocess.Popen broken
	under colinux/windows
In-Reply-To: <1293926870.23.0.886180589728.issue10802@psf.upfronthosting.co.za>
Message-ID: <1293926870.23.0.886180589728.issue10802@psf.upfronthosting.co.za>


New submission from kai zhu <kaizhu256 at gmail.com>:

i have 2 debian i386 unstable distros.
1) python3.2 (latest hg) running under vps @ linode.com seems ok
2) python3.2 (latest hg) running under colinux (in windows xp) breaks

*NOTE
3) python3.2 (release b2) works fine under colinux

public at colinux: python3.2
Python 3.2b2+ (py3k, Jan  1 2011, 17:42:23)
[GCC 4.4.5] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import subprocess
>>> subprocess.Popen('ls')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/public/i486-pc-linux-gnu/lib/python3.2/subprocess.py", line 708, in __init__
    restore_signals, start_new_session)
  File "/home/public/i486-pc-linux-gnu/lib/python3.2/subprocess.py", line 1136, in _execute_child
    errpipe_read, errpipe_write = _create_pipe()
OSError: [Errno 38] Function not implemented
>>>

----------
components: IO, Interpreter Core
messages: 125020
nosy: kaizhu
priority: normal
severity: normal
status: open
title: python3.2 AFTER b2 release has subprocess.Popen broken under colinux/windows
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Sun Jan  2 01:08:58 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 02 Jan 2011 00:08:58 +0000
Subject: [issue8350] Document lack of support for keyword arguments in C
	functions
In-Reply-To: <1270764159.26.0.287104770145.issue8350@psf.upfronthosting.co.za>
Message-ID: <1293926938.36.0.888630162651.issue8350@psf.upfronthosting.co.za>


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

This is an implementation detail specific to CPython and subject to change.  I'm -1 on documenting it for every function/method and thereby making it part of the language spec. We've lived without this spec for almost twenty years, so I'm inclined to think it is truly unimportant.

It is sufficient to mention just once in the docs that CPython functions/methods sometimes don't take keywords.

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

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

From report at bugs.python.org  Sun Jan  2 01:11:15 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 02 Jan 2011 00:11:15 +0000
Subject: [issue10802] python3.2 AFTER b2 release has subprocess.Popen broken
	under colinux/windows
In-Reply-To: <1293926870.23.0.886180589728.issue10802@psf.upfronthosting.co.za>
Message-ID: <1293927075.51.0.63022390365.issue10802@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Sun Jan  2 01:20:02 2011
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 02 Jan 2011 00:20:02 +0000
Subject: [issue10802] python3.2 AFTER b2 release has subprocess.Popen broken
	under colinux/windows
In-Reply-To: <1293926870.23.0.886180589728.issue10802@psf.upfronthosting.co.za>
Message-ID: <1293927602.74.0.308387064603.issue10802@psf.upfronthosting.co.za>


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


----------
nosy: +georg.brandl
priority: normal -> release blocker

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

From report at bugs.python.org  Sun Jan  2 01:51:20 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 02 Jan 2011 00:51:20 +0000
Subject: [issue10789] Lock.acquire documentation is misleading
In-Reply-To: <1293644478.45.0.40426107256.issue10789@psf.upfronthosting.co.za>
Message-ID: <1293929480.52.0.473662913898.issue10789@psf.upfronthosting.co.za>


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

Thanks for the correction Georg.

In msg104113 (on #8350), I quoted http://docs.python.org/dev/reference/expressions#calls :

?An implementation may provide built-in functions whose positional parameters do not have names, even if they are ?named? for the purpose of documentation, and which therefore cannot be supplied by keyword.?

Previous consensus seemed to be that this warning was enough, but recent bugs such as this one show that it does trip up users, so there is further discussion about how best to document this CPython limitation (hence the dependency I?m adding).

----------
dependencies: +Document lack of support for keyword arguments in C functions

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

From report at bugs.python.org  Sun Jan  2 02:16:49 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 02 Jan 2011 01:16:49 +0000
Subject: [issue10789] Lock.acquire documentation is misleading
In-Reply-To: <1293644478.45.0.40426107256.issue10789@psf.upfronthosting.co.za>
Message-ID: <1293931009.13.0.0888653862015.issue10789@psf.upfronthosting.co.za>


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

I concur that the one warning is enough.  Implementations have been given wide latitude in this regard.  Even within CPython there is not much uniformity -- some funcs/methods don't accept keywords, some will disregard keywords, and others may have keywords that are different from the name in the docs.  

I believe it would be a mistake to make to lock in the present state of accidental implementation details by documenting them in the main docs.

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

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

From report at bugs.python.org  Sun Jan  2 02:52:50 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 02 Jan 2011 01:52:50 +0000
Subject: [issue8350] Document lack of support for keyword arguments in C
	functions
In-Reply-To: <1270764159.26.0.287104770145.issue8350@psf.upfronthosting.co.za>
Message-ID: <1293933170.17.0.558341957765.issue8350@psf.upfronthosting.co.za>


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

I think that the warning that things are not always as they seem should be repeated in the front of the library manual where the pseudo-arg names are actual used, so the library manual stands on its own. In any case, I believe a lot of people use the lib ref without reading and remembering every detail of the language ref.

----------
nosy: +terry.reedy
versions:  -Python 2.6

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

From report at bugs.python.org  Sun Jan  2 03:19:05 2011
From: report at bugs.python.org (=?utf-8?q?Andreas_St=C3=BChrk?=)
Date: Sun, 02 Jan 2011 02:19:05 +0000
Subject: [issue8013] time.asctime segfaults when given a time in the far future
In-Reply-To: <1267031714.43.0.416052646257.issue8013@psf.upfronthosting.co.za>
Message-ID: <1293934745.26.0.970613790378.issue8013@psf.upfronthosting.co.za>


Andreas St?hrk <andy-python at hammerhartes.de> added the comment:

Updated patch against py3k branch.

----------
nosy: +Trundle
Added file: http://bugs.python.org/file20213/issue8013_py3k.diff

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

From report at bugs.python.org  Sun Jan  2 03:22:56 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 02 Jan 2011 02:22:56 +0000
Subject: [issue8350] Document lack of support for keyword arguments in C
	functions
In-Reply-To: <1270764159.26.0.287104770145.issue8350@psf.upfronthosting.co.za>
Message-ID: <1293934976.62.0.544219256812.issue8350@psf.upfronthosting.co.za>


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

If there is no indication in the lib manual as to which parameter names and defaults are real and which are fake, then the safe guideline is to never use keywards for library functions and methods and always pass everything positionally.

Slightly more complicated is to be aware of which classes and modules are Python versus C coded. (If needed, change for module.py in /Lib.) For some modules, one can take a cue from doc examples that use keywords.

Otherwise, each person has to experiment for himself and  check each TypeError messages to determine whether it arises from a misspelling or a hidden limitation. And maybe go through the same process a year later after forgetting.

>"We've lived without this spec for almost twenty years,"
Yes, and people have been stumbling on this and complaining for probably just as long. Since []s are no longer used in the doc to indicate 'optional', they can and are being used to indicate 'position-only'. Specify in the introduction, where notation should be explained, that the limitation is only for current CPython and may be changed in the future or be different for other implementations. However....

In my opinion, the real solution is to remove the limitation. Since the language spec says args can be passed by keyword as well as by position, make it be that way for everything we distribute.

----------

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

From report at bugs.python.org  Sun Jan  2 03:23:36 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 02 Jan 2011 02:23:36 +0000
Subject: [issue10789] Lock.acquire documentation is misleading
In-Reply-To: <1293644478.45.0.40426107256.issue10789@psf.upfronthosting.co.za>
Message-ID: <1293935016.92.0.573125693841.issue10789@psf.upfronthosting.co.za>


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

I responded to the general questions on #8350.

----------

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

From report at bugs.python.org  Sun Jan  2 03:58:55 2011
From: report at bugs.python.org (Gregory P. Smith)
Date: Sun, 02 Jan 2011 02:58:55 +0000
Subject: [issue10802] python3.2 AFTER b2 release has subprocess.Popen broken
	under colinux/windows
In-Reply-To: <1293926870.23.0.886180589728.issue10802@psf.upfronthosting.co.za>
Message-ID: <1293937135.34.0.0161724850397.issue10802@psf.upfronthosting.co.za>


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

The only thing that could cause this error is if the Modules/_posixsubprocess.c subprocess_cloexec_pipe function fails either in the pipe2() call or if HAVE_PIPE2 is not defined one of the fcntl() calls.

Can you look to see if HAVE_PIPE2 is defined?

I suspect it is but the colinux/windows environment should apperently not define it.  configure.in magic will be needed to make sure it does not get defined there.

Is your bugreport accurate?  This function was included in 3.2b2 so the failure should be the same in both versions.  As far as I can see nothing else has changed that should impact that.  Did you rerun configure properly on your colinux install?

----------

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

From report at bugs.python.org  Sun Jan  2 04:48:55 2011
From: report at bugs.python.org (Ned Deily)
Date: Sun, 02 Jan 2011 03:48:55 +0000
Subject: [issue8013] time.asctime segfaults when given a time in the far future
In-Reply-To: <1267031714.43.0.416052646257.issue8013@psf.upfronthosting.co.za>
Message-ID: <1293940135.07.0.484681619918.issue8013@psf.upfronthosting.co.za>


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

Thanks for the py3k patch.  I am also attaching a refreshed patch for current 2.7.  They both fix the segfaults when built and run on OS X 10.6 64-bit.  Since the patches change timemodule to use asctime_r, which AFAICT is not used elsewhere in the standard library, one concern might be if this change introduces a regression on any other platforms, something for the buildbots to test.

----------
stage:  -> patch review
Added file: http://bugs.python.org/file20214/issue8013_27.diff

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

From report at bugs.python.org  Sun Jan  2 06:19:22 2011
From: report at bugs.python.org (Ross Lagerwall)
Date: Sun, 02 Jan 2011 05:19:22 +0000
Subject: [issue5870] subprocess.DEVNULL
In-Reply-To: <1240946644.39.0.609275389725.issue5870@psf.upfronthosting.co.za>
Message-ID: <1293945562.23.0.736958934967.issue5870@psf.upfronthosting.co.za>


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

Here is a fairly simple patch that adds the subprocess.DEVNULL constant.

----------
keywords: +patch
nosy: +rosslagerwall
versions: +Python 3.3 -Python 2.7
Added file: http://bugs.python.org/file20215/5870_v1.patch

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

From report at bugs.python.org  Sun Jan  2 06:22:51 2011
From: report at bugs.python.org (Ben Gamari)
Date: Sun, 02 Jan 2011 05:22:51 +0000
Subject: [issue10782] Not possible to cross-compile due to poor detection of
	%lld support in printf
In-Reply-To: <1293473376.4.0.265613686073.issue10782@psf.upfronthosting.co.za>
Message-ID: <1293945771.1.0.354066385123.issue10782@psf.upfronthosting.co.za>


Ben Gamari <bgamari at gmail.com> added the comment:

Well, I'm not convinced that overriding config.cache is the best solution, but I am not really sure what else can be done. So far I've just been carrying a patch which changes configure.in, but this is clearly an awful hack.

----------

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

From report at bugs.python.org  Sun Jan  2 07:59:06 2011
From: report at bugs.python.org (Markus F.X.J. Oberhumer)
Date: Sun, 02 Jan 2011 06:59:06 +0000
Subject: [issue10803] ctypes: better support of bytearray objects
In-Reply-To: <1293951546.17.0.00856255345379.issue10803@psf.upfronthosting.co.za>
Message-ID: <1293951546.17.0.00856255345379.issue10803@psf.upfronthosting.co.za>


New submission from Markus F.X.J. Oberhumer <markus at oberhumer.com>:

Python 3.2b2 does not properly support accessing bytearrays from
ctypes, which makes dealing with large buffers somewhat unpleasant.

A very first fix - a simple patch for the z_set() function - is given here.


build/Python-3.2b2 $ quilt diff
Index: b/Modules/_ctypes/cfield.c
===================================================================
--- a/Modules/_ctypes/cfield.c
+++ b/Modules/_ctypes/cfield.c
@@ -1363,6 +1363,10 @@
         *(char **)ptr = PyBytes_AsString(value);
         Py_INCREF(value);
         return value;
+    } else if (PyByteArray_Check(value)) {
+        *(char **)ptr = PyByteArray_AsString(value);
+        Py_INCREF(value);
+        return value;
     } else if (PyLong_Check(value)) {
 #if SIZEOF_VOID_P == SIZEOF_LONG_LONG
         *(char **)ptr = (char *)PyLong_AsUnsignedLongLongMask(value);

----------
assignee: theller
components: ctypes
messages: 125032
nosy: mfxmfx, theller
priority: normal
severity: normal
status: open
title: ctypes: better support of bytearray objects
type: feature request
versions: Python 3.2

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

From report at bugs.python.org  Sun Jan  2 08:42:28 2011
From: report at bugs.python.org (Ron Adam)
Date: Sun, 02 Jan 2011 07:42:28 +0000
Subject: [issue10716] Modernize pydoc to use CSS
In-Reply-To: <1292491539.55.0.135732310832.issue10716@psf.upfronthosting.co.za>
Message-ID: <1293954148.03.0.42877283864.issue10716@psf.upfronthosting.co.za>


Ron Adam <ron_adam at users.sourceforge.net> added the comment:

Here is a new diff which updates all the new pydoc pages to use the css file. 

The css file is simpler and cleaner.  I also made a few adjustments to the url handler error handling, and changed the titles in the head sections so they say "Pydoc" instead of "Python" as they are PyDoc pages about Python.

None of these changes effect any of the old pydoc code yet.  This is about as far as we can go without removing the old tk panel and server.

Time for some feed back.  And how close do we really need it to be to the original?

:-)

----------
Added file: http://bugs.python.org/file20216/css_v2.diff

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

From report at bugs.python.org  Sun Jan  2 08:42:40 2011
From: report at bugs.python.org (Ron Adam)
Date: Sun, 02 Jan 2011 07:42:40 +0000
Subject: [issue10716] Modernize pydoc to use CSS
In-Reply-To: <1292491539.55.0.135732310832.issue10716@psf.upfronthosting.co.za>
Message-ID: <1293954160.22.0.125363179323.issue10716@psf.upfronthosting.co.za>


Changes by Ron Adam <ron_adam at users.sourceforge.net>:


Removed file: http://bugs.python.org/file20081/defaultstyle.css

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

From report at bugs.python.org  Sun Jan  2 08:42:47 2011
From: report at bugs.python.org (Ron Adam)
Date: Sun, 02 Jan 2011 07:42:47 +0000
Subject: [issue10716] Modernize pydoc to use CSS
In-Reply-To: <1292491539.55.0.135732310832.issue10716@psf.upfronthosting.co.za>
Message-ID: <1293954167.34.0.93929305567.issue10716@psf.upfronthosting.co.za>


Changes by Ron Adam <ron_adam at users.sourceforge.net>:


Removed file: http://bugs.python.org/file20088/pydoc sample html files.zip

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

From report at bugs.python.org  Sun Jan  2 08:43:06 2011
From: report at bugs.python.org (Ron Adam)
Date: Sun, 02 Jan 2011 07:43:06 +0000
Subject: [issue10716] Modernize pydoc to use CSS
In-Reply-To: <1292491539.55.0.135732310832.issue10716@psf.upfronthosting.co.za>
Message-ID: <1293954186.61.0.485552898198.issue10716@psf.upfronthosting.co.za>


Changes by Ron Adam <ron_adam at users.sourceforge.net>:


Removed file: http://bugs.python.org/file20183/css_v1.diff

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

From report at bugs.python.org  Sun Jan  2 09:25:24 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 02 Jan 2011 08:25:24 +0000
Subject: [issue8350] Document lack of support for keyword arguments in
	C	functions
In-Reply-To: <1293926467.3701.0.camel@localhost.localdomain>
Message-ID: <4D203670.9070109@v.loewis.de>


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

> Isn't it kind of a CPython-specific detail, though?

If other implementations do provide proper keyword arguments,
I'd be skeptical that they all settled on the names that the
library documentation gives to the arguments.

----------
title: Document lack of support for keyword arguments in C functions -> Document lack of support for keyword arguments in C	functions

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

From report at bugs.python.org  Sun Jan  2 09:25:47 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 02 Jan 2011 08:25:47 +0000
Subject: [issue10802] python3.2 AFTER b2 release has subprocess.Popen broken
	under colinux/windows
In-Reply-To: <1293926870.23.0.886180589728.issue10802@psf.upfronthosting.co.za>
Message-ID: <1293956747.44.0.640469992928.issue10802@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Sun Jan  2 09:51:42 2011
From: report at bugs.python.org (Pierre Quentel)
Date: Sun, 02 Jan 2011 08:51:42 +0000
Subject: [issue4953] cgi module cannot handle POST with multipart/form-data in
	3.0
In-Reply-To: <1232010166.79.0.972664060868.issue4953@psf.upfronthosting.co.za>
Message-ID: <1293958302.14.0.785429236239.issue4953@psf.upfronthosting.co.za>


Pierre Quentel <pierre.quentel at gmail.com> added the comment:

Hi,

I have started working on the port of a simplified version of Karrigell (a web framework) to Python3. I experienced the same problem as the other posters : in the current version, file upload doesn't work. So I've been working on the cgi module for a few days and now have a version which correctly manages file uploads in the tests I made

The problem in the current version (3.2b2) is that all data is read from sys.stdin, which reads strings, not bytes. This obviously can't work properly to upload binary files. In the proposed version, for multipart/form-data type, all data is read as bytes from sys.stdin.buffer ; in the CGI script, the Python interpreter must be launched with the -u option, as suggested by Amaury, otherwise sys.stdin.buffer.read() only returns the beginning of the data stream

The headers inside the multipart/form-data are decoded to a string using sys.stdin.encoding and passed to a FeedParser (which requires strings) ; then the data is read from sys.stdin.buffer (bytes) until a boundary is found

If the field is a file, the file object in self.file stores bytes, and the attribute "value" is a byte string. If it is not a file, the value is decoded to a string, always using sys.stdin.encoding, as for all other fields for other types of forms

Other cosmetic changes :
- replaced "while 1" by "while True"
- replaced "if type(value) == type([])" by "if isintance(value,list)"

Attached file : zip with cgi_new.py and tests in a folder called "http"
Tested with Python 3.2b2 (r32b2:87398, Dec 19 2010, 22:51:00) [MSC v.1500 32 bit (Intel)] on win32 ; files and CGI scripts served by Apache 2.2

----------
nosy: +quentel
Added file: http://bugs.python.org/file20217/http.zip

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

From report at bugs.python.org  Sun Jan  2 09:59:42 2011
From: report at bugs.python.org (kai zhu)
Date: Sun, 02 Jan 2011 08:59:42 +0000
Subject: [issue10802] python3.2 AFTER b2 release has subprocess.Popen broken
	under colinux/windows
In-Reply-To: <1293926870.23.0.886180589728.issue10802@psf.upfronthosting.co.za>
Message-ID: <1293958782.84.0.988274843873.issue10802@psf.upfronthosting.co.za>


kai zhu <kaizhu256 at gmail.com> added the comment:

tested w/ following debug code.  looks like greg is correct - HAVE_PIPE2 should NOT b defined under colinux.

diff -r 6fa1e3b94d8f Modules/_posixsubprocess.c
--- a/Modules/_posixsubprocess.c        Sat Jan 01 22:18:46 2011 +0100
+++ b/Modules/_posixsubprocess.c        Sun Jan 02 03:48:47 2011 -0500
@@ -412,10 +412,12 @@
     int fds[2];
     int res;
 #ifdef HAVE_PIPE2
+    PyErr_Format(PyExc_RuntimeError, "HAVE_PIPE2 = %i, O_CLOEXEC = %i", HAVE_PIPE2, O_CLOEXEC); return NULL;
     Py_BEGIN_ALLOW_THREADS
     res = pipe2(fds, O_CLOEXEC);
     Py_END_ALLOW_THREADS
 #else
+    PyErr_Format(PyExc_RuntimeError, "HAVE_PIPE2 not defined, O_CLOEXEC = %i", O_CLOEXEC); return NULL;
     /* We hold the GIL which offers some protection from other code calling
      * fork() before the CLOEXEC flags have been set but we can't guarantee
      * anything without pipe2(). */



b2 release:
./python -c 'import _posixsubprocess; _posixsubprocess.cloexec_pipe()'
Traceback (most recent call last):
  File "<string>", line 1, in <module>
RuntimeError: HAVE_PIPE2 not defined, O_CLOEXEC = 524288



latest hg:
./python -c 'import _posixsubprocess; _posixsubprocess.cloexec_pipe()'
Traceback (most recent call last):
  File "<string>", line 1, in <module>
RuntimeError: HAVE_PIPE2 = 1, O_CLOEXEC = 524288

----------

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

From report at bugs.python.org  Sun Jan  2 10:04:22 2011
From: report at bugs.python.org (kai zhu)
Date: Sun, 02 Jan 2011 09:04:22 +0000
Subject: [issue10802] python3.2 AFTER b2 release has subprocess.Popen broken
	under colinux/windows
In-Reply-To: <1293926870.23.0.886180589728.issue10802@psf.upfronthosting.co.za>
Message-ID: <1293959062.04.0.825841872947.issue10802@psf.upfronthosting.co.za>


kai zhu <kaizhu256 at gmail.com> added the comment:

i used the same almost vanilla configure for both:

$ ./configure --prefix=$USERPATH; make

----------

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

From report at bugs.python.org  Sun Jan  2 10:22:12 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Sun, 02 Jan 2011 09:22:12 +0000
Subject: [issue4662] posix module lacks several DeprecationWarning's
In-Reply-To: <1229276083.72.0.194776097767.issue4662@psf.upfronthosting.co.za>
Message-ID: <1293960132.94.0.967458314999.issue4662@psf.upfronthosting.co.za>


Sandro Tosi <sandro.tosi at gmail.com> added the comment:

I've refreshed the patch to only add DeprecationWarning for tempnam, tmpnam and tmpfile.

----------
stage:  -> patch review
Added file: http://bugs.python.org/file20218/issue4662-rel2.7.patch

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

From report at bugs.python.org  Sun Jan  2 10:56:43 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 02 Jan 2011 09:56:43 +0000
Subject: [issue10802] python3.2 AFTER b2 release has subprocess.Popen broken
	under colinux/windows
In-Reply-To: <1293926870.23.0.886180589728.issue10802@psf.upfronthosting.co.za>
Message-ID: <1293962203.05.0.536027018748.issue10802@psf.upfronthosting.co.za>


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

Can you please run the script under strace, and report what system call is not implemented? I.e. put

  import subprocess
  subprocess.Popen('ls')

into a file (foo.py), then run

  strace -o trace.txt python foo.py

Please attach the output in case you cannot identify the problem.

----------

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

From report at bugs.python.org  Sun Jan  2 10:58:25 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Sun, 02 Jan 2011 09:58:25 +0000
Subject: [issue1665333] Documentation missing for OptionGroup class in optparse
Message-ID: <1293962305.61.0.142664864609.issue1665333@psf.upfronthosting.co.za>


Sandro Tosi <sandro.tosi at gmail.com> added the comment:

Could someone give a look to this patch? I can work on fixing the missing stuff (if any :)).

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

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

From report at bugs.python.org  Sun Jan  2 12:46:30 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Sun, 02 Jan 2011 11:46:30 +0000
Subject: [issue10788] test_logging failure
In-Reply-To: <1293557775.34.0.401807724335.issue10788@psf.upfronthosting.co.za>
Message-ID: <1293968790.88.0.0826490967818.issue10788@psf.upfronthosting.co.za>


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

I think I've found the problem: test_concurrent_futures calls logging.critical, which registers a StreamHandler. This only happens when _wait_on_event and _signal_event fail on Win32.

There should be no reason to call logging.critical in a test, especially as the next line is assert False, <message>.

Perhaps the lines were left in by mistake: reassigning to Brian Quinlan.

----------
assignee: vinay.sajip -> bquinlan
nosy: +bquinlan

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

From report at bugs.python.org  Sun Jan  2 13:12:41 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 02 Jan 2011 12:12:41 +0000
Subject: [issue10348] multiprocessing: use SysV semaphores on FreeBSD
In-Reply-To: <1289181459.49.0.601327253766.issue10348@psf.upfronthosting.co.za>
Message-ID: <1293970361.09.0.846946342167.issue10348@psf.upfronthosting.co.za>


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

More info about FreeBSD.

"sysctl p1003_1b.sem_nsems_max" gives the maximum number of POSIX semaphores (per process? system wide?).

Since FreeBSD 8.1, "sudo sysctl -w p1003_1b.sem_nsems_max=256" can be used to change this limit at runtime.

Before FreeBSD 8.1, SEM_MAX constant should be changed in the kernel source code, and the kernel have to be recompiled. (p1003_1b.sem_nsems_max is not configurable in /etc/sysctl.conf, it is an hardcoded limit).

Before FreeBSD 8.0, the POSIX semaphores are disabled by default: the kernel have to be compiled using P1003_1B_SEMAPHORES option. Extract of sys/conf/NOTES:

#####################################################################
# POSIX P1003.1B

# Real time extensions added in the 1993 POSIX
# _KPOSIX_PRIORITY_SCHEDULING: Build in _POSIX_PRIORITY_SCHEDULING

options 	_KPOSIX_PRIORITY_SCHEDULING
# p1003_1b_semaphores are very experimental,
# user should be ready to assist in debugging if problems arise.
options 	P1003_1B_SEMAPHORES

# POSIX message queue
options 	P1003_1B_MQUEUE

#####################################################################

----------

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

From report at bugs.python.org  Sun Jan  2 13:25:47 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 02 Jan 2011 12:25:47 +0000
Subject: [issue10348] multiprocessing: use SysV semaphores on FreeBSD
In-Reply-To: <1289181459.49.0.601327253766.issue10348@psf.upfronthosting.co.za>
Message-ID: <1293971147.35.0.311927217397.issue10348@psf.upfronthosting.co.za>


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

NetBSD.

Extract of the sem_close() manpage
http://www.daemon-systems.org/man/sem_close.3.html
---
STANDARDS
     The sem_open(), sem_close(), and sem_unlink() functions conform to
     ISO/IEC 9945-1:1996 (``POSIX.1'').

HISTORY
     Support for named semaphores first appeared in NetBSD 2.0.
---

Martin wrote on the mailing list:
---
According to

http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/kern/uipc_sem.c?rev=1.22&content-type=text/x-cvsweb-markup&only_with_tag=MAIN

SEM_MAX is 128 since 2007, and dynamically adjustable (no reboot).
---

It looks like the sysctl (read/write) option is kern.posix.semmax.

----------

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

From report at bugs.python.org  Sun Jan  2 13:28:20 2011
From: report at bugs.python.org (Torsten Landschoff)
Date: Sun, 02 Jan 2011 12:28:20 +0000
Subject: [issue10804] Copy and paste error in _json.c
In-Reply-To: <1293971300.52.0.745698040415.issue10804@psf.upfronthosting.co.za>
Message-ID: <1293971300.52.0.745698040415.issue10804@psf.upfronthosting.co.za>


New submission from Torsten Landschoff <t.landschoff at gmx.net>:

There is a copy and paste error in _json.c: The pairs_hook field is assigned but object_hook is verified to be non-null. The same field is verified a few lines back to this is superfluous at least.

----------
components: Library (Lib)
files: patch
messages: 125044
nosy: torsten
priority: normal
severity: normal
status: open
title: Copy and paste error in _json.c
versions: Python 2.7
Added file: http://bugs.python.org/file20219/patch

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

From report at bugs.python.org  Sun Jan  2 13:28:44 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 02 Jan 2011 12:28:44 +0000
Subject: [issue10348] multiprocessing: use SysV semaphores on FreeBSD
In-Reply-To: <1289181459.49.0.601327253766.issue10348@psf.upfronthosting.co.za>
Message-ID: <1293971324.03.0.459951778754.issue10348@psf.upfronthosting.co.za>


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

Darwin (Mac OS X).

According to the following email (July 2010), Darwin supports POSIX semaphores and the default limit is 10,000 semaphores.
http://osdir.com/ml/darwin-dev/2010-07/msg00012.html

The limit is configurable via sysctl as kern.posix.sem.max.

----------

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

From report at bugs.python.org  Sun Jan  2 13:30:49 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 02 Jan 2011 12:30:49 +0000
Subject: [issue10348] multiprocessing: use SysV semaphores on FreeBSD
In-Reply-To: <1289181459.49.0.601327253766.issue10348@psf.upfronthosting.co.za>
Message-ID: <1293971449.66.0.763989709026.issue10348@psf.upfronthosting.co.za>


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

OpenBSD.

According to Martin, OpenBSD doesn't implement POSIX semaphores.
---
I don't have an installation of OpenBSD, but...

In FreeBSD, POSIX semaphores are implemented in sys/kern/uipc_sem.c.
In

http://www.openbsd.org/cgi-bin/cvsweb/src/sys/kern/

that file doesn't exist. Also, in FreeBSD's limits.h,
_POSIX_SEM_NSEMS_MAX is defined (surprisingly to 256);
in

http://www.openbsd.org/cgi-bin/cvsweb/~checkout~/src/include/limits.h?rev=1.15;content-type=text/plain

this constant doesn't appear. So ISTM that OpenBSD doesn't implement
POSIX semaphores. IIUC, this means that the multiprocessing module
won't be fully functional, and its tests (and the concurrent.futures
tests) will be skipped.
---

----------

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

From report at bugs.python.org  Sun Jan  2 13:32:08 2011
From: report at bugs.python.org (Torsten Landschoff)
Date: Sun, 02 Jan 2011 12:32:08 +0000
Subject: [issue10804] Copy and paste error in _json.c
In-Reply-To: <1293971300.52.0.745698040415.issue10804@psf.upfronthosting.co.za>
Message-ID: <1293971528.9.0.296713538452.issue10804@psf.upfronthosting.co.za>


Torsten Landschoff <t.landschoff at gmx.net> added the comment:

FYI, this bug is not in Python 3.3 (as of svn r87615).

----------

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

From report at bugs.python.org  Sun Jan  2 14:31:25 2011
From: report at bugs.python.org (kai zhu)
Date: Sun, 02 Jan 2011 13:31:25 +0000
Subject: [issue10802] python3.2 AFTER b2 release has subprocess.Popen broken
	under colinux/windows
In-Reply-To: <1293926870.23.0.886180589728.issue10802@psf.upfronthosting.co.za>
Message-ID: <1293975085.38.0.631246425882.issue10802@psf.upfronthosting.co.za>


kai zhu <kaizhu256 at gmail.com> added the comment:

the culprit was my colinux kernel (2.6.26.8-co-0.7.7.1) did not have pipe2 support (which libc erronenously assumed). updating the kernel fixed the problem.

the libc issue is partially discussed @ http://www.0x61.com/forum/linux-kernel-f109/popen2-popen-call-t1229012.html.  according to manpage pipe2 was not added to the kernel til 2.6.27

my guess is this affects all unstable debian systems which are running kernels 2.6.26 or older (u decide whether or not using old kernels for debian unstable is an edge case ;)

----------

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

From report at bugs.python.org  Sun Jan  2 14:55:06 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 02 Jan 2011 13:55:06 +0000
Subject: [issue10716] Modernize pydoc to use CSS
In-Reply-To: <1292491539.55.0.135732310832.issue10716@psf.upfronthosting.co.za>
Message-ID: <1293976506.04.0.230011383455.issue10716@psf.upfronthosting.co.za>


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

A few comments about css_v2.diff:
1) when the value is '0', there's no need to specify the unit (e.g. 0em);
2) when the color is specified the background-color should be specified as well (and vice versa);
3) hex colors (e.g. #00FF00) should be preferred to named colors (e.g. gray);
4) some selectors and properties don't work with older browsers (e.g. E > F or min-width);
5) there are a few empty dl.*{} that I would remove (unless you plan to fill them later);
6) the style I prefer for CSS is:
selector {
  property: value;
}

Regarding the HTML:
1) using an HTML 4.01 strict doctype would be better;
2) all the style-related attributes and elements should be removed (e.g bgcolor, valign, <font>);
3) using .red { color: red; } is not a good idea. Classes' names should describe the role of the element (e.g. header, entry) and not their style (otherwise when you want to change the page with a blue theme you'll end up with a .red { color: blue; }). If the colors are passed directly to the HTML they should be removed and left to the CSS(s) only. I don't know the code well enough to say if this is doable and/or if it requires a deprecation first;
4) the <li>s in html_header() should be closed, same for all the other elements that support a closing tag, even if optional (e.g. <dt>, <dd>);

There are also some minor incontinences in the indentantion, e.g.:
+        link_list = ['<a href="%s.html">%s</a>' % (name, name)
+                    for name in sys.builtin_module_names
+                    if name != '__main__']
+        contents = [html.index_columns('Built-in modules',
+                    link_list, css_class='section modules')]
+        link_list = ['<a href="%s.html">%s</a>' % (name, name)
+                      for name in sorted(Helper.keywords.keys())]
(the "contents" one is indented correctly), and some extra space after the '('.

----------

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

From report at bugs.python.org  Sun Jan  2 15:02:36 2011
From: report at bugs.python.org (Ross Lagerwall)
Date: Sun, 02 Jan 2011 14:02:36 +0000
Subject: [issue9905] subprocess.Popen fails with stdout=PIPE,
	stderr=PIPE if standard descriptors (0, 1, 2) are closed.
In-Reply-To: <1285005576.46.0.387895977213.issue9905@psf.upfronthosting.co.za>
Message-ID: <1293976956.51.0.697322225534.issue9905@psf.upfronthosting.co.za>


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

OK here is a patch + tests. Basically, it makes sure that the fd that it is closing is not 0, 1 or 2.

I've set it for 2.7, 3.1 and 3.2.

----------
keywords: +patch
nosy: +rosslagerwall
versions: +Python 2.7, Python 3.1, Python 3.2 -Python 2.6
Added file: http://bugs.python.org/file20220/i9905_v1.patch

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

From report at bugs.python.org  Sun Jan  2 15:08:49 2011
From: report at bugs.python.org (kai zhu)
Date: Sun, 02 Jan 2011 14:08:49 +0000
Subject: [issue10802] python3.2 AFTER b2 release has subprocess.Popen broken
	under colinux/windows
In-Reply-To: <1293926870.23.0.886180589728.issue10802@psf.upfronthosting.co.za>
Message-ID: <1293977329.24.0.406924039429.issue10802@psf.upfronthosting.co.za>


kai zhu <kaizhu256 at gmail.com> added the comment:

hi martin, did an strace & the 'not implemented' system call was pipe2()

pipe2 exists in libc (checked w/ ctypes), but is broken for old linux kernels as mentioned previously.

----------
Added file: http://bugs.python.org/file20221/trace2.txt

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

From report at bugs.python.org  Sun Jan  2 15:13:39 2011
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 02 Jan 2011 14:13:39 +0000
Subject: [issue10802] python3.2 AFTER b2 release has subprocess.Popen broken
	under colinux/windows
In-Reply-To: <1293926870.23.0.886180589728.issue10802@psf.upfronthosting.co.za>
Message-ID: <1293977619.96.0.149012506086.issue10802@psf.upfronthosting.co.za>


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

Does not seem to be a Python problem then.  Thanks for diagnosing!

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

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

From report at bugs.python.org  Sun Jan  2 15:20:25 2011
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 02 Jan 2011 14:20:25 +0000
Subject: [issue10804] Copy and paste error in _json.c
In-Reply-To: <1293971300.52.0.745698040415.issue10804@psf.upfronthosting.co.za>
Message-ID: <1293978025.87.0.93383829475.issue10804@psf.upfronthosting.co.za>


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

Thanks, fixed in r87626.

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

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

From report at bugs.python.org  Sun Jan  2 15:23:51 2011
From: report at bugs.python.org (Austin Bingham)
Date: Sun, 02 Jan 2011 14:23:51 +0000
Subject: [issue10805] traceback.print_exception throws AttributeError when
	exception is None
In-Reply-To: <1293978231.38.0.946265028499.issue10805@psf.upfronthosting.co.za>
Message-ID: <1293978231.38.0.946265028499.issue10805@psf.upfronthosting.co.za>


New submission from Austin Bingham <austin.bingham at gmail.com>:

traceback.print_exception() will throw an AttributeException if `value` is None and `chain` is True. This is because `_iter_chain` assumes that the exception object has a `__cause__` attribute. You can trigger this by trying for format a non-existent exception:

  >>> import logging, sys
  >>> logging.Formatter().formatException(sys.exc_info())
  Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python3.1/logging/__init__.py", line 418, in formatException
    traceback.print_exception(ei[0], ei[1], ei[2], None, sio)
  File "/usr/lib/python3.1/traceback.py", line 155, in print_exception
    for value, tb in values:
  File "/usr/lib/python3.1/traceback.py", line 122, in _iter_chain
    cause = exc.__cause__

This is assuming that sys.exc_info() returns (None, None, None).

----------
components: Library (Lib)
messages: 125054
nosy: abingham
priority: normal
severity: normal
status: open
title: traceback.print_exception throws AttributeError when exception is None
type: behavior
versions: Python 3.1

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

From report at bugs.python.org  Sun Jan  2 15:23:58 2011
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 02 Jan 2011 14:23:58 +0000
Subject: [issue1665333] Documentation missing for OptionGroup class in optparse
Message-ID: <1293978238.06.0.271526754194.issue1665333@psf.upfronthosting.co.za>


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

Looks good, applied in r87627 (after removing stray tabs).

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

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

From report at bugs.python.org  Sun Jan  2 15:37:45 2011
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 02 Jan 2011 14:37:45 +0000
Subject: [issue8013] time.asctime segfaults when given a time in the far future
In-Reply-To: <1267031714.43.0.416052646257.issue8013@psf.upfronthosting.co.za>
Message-ID: <1293979065.18.0.664196007376.issue8013@psf.upfronthosting.co.za>


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

The patch is wrong: it hardcodes the number of characters that the time string has, but it can be more than 24 if the year is > 9999.  (Of course, the check for \n currently in the code is wrong too and must be fixed.)

Also, shouldn't the issue be handled as in ctime()?  There is a NULL check there, and by just doing that check we wouldn't depend on asctime_r().

----------
assignee:  -> belopolsky
nosy: +belopolsky, georg.brandl

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

From report at bugs.python.org  Sun Jan  2 15:42:47 2011
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 02 Jan 2011 14:42:47 +0000
Subject: [issue5870] subprocess.DEVNULL
In-Reply-To: <1240946644.39.0.609275389725.issue5870@psf.upfronthosting.co.za>
Message-ID: <1293979367.07.0.434658807664.issue5870@psf.upfronthosting.co.za>


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

Hmm, we don't like these open-for-eternity file descriptors; we had such a thing for os.urandom() but removed it (see #1177468).

I'm okay with DEVNULL (or even just NULL) as a shorthand, but it should open (and close) the devnull device each time just as if a normal fd was given.

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

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

From report at bugs.python.org  Sun Jan  2 15:50:34 2011
From: report at bugs.python.org (Ross Lagerwall)
Date: Sun, 02 Jan 2011 14:50:34 +0000
Subject: [issue5870] subprocess.DEVNULL
In-Reply-To: <1240946644.39.0.609275389725.issue5870@psf.upfronthosting.co.za>
Message-ID: <1293979834.0.0.400038685712.issue5870@psf.upfronthosting.co.za>


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

I think if you look closely at the patch, the fd does not stay open the whole time. It is opened if necessary in _get_handles() with e.g.:

elif stdin == DEVNULL:
    p2cread = self._get_devnull()

and then closed in _execute_child() with:

if hasattr(self, '_devnull'):
    os.close(self._devnull)

which is executed from __init__(). So I don't think it stays open for eternity :-)

----------

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

From report at bugs.python.org  Sun Jan  2 15:50:59 2011
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 02 Jan 2011 14:50:59 +0000
Subject: [issue9074] subprocess closes standard file descriptors when it
	should not
In-Reply-To: <1277410336.39.0.223644435027.issue9074@psf.upfronthosting.co.za>
Message-ID: <1293979859.61.0.560047614918.issue9074@psf.upfronthosting.co.za>


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

#9905 has a similar patch and adds tests as well.

----------
nosy: +georg.brandl
resolution:  -> duplicate
status: open -> closed
superseder:  -> subprocess.Popen fails with stdout=PIPE, stderr=PIPE if standard descriptors (0, 1, 2) are closed.

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

From report at bugs.python.org  Sun Jan  2 16:36:39 2011
From: report at bugs.python.org (=?utf-8?q?Andreas_St=C3=BChrk?=)
Date: Sun, 02 Jan 2011 15:36:39 +0000
Subject: [issue8013] time.asctime segfaults when given a time in the far future
In-Reply-To: <1267031714.43.0.416052646257.issue8013@psf.upfronthosting.co.za>
Message-ID: <1293982599.97.0.729896037025.issue8013@psf.upfronthosting.co.za>


Andreas St?hrk <andy-python at hammerhartes.de> added the comment:

The real problem with years >= 9999 is that it is undefined behaviour anyway (see e.g. http://pubs.opengroup.org/onlinepubs/9699919799/functions/asctime.html: "the behavior is undefined if the above algorithm would attempt to generate more than 26 bytes of output (including the terminating null)").

----------

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

From report at bugs.python.org  Sun Jan  2 16:38:12 2011
From: report at bugs.python.org (=?utf-8?q?Andreas_St=C3=BChrk?=)
Date: Sun, 02 Jan 2011 15:38:12 +0000
Subject: [issue8013] time.asctime segfaults when given a time in the far future
In-Reply-To: <1267031714.43.0.416052646257.issue8013@psf.upfronthosting.co.za>
Message-ID: <1293982692.03.0.23459890523.issue8013@psf.upfronthosting.co.za>


Andreas St?hrk <andy-python at hammerhartes.de> added the comment:

Sorry, I meant " years > 9999" of course.

----------

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

From report at bugs.python.org  Sun Jan  2 16:52:59 2011
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 02 Jan 2011 15:52:59 +0000
Subject: [issue8013] time.asctime segfaults when given a time in the far future
In-Reply-To: <1267031714.43.0.416052646257.issue8013@psf.upfronthosting.co.za>
Message-ID: <1293983579.55.0.974869919023.issue8013@psf.upfronthosting.co.za>


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

Well, then I would have no problem with checking for that condition beforehand and raising ValueError.

On the other hand, it seems that implementations either return a correct string or NULL, so just erroring out in case of NULL would be fine as well.

----------

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

From report at bugs.python.org  Sun Jan  2 16:53:14 2011
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 02 Jan 2011 15:53:14 +0000
Subject: [issue5870] subprocess.DEVNULL
In-Reply-To: <1240946644.39.0.609275389725.issue5870@psf.upfronthosting.co.za>
Message-ID: <1293983594.64.0.885903962214.issue5870@psf.upfronthosting.co.za>


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

Right, sorry then :)

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

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

From report at bugs.python.org  Sun Jan  2 17:06:39 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 02 Jan 2011 16:06:39 +0000
Subject: [issue7995] On Mac / BSD sockets returned by accept inherit the
	parent's FD flags
In-Reply-To: <1293807050.86.0.598371803966.issue7995@psf.upfronthosting.co.za>
Message-ID: <1293984392.3733.7.camel@localhost.localdomain>


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

I've tried the patch under OpenSolaris and the test fails (EAGAIN),
meaning that accept() semantics there are the same as under BSD:

======================================================================
ERROR: testInheritFlags (test.test_socket.NonBlockingTCPTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/antoine/vbox/py3k/cc/Lib/test/test_socket.py", line 983,
in testInheritFlags
    message = conn.recv(len(MSG))
socket.error: [Errno 11] Resource temporarily unavailable

I think the code path in the patch should be opt-out rather than opt-in:
that is, it should be executed if HAVE_FCNTL, O_NONBLOCK are defined,
and if not under Linux.
(and I don't think O_ASYNC is useful here, is it?)

----------

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

From report at bugs.python.org  Sun Jan  2 17:12:19 2011
From: report at bugs.python.org (Etienne Robillard)
Date: Sun, 02 Jan 2011 16:12:19 +0000
Subject: [issue4953] cgi module cannot handle POST with multipart/form-data in
	3.0
In-Reply-To: <1232010166.79.0.972664060868.issue4953@psf.upfronthosting.co.za>
Message-ID: <1293984739.05.0.216254828482.issue4953@psf.upfronthosting.co.za>


Changes by Etienne Robillard <erob at gthcfoundation.org>:


----------
nosy: +erob

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

From report at bugs.python.org  Sun Jan  2 17:19:51 2011
From: report at bugs.python.org (R. David Murray)
Date: Sun, 02 Jan 2011 16:19:51 +0000
Subject: [issue4953] cgi module cannot handle POST with multipart/form-data in
	3.0
In-Reply-To: <1232010166.79.0.972664060868.issue4953@psf.upfronthosting.co.za>
Message-ID: <1293985191.7.0.887208153217.issue4953@psf.upfronthosting.co.za>


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

Thank you very much for working on this!  I'll try to take a look at the patch soon.  A couple quick comments based on your posting: first, the email module now has a BytesFeedparser that will accept a byte stream, which I hope might simplify your patch.  Second, it would be very helpful if you could upload your patch as an 'svn diff' against the current py3k trunk (see python.org/dev for details on how to do that).  That will make review and application of the patch much much simpler.  (This would be true even if more of the code in cgi.py has changed than not.)  If you don't want to set up an svn checkout, then a context diff against the copy of cgi.py you started with would be second best.  Please post any files individually as .patch or .diff or .txt files...these are preferred in the tracker over .zip files because they can be viewed without downloading.

----------
stage: unit test needed -> patch review
versions: +Python 3.3 -Python 3.0, Python 3.1, Python 3.2

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

From report at bugs.python.org  Sun Jan  2 18:07:01 2011
From: report at bugs.python.org (Ross Lagerwall)
Date: Sun, 02 Jan 2011 17:07:01 +0000
Subject: [issue7995] On Mac / BSD sockets returned by accept inherit the
	parent's FD flags
In-Reply-To: <1266876583.45.0.97810567794.issue7995@psf.upfronthosting.co.za>
Message-ID: <1293988021.91.0.652872284871.issue7995@psf.upfronthosting.co.za>


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

OK try this one, it's now opt-out.

----------
Added file: http://bugs.python.org/file20222/7995_v3.patch

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

From report at bugs.python.org  Sun Jan  2 19:08:37 2011
From: report at bugs.python.org (Ross Lagerwall)
Date: Sun, 02 Jan 2011 18:08:37 +0000
Subject: [issue10806] Subprocess error if fds 0,1,2 are closed
In-Reply-To: <1293991717.46.0.660046429073.issue10806@psf.upfronthosting.co.za>
Message-ID: <1293991717.46.0.660046429073.issue10806@psf.upfronthosting.co.za>


New submission from Ross Lagerwall <rosslagerwall at gmail.com>:

There is an issue where if a python program closes all the std. file descriptors (e.g. a daemon) and then uses the subprocess module, the file descriptors may not be set up properly in the subprocess. This may actually be a fairly common use case in a daemon program that needs to run a subprocess and set up pipes to it.

Here is an example:

import os, subprocess, sys

x=os.open('/dev/null', os.O_RDWR)
os.close(0)
os.close(1)
os.close(2)

res = subprocess.Popen([sys.executable, "-c",
                      'import sys;'
                      'sys.stdout.write("apple");'
                      'sys.stdout.flush();'
                      'sys.stderr.write("orange")'],
           stdin=x,
           stdout=subprocess.PIPE,
           stderr=subprocess.PIPE).communicate()
with open('/tmp/out', 'w') as f:
    f.write(repr(res) + '\n')
    f.write(repr((b'apple', b'orange')) + '\n')

The expected output in /tmp/out is:
('apple', 'orange')
('apple', 'orange')

but we get:
(b'', b"Fatal Python error: Py_Initialize: can't initialize sys standard streams\nOSError: [Errno 9] Bad file descriptor\n")
(b'apple', b'orange')

The problem comes about where the calls are made (this applies to the python & c versions):
 os.dup2(p2cread, 0)
 os.dup2(c2pwrite, 1)
 os.dup2(errwrite, 2)

if c2pwrite or p2cread or errwrite is the same as what it's being dupped() to (eg if c2pwrite == 1) then the dup2 call does nothing. But, if we're using pipes, the close-on-exec flags are set initially and the dup2() call would normally remove the flag but it doesn't.

Attached is a patch which basically uses fcntl if necessary to remove the close-on-exec flag, and tests.

----------
components: Library (Lib)
files: subprocess.patch
keywords: patch
messages: 125067
nosy: georg.brandl, giampaolo.rodola, gregory.p.smith, pitrou, rosslagerwall
priority: normal
severity: normal
status: open
title: Subprocess error if fds 0,1,2 are closed
type: behavior
versions: Python 3.2
Added file: http://bugs.python.org/file20223/subprocess.patch

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

From report at bugs.python.org  Sun Jan  2 19:21:47 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 02 Jan 2011 18:21:47 +0000
Subject: [issue10751] REMOTE_USER and Remote-User collision in wsgiref
In-Reply-To: <1292971576.27.0.760159303747.issue10751@psf.upfronthosting.co.za>
Message-ID: <1293992507.3.0.706245547604.issue10751@psf.upfronthosting.co.za>


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


----------
components: +Library (Lib) -Extension Modules
stage:  -> needs patch
title: WSGIREF - REMOTE_USER and REMOTE-USER collision -> REMOTE_USER and Remote-User collision in wsgiref
type: security -> behavior
versions: +Python 3.1, Python 3.2 -Python 2.6

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

From report at bugs.python.org  Sun Jan  2 19:22:49 2011
From: report at bugs.python.org (yihuang)
Date: Sun, 02 Jan 2011 18:22:49 +0000
Subject: [issue10807] `b'dGVzdA==\n'.decode('base64')` raise exception
In-Reply-To: <1293992569.84.0.544003446653.issue10807@psf.upfronthosting.co.za>
Message-ID: <1293992569.84.0.544003446653.issue10807@psf.upfronthosting.co.za>


New submission from yihuang <yi.codeplayer at gmail.com>:

>>> b'dGVzdA==\n'.decode('base64')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "../Lib/encodings/base64_codec.py", line 20, in base64_decode
    return (base64.decodebytes(input), len(input))
  File "../Lib/base64.py", line 359, in decodebytes
    raise TypeError("expected bytes, not %s" % s.__class__.__name__)
TypeError: expected bytes, not memoryview

----------
components: Unicode
messages: 125068
nosy: yi.codeplayer
priority: normal
severity: normal
status: open
title: `b'dGVzdA==\n'.decode('base64')` raise exception
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Sun Jan  2 19:27:14 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 02 Jan 2011 18:27:14 +0000
Subject: [issue10806] Subprocess error if fds 0,1,2 are closed
In-Reply-To: <1293991717.46.0.660046429073.issue10806@psf.upfronthosting.co.za>
Message-ID: <1293992830.3733.10.camel@localhost.localdomain>


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

> Attached is a patch which basically uses fcntl if necessary to remove
> the close-on-exec flag, and tests.

Python adds extra output at the end of stderr when compiled in debug
mode. Therefore you first have to strip that output, like this:

            out, err = subprocess.Popen(...).communicate()
            err = support.strip_python_stderr(err)
            self.assertEqual((out, err), (b'apple', b'orange'))

Otherwise, looks good, thank you.

----------

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

From report at bugs.python.org  Sun Jan  2 19:34:37 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 02 Jan 2011 18:34:37 +0000
Subject: [issue10791] Wrapping TextIOWrapper around gzip files
In-Reply-To: <1293652434.65.0.434835329632.issue10791@psf.upfronthosting.co.za>
Message-ID: <1293993277.1.0.493272354649.issue10791@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/issue10791>
_______________________________________

From report at bugs.python.org  Sun Jan  2 19:52:36 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sun, 02 Jan 2011 18:52:36 +0000
Subject: [issue8013] time.asctime segfaults when given a time in the far future
In-Reply-To: <1293983579.55.0.974869919023.issue8013@psf.upfronthosting.co.za>
Message-ID: <AANLkTi=Wdih8TkdP6AyO-j-gJNYv+V7ZHJo5x2ANB9Ji@mail.gmail.com>


Alexander Belopolsky <alexander.belopolsky at gmail.com> added the comment:

On Sun, Jan 2, 2011 at 10:52 AM, Georg Brandl <report at bugs.python.org> wrote:
..
> Well, then I would have no problem with checking for that condition beforehand and raising
> ValueError.
>

IIRC, there was a similar bug report about ctime where pre-condition
checking was required because platform ctime would crash for huge
values of time.  I'll try to find the ticket.

> On the other hand, it seems that implementations either return a correct string or NULL,
> so just erroring out in case of NULL would be fine as well.

This is true on the platforms that I have access to: OSX, Linux, and
Solaris.  I think asctime_r is available and behaves this way on
Python supported platforms.  I'll check this in and watch the bots.

----------

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

From report at bugs.python.org  Sun Jan  2 19:59:12 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sun, 02 Jan 2011 18:59:12 +0000
Subject: [issue8013] time.asctime segfaults when given a time in the far future
In-Reply-To: <AANLkTi=Wdih8TkdP6AyO-j-gJNYv+V7ZHJo5x2ANB9Ji@mail.gmail.com>
Message-ID: <AANLkTin3eyiDOoO+LNdzONrdj_m3TRzYV1DJemVo4K=O@mail.gmail.com>


Alexander Belopolsky <alexander.belopolsky at gmail.com> added the comment:

On Sun, Jan 2, 2011 at 1:52 PM, Alexander Belopolsky
<report at bugs.python.org> wrote:
..
>> Well, then I would have no problem with checking for that condition beforehand and raising
>> ValueError.
>>
>
> IIRC, there was a similar bug report about ctime where pre-condition
> checking was required because platform ctime would crash for huge
> values of time. ?I'll try to find the ticket.

Hmm. My search brought up issue 10563, but the last message on that
issue says that "a change has been recently made to time.asctime() to
reject year > 9999.  See r85137 and issue6608."  I wonder if that
change made this issue moot.

----------

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

From report at bugs.python.org  Sun Jan  2 20:00:01 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 02 Jan 2011 19:00:01 +0000
Subject: [issue10807] `b'dGVzdA==\n'.decode('base64')` raise exception
In-Reply-To: <1293992569.84.0.544003446653.issue10807@psf.upfronthosting.co.za>
Message-ID: <1293994801.35.0.630709393661.issue10807@psf.upfronthosting.co.za>


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

base64, bz2, hex, quopri, rot13, uu and zlib codecs (reintroduced recently by r86934, issue #7475) cannot be used by str.encode/bytes.decode, but with .transform() and .untransform() methods of bytes and str objects. But these methods were removed by r87176.

The last solution to use base64 codec is:

>>> import codecs
>>> codecs.lookup('base64').decode(b'YWJj\n')[0]
b'abc'
>>> codecs.lookup('base64').encode(b'YWJj\n')[0]
b'abc'

Or simply use directly the base64 module:

>>> import base64
>>> base64.decodebytes(b'YWJj\n')
b'abc'
>>> base64.encodebytes(b'abc')
b'YWJj\n'

base64, bz2, hex, quopri, rot13, uu and zlib codecs should be removed from encodings.aliases (because they introduced a confusion for Python 2 users), or removed completly (because it's easier to use directly the related module, eg. base64 or zlib).

----------
nosy: +haypo

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

From report at bugs.python.org  Sun Jan  2 20:01:52 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 02 Jan 2011 19:01:52 +0000
Subject: [issue7475] codecs missing: base64 bz2 hex zlib hex_codec ...
In-Reply-To: <1260484060.32.0.471733830707.issue7475@psf.upfronthosting.co.za>
Message-ID: <1293994912.42.0.162546737695.issue7475@psf.upfronthosting.co.za>


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

See issue #10807: 'base64' can be used with bytes.decode() (and str.encode()), but it raises a confusing exception (TypeError: expected bytes, not memoryview).

----------

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

From report at bugs.python.org  Sun Jan  2 20:08:11 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 02 Jan 2011 19:08:11 +0000
Subject: [issue10807] `b'dGVzdA==\n'.decode('base64')` raise exception
In-Reply-To: <1293992569.84.0.544003446653.issue10807@psf.upfronthosting.co.za>
Message-ID: <1293995291.82.0.78559601194.issue10807@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
nosy: +georg.brandl
priority: normal -> release blocker

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

From report at bugs.python.org  Sun Jan  2 20:22:53 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 02 Jan 2011 19:22:53 +0000
Subject: [issue10807] `b'dGVzdA==\n'.decode('base64')` raise exception
In-Reply-To: <1293992569.84.0.544003446653.issue10807@psf.upfronthosting.co.za>
Message-ID: <1293996173.9.0.0860457891657.issue10807@psf.upfronthosting.co.za>


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

issue10807.patch just disables hex, base64, ... codecs in aliases (so it's still possible to use they through codecs.lookup()).

----------
keywords: +patch
Added file: http://bugs.python.org/file20224/issue10780.patch

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

From report at bugs.python.org  Sun Jan  2 20:23:31 2011
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 02 Jan 2011 19:23:31 +0000
Subject: [issue10807] `b'dGVzdA==\n'.decode('base64')` raise exception
In-Reply-To: <1293992569.84.0.544003446653.issue10807@psf.upfronthosting.co.za>
Message-ID: <1293996211.29.0.200760531677.issue10807@psf.upfronthosting.co.za>


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

That does not look like the right patch...

----------

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

From report at bugs.python.org  Sun Jan  2 20:24:06 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 02 Jan 2011 19:24:06 +0000
Subject: [issue10807] `b'dGVzdA==\n'.decode('base64')` raise exception
In-Reply-To: <1293992569.84.0.544003446653.issue10807@psf.upfronthosting.co.za>
Message-ID: <1293996246.96.0.216207308408.issue10807@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Removed file: http://bugs.python.org/file20224/issue10780.patch

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

From report at bugs.python.org  Sun Jan  2 20:24:20 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 02 Jan 2011 19:24:20 +0000
Subject: [issue10807] `b'dGVzdA==\n'.decode('base64')` raise exception
In-Reply-To: <1293992569.84.0.544003446653.issue10807@psf.upfronthosting.co.za>
Message-ID: <1293996260.75.0.91328703508.issue10807@psf.upfronthosting.co.za>


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

Ah yes :-)

----------
Added file: http://bugs.python.org/file20225/issue10807.patch

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

From report at bugs.python.org  Sun Jan  2 20:25:25 2011
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 02 Jan 2011 19:25:25 +0000
Subject: [issue10807] `b'dGVzdA==\n'.decode('base64')` raise exception
In-Reply-To: <1293992569.84.0.544003446653.issue10807@psf.upfronthosting.co.za>
Message-ID: <1293996325.93.0.334809726113.issue10807@psf.upfronthosting.co.za>


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

Looks good, please commit.

----------

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

From report at bugs.python.org  Sun Jan  2 20:26:45 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sun, 02 Jan 2011 19:26:45 +0000
Subject: [issue10807] `b'dGVzdA==\n'.decode('base64')` raise exception
In-Reply-To: <1293992569.84.0.544003446653.issue10807@psf.upfronthosting.co.za>
Message-ID: <1293996405.79.0.139404170634.issue10807@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


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

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

From report at bugs.python.org  Sun Jan  2 20:26:50 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 02 Jan 2011 19:26:50 +0000
Subject: [issue7995] On Mac / BSD sockets returned by accept inherit the
	parent's FD flags
In-Reply-To: <1266876583.45.0.97810567794.issue7995@psf.upfronthosting.co.za>
Message-ID: <1293996410.55.0.640074706872.issue7995@psf.upfronthosting.co.za>


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

After further testing, it turns out that Windows exhibits BSD-like behaviour too. So instead of complicating the flag-setting code again, I suggest an alternative of doing it in the Python wrapper. Patch attached.

----------
Added file: http://bugs.python.org/file20226/nonblock.patch

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

From report at bugs.python.org  Sun Jan  2 20:39:12 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 02 Jan 2011 19:39:12 +0000
Subject: [issue10475] hardcoded compilers for LDSHARED/LDCXXSHARED on NetBSD
In-Reply-To: <1290297580.46.0.357018780785.issue10475@psf.upfronthosting.co.za>
Message-ID: <1293997152.77.0.033110651634.issue10475@psf.upfronthosting.co.za>


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

Patch committed in r87639 (3.2), r87641 (3.1) and r87640 (2.7). Thank you!

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed
versions:  -Python 2.5, Python 2.6

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

From report at bugs.python.org  Sun Jan  2 20:49:15 2011
From: report at bugs.python.org (Brian Quinlan)
Date: Sun, 02 Jan 2011 19:49:15 +0000
Subject: [issue10798] test_concurrent_futures fails on FreeBSD
In-Reply-To: <1293740054.42.0.931376139757.issue10798@psf.upfronthosting.co.za>
Message-ID: <1293997755.66.0.532219459693.issue10798@psf.upfronthosting.co.za>


Brian Quinlan <brian at sweetapp.com> added the comment:

Martin,

Could you commit this patch if you think that it is the right thing? I'm going to be restructuring the tests and don't want you to get caught in merge hell.

Cheers,
Brian

----------

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

From report at bugs.python.org  Sun Jan  2 20:52:18 2011
From: report at bugs.python.org (Florian Apolloner)
Date: Sun, 02 Jan 2011 19:52:18 +0000
Subject: [issue10808] ssl unwrap fails with Error 0
In-Reply-To: <1293997937.94.0.348375754935.issue10808@psf.upfronthosting.co.za>
Message-ID: <1293997937.94.0.348375754935.issue10808@psf.upfronthosting.co.za>


New submission from Florian Apolloner <florian at apolloner.eu>:

If I use the server code in the attachment I get this error in unwrap:

Traceback (most recent call last):
  File "server.py", line 23, in <module>
    deal_with_client(connstream)
  File "server.py", line 13, in deal_with_client
    s = connstream.unwrap()
  File "/usr/lib/python3.1/ssl.py", line 302, in unwrap
    s = self._sslobj.shutdown()
socket.error: [Errno 0] Error

This error message is imo far from optiomal as it gives no clue whatsoever. My Openssl version is: 'OpenSSL 0.9.8o 01 Jun 2010'. Aside from that connstream.close() doesn't close the underlying socket (as seen in http://bugs.python.org/issue10127 Reproduceable with py2.6 and 2.7). The only way to properly close the connection now is:

connstream.close(); newsocket.close()
or 
del newsocket; connstream.close()
Maybe the docs should point that out more prominent.

If you need more info just tell me.

----------
components: None
files: server.py
messages: 125081
nosy: apollo13
priority: normal
severity: normal
status: open
title: ssl unwrap fails with Error 0
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1
Added file: http://bugs.python.org/file20227/server.py

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

From report at bugs.python.org  Sun Jan  2 20:52:23 2011
From: report at bugs.python.org (Phillip J. Eby)
Date: Sun, 02 Jan 2011 19:52:23 +0000
Subject: [issue10751] REMOTE_USER and Remote-User collision in wsgiref
In-Reply-To: <1292971576.27.0.760159303747.issue10751@psf.upfronthosting.co.za>
Message-ID: <1293997943.19.0.782477922474.issue10751@psf.upfronthosting.co.za>


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

I don't understand.  HTTP_REMOTE_USER is not the name of a standard CGI variable - it's REMOTE_USER.

It would help if you could show code for what client/proxy/server combination has this problem, what happens when that code runs, and what you want to happen instead.

----------

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

From report at bugs.python.org  Sun Jan  2 20:55:33 2011
From: report at bugs.python.org (Ross Lagerwall)
Date: Sun, 02 Jan 2011 19:55:33 +0000
Subject: [issue10806] Subprocess error if fds 0,1,2 are closed
In-Reply-To: <1293991717.46.0.660046429073.issue10806@psf.upfronthosting.co.za>
Message-ID: <1293998133.7.0.255741216342.issue10806@psf.upfronthosting.co.za>


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

Updated patch for debug mode. Does this also need to be applied for 3.1?

----------
Added file: http://bugs.python.org/file20228/subprocess_v2.patch

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

From report at bugs.python.org  Sun Jan  2 20:55:54 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 02 Jan 2011 19:55:54 +0000
Subject: [issue10807] `b'dGVzdA==\n'.decode('base64')` raise exception
In-Reply-To: <1293992569.84.0.544003446653.issue10807@psf.upfronthosting.co.za>
Message-ID: <1293998154.97.0.351194304463.issue10807@psf.upfronthosting.co.za>


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

> Looks good, please commit.

Ok, done: r87642

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

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

From report at bugs.python.org  Sun Jan  2 20:58:01 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sun, 02 Jan 2011 19:58:01 +0000
Subject: [issue8013] time.asctime segfaults when given a time in the far future
In-Reply-To: <AANLkTin3eyiDOoO+LNdzONrdj_m3TRzYV1DJemVo4K=O@mail.gmail.com>
Message-ID: <AANLkTimDOdZzHQGGrF+LYaM01U6vko-KE02_OB+9jz+i@mail.gmail.com>


Alexander Belopolsky <alexander.belopolsky at gmail.com> added the comment:

On Sun, Jan 2, 2011 at 1:59 PM, Alexander Belopolsky
<report at bugs.python.org> wrote:
..
> Hmm. My search brought up issue 10563, but the last message on that
> issue says that "a change has been recently made to time.asctime() to
> reject year > 9999. ?See r85137 and issue6608." ?I wonder if that
> change made this issue moot.

It turns out the check added in r85137 does not cover tm_year even
though CERT recommends it (see msg107605).  These are separate issues
though. I think given where we are in the release cycle, the most
conservative solution would be to simply add a null check as follows.
(I did check that it fixes the crash on OSX.)

===================================================================
--- timemodule.c        (revision 87556)
+++ timemodule.c        (working copy)
@@ -620,6 +620,10 @@
     } else if (!gettmarg(tup, &buf) || !checktm(&buf))
         return NULL;
     p = asctime(&buf);
+    if (p == NULL) {
+        PyErr_SetString(PyExc_ValueError, "invalid time");
+        return NULL;
+    }
     if (p[24] == '\n')
         p[24] = '\0';
     return PyUnicode_FromString(p);

----------

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

From report at bugs.python.org  Sun Jan  2 21:00:00 2011
From: report at bugs.python.org (Pierre Quentel)
Date: Sun, 02 Jan 2011 20:00:00 +0000
Subject: [issue4953] cgi module cannot handle POST with multipart/form-data in
	3.0
In-Reply-To: <1232010166.79.0.972664060868.issue4953@psf.upfronthosting.co.za>
Message-ID: <1293998400.48.0.924152613158.issue4953@psf.upfronthosting.co.za>


Pierre Quentel <pierre.quentel at gmail.com> added the comment:

I attach the svn diff file against the present version (generated by Tortoise SVN), hope it's what you expect

----------
Added file: http://bugs.python.org/file20229/cgi_diff.txt

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

From report at bugs.python.org  Sun Jan  2 21:07:14 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 02 Jan 2011 20:07:14 +0000
Subject: [issue4662] posix module lacks several DeprecationWarning's
In-Reply-To: <1229276083.72.0.194776097767.issue4662@psf.upfronthosting.co.za>
Message-ID: <1293998834.16.0.368007626261.issue4662@psf.upfronthosting.co.za>


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

Patch committed in r87643, thank you.

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

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

From report at bugs.python.org  Sun Jan  2 21:08:05 2011
From: report at bugs.python.org (Pierre Quentel)
Date: Sun, 02 Jan 2011 20:08:05 +0000
Subject: [issue4953] cgi module cannot handle POST with multipart/form-data in
	3.0
In-Reply-To: <1232010166.79.0.972664060868.issue4953@psf.upfronthosting.co.za>
Message-ID: <1293998885.89.0.540234428299.issue4953@psf.upfronthosting.co.za>


Pierre Quentel <pierre.quentel at gmail.com> added the comment:

Please ignore previous post. I worked on the version of cgi.py included in version 3.2b2, and I just realized there were changes commited to the svn repository since this version. I will post the diff file later, but you can always test the files in the zip file

----------

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

From report at bugs.python.org  Sun Jan  2 21:13:46 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 02 Jan 2011 20:13:46 +0000
Subject: [issue10802] python3.2 AFTER b2 release has subprocess.Popen broken
	under colinux/windows
In-Reply-To: <1293926870.23.0.886180589728.issue10802@psf.upfronthosting.co.za>
Message-ID: <1293999226.82.0.342913988125.issue10802@psf.upfronthosting.co.za>


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

If more people report this, there is still something Python could do:

- the configure test could verify that the running kernel actually implements the system call, and undefine HAVE_PIPE2 if that's not the case. Of course this would only help if the resulting binary only ever runs on the same system, and if the kernel is only ever upgraded.
- the test could be deferred to run-time, having subprocess_cloexec_pipe fall back to the pipe()/fcntl() branch if the system call fails with ENOSYS.

----------

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

From report at bugs.python.org  Sun Jan  2 21:15:33 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 02 Jan 2011 20:15:33 +0000
Subject: [issue10806] Subprocess error if fds 0,1,2 are closed
In-Reply-To: <1293998133.7.0.255741216342.issue10806@psf.upfronthosting.co.za>
Message-ID: <1293999314.2662.0.camel@localhost.localdomain>


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

> Updated patch for debug mode. Does this also need to be applied for 3.1?

Yes, but we can port it ourselves (unless you're really motivated)

----------

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

From report at bugs.python.org  Sun Jan  2 21:17:15 2011
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sun, 02 Jan 2011 20:17:15 +0000
Subject: [issue10475] hardcoded compilers for LDSHARED/LDCXXSHARED on NetBSD
In-Reply-To: <1290297580.46.0.357018780785.issue10475@psf.upfronthosting.co.za>
Message-ID: <1293999435.14.0.91312010602.issue10475@psf.upfronthosting.co.za>


Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com> added the comment:

$(CC) and $(CXX) should be expanded by `make`, but configure.in contains wrong quoting, which results in incorrect expansion during running `configure`.

-LDSHARED="$(CC) -shared"
-LDCXXSHARED="$(CXX) -shared";;
+LDSHARED='$(CC) -shared'
+LDCXXSHARED='$(CXX) -shared';;

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

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

From report at bugs.python.org  Sun Jan  2 21:17:23 2011
From: report at bugs.python.org (Gregory P. Smith)
Date: Sun, 02 Jan 2011 20:17:23 +0000
Subject: [issue10802] python3.2 AFTER b2 release has subprocess.Popen broken
	under colinux/windows
In-Reply-To: <1293926870.23.0.886180589728.issue10802@psf.upfronthosting.co.za>
Message-ID: <1293999443.12.0.953645760659.issue10802@psf.upfronthosting.co.za>


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

This bug has brought up a broader issue.  the pipe2 syscall on Linux is very new.  It is perfectly reasonable to expect a Python binary will be compiled against a C library that has a pipe2() function but run on a system with an older (pre 2.6.27) linux kernel.  I have many systems like that at work.

I'm going to make subprocess_cloexec_pipe check for a not implemented error from the pipe2 call and use the fallback pipe+fcntl code in that case instead.

----------

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

From report at bugs.python.org  Sun Jan  2 21:17:55 2011
From: report at bugs.python.org (Gregory P. Smith)
Date: Sun, 02 Jan 2011 20:17:55 +0000
Subject: [issue10802] python3.2 AFTER b2 release has subprocess.Popen broken
	under colinux/windows
In-Reply-To: <1293926870.23.0.886180589728.issue10802@psf.upfronthosting.co.za>
Message-ID: <1293999475.47.0.443974169.issue10802@psf.upfronthosting.co.za>


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

This bug has brought up a broader issue.  the pipe2 syscall on Linux is very new.  It is perfectly reasonable to expect a Python binary will be compiled against a C library that has a pipe2() function but run on a system with an older (pre 2.6.27) linux kernel.  I have many systems like that at work.

I'm going to make subprocess_cloexec_pipe check for a not implemented error from the pipe2 call and use the fallback pipe+fcntl code in that case instead.

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

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

From report at bugs.python.org  Sun Jan  2 21:46:24 2011
From: report at bugs.python.org (Yotam Medini)
Date: Sun, 02 Jan 2011 20:46:24 +0000
Subject: [issue670664] HTMLParser.py - more robust SCRIPT tag parsing
Message-ID: <1294001184.05.0.441216200434.issue670664@psf.upfronthosting.co.za>


Changes by Yotam Medini <yotam at users.sourceforge.net>:


Added file: http://bugs.python.org/file20231/endtag-space.html

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

From report at bugs.python.org  Sun Jan  2 21:46:23 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 02 Jan 2011 20:46:23 +0000
Subject: [issue10806] Subprocess error if fds 0,1,2 are closed
In-Reply-To: <1293991717.46.0.660046429073.issue10806@psf.upfronthosting.co.za>
Message-ID: <1294001183.55.0.831788211543.issue10806@psf.upfronthosting.co.za>


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

Patch works fine, thank you. Here is an attempt at a slightly more readable code by refactoring.

----------
Added file: http://bugs.python.org/file20230/sp.patch

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

From report at bugs.python.org  Sun Jan  2 21:48:36 2011
From: report at bugs.python.org (Yotam Medini)
Date: Sun, 02 Jan 2011 20:48:36 +0000
Subject: [issue670664] HTMLParser.py - more robust SCRIPT tag parsing
Message-ID: <1294001316.61.0.605571229225.issue670664@psf.upfronthosting.co.za>


Changes by Yotam Medini <yotam at users.sourceforge.net>:


Added file: http://bugs.python.org/file20232/dollar-extra.html

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

From report at bugs.python.org  Sun Jan  2 21:49:10 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sun, 02 Jan 2011 20:49:10 +0000
Subject: [issue8013] time.asctime segfaults when given a time in the far future
In-Reply-To: <1267031714.43.0.416052646257.issue8013@psf.upfronthosting.co.za>
Message-ID: <1294001350.5.0.30449969881.issue8013@psf.upfronthosting.co.za>


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

Committed in revision 87648.

----------

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

From report at bugs.python.org  Sun Jan  2 21:50:17 2011
From: report at bugs.python.org (Yotam Medini)
Date: Sun, 02 Jan 2011 20:50:17 +0000
Subject: [issue670664] HTMLParser.py - more robust SCRIPT tag parsing
Message-ID: <1294001417.32.0.877929614273.issue670664@psf.upfronthosting.co.za>


Yotam Medini <yotam at users.sourceforge.net> added the comment:

Suggested fix for the attached cases:
  lt-in-script-example.tgz
  endtag-space.html
  dollar-extra.html

----------
Added file: http://bugs.python.org/file20233/ltscr-endtag-dollarext.diff

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

From report at bugs.python.org  Sun Jan  2 21:54:36 2011
From: report at bugs.python.org (Gregory P. Smith)
Date: Sun, 02 Jan 2011 20:54:36 +0000
Subject: [issue10802] python3.2 AFTER b2 release has subprocess.Popen broken
	under colinux/windows
In-Reply-To: <1293926870.23.0.886180589728.issue10802@psf.upfronthosting.co.za>
Message-ID: <1294001676.44.0.601826002327.issue10802@psf.upfronthosting.co.za>


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

fixed r87651.

kaizhu if you still have the ability to run your colinux install with an old 2.6.26 kernel i'd appreciate it if you could explicitly test that the change does the right thing.

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

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

From report at bugs.python.org  Sun Jan  2 22:05:55 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 02 Jan 2011 21:05:55 +0000
Subject: [issue10475] hardcoded compilers for LDSHARED/LDCXXSHARED on NetBSD
In-Reply-To: <1293999435.14.0.91312010602.issue10475@psf.upfronthosting.co.za>
Message-ID: <1294002349.2662.1.camel@localhost.localdomain>


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

> $(CC) and $(CXX) should be expanded by `make`, but configure.in
> contains wrong quoting, which results in incorrect expansion during
> running `configure`.

Oops, sorry. Should be fixed, now.

----------

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

From report at bugs.python.org  Sun Jan  2 22:14:21 2011
From: report at bugs.python.org (SilentGhost)
Date: Sun, 02 Jan 2011 21:14:21 +0000
Subject: [issue8013] time.asctime segfaults when given a time in the far future
In-Reply-To: <1267031714.43.0.416052646257.issue8013@psf.upfronthosting.co.za>
Message-ID: <1294002861.19.0.146077722999.issue8013@psf.upfronthosting.co.za>


SilentGhost <michael.mischurow+bpo at gmail.com> added the comment:

Sasha, commit is not working. It doesn't pass test on Ubuntu and returns the string with a trailing \n. Seems like that hunk of code is misplaced.

----------
nosy: +SilentGhost

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

From report at bugs.python.org  Sun Jan  2 22:16:46 2011
From: report at bugs.python.org (Glenn Linderman)
Date: Sun, 02 Jan 2011 21:16:46 +0000
Subject: [issue4953] cgi module cannot handle POST with multipart/form-data in
	3.0
In-Reply-To: <1232010166.79.0.972664060868.issue4953@psf.upfronthosting.co.za>
Message-ID: <1294003006.72.0.978579722864.issue4953@psf.upfronthosting.co.za>


Glenn Linderman <v+python at g.nevcal.com> added the comment:

Pierre, thanks for your work on this.  I hope a fix can make it in to 3.2.

However, while starting Python with -u can help a but, that should not, in my opinion, be requirement to use CGI.  Rather, the stdin should be set into binary mode by the CGI processing... it would be helpful if the CGI module either did it automatically, verified it has been done, or at least provided a helper function that could do it, and that appropriate documentation be provided, if it is not automatic.  I've seen code like:

    try: # Windows needs stdio set for binary mode.
        import msvcrt
        msvcrt.setmode (0, os.O_BINARY) # stdin  = 0
        msvcrt.setmode (1, os.O_BINARY) # stdout = 1
        msvcrt.setmode (2, os.O_BINARY) # stderr = 2
    except ImportError:
        pass

and

        if hasattr( sys.stdin, 'buffer'):
            sys.stdin = sys.stdin.buffer

which together, seem to do the job.  For output, I use a little class that accepts either binary or text, encoding the latter:

    class IOMix():
        def __init__( self, fh, encoding="UTF-8"):
            if hasattr( fh, 'buffer'):
                self._bio = fh.buffer
                fh.flush()
                self._last = 'b'
                import io
                self._txt = io.TextIOWrapper( self.bio, encoding, None, '\r\n')
                self._encoding = encoding
            else:
                raise ValueError("not a buffered stream")
        def write( self, param ):
            if isinstance( param, str ):
                self._last = 't'
                self._txt.write( param )
            else:
                if self._last == 't':
                    self._txt.flush()
                self._last = 'b'
                self._bio.write( param )
        def flush( self ):
            self._txt.flush()
        def close( self ):
            self.flush()
            self._txt.close()
            self._bio.close()


        sys.stdout = IOMix( sys.stdout, encoding )
        sys.stderr = IOMix( sys.stderr, encoding )


IOMix may need a few more methods for general use, "print" comes to mind, for example.

----------

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

From report at bugs.python.org  Sun Jan  2 22:19:42 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 02 Jan 2011 21:19:42 +0000
Subject: [issue10806] Subprocess error if fds 0,1,2 are closed
In-Reply-To: <1293991717.46.0.660046429073.issue10806@psf.upfronthosting.co.za>
Message-ID: <1294003182.51.0.504073770721.issue10806@psf.upfronthosting.co.za>


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

This further patch also addresses issue9905 (incorporating Ross' tests).

----------
Added file: http://bugs.python.org/file20234/sp2.patch

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

From report at bugs.python.org  Sun Jan  2 22:20:58 2011
From: report at bugs.python.org (Oren Held)
Date: Sun, 02 Jan 2011 21:20:58 +0000
Subject: [issue10800] libffi build failure on HP-UX 11/PA
In-Reply-To: <1293780948.24.0.107395792812.issue10800@psf.upfronthosting.co.za>
Message-ID: <1294003258.94.0.916894688454.issue10800@psf.upfronthosting.co.za>


Oren Held <oren at held.org.il> added the comment:

I confirm that on Python 2.7.1, on HP-UX 11.31, ia64 architecture).

dlmalloc.c is the problematic file, a part of libffi.

I reported the same problem and solution + patch in here:
http://sourceware.org/ml/libffi-discuss/2010/msg00203.html

----------
nosy: +Oren_Held
versions: +Python 2.7

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

From report at bugs.python.org  Sun Jan  2 22:21:24 2011
From: report at bugs.python.org (Steven Bethard)
Date: Sun, 02 Jan 2011 21:21:24 +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: <1294003284.23.0.637126214999.issue10772@psf.upfronthosting.co.za>


Steven Bethard <steven.bethard at gmail.com> added the comment:

action="help" definitely needs to be documented

action="count" probably should be, though I think it's pretty useless (I just copied it from optparse)

action="parsers", nargs="..." and nargs="A..." I'm not so sure about. These are currently kind of implementation details.

----------

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

From report at bugs.python.org  Sun Jan  2 22:21:32 2011
From: report at bugs.python.org (Andrew Dalke)
Date: Sun, 02 Jan 2011 21:21:32 +0000
Subject: [issue10809] complex() comments wrongly say it supports NaN and inf
In-Reply-To: <1294003292.33.0.779224851357.issue10809@psf.upfronthosting.co.za>
Message-ID: <1294003292.33.0.779224851357.issue10809@psf.upfronthosting.co.za>


New submission from Andrew Dalke <dalke at dalkescientific.com>:

complex("nan") raises "ValueError: complex() arg is a malformed string"  while complex(float("nan")) returns (nan+0j). This was reported in http://bugs.python.org/issue2121 with the conclusion "wont fix".

complex("inf") has the same behaviors.

The implementation in complexobject.c says 


    /* a valid complex string usually takes one of the three forms:

         <float>                  - real part only
         <float>j                 - imaginary part only
         <float><signed-float>j   - real and imaginary parts

       where <float> represents any numeric string that's accepted by the
       float constructor (including 'nan', 'inf', 'infinity', etc.), and
       <signed-float> is any string of the form <float> whose first
       character is '+' or '-'.

This comment is wrong and it distracted me for a while as I tried to figure out why complex("nan") wasn't working. It should be fixed, with the word "including" replaced by "excluding".

I don't have a real need for complex("nan") support - this was of intellectual interest only. Also of intellectual interest, PyPy 1.4 does accept complex("nan") but converts complex("nan+nanj") to (nannanj), so it suffers from the strange corner cases which Raymond points out when advocating for "wont fix."

Because

----------
assignee: docs at python
components: Documentation
messages: 125104
nosy: dalke, docs at python
priority: normal
severity: normal
status: open
title: complex() comments wrongly say it supports NaN and inf
versions: Python 2.7

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

From report at bugs.python.org  Sun Jan  2 22:24:01 2011
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 02 Jan 2011 21:24:01 +0000
Subject: [issue10808] ssl unwrap fails with Error 0
In-Reply-To: <1293997937.94.0.348375754935.issue10808@psf.upfronthosting.co.za>
Message-ID: <1294003441.87.0.231005622715.issue10808@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Sun Jan  2 22:24:09 2011
From: report at bugs.python.org (Peter Kleiweg)
Date: Sun, 02 Jan 2011 21:24:09 +0000
Subject: [issue4953] cgi module cannot handle POST with multipart/form-data in
	3.0
In-Reply-To: <1232010166.79.0.972664060868.issue4953@psf.upfronthosting.co.za>
Message-ID: <1294003449.16.0.24123361018.issue4953@psf.upfronthosting.co.za>


Peter Kleiweg <pkleiweg at xs4all.nl> added the comment:

Why not simply:

fp = sys.stdin.detach()

----------

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

From report at bugs.python.org  Sun Jan  2 22:28:00 2011
From: report at bugs.python.org (Pierre Quentel)
Date: Sun, 02 Jan 2011 21:28:00 +0000
Subject: [issue4953] cgi module cannot handle POST with multipart/form-data in
	3.0
In-Reply-To: <1232010166.79.0.972664060868.issue4953@psf.upfronthosting.co.za>
Message-ID: <1294003680.96.0.467565047153.issue4953@psf.upfronthosting.co.za>


Pierre Quentel <pierre.quentel at gmail.com> added the comment:

Here is the correct diff file

I also introduced a test to exit from the loop in read_multi() if the total number of bytes read reaches "content-length". It was necessary for my framework, which uses cgi.FieldStorage to read from the attribute rfile defined in socketserver. Without this patch, the program hangs after receiving the number of bytes specified in content length. I work on a Windows XP PC so it might be related to the bug #427345 handled by server.CGIHTTPRequestHandler.run_cgi()

----------
Added file: http://bugs.python.org/file20235/cgi_diff.txt

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

From report at bugs.python.org  Sun Jan  2 22:32:11 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 02 Jan 2011 21:32:11 +0000
Subject: [issue10806] Subprocess error if fds 0,1,2 are closed
In-Reply-To: <1293991717.46.0.660046429073.issue10806@psf.upfronthosting.co.za>
Message-ID: <1294003931.02.0.852675855537.issue10806@psf.upfronthosting.co.za>


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

See also #6610 which has a patch with another test.

----------
nosy: +haypo

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

From report at bugs.python.org  Sun Jan  2 22:37:00 2011
From: report at bugs.python.org (Glenn Linderman)
Date: Sun, 02 Jan 2011 21:37:00 +0000
Subject: [issue4953] cgi module cannot handle POST with multipart/form-data in
	3.0
In-Reply-To: <1232010166.79.0.972664060868.issue4953@psf.upfronthosting.co.za>
Message-ID: <1294004220.57.0.853154582356.issue4953@psf.upfronthosting.co.za>


Glenn Linderman <v+python at g.nevcal.com> added the comment:

Regarding the use of detach(), I don't know if it works.  Maybe it would.  I know my code works, because I have it working.  But if there are simpler solutions that are shown to work, that would be great.

----------

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

From report at bugs.python.org  Sun Jan  2 22:54:00 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 02 Jan 2011 21:54:00 +0000
Subject: [issue8013] time.asctime segfaults when given a time in the far future
In-Reply-To: <1267031714.43.0.416052646257.issue8013@psf.upfronthosting.co.za>
Message-ID: <1294005240.47.0.485203233664.issue8013@psf.upfronthosting.co.za>


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

> Sasha, commit is not working.

I suppose that the fix for the segfault is correct. The problem on Linux is the new test: asc

>>> import time; time.asctime((12345, 1, 0, 0, 0, 0, 0, 0, 0))
'Mon Jan  1 00:00:00 12345\n'

asctime() of the GNU libc doesn't fail. The test should maybe just calls the function without checking the result and ignores the exception.

----------
nosy: +haypo

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

From report at bugs.python.org  Sun Jan  2 22:54:08 2011
From: report at bugs.python.org (kai zhu)
Date: Sun, 02 Jan 2011 21:54:08 +0000
Subject: [issue10802] python3.2 AFTER b2 release has subprocess.Popen broken
	under colinux/windows
In-Reply-To: <1293926870.23.0.886180589728.issue10802@psf.upfronthosting.co.za>
Message-ID: <1294005248.57.0.418156613725.issue10802@psf.upfronthosting.co.za>


kai zhu <kaizhu256 at gmail.com> added the comment:

re-tested under old 2.6.26 kernel using previous foo.py example:

1. unpatched python3.2 broken as expected
2. patched   python3.2 now works :)

strace confirms ENOSYS being raised from pipe2() in both cases

----------

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

From report at bugs.python.org  Sun Jan  2 23:20:52 2011
From: report at bugs.python.org (Ron Adam)
Date: Sun, 02 Jan 2011 22:20:52 +0000
Subject: [issue10716] Modernize pydoc to use CSS
In-Reply-To: <1292491539.55.0.135732310832.issue10716@psf.upfronthosting.co.za>
Message-ID: <1294006852.39.0.763747915098.issue10716@psf.upfronthosting.co.za>


Ron Adam <ron_adam at users.sourceforge.net> added the comment:

> If the colors are passed directly to the HTML they should be
> removed >and left to the CSS(s) only. I don't know the code
> well enough to say if this is doable and/or if it requires a
> deprecation first;

We may have to do dome depreciating when it comes to the old HTMLDoc class methods.  Would it be possible to depreciate the whole class instead of the separate methods?  If so, it would be good if we can squeeze that into 3.2. <hint hint>  Or else we may not be able to finish this until Python 3.4.

The empty css elements will be used later.

Here is the css_v3.diff for review.  I'd like to hear any thoughts about the general html structure and class/id names.

Beside validating them, I test with firefox and chromium. I don't have easy access to ms-explorer or the current mac browser.

----------
Added file: http://bugs.python.org/file20236/css_v3.diff

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

From report at bugs.python.org  Sun Jan  2 23:35:13 2011
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 02 Jan 2011 22:35:13 +0000
Subject: [issue8013] time.asctime segfaults when given a time in the far future
In-Reply-To: <1267031714.43.0.416052646257.issue8013@psf.upfronthosting.co.za>
Message-ID: <1294007713.38.0.577657917241.issue8013@psf.upfronthosting.co.za>


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

Tests fixed to ignore ValueError in r87656.

Both asctime() and ctime() fixed to remove newline no matter how many digits the year has in r87657.  I also took the liberty of making the error messages consistent.

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

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

From report at bugs.python.org  Sun Jan  2 23:40:54 2011
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 02 Jan 2011 22:40:54 +0000
Subject: [issue10716] Modernize pydoc to use CSS
In-Reply-To: <1292491539.55.0.135732310832.issue10716@psf.upfronthosting.co.za>
Message-ID: <1294008054.29.0.224439849492.issue10716@psf.upfronthosting.co.za>


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

These arguments should not really be of concern.  If we indeed deem them public API, they can stay but be ignored.

----------

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

From report at bugs.python.org  Sun Jan  2 23:43:32 2011
From: report at bugs.python.org (Peter Kleiweg)
Date: Sun, 02 Jan 2011 22:43:32 +0000
Subject: [issue4953] cgi module cannot handle POST with multipart/form-data in
	3.0
In-Reply-To: <1232010166.79.0.972664060868.issue4953@psf.upfronthosting.co.za>
Message-ID: <1294008212.18.0.633731897324.issue4953@psf.upfronthosting.co.za>


Peter Kleiweg <pkleiweg at xs4all.nl> added the comment:

Using platform-dependant code seems iffy to me. The detach function on sys.stdin, sys,stdout and sys.stderr is there specifically to switch these streams from text mode to binary mode. See: http://docs.python.org/py3k/library/sys.html#sys.stdin

----------

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

From report at bugs.python.org  Sun Jan  2 23:48:56 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sun, 02 Jan 2011 22:48:56 +0000
Subject: [issue8278] os.utime doesn't allow a atime (Last Access) which is 27
	years in the future.
In-Reply-To: <1270107966.42.0.283455861085.issue8278@psf.upfronthosting.co.za>
Message-ID: <1294008536.36.0.165437590712.issue8278@psf.upfronthosting.co.za>


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

Here is a renewed patch against py3k, with a test.

----------
Added file: http://bugs.python.org/file20237/timet_64-2.patch

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

From report at bugs.python.org  Sun Jan  2 23:50:31 2011
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sun, 02 Jan 2011 22:50:31 +0000
Subject: [issue10810] logging.handlers.TimedRotatingFileHandler.__init__():
	ST_MTIME NameError
In-Reply-To: <1294008631.29.0.376698831209.issue10810@psf.upfronthosting.co.za>
Message-ID: <1294008631.29.0.376698831209.issue10810@psf.upfronthosting.co.za>


New submission from Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:

r82912 introduced NameError for ST_MTIME in Lib/logging/handlers.py on 3.1 branch. It's a regression in 3.1.3. The code in 3.2 is correct.

-from stat import ST_DEV, ST_INO
+from stat import ST_DEV, ST_INO, ST_MTIME

This bug was originally reported in Gentoo Bugzilla:
https://bugs.gentoo.org/show_bug.cgi?id=350400

----------
components: Library (Lib)
messages: 125116
nosy: Arfrever, vinay.sajip
priority: normal
severity: normal
status: open
title: logging.handlers.TimedRotatingFileHandler.__init__(): ST_MTIME NameError
versions: Python 3.1

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

From report at bugs.python.org  Sun Jan  2 23:53:48 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sun, 02 Jan 2011 22:53:48 +0000
Subject: [issue8013] time.asctime segfaults when given a time in the far future
In-Reply-To: <1294007713.38.0.577657917241.issue8013@psf.upfronthosting.co.za>
Message-ID: <AANLkTikpGkYYDCjqjzzgCSbzp73ks=krKbmBTvd3Mhc2@mail.gmail.com>


Alexander Belopolsky <alexander.belopolsky at gmail.com> added the comment:

On Sun, Jan 2, 2011 at 5:35 PM, Georg Brandl <report at bugs.python.org> wrote:
..
> Both asctime() and ctime() fixed to remove newline no matter how many
> digits the year has in r87657. ?I also took the liberty of making the error
> messages consistent.

Georg,

I disagree with your solution.  According to relevant standards,
asctime is undefined for year > 9999.  A compliant implementation can
do anything in this case including not null-terminating the internal
buffer.  With your change, time.strftime  will happily replace the
first unrelated '\n' with '\0' that it will find beyond the internal
buffer.

I was considering raising an ValueError if '\n' is not found at 24th
position, but this (or a precondition check solution) should wait
until 3.3.

----------

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

From report at bugs.python.org  Sun Jan  2 23:55:38 2011
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 02 Jan 2011 22:55:38 +0000
Subject: [issue10810] logging.handlers.TimedRotatingFileHandler.__init__():
	ST_MTIME NameError
In-Reply-To: <1294008631.29.0.376698831209.issue10810@psf.upfronthosting.co.za>
Message-ID: <1294008938.71.0.141786160861.issue10810@psf.upfronthosting.co.za>


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

Thanks, fixed in r87660.

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

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

From report at bugs.python.org  Mon Jan  3 00:01:22 2011
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 02 Jan 2011 23:01:22 +0000
Subject: [issue8013] time.asctime segfaults when given a time in the far future
In-Reply-To: <1267031714.43.0.416052646257.issue8013@psf.upfronthosting.co.za>
Message-ID: <1294009282.92.0.714851448688.issue8013@psf.upfronthosting.co.za>


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

In that case however, it's equally unsafe to not replace a \n, but still use PyUnicode_FromString() without a size given -- you will read from random memory.

Since all implementations we have or can test have a defined behavior in one way or the other, I think an example of an implementation that exhibits such undefined behavior is required first.

----------

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

From report at bugs.python.org  Mon Jan  3 00:06:10 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sun, 02 Jan 2011 23:06:10 +0000
Subject: [issue8013] time.asctime segfaults when given a time in the far future
In-Reply-To: <1294009282.92.0.714851448688.issue8013@psf.upfronthosting.co.za>
Message-ID: <AANLkTi=Wvb472XF5A2MQi0rtt4dGSMMZWd+KJj=OgJ4N@mail.gmail.com>


Alexander Belopolsky <alexander.belopolsky at gmail.com> added the comment:

On Sun, Jan 2, 2011 at 6:01 PM, Georg Brandl <report at bugs.python.org> wrote:
..
>
> Since all implementations we have or can test have a defined behavior in one way or the other,
> I think an example of an implementation that exhibits such undefined behavior is required first.

No.  A CERT recommendation on how to write secure and portable code
should be enough.  See msg107605.

----------

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

From report at bugs.python.org  Mon Jan  3 00:10:32 2011
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 02 Jan 2011 23:10:32 +0000
Subject: [issue8013] time.asctime segfaults when given a time in the far future
In-Reply-To: <1267031714.43.0.416052646257.issue8013@psf.upfronthosting.co.za>
Message-ID: <1294009832.71.0.404652544037.issue8013@psf.upfronthosting.co.za>


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

All right, then I wonder why your checktm() doesn't check the tm_year?

----------

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

From report at bugs.python.org  Mon Jan  3 00:15:47 2011
From: report at bugs.python.org (Ron Adam)
Date: Sun, 02 Jan 2011 23:15:47 +0000
Subject: [issue10716] Modernize pydoc to use CSS
In-Reply-To: <1292491539.55.0.135732310832.issue10716@psf.upfronthosting.co.za>
Message-ID: <1294010147.03.0.807743171832.issue10716@psf.upfronthosting.co.za>


Ron Adam <ron_adam at users.sourceforge.net> added the comment:

To go forward I can create a new private api instead of changing HTMLDoc, that would be preferable.

Should the -w option also use the new html pages?  Or do we need a new option for that?

----------

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

From report at bugs.python.org  Mon Jan  3 00:17:47 2011
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 02 Jan 2011 23:17:47 +0000
Subject: [issue8013] time.asctime segfaults when given a time in the far future
In-Reply-To: <1267031714.43.0.416052646257.issue8013@psf.upfronthosting.co.za>
Message-ID: <1294010267.46.0.830315998728.issue8013@psf.upfronthosting.co.za>


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

(What I mean is that overwriting \n or not, the code is unsafe, so the check must be done beforehand.  Why should that be left to 3.3?)

----------

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

From report at bugs.python.org  Mon Jan  3 00:18:50 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sun, 02 Jan 2011 23:18:50 +0000
Subject: [issue8013] time.asctime segfaults when given a time in the far future
In-Reply-To: <1294009832.71.0.404652544037.issue8013@psf.upfronthosting.co.za>
Message-ID: <AANLkTikarB1MtTY-Sz_ScgjJOvo-m3hc+FTov6Y89kDV@mail.gmail.com>


Alexander Belopolsky <alexander.belopolsky at gmail.com> added the comment:

On Sun, Jan 2, 2011 at 6:10 PM, Georg Brandl <report at bugs.python.org> wrote:
..
> All right, then I wonder why your checktm() doesn't check the tm_year?

It is not mine.  I thought it did.  I might have missed that when I
reviewed the patch or there was a reason for that at the time.  Note
that there is a comment that says:

"""
tm_year: [0, max(int)] (1)
..
(1) gettmarg() handles bounds-checking.
"""

If you are ok with introducing stricter bounds checking in beta, I'll
try to get to the bottom of it shortly.

----------

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

From report at bugs.python.org  Mon Jan  3 00:22:45 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sun, 02 Jan 2011 23:22:45 +0000
Subject: [issue8013] time.asctime segfaults when given a time in the far future
In-Reply-To: <1294010267.46.0.830315998728.issue8013@psf.upfronthosting.co.za>
Message-ID: <AANLkTi=gMMzGZN_s=hj3oCu50dZqDja4obB9cbVfWVpH@mail.gmail.com>


Alexander Belopolsky <alexander.belopolsky at gmail.com> added the comment:

On Sun, Jan 2, 2011 at 6:17 PM, Georg Brandl <report at bugs.python.org> wrote:
..
> (What I mean is that overwriting \n or not, the code is unsafe, so the check must be
> done beforehand. ?Why should that be left to 3.3?)

Reading beyond a buffer is somewhat safer than writing, but I agree
that checks must be done before calling asctime/ctime.   I thought it
would have to wait because it is a feature.  Some Linux users may
expect year 10000 to work.  (Maybe as a sentinel value somewhere.)
But you are the RM, so it is your call.

----------

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

From report at bugs.python.org  Mon Jan  3 00:29:16 2011
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 02 Jan 2011 23:29:16 +0000
Subject: [issue8013] time.asctime segfaults when given a time in the far future
In-Reply-To: <1267031714.43.0.416052646257.issue8013@psf.upfronthosting.co.za>
Message-ID: <1294010956.93.0.342939520634.issue8013@psf.upfronthosting.co.za>


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

You cannot have both: a safe implementation and the correct behavior with glibc (not Linux!) -- except if you start special-casing.  Not sure that's worth it.

Note that time.asctime() is documented in time.rst to return a 24-character string, so what it currently returns with glibc is violating our docs as well.

----------

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

From report at bugs.python.org  Mon Jan  3 00:35:26 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 02 Jan 2011 23:35:26 +0000
Subject: [issue8278] os.utime doesn't allow a atime (Last Access) which is 27
	years in the future.
In-Reply-To: <1270107966.42.0.283455861085.issue8278@psf.upfronthosting.co.za>
Message-ID: <1294011326.5.0.970467743435.issue8278@psf.upfronthosting.co.za>


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

The patch looks still fine. The only concern is that the test probably fails on FAT, but I think that's acceptable.

----------

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

From report at bugs.python.org  Mon Jan  3 00:37:34 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 02 Jan 2011 23:37:34 +0000
Subject: [issue10810] logging.handlers.TimedRotatingFileHandler.__init__():
	ST_MTIME NameError
In-Reply-To: <1294008631.29.0.376698831209.issue10810@psf.upfronthosting.co.za>
Message-ID: <1294011454.7.0.636971308083.issue10810@psf.upfronthosting.co.za>


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

Hmm. I wonder why the code doesn't use the st_mtime field. We should really deprecate the stat module.

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

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

From report at bugs.python.org  Mon Jan  3 00:38:02 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sun, 02 Jan 2011 23:38:02 +0000
Subject: [issue8278] os.utime doesn't allow a atime (Last Access) which is 27
	years in the future.
In-Reply-To: <1270107966.42.0.283455861085.issue8278@psf.upfronthosting.co.za>
Message-ID: <1294011481.99.0.522949362138.issue8278@psf.upfronthosting.co.za>


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

> The only concern is that the test probably fails on FAT
The patch does not show it, but I've put the test under a
'if get_file_system(support.TESTFN) == "NTFS"'

----------

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

From report at bugs.python.org  Mon Jan  3 00:43:16 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sun, 02 Jan 2011 23:43:16 +0000
Subject: [issue8013] time.asctime segfaults when given a time in the far future
In-Reply-To: <1294010956.93.0.342939520634.issue8013@psf.upfronthosting.co.za>
Message-ID: <AANLkTimj3KBu7=DL1E3QKP=u18nXLE4GX_bGQtcEOw-o@mail.gmail.com>


Alexander Belopolsky <alexander.belopolsky at gmail.com> added the comment:

On Sun, Jan 2, 2011 at 6:29 PM, Georg Brandl <report at bugs.python.org> wrote:
..
> You cannot have both: a safe implementation and the correct behavior with glibc
> (not Linux!) -- except if you start special-casing. ?Not sure that's worth it.
>
That's the reason why this and the related ctime issue were lingering
for so long.

My plan was to pick the low-hanging fruit (the null check) for 3.3 and
leave proper bounds checking and possibly switch to reentrant APIs for
the next release.   There is a long tradition in keeping OS functions'
wrappers thin with an expectation that application programmers will
know the limitations/quirks of their target OSes.  Given that datetime
module does not have these issues, I don't see this as "must fix."

----------

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

From report at bugs.python.org  Mon Jan  3 00:43:44 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sun, 02 Jan 2011 23:43:44 +0000
Subject: [issue8013] time.asctime segfaults when given a time in the far future
In-Reply-To: <AANLkTimj3KBu7=DL1E3QKP=u18nXLE4GX_bGQtcEOw-o@mail.gmail.com>
Message-ID: <AANLkTi=iq=rcmyxezhi8qzjBDc3XF=RRoAtpYoB-pw4e@mail.gmail.com>


Alexander Belopolsky <alexander.belopolsky at gmail.com> added the comment:

..
> My plan was to pick the low-hanging fruit (the null check) for 3.3 and

s/3.3/3.2/

----------

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

From report at bugs.python.org  Mon Jan  3 00:46:37 2011
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 02 Jan 2011 23:46:37 +0000
Subject: [issue8013] time.asctime segfaults when given a time in the far future
In-Reply-To: <1267031714.43.0.416052646257.issue8013@psf.upfronthosting.co.za>
Message-ID: <1294011997.61.0.317224980492.issue8013@psf.upfronthosting.co.za>


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

> There is a long tradition in keeping OS functions'
> wrappers thin with an expectation that application programmers will
> know the limitations/quirks of their target OSes.

Sorry, but that does not apply if we trigger undefined behavior which
is inherently unsafe, as you rightly insist.

I don't see the range checking as particularly challenging; I'm sure you can get it done in time for 3.2.

----------

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

From report at bugs.python.org  Mon Jan  3 00:48:29 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sun, 02 Jan 2011 23:48:29 +0000
Subject: [issue8013] time.asctime segfaults when given a time in the far future
In-Reply-To: <1294011997.61.0.317224980492.issue8013@psf.upfronthosting.co.za>
Message-ID: <AANLkTi=R0xvUROimM=sdSH8uVr-m7K8tJXbTSZHFup_m@mail.gmail.com>


Alexander Belopolsky <alexander.belopolsky at gmail.com> added the comment:

On Sun, Jan 2, 2011 at 6:46 PM, Georg Brandl <report at bugs.python.org> wrote:
..
> I don't see the range checking as particularly challenging; I'm sure you can get it done in time for 3.2.

Will do.

----------

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

From report at bugs.python.org  Mon Jan  3 00:52:10 2011
From: report at bugs.python.org (SilentGhost)
Date: Sun, 02 Jan 2011 23:52:10 +0000
Subject: [issue8013] time.asctime segfaults when given a time in the far future
In-Reply-To: <1267031714.43.0.416052646257.issue8013@psf.upfronthosting.co.za>
Message-ID: <1294012330.92.0.197462573758.issue8013@psf.upfronthosting.co.za>


SilentGhost <michael.mischurow+bpo at gmail.com> added the comment:

I'm not sure that whether it's related to the current issue, but asctime doesn't seem to accept years < 1900. Which might be fair enough, has this been documented.

----------

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

From report at bugs.python.org  Mon Jan  3 00:52:44 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 02 Jan 2011 23:52:44 +0000
Subject: [issue7995] On Mac / BSD sockets returned by accept inherit the
	parent's FD flags
In-Reply-To: <1266876583.45.0.97810567794.issue7995@psf.upfronthosting.co.za>
Message-ID: <1294012364.96.0.87043740472.issue7995@psf.upfronthosting.co.za>


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

I like the logic of Antoine's patch much better (basing this on whether the listening socket had a timeout). I wonder whether it's correct though if there is a defaulttimeout: shouldn't it then leave the timeout on the socket instead?

----------

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

From report at bugs.python.org  Mon Jan  3 00:54:30 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 02 Jan 2011 23:54:30 +0000
Subject: [issue10798] test_concurrent_futures fails on FreeBSD
In-Reply-To: <1293740054.42.0.931376139757.issue10798@psf.upfronthosting.co.za>
Message-ID: <1294012470.17.0.687179220156.issue10798@psf.upfronthosting.co.za>


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

Is this really the time for restructuring tests? I think such activity should wait until after the 3.2 release.

----------

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

From report at bugs.python.org  Mon Jan  3 00:57:03 2011
From: report at bugs.python.org (=?utf-8?q?Andreas_St=C3=BChrk?=)
Date: Sun, 02 Jan 2011 23:57:03 +0000
Subject: [issue8013] time.asctime segfaults when given a time in the far future
In-Reply-To: <1267031714.43.0.416052646257.issue8013@psf.upfronthosting.co.za>
Message-ID: <1294012623.24.0.313560061476.issue8013@psf.upfronthosting.co.za>


Andreas St?hrk <andy-python at hammerhartes.de> added the comment:

It's documented under "Year 2000 (Y2K) issues": http://docs.python.org/library/time.html#time-y2kissues

----------

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

From report at bugs.python.org  Mon Jan  3 01:02:27 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 03 Jan 2011 00:02:27 +0000
Subject: [issue8013] time.asctime segfaults when given a time in the far future
In-Reply-To: <1267031714.43.0.416052646257.issue8013@psf.upfronthosting.co.za>
Message-ID: <1294012947.93.0.785881229399.issue8013@psf.upfronthosting.co.za>


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

Backported in r87664 (2.6), r87663 (2.7) and r87662 (3.1).

Reopening to implement bounds checking for 3.2.  Note that for time.asctime, checking the year range is trivial, but for time.ctime it is not because year is not computed in python code.  One solution may be to check bounds of the time_t timestamp, but those depend on the timezone.  Maybe it is easiest to simply call mktime(), check year and call asctime() bypassing OS ctime completely.

----------
components: +Extension Modules -Library (Lib)
nosy:  -Alexander.Belopolsky
resolution: fixed -> 
stage: patch review -> needs patch
status: closed -> open
type: crash -> behavior
versions:  -Python 2.7, Python 3.1

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

From report at bugs.python.org  Mon Jan  3 01:03:42 2011
From: report at bugs.python.org (SilentGhost)
Date: Mon, 03 Jan 2011 00:03:42 +0000
Subject: [issue8013] time.asctime segfaults when given a time in the far future
In-Reply-To: <1267031714.43.0.416052646257.issue8013@psf.upfronthosting.co.za>
Message-ID: <1294013022.16.0.333236182208.issue8013@psf.upfronthosting.co.za>


SilentGhost <michael.mischurow+bpo at gmail.com> added the comment:

yes, sorry. what I meant to say is that fixing only upper bound for the year (according to CERT recommendation cited above) and leaving the lower bound in its current state is somewhat unsatisfactory.

----------

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

From report at bugs.python.org  Mon Jan  3 01:04:10 2011
From: report at bugs.python.org (Brian Quinlan)
Date: Mon, 03 Jan 2011 00:04:10 +0000
Subject: [issue10798] test_concurrent_futures fails on FreeBSD
In-Reply-To: <1293740054.42.0.931376139757.issue10798@psf.upfronthosting.co.za>
Message-ID: <1294013050.16.0.912595606009.issue10798@psf.upfronthosting.co.za>


Brian Quinlan <brian at sweetapp.com> added the comment:

The tests are currently flaky on Windows and I'd like to fix that before the release. But I don't have the bandwidth to debug the Call() abstraction used in the tests before 3.2 RC1.

You can see the test change here:
http://svn.python.org/view/python/branches/py3k-futures-on-windows/Lib/test/test_concurrent_futures.py?r1=87484&r2=87652

So far it is passing on all the platforms that I've tested it on (Mac OS X, Ubuntu and Windows 7).

----------

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

From report at bugs.python.org  Mon Jan  3 01:08:59 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 03 Jan 2011 00:08:59 +0000
Subject: [issue10798] test_concurrent_futures fails on FreeBSD
In-Reply-To: <1293740054.42.0.931376139757.issue10798@psf.upfronthosting.co.za>
Message-ID: <1294013339.7.0.608228540929.issue10798@psf.upfronthosting.co.za>


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

Thanks for the review, committed as r87665. Fixing flaky tests is fine, of course.

----------

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

From report at bugs.python.org  Mon Jan  3 01:22:09 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 03 Jan 2011 00:22:09 +0000
Subject: [issue10798] test_concurrent_futures fails on FreeBSD
In-Reply-To: <1293740054.42.0.931376139757.issue10798@psf.upfronthosting.co.za>
Message-ID: <1294014129.7.0.315880970143.issue10798@psf.upfronthosting.co.za>


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

Follow-up: I have disabled test_all_completed_some_already_completed in r87667, as I couldn't figure out why it hangs.

----------

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

From report at bugs.python.org  Mon Jan  3 01:23:56 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 03 Jan 2011 00:23:56 +0000
Subject: [issue8278] os.utime doesn't allow a atime (Last Access) which is 27
	years in the future.
In-Reply-To: <1270107966.42.0.283455861085.issue8278@psf.upfronthosting.co.za>
Message-ID: <1294014236.41.0.129392680383.issue8278@psf.upfronthosting.co.za>


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

Committed r87666 (py3k), I'll backport to 3.1 and 2.7.

----------
resolution: accepted -> fixed
status: open -> pending

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

From report at bugs.python.org  Mon Jan  3 01:50:08 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Mon, 03 Jan 2011 00:50:08 +0000
Subject: [issue10810] logging.handlers.TimedRotatingFileHandler.__init__():
	ST_MTIME NameError
In-Reply-To: <1294008631.29.0.376698831209.issue10810@psf.upfronthosting.co.za>
Message-ID: <1294015808.56.0.923312357947.issue10810@psf.upfronthosting.co.za>


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

It's just old code which just never got changed. I will change 3.2 to use the posix.stat_result attributes and remove the stat import, but I'll wait until after 3.2 is released.

----------

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

From report at bugs.python.org  Mon Jan  3 01:51:04 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Mon, 03 Jan 2011 00:51:04 +0000
Subject: [issue10810] logging.handlers.TimedRotatingFileHandler.__init__():
	ST_MTIME NameError
In-Reply-To: <1294008631.29.0.376698831209.issue10810@psf.upfronthosting.co.za>
Message-ID: <1294015864.1.0.542356962156.issue10810@psf.upfronthosting.co.za>


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

Er, I meant to say "I'll change py3k ... after 3.2 is released".

----------

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

From report at bugs.python.org  Mon Jan  3 01:52:09 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 03 Jan 2011 00:52:09 +0000
Subject: [issue8278] os.utime doesn't allow a atime (Last Access) which is 27
	years in the future.
In-Reply-To: <1270107966.42.0.283455861085.issue8278@psf.upfronthosting.co.za>
Message-ID: <1294015929.48.0.706489233996.issue8278@psf.upfronthosting.co.za>


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

Merged into release31-maint (r87668) and release27-maint (r87669)

----------
status: pending -> closed

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

From report at bugs.python.org  Mon Jan  3 02:31:44 2011
From: report at bugs.python.org (Andrew Dalke)
Date: Mon, 03 Jan 2011 01:31:44 +0000
Subject: [issue10809] complex() comments wrongly say it supports NaN and inf
In-Reply-To: <1294003292.33.0.779224851357.issue10809@psf.upfronthosting.co.za>
Message-ID: <1294018304.1.0.227364194166.issue10809@psf.upfronthosting.co.za>


Andrew Dalke <dalke at dalkescientific.com> added the comment:

Well that's ... interesting. While I compiled 2.7 and was looking at the 2.7 code my tests were against 2.6. 


Python 2.7 (trunk:74969:87651M, Jan  2 2011, 21:58:12) 
[GCC 4.2.1 (Apple Inc. build 5664)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> complex("nan-nanj")
(nan+nanj)
>>> 

This means that the comments are correct and the error was in my understanding, as influenced by issue2121.

I therefore closed this.

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

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

From report at bugs.python.org  Mon Jan  3 02:33:48 2011
From: report at bugs.python.org (Erick Tryzelaar)
Date: Mon, 03 Jan 2011 01:33:48 +0000
Subject: [issue10811] sqlite segfault with generators
In-Reply-To: <1294018427.94.0.141740646278.issue10811@psf.upfronthosting.co.za>
Message-ID: <1294018427.94.0.141740646278.issue10811@psf.upfronthosting.co.za>


New submission from Erick Tryzelaar <erick.tryzelaar at gmail.com>:

I found that the sqlite3 function executemany module crashes when passed in a generator that it iself is executing a query. It looks like this confuses the statement cache, and causes it to get cleared inappropriately in this case.

I've attached a file that exhibits the problem, which results in this stack trace:

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x0000000000000028
pysqlite_statement_mark_dirty (self=0x0) at /Users/Shared/erickt/Projects/py3k/Modules/_sqlite/statement.c:367
367	    self->in_use = 1;
(gdb) bt
#0  pysqlite_statement_mark_dirty (self=0x0) at /Users/Shared/erickt/Projects/py3k/Modules/_sqlite/statement.c:367
#1  0x000000010067e125 in _pysqlite_query_execute (self=0x100568880, multiple=1, args=<value temporarily unavailable, due to optimizations>) at /Users/Shared/erickt/Projects/py3k/Modules/_sqlite/cursor.c:625
#2  0x00000001000af6a2 in PyEval_EvalFrameEx (f=0x1003579f0, throwflag=<value temporarily unavailable, due to optimizations>) at Python/ceval.c:3874
#3  0x00000001000b000a in PyEval_EvalCodeEx (_co=0x1004977a0, globals=<value temporarily unavailable, due to optimizations>, locals=<value temporarily unavailable, due to optimizations>, args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0, defcount=0, kwdefs=0x0, closure=0x0) at Python/ceval.c:3310
#4  0x00000001000b031f in PyEval_EvalCode (co=<value temporarily unavailable, due to optimizations>, globals=<value temporarily unavailable, due to optimizations>, locals=<value temporarily unavailable, due to optimizations>) at Python/ceval.c:760
#5  0x00000001000d71eb in run_mod [inlined] () at /Users/Shared/erickt/Projects/py3k/Python/pythonrun.c:1759
#6  0x00000001000d71eb in PyRun_FileExFlags (fp=0x7fff703f6f40, filename=0x1005c9190 "/Users/erickt/sqlite-crash.py", start=<value temporarily unavailable, due to optimizations>, globals=0x100325220, locals=0x100325220, closeit=1, flags=0x7fff5fbfef90) at Python/pythonrun.c:1716
#7  0x00000001000d74b9 in PyRun_SimpleFileExFlags (fp=0x7fff703f6f40, filename=0x1005c9190 "/Users/erickt/sqlite-crash.py", closeit=1, flags=0x7fff5fbfef90) at Python/pythonrun.c:1241
#8  0x00000001000ebe13 in Py_Main (argc=4832928, argv=<value temporarily unavailable, due to optimizations>) at Modules/main.c:297
#9  0x0000000100000abf in main (argc=2, argv=0x7fff5fbff090) at ./Modules/python.c:59

----------
components: Library (Lib)
files: sqlite-crash.py
messages: 125148
nosy: Erick.Tryzelaar
priority: normal
severity: normal
status: open
title: sqlite segfault with generators
type: crash
versions: Python 3.2
Added file: http://bugs.python.org/file20238/sqlite-crash.py

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

From report at bugs.python.org  Mon Jan  3 02:36:03 2011
From: report at bugs.python.org (Dev Player)
Date: Mon, 03 Jan 2011 01:36:03 +0000
Subject: [issue10060] python.exe crashes or hangs on help() modules when bad
	modules found
In-Reply-To: <1286676227.2.0.62342583611.issue10060@psf.upfronthosting.co.za>
Message-ID: <1294018563.6.0.148290580665.issue10060@psf.upfronthosting.co.za>


Dev Player <devplayer at gmail.com> added the comment:

import win32ui
from win32ui import GetMainFrame

dir(win32ui.GetMainFrame)
['__call__', '__class__', '__cmp__', '__delattr__', '__doc__', '__eq__', '__format__', '__ge__', '__getattribute__', '__gt__', '__hash__', '__init__', '__le__', '__lt__', '__module__', '__name__', '__ne__', '__new__', '__reduce__', '__reduce_ex__', '__repr__', '__self__', '__setattr__', '__sizeof__', '__str__', '__subclasshook__']

dir(GetMainFrame)
['__call__', '__class__', '__cmp__', '__delattr__', '__doc__', '__eq__', '__format__', '__ge__', '__getattribute__', '__gt__', '__hash__', '__init__', '__le__', '__lt__', '__module__', '__name__', '__ne__', '__new__', '__reduce__', '__reduce_ex__', '__repr__', '__self__', '__setattr__', '__sizeof__', '__str__', '__subclasshook__']


Is this normal? I'd expect at least GetWindowText() in the dir().

----------

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

From report at bugs.python.org  Mon Jan  3 02:41:44 2011
From: report at bugs.python.org (Dev Player)
Date: Mon, 03 Jan 2011 01:41:44 +0000
Subject: [issue10060] python.exe crashes or hangs on help() modules when bad
	modules found
In-Reply-To: <1286676227.2.0.62342583611.issue10060@psf.upfronthosting.co.za>
Message-ID: <1294018904.8.0.370559168151.issue10060@psf.upfronthosting.co.za>


Dev Player <devplayer at gmail.com> added the comment:

from GetMainFrame import GetWindowText
Traceback (most recent call last):
  File "<input>", line 1, in <module>
ImportError: No module named GetMainFrame


Also, I installed from the MS-Windows installer file:
pywin32-214.win32-py2.7.exe

not from "pywin32-214.zip" which I think is the source distrobution.

I've tried reinstallation but I get the same results.

----------

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

From report at bugs.python.org  Mon Jan  3 02:43:24 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 03 Jan 2011 01:43:24 +0000
Subject: [issue10811] sqlite segfault with generators
In-Reply-To: <1294018427.94.0.141740646278.issue10811@psf.upfronthosting.co.za>
Message-ID: <1294019004.79.0.79961933666.issue10811@psf.upfronthosting.co.za>


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


----------
assignee:  -> ghaering
nosy: +ghaering

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

From report at bugs.python.org  Mon Jan  3 02:44:40 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 03 Jan 2011 01:44:40 +0000
Subject: [issue10805] traceback.print_exception throws AttributeError when
	exception is None
In-Reply-To: <1293978231.38.0.946265028499.issue10805@psf.upfronthosting.co.za>
Message-ID: <1294019080.15.0.0126720939184.issue10805@psf.upfronthosting.co.za>


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


----------
nosy: +pitrou
versions: +Python 3.2

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

From report at bugs.python.org  Mon Jan  3 02:46:53 2011
From: report at bugs.python.org (Dev Player)
Date: Mon, 03 Jan 2011 01:46:53 +0000
Subject: [issue10060] python.exe crashes or hangs on help() modules when bad
	modules found
In-Reply-To: <1286676227.2.0.62342583611.issue10060@psf.upfronthosting.co.za>
Message-ID: <1294019213.07.0.231866935061.issue10060@psf.upfronthosting.co.za>


Dev Player <devplayer at gmail.com> added the comment:

Oh I am running on an Intel Pentium 4 3.2GHz/3.2Ghz.
Windows XP Pro SP3 32 bit
So I presume I should not have used the AMD 64 versions of course.

http://sourceforge.net/projects/pywin32/files/pywin32/Build%20214/

----------

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

From report at bugs.python.org  Mon Jan  3 04:18:19 2011
From: report at bugs.python.org (Shashwat Anand)
Date: Mon, 03 Jan 2011 03:18:19 +0000
Subject: [issue8013] time.asctime segfaults when given a time in the far future
In-Reply-To: <1267031714.43.0.416052646257.issue8013@psf.upfronthosting.co.za>
Message-ID: <1294024699.6.0.750662236202.issue8013@psf.upfronthosting.co.za>


Changes by Shashwat Anand <anand.shashwat at gmail.com>:


----------
nosy:  -l0nwlf

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

From report at bugs.python.org  Mon Jan  3 04:19:15 2011
From: report at bugs.python.org (Shashwat Anand)
Date: Mon, 03 Jan 2011 03:19:15 +0000
Subject: [issue4953] cgi module cannot handle POST with multipart/form-data in
	3.0
In-Reply-To: <1232010166.79.0.972664060868.issue4953@psf.upfronthosting.co.za>
Message-ID: <1294024755.15.0.767522183064.issue4953@psf.upfronthosting.co.za>


Changes by Shashwat Anand <anand.shashwat at gmail.com>:


----------
nosy:  -l0nwlf

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

From report at bugs.python.org  Mon Jan  3 04:44:59 2011
From: report at bugs.python.org (Glenn Linderman)
Date: Mon, 03 Jan 2011 03:44:59 +0000
Subject: [issue4953] cgi module cannot handle POST with multipart/form-data in
	3.0
In-Reply-To: <1232010166.79.0.972664060868.issue4953@psf.upfronthosting.co.za>
Message-ID: <1294026299.28.0.586200957813.issue4953@psf.upfronthosting.co.za>


Glenn Linderman <v+python at g.nevcal.com> added the comment:

Peter, it seems that detach is relatively new (3.1) likely the code samples and suggestions that I had found to cure the problem predate that.  While I haven't yet tried detach, your code doesn't seem to modify stdin, so are you suggesting, really...

   sys.stdin = sys.stdin.detach()

or maybe

   if hasattr( sys.stdin, 'detach'):
        sys.stdin = sys.stdin.detach()

On the other hand, if detach, coded as above, is equivalent to 

   if hasattr( sys.stdin, 'buffer'):
        sys.stdin = sys.stdin.buffer

then I wonder why it was added.  So maybe I'm missing something in reading the documentation you pointed at, and also that at http://docs.python.org/py3k/library/io.html#io.TextIOBase.detach
both of which seem to be well-documented if you already have an clear understanding of the layers in the IO subsystem, but perhaps not so well-documented if you don't yet (and I don't).

But then you referred to the platform-dependent stuff... I don't see anything in the documentation for detach() that implies that it also makes the adjustments needed on Windows to the C-runtime, which is what the platform-dependent stuff I suggested does... if it does, great, but a bit more documentation would help in understanding that.  And if it does, maybe that is the difference between the two code fragments in this comment?  I would have to experiment to find out, and am not in a position to do that this moment.

----------

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

From report at bugs.python.org  Mon Jan  3 04:50:20 2011
From: report at bugs.python.org (Glenn Linderman)
Date: Mon, 03 Jan 2011 03:50:20 +0000
Subject: [issue4953] cgi module cannot handle POST with multipart/form-data in
	3.0
In-Reply-To: <1232010166.79.0.972664060868.issue4953@psf.upfronthosting.co.za>
Message-ID: <1294026620.76.0.999276764714.issue4953@psf.upfronthosting.co.za>


Glenn Linderman <v+python at g.nevcal.com> added the comment:

Rereading the doc link I pointed at, I guess detach() is part of the new API since 3.1, so doesn't need to be checked for in 3.1+ code... but instead, may need to be coded as:

    try:
        sys.stdin = sys.stdin.detach()
    except UnsupportedOperation:
        pass

----------

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

From orsenthil at gmail.com  Mon Jan  3 05:05:07 2011
From: orsenthil at gmail.com (Senthil Kumaran)
Date: Mon, 3 Jan 2011 12:05:07 +0800
Subject: [issue670664] HTMLParser.py - more robust SCRIPT tag parsing
Message-ID: <20110103040506.GC1053@rubuntu>

If you provide some tests augumenting the currently existing tests
test_htmlparser.py  and also ensure that no existing test breaks, it
would be help better to review the patch. I do see some changes made
to the regex and parsing. So tests would definitely help.


From report at bugs.python.org  Mon Jan  3 05:05:22 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Mon, 03 Jan 2011 04:05:22 +0000
Subject: [issue670664] HTMLParser.py - more robust SCRIPT tag parsing
Message-ID: <20110103040506.GC1053@rubuntu>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

If you provide some tests augumenting the currently existing tests
test_htmlparser.py  and also ensure that no existing test breaks, it
would be help better to review the patch. I do see some changes made
to the regex and parsing. So tests would definitely help.

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

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

From report at bugs.python.org  Mon Jan  3 08:31:40 2011
From: report at bugs.python.org (Brian Quinlan)
Date: Mon, 03 Jan 2011 07:31:40 +0000
Subject: [issue10788] test_logging failure
In-Reply-To: <1293557775.34.0.401807724335.issue10788@psf.upfronthosting.co.za>
Message-ID: <1294039900.06.0.355100111099.issue10788@psf.upfronthosting.co.za>


Brian Quinlan <brian at sweetapp.com> added the comment:

Fixed in r87673.

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

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

From report at bugs.python.org  Mon Jan  3 08:32:46 2011
From: report at bugs.python.org (Brian Quinlan)
Date: Mon, 03 Jan 2011 07:32:46 +0000
Subject: [issue10737] test_concurrent_futures failure on Windows
In-Reply-To: <1292765565.27.0.231692660703.issue10737@psf.upfronthosting.co.za>
Message-ID: <1294039966.77.0.681821616561.issue10737@psf.upfronthosting.co.za>


Brian Quinlan <brian at sweetapp.com> added the comment:

Fixed in r87673.

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

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

From report at bugs.python.org  Mon Jan  3 08:33:49 2011
From: report at bugs.python.org (Brian Quinlan)
Date: Mon, 03 Jan 2011 07:33:49 +0000
Subject: [issue10028] test_concurrent_futures fails on Windows Server 2003
In-Reply-To: <1286303139.16.0.442132720104.issue10028@psf.upfronthosting.co.za>
Message-ID: <1294040029.85.0.487077830092.issue10028@psf.upfronthosting.co.za>


Brian Quinlan <brian at sweetapp.com> added the comment:

Fixed in r87673.

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

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

From report at bugs.python.org  Mon Jan  3 09:16:41 2011
From: report at bugs.python.org (Brian Quinlan)
Date: Mon, 03 Jan 2011 08:16:41 +0000
Subject: [issue10632] multiprocessing generates a fatal error
In-Reply-To: <1291575231.48.0.0739915325097.issue10632@psf.upfronthosting.co.za>
Message-ID: <1294042601.34.0.589880078411.issue10632@psf.upfronthosting.co.za>


Changes by Brian Quinlan <brian at sweetapp.com>:


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

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

From report at bugs.python.org  Mon Jan  3 11:19:51 2011
From: report at bugs.python.org (Etienne Robillard)
Date: Mon, 03 Jan 2011 10:19:51 +0000
Subject: [issue4953] cgi module cannot handle POST with multipart/form-data
	in	3.0
In-Reply-To: <1294026620.76.0.999276764714.issue4953@psf.upfronthosting.co.za>
Message-ID: <4D21A577.7020504@gthcfoundation.org>


Etienne Robillard <erob at gthcfoundation.org> added the comment:

On 02/01/11 10:50 PM, Glenn Linderman wrote:
> Glenn Linderman <v+python at g.nevcal.com> added the comment:
>
> Rereading the doc link I pointed at, I guess detach() is part of the new API since 3.1, so doesn't need to be checked for in 3.1+ code... but instead, may need to be coded as:
>
>     try:
>         sys.stdin = sys.stdin.detach()
>     except UnsupportedOperation:
>         pass
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue4953>
> _______________________________________
>   

Hi!

using "detach" would be great but I'm missing that method here in 2.7! :-)

erob at localhost:~$ python2.7
Python 2.7.1 (r271:86832, Jan  2 2011, 10:38:30)
[GCC 4.2.1 (Based on Apple Inc. build 5658) (LLVM build)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> sys.stdin.detach
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
NameError: name 'sys' is not defined
>>> import sys
>>> sys.stdin.detach
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: 'file' object has no attribute 'detach'

----------
title: cgi module cannot handle POST with multipart/form-data in 3.0 -> cgi module cannot handle POST with multipart/form-data in	3.0

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

From report at bugs.python.org  Mon Jan  3 11:44:47 2011
From: report at bugs.python.org (Etienne Robillard)
Date: Mon, 03 Jan 2011 10:44:47 +0000
Subject: [issue4953] cgi module cannot handle POST with multipart/form-data
	in	3.0
In-Reply-To: <1294026620.76.0.999276764714.issue4953@psf.upfronthosting.co.za>
Message-ID: <4D21AB4F.4020904@gthcfoundation.org>


Etienne Robillard <erob at gthcfoundation.org> added the comment:

i'm thinking this issue is also well connected to:

http://bugs.python.org/issue1573931

so a backport of whatever solution comes to 3.2 would be a great
addition to Python 2.6 as the very minimum, in order to satisfy
minimal backward compatibility!

Thanks,

On 02/01/11 10:50 PM, Glenn Linderman wrote:
> Glenn Linderman <v+python at g.nevcal.com> added the comment:
>
> Rereading the doc link I pointed at, I guess detach() is part of the new API since 3.1, so doesn't need to be checked for in 3.1+ code... but instead, may need to be coded as:
>
>     try:
>         sys.stdin = sys.stdin.detach()
>     except UnsupportedOperation:
>         pass
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue4953>
> _______________________________________
>

----------

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

From report at bugs.python.org  Mon Jan  3 12:42:15 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 03 Jan 2011 11:42:15 +0000
Subject: [issue10348] multiprocessing: use SysV semaphores on FreeBSD
In-Reply-To: <1289181459.49.0.601327253766.issue10348@psf.upfronthosting.co.za>
Message-ID: <1294054935.78.0.970838081058.issue10348@psf.upfronthosting.co.za>


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

Martin fixed test_concurrent_futures (#10798), this issue can be implemented later.

----------
type:  -> feature request
versions: +Python 3.3 -Python 3.2

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

From report at bugs.python.org  Mon Jan  3 13:27:11 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 03 Jan 2011 12:27:11 +0000
Subject: [issue8013] time.asctime segfaults when given a time in the far future
In-Reply-To: <1267031714.43.0.416052646257.issue8013@psf.upfronthosting.co.za>
Message-ID: <1294057631.91.0.0155272491228.issue8013@psf.upfronthosting.co.za>


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

> http://docs.python.org/library/time.html#time-y2kissues
> "Values 100?1899 are always illegal."

Why are these values illegal? The GNU libc accepts year in [1900-2^31; 2^31-1] (tm_year in [-2147483648; 2147481747]). If time.accept2dyear=False, we should at least accept years in [1; 9999]. The system libc would raise an error (return NULL) if it doesn't know how to format years older than 1900.

----------

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

From report at bugs.python.org  Mon Jan  3 13:45:54 2011
From: report at bugs.python.org (Ross Lagerwall)
Date: Mon, 03 Jan 2011 12:45:54 +0000
Subject: [issue10812] Add some posix functions
In-Reply-To: <1294058752.01.0.285856626146.issue10812@psf.upfronthosting.co.za>
Message-ID: <1294058752.01.0.285856626146.issue10812@psf.upfronthosting.co.za>


New submission from Ross Lagerwall <rosslagerwall at gmail.com>:

Here's a patch that adds a bunch of posix functions that are missing from the posix module. Includes tests & documentation.

Tested on Linux & FreeBSD.

Specifically:
	futimes
	lutimes
	futimens
	fexecve
	gethostid
	sethostname
	waitid
	lockf
	readv
	pread
	writev
	pwrite
	truncate
	posix_fallocate
	posix_fadvise
	sync

----------
components: Extension Modules
files: mpos.patch
keywords: patch
messages: 125162
nosy: georg.brandl, giampaolo.rodola, gregory.p.smith, loewis, pitrou, rosslagerwall
priority: normal
severity: normal
status: open
title: Add some posix functions
type: feature request
versions: Python 3.3
Added file: http://bugs.python.org/file20239/mpos.patch

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

From report at bugs.python.org  Mon Jan  3 13:56:14 2011
From: report at bugs.python.org (Michael Foord)
Date: Mon, 03 Jan 2011 12:56:14 +0000
Subject: [issue10786] unittest.TextTextRunner does not respect redirected
	stderr
In-Reply-To: <1293519479.07.0.371916485658.issue10786@psf.upfronthosting.co.za>
Message-ID: <1294059374.16.0.0749409968522.issue10786@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

Thanks Terry. Done. Doc changes committed revision 87679.

----------
keywords:  -patch
nosy:  -MarkRoddy, terry.reedy
resolution:  -> accepted
stage: needs patch -> committed/rejected
status: open -> closed
type: feature request -> behavior

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

From report at bugs.python.org  Mon Jan  3 13:58:07 2011
From: report at bugs.python.org (Carsten Grohmann)
Date: Mon, 03 Jan 2011 12:58:07 +0000
Subject: [issue10813] Suppress adding decimal point for places=0 in moneyfmt()
In-Reply-To: <1294059487.44.0.656415691247.issue10813@psf.upfronthosting.co.za>
Message-ID: <1294059487.44.0.656415691247.issue10813@psf.upfronthosting.co.za>


New submission from Carsten Grohmann <carstengrohmann at gmx.de>:

Hi,

the documentation of the decimal module contains a small recipe called moneyfmt() for format decimal values. It's very usefull.

I'd like to suggest a small improvement because the output is incorrect with given dp="." (default) and places=0.

Example:
>>> moneyfmt(decimal.Decimal('-0.02'), neg='<', trailneg='>', places=1)
'<0.0>'
>>> moneyfmt(decimal.Decimal('-0.02'), neg='<', trailneg='>', places=0)
'<0.>'

Change:
--- moneyfmt.py 2011-01-03 13:56:32.774169788 +0100
+++ moneyfmt.py.new     2011-01-03 13:56:58.130165330 +0100
@@ -33,7 +33,8 @@
         build(trailneg)
     for i in range(places):
         build(next() if digits else '0')
-    build(dp)
+    if places:
+        build(dp)
     if not digits:
         build('0')
     i = 0

What do you think about the change?

Regrads,
Carsten

----------
assignee: docs at python
components: Documentation
messages: 125164
nosy: cgrohmann, docs at python
priority: normal
severity: normal
status: open
title: Suppress adding decimal point for places=0 in moneyfmt()

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

From report at bugs.python.org  Mon Jan  3 14:06:27 2011
From: report at bugs.python.org (Ross Lagerwall)
Date: Mon, 03 Jan 2011 13:06:27 +0000
Subject: [issue6800] os.exec* raises "OSError: [Errno 45] Operation not
	supported" in a multithreaded application
In-Reply-To: <1251515988.29.0.608870203555.issue6800@psf.upfronthosting.co.za>
Message-ID: <1294059987.56.0.75244440423.issue6800@psf.upfronthosting.co.za>


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

I tested this on FreeBSD 8.1 - it outputs 'hello world'.

I think this should be closed - i think the os.exec* functions should mirror the operating system exec* functions. If the platform has a limitation then so be it.

And it seems like the latest versions of those platforms have overcome this limitation anyway.

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

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

From report at bugs.python.org  Mon Jan  3 14:10:29 2011
From: report at bugs.python.org (Mher Movsisyan)
Date: Mon, 03 Jan 2011 13:10:29 +0000
Subject: [issue5162] multiprocessing cannot spawn child from a Windows service
In-Reply-To: <1233885632.9.0.0484597105973.issue5162@psf.upfronthosting.co.za>
Message-ID: <1294060229.37.0.121761881124.issue5162@psf.upfronthosting.co.za>


Mher Movsisyan <mher.movsisyan at gmail.com> added the comment:

Attached test case demonstrates the issue.

----------
nosy: +mher
Added file: http://bugs.python.org/file20240/test_issue5162.py

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

From report at bugs.python.org  Mon Jan  3 14:21:33 2011
From: report at bugs.python.org (Mher Movsisyan)
Date: Mon, 03 Jan 2011 13:21:33 +0000
Subject: [issue5162] multiprocessing cannot spawn child from a Windows service
In-Reply-To: <1233885632.9.0.0484597105973.issue5162@psf.upfronthosting.co.za>
Message-ID: <1294060893.37.0.0659354790522.issue5162@psf.upfronthosting.co.za>


Mher Movsisyan <mher.movsisyan at gmail.com> added the comment:

Treating python services like frozen executables solves the issue. The patch is attached.

----------
Added file: http://bugs.python.org/file20241/forking_r87679.patch

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

From report at bugs.python.org  Mon Jan  3 14:44:58 2011
From: report at bugs.python.org (R. David Murray)
Date: Mon, 03 Jan 2011 13:44:58 +0000
Subject: [issue10060] python.exe crashes or hangs on help() modules when bad
	modules found
In-Reply-To: <1286676227.2.0.62342583611.issue10060@psf.upfronthosting.co.za>
Message-ID: <1294062298.52.0.453221053133.issue10060@psf.upfronthosting.co.za>


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

Dev: I have no idea how what you just posted relates to the subject of this issue.  Could you clarify please?

----------

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

From report at bugs.python.org  Mon Jan  3 14:48:48 2011
From: report at bugs.python.org (Michael Foord)
Date: Mon, 03 Jan 2011 13:48:48 +0000
Subject: [issue10775] assertRaises as a context manager should accept a 'msg'
	keyword argument.
In-Reply-To: <1293391143.22.0.15906903458.issue10775@psf.upfronthosting.co.za>
Message-ID: <1294062528.04.0.653899354514.issue10775@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

I'm fine with this functionality being added in 3.3.

----------

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

From report at bugs.python.org  Mon Jan  3 15:03:47 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 03 Jan 2011 14:03:47 +0000
Subject: [issue10814] assertion failed on Windows buildbots
In-Reply-To: <1294063427.37.0.763229574949.issue10814@psf.upfronthosting.co.za>
Message-ID: <1294063427.37.0.763229574949.issue10814@psf.upfronthosting.co.za>


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

See e.g. http://www.python.org/dev/buildbot/all/builders/x86%20XP-4%203.1

test_time
f:\dd\vctools\crt_bld\self_x86\crt\src\asctime.c(130) : Assertion failed: ( ( tb->tm_mday >= 1 ) && ( ( ( _days[ tb->tm_mon + 1 ] - _days[ tb->tm_mon ] ) >= tb->tm_mday ) || ( ( IS_LEAP_YEAR( tb->tm_year + 1900 ) ) && ( tb->tm_mon == 1 ) && ( tb->tm_mday <= 29 ) ) ) )
program finished with exit code -1073740777

(don't know about 2.6 but it's likely to crash there too)

----------
components: Library (Lib), Tests
messages: 125170
nosy: amaury.forgeotdarc, belopolsky, benjamin.peterson, db3l, georg.brandl, pitrou
priority: critical
severity: normal
stage: needs patch
status: open
title: assertion failed on Windows buildbots
type: crash
versions: Python 2.7, Python 3.1

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

From report at bugs.python.org  Mon Jan  3 15:05:10 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 03 Jan 2011 14:05:10 +0000
Subject: [issue6800] os.exec* raises "OSError: [Errno 45] Operation not
	supported" in a multithreaded application
In-Reply-To: <1251515988.29.0.608870203555.issue6800@psf.upfronthosting.co.za>
Message-ID: <1294063510.1.0.690023222911.issue6800@psf.upfronthosting.co.za>


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

Agreed, not a Python bug.

----------
nosy: +pitrou
resolution:  -> rejected
status: open -> closed

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

From report at bugs.python.org  Mon Jan  3 15:05:24 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 03 Jan 2011 14:05:24 +0000
Subject: [issue10814] assertion failed on Windows buildbots
In-Reply-To: <1294063427.37.0.763229574949.issue10814@psf.upfronthosting.co.za>
Message-ID: <1294063524.47.0.58751695675.issue10814@psf.upfronthosting.co.za>


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

Regression introduced by r87648 (issue #8013).

----------
nosy: +haypo

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

From report at bugs.python.org  Mon Jan  3 15:06:21 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 03 Jan 2011 14:06:21 +0000
Subject: [issue8013] time.asctime segfaults when given a time in the far future
In-Reply-To: <1267031714.43.0.416052646257.issue8013@psf.upfronthosting.co.za>
Message-ID: <1294063581.6.0.0994705144584.issue8013@psf.upfronthosting.co.za>


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

test_time fails with an (C) assertion error on Windows: see issue #10814.

----------

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

From report at bugs.python.org  Mon Jan  3 15:14:12 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 03 Jan 2011 14:14:12 +0000
Subject: [issue10812] Add some posix functions
In-Reply-To: <1294058752.01.0.285856626146.issue10812@psf.upfronthosting.co.za>
Message-ID: <1294064052.41.0.315741384576.issue10812@psf.upfronthosting.co.za>


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

First couple comments:
- you don't have to modify Misc/NEWS yourself; it will probably make patch maintenance easier
- it would seem more natural for readv() to take a sequence of writable buffers (such as bytearrays) instead; I don't think the current signature is very useful
- readv() and writev() should support both lists and tuples, at the minimum (perhaps arbitrary iterables if you like to spend more time on it :-)): see the PySequence* API

----------

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

From report at bugs.python.org  Mon Jan  3 15:26:44 2011
From: report at bugs.python.org (Michal Vyskocil)
Date: Mon, 03 Jan 2011 14:26:44 +0000
Subject: [issue10815] Write to /dev/full does not raise IOError
In-Reply-To: <1294064804.78.0.484906299225.issue10815@psf.upfronthosting.co.za>
Message-ID: <1294064804.78.0.484906299225.issue10815@psf.upfronthosting.co.za>


New submission from Michal Vyskocil <mvyskocil at suse.cz>:

Write to /dev/full in python3 don't raise IOError. Python2 works as expected, the close call causes an IOError exception with no space left on device message.

$ python
Python 2.7 (r27:82500, Aug 07 2010, 16:54:59) [GCC] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> f = open('/dev/full', 'w')
>>> f.write('s')
>>> f.close()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
IOError: [Errno 28] No space left on device

However using python3 I don't get an IOError after close
$ python3
Python 3.1.2 (r312:79147, Nov 20 2010, 11:33:28) 
[GCC 4.5.1 20101001 [gcc-4_5-branch revision 164883]] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> f = open('/dev/full', 'w')
>>> f.write('s')
1
>>> f.close()

The only one way how to raise IOError in python3 is call f.flush()

...
>>> f.write('s')
1
>>> f.flush()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
IOError: [Errno 28] No space left on device

Documentation of io.IOBase.close() [1] said Flush and close this stream, so one should expect calls f.flush();f.close() will be the same as plain f.close().

[1] http://docs.python.org/py3k/library/io.html

----------
components: IO
messages: 125175
nosy: mvyskocil
priority: normal
severity: normal
status: open
title: Write to /dev/full does not raise IOError
versions: Python 3.1

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

From report at bugs.python.org  Mon Jan  3 15:33:30 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 03 Jan 2011 14:33:30 +0000
Subject: [issue10512] regrtest ResourceWarning - unclosed sockets and files
In-Reply-To: <1290506536.77.0.313292165719.issue10512@psf.upfronthosting.co.za>
Message-ID: <1294065210.03.0.94056923853.issue10512@psf.upfronthosting.co.za>


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

* r87680 fixes test_sockserver
 * r87681 fixes test_timeout
 * r87682 fixes test_tk
 * r87683 fixes test_xmlrpc
 * r87684 fixes test_socket

r87682, r87683, r87684 are patches from Nadeem Vawda.

On my Linux box, I am unable to get the warning on test_cgi or test_normalization.

----------
nosy: +haypo

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

From report at bugs.python.org  Mon Jan  3 15:41:48 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 03 Jan 2011 14:41:48 +0000
Subject: [issue10815] Write to /dev/full does not raise IOError
In-Reply-To: <1294064804.78.0.484906299225.issue10815@psf.upfronthosting.co.za>
Message-ID: <1294065708.99.0.0637541706927.issue10815@psf.upfronthosting.co.za>


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

This issue is fixed in Python 3.2 beta 2:
--------
$ ./python 
>>> f=open("/dev/full", "wb")
>>> f.write(b'x')
1
>>> f.close()
IOError: [Errno 28] No space left on device
>>> ^D

sys:1: ResourceWarning: unclosed file <_io.BufferedWriter name='/dev/full'>
sys:1: ResourceWarning: unclosed file <_io.FileIO name='/dev/full' mode='wb'>
--------

If you would like to get the error earlier, disable the buffer (which is not completly possible for a text file, Python requires at least a line buffer).

Backport the fix to Python 3.1 is not a good idea because it may break programs using Python 3.1.

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

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

From report at bugs.python.org  Mon Jan  3 15:45:16 2011
From: report at bugs.python.org (R. David Murray)
Date: Mon, 03 Jan 2011 14:45:16 +0000
Subject: [issue4953] cgi module cannot handle POST with multipart/form-data
	in	3.0
In-Reply-To: <1232010166.79.0.972664060868.issue4953@psf.upfronthosting.co.za>
Message-ID: <1294065916.43.0.119829486085.issue4953@psf.upfronthosting.co.za>


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

Etienne: since this is about solving a 3.x specific problem, it will not get backported.  Issue 1573931 looks unrelated to me at a quick glance.  FYI, you will find that you *do* have detach in 2.7 if you open a file using the io subsystem (import io).  Of course, that isn't used for the std files in 2.7.

Glen: the new IO subsystem is a complete C layer on top of only the most basic of the C runtime stuff.  It does handle cross platform issues.  Given that, and given that the input to CGI *should* be bytes, I think letting an error raise if the stream is text and detatch isn't available is fine, though we might find we want to catch it to improve the error message with extra context.

Pierre: yes, that diff is what I was looking for.  I hope to have time to look it over later today.

----------

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

From report at bugs.python.org  Mon Jan  3 16:07:53 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 03 Jan 2011 15:07:53 +0000
Subject: [issue10806] Subprocess error if fds 0,1,2 are closed
In-Reply-To: <1293991717.46.0.660046429073.issue10806@psf.upfronthosting.co.za>
Message-ID: <1294067273.61.0.665219477366.issue10806@psf.upfronthosting.co.za>


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

This new patch makes tests more comprehensive (closes all combinations of the three standard fds).

----------
Added file: http://bugs.python.org/file20242/sp3.patch

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

From report at bugs.python.org  Mon Jan  3 16:27:49 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 03 Jan 2011 15:27:49 +0000
Subject: [issue10816] test_multiprocessing: unclosed sockets
In-Reply-To: <1294068469.4.0.316876658618.issue10816@psf.upfronthosting.co.za>
Message-ID: <1294068469.4.0.316876658618.issue10816@psf.upfronthosting.co.za>


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

test_remote (__main__.WithManagerTestRemoteManager) ... /home/haypo/prog/GIT/py3k/Lib/multiprocessing/managers.py:812: ResourceWarning: unclosed <socket.socket object, fd=8, family=2, type=1, proto=0>
  util.debug('... decref failed %s', e)
ok


test_pool_initializer (__main__.TestInitializers) ... /home/haypo/prog/GIT/py3k/Lib/multiprocessing/managers.py:831: ResourceWarning: unclosed <socket.socket object, fd=9, family=1, type=1, proto=0>
  util.info('incref failed: %s' % e)
ok


test_pool_in_process (__main__.TestStdinBadfiledescriptor) ... /home/haypo/prog/GIT/py3k/Lib/multiprocessing/managers.py:831: ResourceWarning: unclosed <socket.socket object, fd=9, family=1, type=1, proto=0>
  util.info('incref failed: %s' % e)
/home/haypo/prog/GIT/py3k/Lib/multiprocessing/managers.py:831: ResourceWarning: unclosed <socket.socket object, fd=9, family=1, type=1, proto=0>
  util.info('incref failed: %s' % e)
/home/haypo/prog/GIT/py3k/Lib/multiprocessing/managers.py:831: ResourceWarning: unclosed <socket.socket object, fd=13, family=1, type=1, proto=0>
  util.info('incref failed: %s' % e)
/home/haypo/prog/GIT/py3k/Lib/multiprocessing/managers.py:831: ResourceWarning: unclosed <socket.socket object, fd=13, family=1, type=1, proto=0>
  util.info('incref failed: %s' % e)
/home/haypo/prog/GIT/py3k/Lib/multiprocessing/managers.py:831: ResourceWarning: unclosed <socket.socket object, fd=13, family=1, type=1, proto=0>
  util.info('incref failed: %s' % e)
/home/haypo/prog/GIT/py3k/Lib/multiprocessing/managers.py:831: ResourceWarning: unclosed <socket.socket object, fd=13, family=1, type=1, proto=0>
  util.info('incref failed: %s' % e)
/home/haypo/prog/GIT/py3k/Lib/multiprocessing/managers.py:831: ResourceWarning: unclosed <socket.socket object, fd=13, family=1, type=1, proto=0>
  util.info('incref failed: %s' % e)
/home/haypo/prog/GIT/py3k/Lib/multiprocessing/managers.py:831: ResourceWarning: unclosed <socket.socket object, fd=13, family=1, type=1, proto=0>
  util.info('incref failed: %s' % e)
ok


test_queue_in_process (__main__.TestStdinBadfiledescriptor) ... /home/haypo/prog/GIT/py3k/Lib/multiprocessing/managers.py:831: ResourceWarning: unclosed <socket.socket object, fd=9, family=1, type=1, proto=0>
  util.info('incref failed: %s' % e)
/home/haypo/prog/GIT/py3k/Lib/multiprocessing/managers.py:831: ResourceWarning: unclosed <socket.socket object, fd=9, family=1, type=1, proto=0>
  util.info('incref failed: %s' % e)
/home/haypo/prog/GIT/py3k/Lib/multiprocessing/managers.py:831: ResourceWarning: unclosed <socket.socket object, fd=13, family=1, type=1, proto=0>
  util.info('incref failed: %s' % e)
/home/haypo/prog/GIT/py3k/Lib/multiprocessing/managers.py:831: ResourceWarning: unclosed <socket.socket object, fd=13, family=1, type=1, proto=0>
  util.info('incref failed: %s' % e)
ok

----------
components: Library (Lib)
messages: 125180
nosy: haypo
priority: normal
severity: normal
status: open
title: test_multiprocessing: unclosed sockets
versions: Python 3.2

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

From report at bugs.python.org  Mon Jan  3 16:33:22 2011
From: report at bugs.python.org (Etienne Robillard)
Date: Mon, 03 Jan 2011 15:33:22 +0000
Subject: [issue4953] cgi module cannot handle POST with multipart/form-data
	in	3.0
In-Reply-To: <1294065916.43.0.119829486085.issue4953@psf.upfronthosting.co.za>
Message-ID: <4D21EEE5.6040807@gthcfoundation.org>


Etienne Robillard <erob at gthcfoundation.org> added the comment:

On 03/01/11 09:45 AM, R. David Murray wrote:
> R. David Murray <rdmurray at bitdance.com> added the comment:
>
> Etienne: since this is about solving a 3.x specific problem, it will not get backported.  Issue 1573931 looks unrelated to me at a quick glance.  FYI, you will find that you *do* have detach in 2.7 if you open a file using the io subsystem (import io).  Of course, that isn't used for the std files in 2.7.
>
> Glen: the new IO subsystem is a complete C layer on top of only the most basic of the C runtime stuff.  It does handle cross platform issues.  Given that, and given that the input to CGI *should* be bytes, I think letting an error raise if the stream is text and detatch isn't available is fine, though we might find we want to catch it to improve the error message with extra context.
>
> Pierre: yes, that diff is what I was looking for.  I hope to have time to look it over later today.
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue4953>
> _______________________________________
>   

Thanks for theses precisions, David.

So will cgi.FieldStorage still be usable in 3.x using 2.5 semantics ?
implementing the size argument
in the FieldStorage class would surely be a good fix for WSGI middlewares. 

Either ways (using the new io subsystem) or monkey-patching
cgi.FieldStorage so it accepts the size argument could probably helps to
resolve memory-usage issues with things like file uploads!

Regards

----------

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

From report at bugs.python.org  Mon Jan  3 16:40:08 2011
From: report at bugs.python.org (Kevin Walzer)
Date: Mon, 03 Jan 2011 15:40:08 +0000
Subject: [issue6075] Patch for IDLE/OS X to work with Tk-Cocoa
In-Reply-To: <1242858324.92.0.20433040915.issue6075@psf.upfronthosting.co.za>
Message-ID: <1294069208.18.0.435381584993.issue6075@psf.upfronthosting.co.za>


Kevin Walzer <wordtech at users.sourceforge.net> added the comment:

Ned--thank you for reviewing, testing, and modifying the patch. I applied your revised version to my new install of Python 2.7.1 and it works fine.

----------

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

From report at bugs.python.org  Mon Jan  3 16:41:11 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 03 Jan 2011 15:41:11 +0000
Subject: [issue10814] assertion failed on Windows buildbots
In-Reply-To: <1294063427.37.0.763229574949.issue10814@psf.upfronthosting.co.za>
Message-ID: <1294069271.04.0.393769043016.issue10814@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


----------
assignee:  -> belopolsky

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

From report at bugs.python.org  Mon Jan  3 16:43:00 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 03 Jan 2011 15:43:00 +0000
Subject: [issue10812] Add some posix functions
In-Reply-To: <1294058752.01.0.285856626146.issue10812@psf.upfronthosting.co.za>
Message-ID: <1294069380.61.0.048609225096.issue10812@psf.upfronthosting.co.za>


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

For the record, I get the following failures under OpenSolaris:

======================================================================
ERROR: test_lutimes (test.test_posix.PosixTester)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/antoine/py3k/cc/Lib/test/test_posix.py", line 265, in test_lutimes
    posix.lutimes(support.TESTFN, None)
AttributeError: 'module' object has no attribute 'lutimes'

======================================================================
ERROR: test_posix_fallocate (test.test_posix.PosixTester)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/antoine/py3k/cc/Lib/test/test_posix.py", line 236, in test_posix_fallocate
    posix.posix_fallocate(fd, 0, 10)
OSError: [Errno 22] Invalid argument

----------

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

From report at bugs.python.org  Mon Jan  3 16:46:31 2011
From: report at bugs.python.org (Michael Foord)
Date: Mon, 03 Jan 2011 15:46:31 +0000
Subject: [issue10502] Add unittestguirunner to Tools/
In-Reply-To: <1290424978.75.0.300298743015.issue10502@psf.upfronthosting.co.za>
Message-ID: <1294069591.18.0.515934115144.issue10502@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

Committed revision 87685. 

It would be nice to see this included in the Mac OS X and Windows distribution, but I guess that applies to the *whole* Tools/ directory.

----------
resolution:  -> accepted
stage: needs patch -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Mon Jan  3 16:48:29 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 03 Jan 2011 15:48:29 +0000
Subject: [issue10816] test_multiprocessing: unclosed sockets
In-Reply-To: <1294068469.4.0.316876658618.issue10816@psf.upfronthosting.co.za>
Message-ID: <1294069709.26.0.673965011384.issue10816@psf.upfronthosting.co.za>


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

Ok, I found it: fixed by r87686

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

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

From report at bugs.python.org  Mon Jan  3 16:50:04 2011
From: report at bugs.python.org (Robert Cheng)
Date: Mon, 03 Jan 2011 15:50:04 +0000
Subject: [issue10817] urllib.request.urlretrieve never raises
	ContentTooShortError if no reporthook
In-Reply-To: <1294069804.34.0.860239284714.issue10817@psf.upfronthosting.co.za>
Message-ID: <1294069804.34.0.860239284714.issue10817@psf.upfronthosting.co.za>


New submission from Robert Cheng <robert.h.cheng at gmail.com>:

When reporthook is None, size variable is not computed and defaulted to -1. Thus, without reporthook, ContentTooShortError is not raised even when Content-Length header is supplied and download size is less than expected amount, contrary to the documentation.

----------
components: Library (Lib)
messages: 125186
nosy: RC
priority: normal
severity: normal
status: open
title: urllib.request.urlretrieve never raises ContentTooShortError if no reporthook
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Mon Jan  3 16:52:18 2011
From: report at bugs.python.org (Giampaolo Rodola')
Date: Mon, 03 Jan 2011 15:52:18 +0000
Subject: [issue4953] cgi module cannot handle POST with multipart/form-data
	in	3.0
In-Reply-To: <1232010166.79.0.972664060868.issue4953@psf.upfronthosting.co.za>
Message-ID: <1294069938.94.0.151633668232.issue4953@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/issue4953>
_______________________________________

From report at bugs.python.org  Mon Jan  3 16:53:07 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Mon, 03 Jan 2011 15:53:07 +0000
Subject: [issue10817] urllib.request.urlretrieve never raises
	ContentTooShortError if no reporthook
In-Reply-To: <1294069804.34.0.860239284714.issue10817@psf.upfronthosting.co.za>
Message-ID: <1294069987.94.0.111343518529.issue10817@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Mon Jan  3 16:58:50 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 03 Jan 2011 15:58:50 +0000
Subject: [issue10812] Add some posix functions
In-Reply-To: <1294058752.01.0.285856626146.issue10812@psf.upfronthosting.co.za>
Message-ID: <1294070330.61.0.948059288935.issue10812@psf.upfronthosting.co.za>


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

According to the posix_fallocate() man page under OpenSolaris:

     EINVAL    The len argument is less than or equal to zero, or
               the  offset  argument  is  less  than zero, or the
               underlying  file  system  does  not  support  this
               operation.

I would go for the third (last) interpretation: the filesystem (ZFS here) doesn't support it.

----------

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

From report at bugs.python.org  Mon Jan  3 17:14:41 2011
From: report at bugs.python.org (Zsolt Cserna)
Date: Mon, 03 Jan 2011 16:14:41 +0000
Subject: [issue9115] test_site: support for systems without unsetenv
In-Reply-To: <1277821678.96.0.414728435775.issue9115@psf.upfronthosting.co.za>
Message-ID: <1294071281.25.0.822082048051.issue9115@psf.upfronthosting.co.za>


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

I confirm that this patch fixes the problem. Thanks.

On my systems I haven't seen other bugs related to unsetenv - however, it might be useful to fix subprocess.Popen and subprocess.call to use the os.environ by default (but this would be another request or discussion).

----------

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

From report at bugs.python.org  Mon Jan  3 17:15:41 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 03 Jan 2011 16:15:41 +0000
Subject: [issue10814] assertion failed on Windows buildbots
In-Reply-To: <1294063427.37.0.763229574949.issue10814@psf.upfronthosting.co.za>
Message-ID: <1294071341.24.0.588203956324.issue10814@psf.upfronthosting.co.za>


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

Can someone with a windows box test

>>> time.asctime((12345, 1, 1, 0, 0, 0, 0, 0, 0))?

If that crashes as well, can you tell which part of 

( ( tb->tm_mday >= 1 ) && ( ( ( _days[ tb->tm_mon + 1 ] - _days[ tb->tm_mon ] ) >= tb->tm_mday ) || ( ( IS_LEAP_YEAR( tb->tm_year + 1900 ) ) && ( tb->tm_mon == 1 ) && ( tb->tm_mday <= 29 ) ) ) )


triggers the assertion?

----------

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

From report at bugs.python.org  Mon Jan  3 17:16:30 2011
From: report at bugs.python.org (=?utf-8?q?Andreas_St=C3=BChrk?=)
Date: Mon, 03 Jan 2011 16:16:30 +0000
Subject: [issue10814] assertion failed on Windows buildbots
In-Reply-To: <1294063427.37.0.763229574949.issue10814@psf.upfronthosting.co.za>
Message-ID: <1294071390.8.0.511944797867.issue10814@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/issue10814>
_______________________________________

From report at bugs.python.org  Mon Jan  3 17:17:21 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 03 Jan 2011 16:17:21 +0000
Subject: [issue10818] pydoc: refactorize duplicate DocHandler and DocServer
	classes
In-Reply-To: <1294071441.53.0.907267492881.issue10818@psf.upfronthosting.co.za>
Message-ID: <1294071441.53.0.907267492881.issue10818@psf.upfronthosting.co.za>


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

The pydoc module has two DocHandler classes and two DocServer classes. I think that they can be easily factorized.

DocServer may also use serve_forever()+shutdown() instead of serve_until_quit()+quit flag, to be able to wait the server (with shutdown()).

----------
assignee: docs at python
components: Documentation, Library (Lib)
messages: 125190
nosy: docs at python, haypo
priority: normal
severity: normal
status: open
title: pydoc: refactorize duplicate DocHandler and DocServer classes
versions: Python 3.2, Python 3.3

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

From report at bugs.python.org  Mon Jan  3 17:17:48 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 03 Jan 2011 16:17:48 +0000
Subject: [issue10818] pydoc: refactorize duplicate DocHandler and DocServer
	classes
In-Reply-To: <1294071441.53.0.907267492881.issue10818@psf.upfronthosting.co.za>
Message-ID: <1294071468.98.0.987096342866.issue10818@psf.upfronthosting.co.za>


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

I opened this issue because I had to fix a bug twice in pydoc: r87687 (fix a ResourceWarning(unclosed socket)).

----------

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

From report at bugs.python.org  Mon Jan  3 17:26:27 2011
From: report at bugs.python.org (Brian Curtin)
Date: Mon, 03 Jan 2011 16:26:27 +0000
Subject: [issue10814] assertion failed on Windows buildbots
In-Reply-To: <1294063427.37.0.763229574949.issue10814@psf.upfronthosting.co.za>
Message-ID: <1294071987.12.0.843147181357.issue10814@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

Alexander:

>PCbuild\amd64\python_d.exe
Python 3.2b2+ (py3k, Jan  3 2011, 10:24:18) [MSC v.1500 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import time
[54931 refs]
>>> time.asctime((12345, 1, 1, 0, 0, 0, 0, 0, 0))
'Mon Jan 01 00:00:00 <345'
[54935 refs]

----------
nosy: +brian.curtin

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

From report at bugs.python.org  Mon Jan  3 17:37:35 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 03 Jan 2011 16:37:35 +0000
Subject: [issue10512] regrtest ResourceWarning - unclosed sockets and files
In-Reply-To: <1290506536.77.0.313292165719.issue10512@psf.upfronthosting.co.za>
Message-ID: <1294072655.97.0.927626649908.issue10512@psf.upfronthosting.co.za>


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

* r87686 fixes multiprocessing
 * r87687 fixes pydoc
 * r87688 fixes test_subprocess

Remaining ResourceWarning warnings:
 * test_imaplib
 * test_urllibnet
 * test_urllib2net

----------

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

From report at bugs.python.org  Mon Jan  3 17:39:42 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 03 Jan 2011 16:39:42 +0000
Subject: [issue10814] assertion failed on Windows buildbots
In-Reply-To: <1294071987.12.0.843147181357.issue10814@psf.upfronthosting.co.za>
Message-ID: <AANLkTikNLHP4_U-AsEEz=B3YSLBKh5iXNd2ZyKFJTfVb@mail.gmail.com>


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

On Mon, Jan 3, 2011 at 11:26 AM, Brian Curtin <report at bugs.python.org> wrote:
..
>>PCbuild\amd64\python_d.exe
> Python 3.2b2+ (py3k, Jan ?3 2011, 10:24:18) [MSC v.1500 64 bit (AMD64)] on win32
> Type "help", "copyright", "credits" or "license" for more information.
>>>> import time
> [54931 refs]
>>>> time.asctime((12345, 1, 1, 0, 0, 0, 0, 0, 0))
> 'Mon Jan 01 00:00:00 <345'

Thanks, Brian.  This is rather strange because checktm() is supposed
to convert tm_day=0 to 1:

    if (buf->tm_mday == 0)
        buf->tm_mday = 1;

Does time.asctime((12345, 1, 0, 0, 0, 0, 0, 0, 0)) crash on your system?

BTW, '<' in the output looks like a naive ASCII encoding for the 12-th
millennium:

12

You may need year 300,000 to observe a crash.

----------

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

From report at bugs.python.org  Mon Jan  3 17:43:40 2011
From: report at bugs.python.org (Brian Curtin)
Date: Mon, 03 Jan 2011 16:43:40 +0000
Subject: [issue10814] assertion failed on Windows buildbots
In-Reply-To: <1294063427.37.0.763229574949.issue10814@psf.upfronthosting.co.za>
Message-ID: <1294073020.04.0.983571805286.issue10814@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

No crash on 0-day or 300,000. I bumped it up to 3,000,000 and got a UnicodeDecodeError, although I'm not sure of the relevance of that to this issue.


>>> time.asctime((12345, 1, 0, 0, 0, 0, 0, 0, 0))
'Mon Jan 01 00:00:00 <345'
[54935 refs]
>>> time.asctime((300000, 1, 0, 0, 0, 0, 0, 0, 0))
'Mon Jan 01 00:00:00 \\000'
[54935 refs]
>>> time.asctime((3000000, 1, 0, 0, 0, 0, 0, 0, 0))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
UnicodeDecodeError: 'utf8' codec can't decode byte 0xe8 in position 20: invalid continuation byte

----------

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

From report at bugs.python.org  Mon Jan  3 17:56:36 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 03 Jan 2011 16:56:36 +0000
Subject: [issue10814] assertion failed on Windows buildbots
In-Reply-To: <1294073020.04.0.983571805286.issue10814@psf.upfronthosting.co.za>
Message-ID: <AANLkTikCARnmubmw1akHkN9ctpGGQysg9nD874c=UsJT@mail.gmail.com>


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

On Mon, Jan 3, 2011 at 11:43 AM, Brian Curtin <report at bugs.python.org> wrote:
..
> No crash on 0-day or 300,000. I bumped it up to 3,000,000 and got a UnicodeDecodeError, although
> I'm not sure of the relevance of that to this issue.

It looks like we need an XP box with a debug version of the crt lib to
reproduce the crash.

..
>>>> time.asctime((3000000, 1, 0, 0, 0, 0, 0, 0, 0))
> Traceback (most recent call last):
> ?File "<stdin>", line 1, in <module>
> UnicodeDecodeError: 'utf8' codec can't decode byte 0xe8 in position 20: invalid continuation byte

Well, undefined behavior is undefined behavior.  Arguably, writing
binary garbage in a timestamp is better than crashing.  (given Windows
reputation, I would not be surprised if the above also involves
undetected memory corruption, though.) I am convinced that we don't
have a choice but to check the input of asctime() beforehand.  I am
preparing a patch.

----------

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

From report at bugs.python.org  Mon Jan  3 17:56:56 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 03 Jan 2011 16:56:56 +0000
Subject: [issue10814] assertion failed on Windows buildbots
In-Reply-To: <1294063427.37.0.763229574949.issue10814@psf.upfronthosting.co.za>
Message-ID: <1294073816.16.0.465257754139.issue10814@psf.upfronthosting.co.za>


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

This is under 3.1, not 3.2.

----------

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

From report at bugs.python.org  Mon Jan  3 18:09:54 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 03 Jan 2011 17:09:54 +0000
Subject: [issue10814] assertion failed on Windows buildbots
In-Reply-To: <1294063427.37.0.763229574949.issue10814@psf.upfronthosting.co.za>
Message-ID: <1294074594.69.0.219357913287.issue10814@psf.upfronthosting.co.za>


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

I can reproduce under Windows 7, 32-bit debug build, with the following line:

time.asctime((12345, 1, 0, 0, 0, 0, 0, 0, 0))

Apparently, the debugger tells me that tb->tm_mday is 0.
Actually, most of the tb fields are 0 except tm_year (10445), tm_wday (1) and tm_yday (-1).

The code is the following:

    _VALIDATE_RETURN_ERRCODE(
        (
            ( tb->tm_mday >= 1 ) &&
            (
                // Day is in valid range for the month
                ( ( _days[ tb->tm_mon + 1 ] - _days[ tb->tm_mon ] ) >=
                        tb->tm_mday ) ||
                // Special case for Feb in a leap year
                (
                    ( IS_LEAP_YEAR( tb->tm_year + 1900 ) ) &&
                    ( tb->tm_mon == 1 ) &&
                    ( tb->tm_mday <= 29 )
                )
            )
        ),
        EINVAL
    )

So I would say the problem is really that the CRT should return EINVAL but instead triggers an assertion, perhaps because of a debug mode thing that we disable manually in 3.2?

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

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

From report at bugs.python.org  Mon Jan  3 18:22:18 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 03 Jan 2011 17:22:18 +0000
Subject: [issue10814] assertion failed on Windows buildbots
In-Reply-To: <1294063427.37.0.763229574949.issue10814@psf.upfronthosting.co.za>
Message-ID: <1294075338.05.0.684739017461.issue10814@psf.upfronthosting.co.za>


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

I committed a a fix for the test in r87690.  If this fixes the buildbot, I'll backport to 2.7 and call it a day for < 3.2.  For 3.2 a proper year range check will be added to close issue 8013.

----------

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

From report at bugs.python.org  Mon Jan  3 18:30:32 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 03 Jan 2011 17:30:32 +0000
Subject: [issue10814] assertion failed on Windows buildbots
In-Reply-To: <1294063427.37.0.763229574949.issue10814@psf.upfronthosting.co.za>
Message-ID: <1294075832.68.0.0759917249502.issue10814@psf.upfronthosting.co.za>


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

Btw, I have a failed assertion in the test suite, with "time.ctime(1e12)":
File: loctim64.c
Line: 78
Expression: (*ptime <= _MAX__TIME64_T)

This is a recent py3k, compiled with VS2005.

----------

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

From report at bugs.python.org  Mon Jan  3 18:33:10 2011
From: report at bugs.python.org (Glenn Linderman)
Date: Mon, 03 Jan 2011 17:33:10 +0000
Subject: [issue4953] cgi module cannot handle POST with multipart/form-data
	in	3.0
In-Reply-To: <1232010166.79.0.972664060868.issue4953@psf.upfronthosting.co.za>
Message-ID: <1294075990.01.0.325194329496.issue4953@psf.upfronthosting.co.za>


Glenn Linderman <v+python at g.nevcal.com> added the comment:

So then David, is your suggestion to use

sys.stdin = sys.stdin.detach()

and you claim that the Windows-specific hacks are not needed in 3.x land?  The are, in 2.x land, I have proven empirically, but haven't been able to test CGI forms very well in 3.x because of this bug.  I will test 3.x download without the Windows-specific hack, and report how it goes.  My testing started with 2.x and has proceeded to 3.x, and it is not always obvious what hacks are no longer needed in 3.x.  Thanks for the info.

----------

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

From report at bugs.python.org  Mon Jan  3 18:37:14 2011
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Mon, 03 Jan 2011 17:37:14 +0000
Subject: [issue1674555] sys.path in tests contains system directories
Message-ID: <1294076234.96.0.696438471457.issue1674555@psf.upfronthosting.co.za>


Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com> added the comment:

Apparently this patch isn't sufficient for test___all__.
Please create empty _xmlplus directory (without __init__.py) in site-packages directory appropriate for given sys.prefix (e.g. /usr/lib/python3.2/site-packages/_xmlplus for sys.prefix='/usr').

The output of `make test` contains:
LD_LIBRARY_PATH=/var/tmp/portage/dev-lang/python-3.2_pre20110102/work/python-3.2_pre20110102: ./python -Wd -E -bb -S -s  ./Lib/test/regrtest.py -j1 
== CPython 3.2b2+ (py3k:87612, Jan 3 2011, 18:30:27) [GCC 4.4.5]
==   Linux-2.6.34-tuxonice-r8-AFTA-x86_64-Intel-R-_Pentium-R-_Dual_CPU_T2390_ at _1.86GHz-with-gentoo-2.0.1 little-endian
==   /var/tmp/portage/dev-lang/python-3.2_pre20110102/work/python-3.2_pre20110102/build/test_python_2301
[  1/349] test_grammar
[  2/349] test_opcodes
[  3/349] test_dict
[  4/349] test_builtin
[  5/349] test_exceptions
[  6/349] test_types
[  7/349] test_unittest
[  8/349] test_doctest

[  9/349] test_doctest2

[ 10/349] test___all__

Warning -- sys.path was modified by test___all__
test test___all__ failed -- Traceback (most recent call last):
  File "/var/tmp/portage/dev-lang/python-3.2_pre20110102/work/python-3.2_pre20110102/Lib/test/test___all__.py", line 101, in test_all
    self.check_all(modname)
  File "/var/tmp/portage/dev-lang/python-3.2_pre20110102/work/python-3.2_pre20110102/Lib/test/test___all__.py", line 28, in check_all
    raise FailedImport(modname)
  File "/var/tmp/portage/dev-lang/python-3.2_pre20110102/work/python-3.2_pre20110102/Lib/contextlib.py", line 35, in __exit__
    next(self.gen)
  File "/var/tmp/portage/dev-lang/python-3.2_pre20110102/work/python-3.2_pre20110102/Lib/test/support.py", line 623, in _filterwarnings
    raise AssertionError("unhandled warning %s" % reraise[0])
AssertionError: unhandled warning {message : ImportWarning("Not importing directory '/usr/lib/python3.2/site-packages/_xmlplus': missing __init__.py",), category : 'ImportWarning', filename : '/var/tmp/portage/dev-lang/python-3.2_pre20110102/work/python-3.2_pre20110102/Lib/xml/__init__.py', lineno : 26, line : None}
[ 11/349] test___future__
[ 12/349] test__locale
[ 13/349] test_abc

----------

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

From report at bugs.python.org  Mon Jan  3 18:41:41 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 03 Jan 2011 17:41:41 +0000
Subject: [issue10814] assertion failed on Windows buildbots
In-Reply-To: <1294075832.68.0.0759917249502.issue10814@psf.upfronthosting.co.za>
Message-ID: <AANLkTik5ES4vfZ6HWqoEKoThvT2KWsNymyyndFvXKgo3@mail.gmail.com>


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

On Mon, Jan 3, 2011 at 12:30 PM, Amaury Forgeot d'Arc
<report at bugs.python.org> wrote:
..
> Btw, I have a failed assertion in the test suite, with "time.ctime(1e12)"

This is from r87657.  I commented on that change in msg125117.
Hopefully a range check will fix that as well.

----------

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

From report at bugs.python.org  Mon Jan  3 18:43:35 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 03 Jan 2011 17:43:35 +0000
Subject: [issue10818] pydoc: refactorize duplicate DocHandler and DocServer
	classes
In-Reply-To: <1294071441.53.0.907267492881.issue10818@psf.upfronthosting.co.za>
Message-ID: <1294076615.55.0.71737480582.issue10818@psf.upfronthosting.co.za>


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


----------
assignee: docs at python -> 
components:  -Documentation
nosy: +eric.araujo, ron_adam -docs at python
stage:  -> needs patch
type:  -> feature request
versions:  -Python 3.2

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

From report at bugs.python.org  Mon Jan  3 18:47:45 2011
From: report at bugs.python.org (Michael Foord)
Date: Mon, 03 Jan 2011 17:47:45 +0000
Subject: [issue10619] Failed module loading in test discovery loses traceback
In-Reply-To: <1291421664.92.0.199127782586.issue10619@psf.upfronthosting.co.za>
Message-ID: <1294076865.51.0.40891051872.issue10619@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

This doesn't appear to be true on py3k (traceback.format_exc is used to preserve the original traceback). Need to check on Python 2.7.

----------
versions:  -Python 3.2

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

From report at bugs.python.org  Mon Jan  3 18:52:57 2011
From: report at bugs.python.org (Michael Foord)
Date: Mon, 03 Jan 2011 17:52:57 +0000
Subject: [issue9977] TestCase.assertItemsEqual's description of differences
In-Reply-To: <1285704922.32.0.659854668668.issue9977@psf.upfronthosting.co.za>
Message-ID: <1294077177.8.0.42155755234.issue9977@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

In Python 3.2 assertItemsEqual has been replaced with assertCountEqual that has a completely different implementation and error format. The implementation and error output will be backported to the assertItemsEqual method of 2.7 (and to unittest2).

Error output:

AssertionError: Element counts were not equal:
First has 1, Second has 0:  ('b', (2, 3))
First has 0, Second has 1:  ('x', (2, 3))

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

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

From report at bugs.python.org  Mon Jan  3 18:56:40 2011
From: report at bugs.python.org (Michael Foord)
Date: Mon, 03 Jan 2011 17:56:40 +0000
Subject: [issue10619] Failed module loading in test discovery loses traceback
In-Reply-To: <1291421664.92.0.199127782586.issue10619@psf.upfronthosting.co.za>
Message-ID: <1294077400.1.0.0113174319257.issue10619@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

Same is true of Python 2.7 - looks like an invalid error report.

----------
resolution:  -> invalid
stage: needs patch -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Mon Jan  3 18:59:06 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 03 Jan 2011 17:59:06 +0000
Subject: [issue9115] test_site: support for systems without unsetenv
In-Reply-To: <1277821678.96.0.414728435775.issue9115@psf.upfronthosting.co.za>
Message-ID: <1294077546.49.0.0645946262403.issue9115@psf.upfronthosting.co.za>


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

Fixed in r87691 (py3k), r87693 (3.1) and r87694 (2.7), thanks!

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

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

From report at bugs.python.org  Mon Jan  3 19:00:16 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 03 Jan 2011 18:00:16 +0000
Subject: [issue10814] assertion failed on Windows buildbots
In-Reply-To: <1294063427.37.0.763229574949.issue10814@psf.upfronthosting.co.za>
Message-ID: <1294077616.69.0.35618144944.issue10814@psf.upfronthosting.co.za>


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

The 3.1 buildbot is green:

http://www.python.org/dev/buildbot/all/builders/x86%20XP-4%203.1/builds/1591

Committed 2.7 backport in r87692.

----------

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

From report at bugs.python.org  Mon Jan  3 19:12:00 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 03 Jan 2011 18:12:00 +0000
Subject: [issue1674555] sys.path in tests contains system directories
Message-ID: <1294078320.1.0.722616310809.issue1674555@psf.upfronthosting.co.za>


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

I agree with Martin here.
Also, since test_site is a special case here, perhaps it could arrange to launch its test cases in a subprocess? I don't think complicating regrtest is the most maintainable approach.

----------

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

From report at bugs.python.org  Mon Jan  3 19:19:56 2011
From: report at bugs.python.org (Michael Foord)
Date: Mon, 03 Jan 2011 18:19:56 +0000
Subject: [issue10620] `python -m uniittest` should work with file paths as
	well as test module names
In-Reply-To: <1291422007.54.0.147727211127.issue10620@psf.upfronthosting.co.za>
Message-ID: <1294078796.22.0.962165421747.issue10620@psf.upfronthosting.co.za>


Changes by Michael Foord <michael at voidspace.org.uk>:


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

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

From report at bugs.python.org  Mon Jan  3 19:29:18 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 03 Jan 2011 18:29:18 +0000
Subject: [issue10813] Suppress adding decimal point for places=0 in moneyfmt()
In-Reply-To: <1294059487.44.0.656415691247.issue10813@psf.upfronthosting.co.za>
Message-ID: <1294079358.74.0.228065815635.issue10813@psf.upfronthosting.co.za>


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


----------
assignee: docs at python -> rhettinger
nosy: +rhettinger

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

From report at bugs.python.org  Mon Jan  3 19:31:08 2011
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 03 Jan 2011 18:31:08 +0000
Subject: [issue6610] Subprocess descriptor debacle
In-Reply-To: <1249000024.51.0.280381658662.issue6610@psf.upfronthosting.co.za>
Message-ID: <1294079468.19.0.53142730093.issue6610@psf.upfronthosting.co.za>


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

Superseded by #10806.

----------
nosy: +georg.brandl
resolution:  -> duplicate
status: open -> closed
superseder:  -> Subprocess error if fds 0,1,2 are closed

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

From report at bugs.python.org  Mon Jan  3 19:47:22 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 03 Jan 2011 18:47:22 +0000
Subject: [issue10806] Subprocess error if fds 0,1,2 are closed
In-Reply-To: <1293991717.46.0.660046429073.issue10806@psf.upfronthosting.co.za>
Message-ID: <1294080442.44.0.991066092882.issue10806@psf.upfronthosting.co.za>


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

Committed in r87695 (3.2), r87696 (3.1) and r87697 (2.7).

----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
versions: +Python 2.7, Python 3.1

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

From report at bugs.python.org  Mon Jan  3 19:47:40 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 03 Jan 2011 18:47:40 +0000
Subject: [issue9905] subprocess.Popen fails with stdout=PIPE,
	stderr=PIPE if standard descriptors (0, 1, 2) are closed.
In-Reply-To: <1285005576.46.0.387895977213.issue9905@psf.upfronthosting.co.za>
Message-ID: <1294080460.72.0.732652167688.issue9905@psf.upfronthosting.co.za>


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

Fixed in issue10806.

----------
nosy: +pitrou
resolution:  -> duplicate
status: open -> closed
superseder:  -> Subprocess error if fds 0,1,2 are closed

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

From report at bugs.python.org  Mon Jan  3 19:58:08 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 03 Jan 2011 18:58:08 +0000
Subject: [issue7716] IPv6 detection,
	don't assume existence of /usr/xpg4/bin/grep
In-Reply-To: <1263666299.94.0.843434843075.issue7716@psf.upfronthosting.co.za>
Message-ID: <1294081088.04.0.795135527335.issue7716@psf.upfronthosting.co.za>


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

Thank you for the patch! It is committed in r87698 (3.2), r87699 (3.1) and r87700 (2.7).

----------
nosy: +pitrou
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
versions:  -Python 2.6

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

From report at bugs.python.org  Mon Jan  3 20:00:54 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 03 Jan 2011 19:00:54 +0000
Subject: [issue10814] assertion failed on Windows buildbots
In-Reply-To: <1294063427.37.0.763229574949.issue10814@psf.upfronthosting.co.za>
Message-ID: <1294081254.85.0.2550957059.issue10814@psf.upfronthosting.co.za>


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

2.7 buildbot is green as well.  Closing.

http://www.python.org/dev/buildbot/all/builders/x86%20XP-4%202.7

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

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

From report at bugs.python.org  Mon Jan  3 20:01:01 2011
From: report at bugs.python.org (Matthias Klose)
Date: Mon, 03 Jan 2011 19:01:01 +0000
Subject: [issue1674555] sys.path in tests contains system directories
Message-ID: <1294081261.47.0.650875582289.issue1674555@psf.upfronthosting.co.za>


Matthias Klose <doko at debian.org> added the comment:

The java/openjdk tests allow setting an attribute `samevm' for running a specific test.  maybe something like this could be used for some problematic tests which occasionally hang on some buildds?

----------

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

From report at bugs.python.org  Mon Jan  3 20:03:27 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 03 Jan 2011 19:03:27 +0000
Subject: [issue10805] traceback.print_exception throws AttributeError when
	exception is None
In-Reply-To: <1293978231.38.0.946265028499.issue10805@psf.upfronthosting.co.za>
Message-ID: <1294081407.84.0.376750079731.issue10805@psf.upfronthosting.co.za>


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

Well, under 2.x, print_traceback(None, None, None) would just print "None", but I'm not sure that's a supported use case.

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

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

From report at bugs.python.org  Mon Jan  3 20:09:50 2011
From: report at bugs.python.org (R. David Murray)
Date: Mon, 03 Jan 2011 19:09:50 +0000
Subject: [issue4953] cgi module cannot handle POST with multipart/form-data
	in	3.0
In-Reply-To: <1232010166.79.0.972664060868.issue4953@psf.upfronthosting.co.za>
Message-ID: <1294081790.24.0.510533355733.issue4953@psf.upfronthosting.co.za>


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

Yes, that is my suggestion.  Keep in mind that I haven't looked at the patch or run any tests yet :)

If windows-specific hacks are needed to get the binary stream in 3.x, then IMO that's a bug in IO.  As far as I know at the moment there's no such bug :)

----------

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

From report at bugs.python.org  Mon Jan  3 20:34:45 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 03 Jan 2011 19:34:45 +0000
Subject: [issue7995] On Mac / BSD sockets returned by accept inherit the
	parent's FD flags
In-Reply-To: <1294012364.96.0.87043740472.issue7995@psf.upfronthosting.co.za>
Message-ID: <1294083266.3703.0.camel@localhost.localdomain>


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

> I like the logic of Antoine's patch much better (basing this on
> whether the listening socket had a timeout). I wonder whether it's
> correct though if there is a defaulttimeout: shouldn't it then leave
> the timeout on the socket instead?

Indeed, so I'll try to make the patch better.

----------

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

From report at bugs.python.org  Mon Jan  3 20:35:04 2011
From: report at bugs.python.org (Ron Adam)
Date: Mon, 03 Jan 2011 19:35:04 +0000
Subject: [issue10818] pydoc: refactorize duplicate DocHandler and DocServer
	classes
In-Reply-To: <1294071441.53.0.907267492881.issue10818@psf.upfronthosting.co.za>
Message-ID: <1294083304.08.0.252251142217.issue10818@psf.upfronthosting.co.za>


Ron Adam <ron_adam at users.sourceforge.net> added the comment:

No refactoring is needed.

The second copies are part of the new server.  The old server was depreciated in 3.2 and is supposed to be removed along with the tk panel for 3.3.  After that there will only be one of each again.

This issue can be used for that purpose.

----------

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

From report at bugs.python.org  Mon Jan  3 20:37:46 2011
From: report at bugs.python.org (R. David Murray)
Date: Mon, 03 Jan 2011 19:37:46 +0000
Subject: [issue1674555] sys.path in tests contains system directories
Message-ID: <1294083466.7.0.360526440399.issue1674555@psf.upfronthosting.co.za>


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

Yeah, making a generic way to put specific tests into a subprocess run sounds like a better solution.

But...

The xml error in test___all__ is due to the fact that test___all__ imports site.  So even with the above we'd need to special case site in test___all__.  This probably answers the question of why more tests show as changing the environment when run with -S -s, so there are probably other tests that would need to be touched as well.

This is becoming a bit of a jerry-rig.  Anyone have a better idea?  A way to identify the "system paths" (or, conversely, identify the paths *not* added by site) and delete them in regrtest before running the tests might be cleaner.

Or another idea: change site so that it does not execute on import, but instead the machinery that currently imports test site runs a 'setup' function after it does the import.  If test_site were then to test the setup function and take care to restore sys.path when it was done, I think things would work as expected if all tests were run with -S -s.  Of course, this would break all the custom site.py's out there, so it is probably a non-starter of an idea.

In the meantime, test___all__ could perhaps be made more robust in the face of import errors/warnings for those few modules that import from external libraries (xml, logging...anything else?)

----------

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

From report at bugs.python.org  Mon Jan  3 20:43:49 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 03 Jan 2011 19:43:49 +0000
Subject: [issue1674555] sys.path in tests contains system directories
In-Reply-To: <1294083466.7.0.360526440399.issue1674555@psf.upfronthosting.co.za>
Message-ID: <1294083821.3703.5.camel@localhost.localdomain>


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

Le lundi 03 janvier 2011 ? 19:37 +0000, R. David Murray a ?crit :
> Or another idea: change site so that it does not execute on import,
> but instead the machinery that currently imports test site runs a
> 'setup' function after it does the import.

I'm not sure this means anything :) Importing a module automatically
entails running its top-level code (that's the only way it can create
functions, classes, etc.).

However, I agree that in the default site.py, we could stop calling
main() at the top-level and instead call it from the importing code.

> Of course, this would break all the custom site.py's out there, so it
> is probably a non-starter of an idea.

Are there many of them? And usually, you would take the original site.py
and modify it a little. Starting from scratch sounds crazy.

> In the meantime, test___all__ could perhaps be made more robust in the
> face of import errors/warnings for those few modules that import from
> external libraries (xml, logging...anything else?)

Well, ideally, these modules should stop importing external libraries
implicitly. Give them a dedicated function for that instead, that the
user can call if they want to.

----------

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

From report at bugs.python.org  Mon Jan  3 20:49:32 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 03 Jan 2011 19:49:32 +0000
Subject: [issue7946] Convoy effect with I/O bound threads and New GIL
In-Reply-To: <1266353325.38.0.278549753357.issue7946@psf.upfronthosting.co.za>
Message-ID: <1294084172.92.0.598410636829.issue7946@psf.upfronthosting.co.za>


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


----------
priority: high -> low
versions:  -Python 3.2

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

From report at bugs.python.org  Mon Jan  3 20:50:23 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 03 Jan 2011 19:50:23 +0000
Subject: [issue444582] Finding programs in PATH, adding shutil.which
Message-ID: <1294084223.86.0.159271835867.issue444582@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Mon Jan  3 20:50:28 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 03 Jan 2011 19:50:28 +0000
Subject: [issue444582] Finding programs in PATH, adding shutil.which
Message-ID: <1294084228.93.0.753253825765.issue444582@psf.upfronthosting.co.za>


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


----------
resolution: accepted -> 

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

From report at bugs.python.org  Mon Jan  3 20:52:15 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 03 Jan 2011 19:52:15 +0000
Subject: [issue10566] gdb debugging support additions (Tools/gdb/libpython.py)
In-Reply-To: <1290962543.45.0.132664091788.issue10566@psf.upfronthosting.co.za>
Message-ID: <1294084335.09.0.395013739769.issue10566@psf.upfronthosting.co.za>


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


----------
stage:  -> patch review
versions: +Python 3.3 -Python 3.2

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

From report at bugs.python.org  Mon Jan  3 20:53:39 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 03 Jan 2011 19:53:39 +0000
Subject: [issue10516] Add list.clear() and list.copy()
In-Reply-To: <1290555468.47.0.0329661397161.issue10516@psf.upfronthosting.co.za>
Message-ID: <1294084419.51.0.386649322678.issue10516@psf.upfronthosting.co.za>


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


----------
stage: unit test needed -> needs patch

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

From report at bugs.python.org  Mon Jan  3 20:53:51 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 03 Jan 2011 19:53:51 +0000
Subject: [issue9216] FIPS support for hashlib
In-Reply-To: <1278721335.16.0.522410247151.issue9216@psf.upfronthosting.co.za>
Message-ID: <1294084431.66.0.80107186437.issue9216@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Mon Jan  3 20:56:20 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 03 Jan 2011 19:56:20 +0000
Subject: [issue444582] Finding programs in PATH, adding shutil.which
Message-ID: <1294084580.46.0.520386592345.issue444582@psf.upfronthosting.co.za>


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

Sandro: I merely did some bug triage here.  I will let interested parties come to an agreement, and Tarek will make the decisions on this request.

----------

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

From report at bugs.python.org  Mon Jan  3 20:57:11 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 03 Jan 2011 19:57:11 +0000
Subject: [issue10673] multiprocess.Process join method - timeout
	indistinguishable from success
In-Reply-To: <1291991778.63.0.145134143934.issue10673@psf.upfronthosting.co.za>
Message-ID: <1294084631.44.0.12873586285.issue10673@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Mon Jan  3 20:58:49 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 03 Jan 2011 19:58:49 +0000
Subject: [issue5673] Add timeout option to subprocess.Popen
In-Reply-To: <1238701276.41.0.515283298202.issue5673@psf.upfronthosting.co.za>
Message-ID: <1294084729.05.0.776607678154.issue5673@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Mon Jan  3 21:02:27 2011
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 03 Jan 2011 20:02:27 +0000
Subject: [issue10563] Spurious newline in time.ctime
In-Reply-To: <1290959240.08.0.913009457798.issue10563@psf.upfronthosting.co.za>
Message-ID: <1294084947.73.0.747745353299.issue10563@psf.upfronthosting.co.za>


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

This has now been superseded by the changes made for issue #8013.

----------
nosy: +georg.brandl
resolution:  -> out of date
status: open -> closed
superseder:  -> time.asctime segfaults when given a time in the far future

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

From report at bugs.python.org  Mon Jan  3 21:03:23 2011
From: report at bugs.python.org (R. David Murray)
Date: Mon, 03 Jan 2011 20:03:23 +0000
Subject: [issue1674555] sys.path in tests contains system directories
Message-ID: <1294085003.25.0.815430881673.issue1674555@psf.upfronthosting.co.za>


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

Ah, I hadn't looked closely enough at site.py to realize that the init work was being done by a 'main()' call.  Given that, just moving the main call out should be relatively unlikely to break any custom site.py.  Worse case would presumably be main() getting called twice, which could be annoying but probably not catastrophic.  One would like to think that anyone customizing site.py would redo the customization for a major release and would notice. (And no, I don't know how common customized site.py's are.)

Logging already only does its import if you construct an NTEventLogHandler, so that's probably safe enough.  Changing xml to require a function call might make some people mad, and other people happy...

I wonder if there are any other stdlib modules that do these kinds of external imports.  I suppose we can just fix xml and wait for additional bug reports :)

I'm not sure either of these changes (site.py-call or xml-activate-xmlplus) should be backported, though, assuming we go ahead with them.

----------

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

From report at bugs.python.org  Mon Jan  3 21:04:35 2011
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Mon, 03 Jan 2011 20:04:35 +0000
Subject: [issue9671] test_executable_without_cwd fails: AssertionError: 1 != 47
In-Reply-To: <1293823473.77.0.561010712704.issue9671@psf.upfronthosting.co.za>
Message-ID: <4D222BCE.2020404@activestate.com>


Sridhar Ratnakumar <sridharr at activestate.com> added the comment:

Sandro Tosi wrote:
> Sridhar, are you still seeing this error?

I still see the error with Python 2.7.1.

----------

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

From report at bugs.python.org  Mon Jan  3 21:06:04 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 03 Jan 2011 20:06:04 +0000
Subject: [issue3548] subprocess.pipe function
In-Reply-To: <1218561839.36.0.810217326739.issue3548@psf.upfronthosting.co.za>
Message-ID: <1294085164.31.0.800767312822.issue3548@psf.upfronthosting.co.za>


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

I think this would be more useful if you could pass an optional input string (as in communicate()) and if it returned a (stdout, stderr) tuple. Or perhaps even a (return code, stdout, stderr) tuple; alternately, non-zero return codes could raise an exception.

----------
nosy: +pitrou
versions: +Python 3.3 -Python 3.2

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

From report at bugs.python.org  Mon Jan  3 21:07:22 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 03 Jan 2011 20:07:22 +0000
Subject: [issue9263] Try to print repr() when an C-level assert fails (in the
	garbage collector, beyond?)
In-Reply-To: <1279151450.93.0.973335817084.issue9263@psf.upfronthosting.co.za>
Message-ID: <1294085242.3.0.144279523193.issue9263@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Mon Jan  3 21:14:25 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 03 Jan 2011 20:14:25 +0000
Subject: [issue10227] Improve performance of MemoryView slicing
In-Reply-To: <1288342228.97.0.170566139041.issue10227@psf.upfronthosting.co.za>
Message-ID: <1294085665.23.0.342947473581.issue10227@psf.upfronthosting.co.za>


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


----------
assignee:  -> mark.dickinson
nosy: +mark.dickinson
versions: +Python 3.3 -Python 3.2

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

From report at bugs.python.org  Mon Jan  3 21:16:17 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 03 Jan 2011 20:16:17 +0000
Subject: [issue5840] "Thread State and the Global Interpreter Lock" section of
	the docs doesn't cover TLS APIs
In-Reply-To: <1240664318.91.0.855784600353.issue5840@psf.upfronthosting.co.za>
Message-ID: <1294085777.83.0.995832697269.issue5840@psf.upfronthosting.co.za>


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

Actually, I don't think the TLS APIs should be documented. They are quite internal, and used only for the PyGILState APIs.

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

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

From report at bugs.python.org  Mon Jan  3 21:17:38 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 03 Jan 2011 20:17:38 +0000
Subject: [issue10079] idlelib for Python 3 with Guilherme Polo GSoC
	enhancements
In-Reply-To: <1286939996.87.0.346411752414.issue10079@psf.upfronthosting.co.za>
Message-ID: <1294085858.37.0.235085493632.issue10079@psf.upfronthosting.co.za>


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

Ping. IDLE dead again?

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

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

From report at bugs.python.org  Mon Jan  3 21:19:17 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 03 Jan 2011 20:19:17 +0000
Subject: [issue7425] [PATCH] Improve the robustness of "pydoc -k" in the face
	of broken modules
In-Reply-To: <1259786972.24.0.35920903506.issue7425@psf.upfronthosting.co.za>
Message-ID: <1294085957.54.0.683618839451.issue7425@psf.upfronthosting.co.za>


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


----------
stage: unit test needed -> patch review
versions: +Python 2.7, Python 3.1, Python 3.2 -Python 2.6

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

From report at bugs.python.org  Mon Jan  3 21:19:19 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 03 Jan 2011 20:19:19 +0000
Subject: [issue8013] time.asctime segfaults when given a time in the far future
In-Reply-To: <1267031714.43.0.416052646257.issue8013@psf.upfronthosting.co.za>
Message-ID: <1294085959.95.0.108144012568.issue8013@psf.upfronthosting.co.za>


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

Attached patch, issue8013-pre-check.diff, checks for year range before calling system asctime and replaces a call to ctime with a asctime(localtime(..)).

----------
stage: needs patch -> commit review
Added file: http://bugs.python.org/file20243/issue8013-pre-check.diff

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

From report at bugs.python.org  Mon Jan  3 21:20:09 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 03 Jan 2011 20:20:09 +0000
Subject: [issue1195571] simple callback system for Py_FatalError
Message-ID: <1294086009.79.0.415047041355.issue1195571@psf.upfronthosting.co.za>


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


----------
nosy: +haypo
versions: +Python 3.3 -Python 3.2

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

From report at bugs.python.org  Mon Jan  3 21:22:04 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 03 Jan 2011 20:22:04 +0000
Subject: [issue6664] readlines should understand Line Separator and Paragraph
	Separator characters
In-Reply-To: <1249636455.06.0.336549280075.issue6664@psf.upfronthosting.co.za>
Message-ID: <1294086124.41.0.531834982864.issue6664@psf.upfronthosting.co.za>


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

By design, readlines() only recognizes those characters which are official line separators on various OSes (\n, \r, \r\n). This is important for proper parsing of log files, internet protocols, etc.
If you want to split on all line separators recognized by the unicode spec, use str.splitlines().

----------
resolution:  -> rejected
status: open -> closed

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

From report at bugs.python.org  Mon Jan  3 21:24:10 2011
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 03 Jan 2011 20:24:10 +0000
Subject: [issue10238] ctypes not building under OS X 10.6 with LLVM/Clang 2.8
In-Reply-To: <1288391275.39.0.918201255477.issue10238@psf.upfronthosting.co.za>
Message-ID: <1294086250.34.0.623768479952.issue10238@psf.upfronthosting.co.za>


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

This is still failing. I also just confirmed it is also happening for 3.1 and 2.7.

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

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

From report at bugs.python.org  Mon Jan  3 21:27:10 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 03 Jan 2011 20:27:10 +0000
Subject: [issue5840] "Thread State and the Global Interpreter Lock" section of
	the docs doesn't cover TLS APIs
In-Reply-To: <1240664318.91.0.855784600353.issue5840@psf.upfronthosting.co.za>
Message-ID: <1294086430.58.0.449403374465.issue5840@psf.upfronthosting.co.za>


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

They are used by pyOpenSSL and pygobject/pyglib, though :/

----------

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

From report at bugs.python.org  Mon Jan  3 21:27:44 2011
From: report at bugs.python.org (Jan Killian)
Date: Mon, 03 Jan 2011 20:27:44 +0000
Subject: [issue444582] Finding programs in PATH, adding shutil.which
Message-ID: <1294086464.11.0.68157135454.issue444582@psf.upfronthosting.co.za>


Jan Killian <jan.killian at gmail.com> added the comment:

Hello All,

sorry for lack of communication recently, I'd alos like to see it in 3.2 instead of 3.3, but my time is not as scalable as I wish and I can't run on clouds yet .)

I like Trent's module and especially its usefullness via the commandline. I'm also happy about learning on "SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\App Paths\\" key, and did reimplement it in my module (with optional static=True parameter to cache the key and parsed path instead of querying and parsing them on each run).

For inclusion in shutil, I'd imho prefer the interface chosen here, ie. which_files() returns generator, which() returns first match, or raises IOError(errno.ENOENT), but that's my opinion only. There's also adapted the default extension list to match the given Windows version, which helps resembling the real command execution behavior.

The escape+quote chars in path are an interesting problem. I wrote a simple test for them to find out the behavior on Windows XP/7 and Linux, and will do the correct implementation and tests later this week.

----------

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

From report at bugs.python.org  Mon Jan  3 21:28:55 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 03 Jan 2011 20:28:55 +0000
Subject: [issue10238] ctypes not building under OS X 10.6 with LLVM/Clang 2.8
In-Reply-To: <1288391275.39.0.918201255477.issue10238@psf.upfronthosting.co.za>
Message-ID: <1294086535.48.0.608353845989.issue10238@psf.upfronthosting.co.za>


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


----------
nosy: +jyasskin

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

From report at bugs.python.org  Mon Jan  3 21:43:16 2011
From: report at bugs.python.org (Gregory P. Smith)
Date: Mon, 03 Jan 2011 20:43:16 +0000
Subject: [issue7978] SocketServer doesn't handle syscall interruption
In-Reply-To: <1266779695.23.0.617672066685.issue7978@psf.upfronthosting.co.za>
Message-ID: <1294087396.89.0.712047838587.issue7978@psf.upfronthosting.co.za>


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

I've added some code comments on http://bugs.python.org/review/7978/show

overall I think the patch is right, I pointed out one thing to clean up and I think the unittest can be greatly simplified by using stubbed out mock select.select() instead of fork+signals+sleeping.

----------

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

From report at bugs.python.org  Mon Jan  3 21:45:28 2011
From: report at bugs.python.org (Glenn Linderman)
Date: Mon, 03 Jan 2011 20:45:28 +0000
Subject: [issue4953] cgi module cannot handle POST with multipart/form-data
	in	3.0
In-Reply-To: <1232010166.79.0.972664060868.issue4953@psf.upfronthosting.co.za>
Message-ID: <1294087528.97.0.97577620627.issue4953@psf.upfronthosting.co.za>


Glenn Linderman <v+python at g.nevcal.com> added the comment:

David, Starting from a working (but hacked to work) version of http.server and using 3.2a1 (I should upgrade to the Beta, but I doubt it makes a difference at the moment), I modified

        # if hasattr( sys.stdin, 'buffer'):
        #     sys.stdin = sys.stdin.buffer
        sys.stdin = sys.stdin.detach()

and it all kept working.

Then I took out the

    try: # Windows needs stdio set for binary mode.
        import msvcrt
        msvcrt.setmode (0, os.O_BINARY) # stdin  = 0
        msvcrt.setmode (1, os.O_BINARY) # stdout = 1
        msvcrt.setmode (2, os.O_BINARY) # stderr = 2
    except ImportError:
        pass

and it quit working.  Seems that \r\r\n\r\r\n is not recognized by Firefox as the "end of the headers" delimiter.

Whether this is a bug in IO or not, I can't say for sure.  It does seem, though, that

1) If Python is fully replacing the IO layers, which in 3.x it seems to claim to, then it should fully replace them, building on a binary byte stream, not a "binary byte stream with replacement of \n by \r\n".  The Windows hack above replaces, for stdin, stdout, and stderr, a "binary byte stream with replacement of \n by \r\n" with a binary byte stream.  Seems like Python should do that, on Windows, so that it has a chance of actually knowing/controlling what gets generated.  Perhaps it does, if started with "-u", but starting with "-u" should not be a requirement for a properly functioning program. Alternately, the IO streams could understand, and toggle the os.O_BINARY flag, but that seems like it would require more platform-specific code than simply opening all Windows files (and adjusting preopened Windows files) during initialization.

2) The weird CGI processing that exists in the released version of http.server seems to cover up this problem, partly because it isn't very functional, claims "alternate semantics" (read: non-standard semantics), and invokes Python with -u when it does do so.  It is so non-standard that it isn't clear what should or should not be happening.  But the CGI scripts I am running, that pass or fail as above, also run on Windows 2.6, and particularly, Unix 2.6, in an Apache environment.  So I have been trying to minimize the differences to startup code, rather than add platform-specific tweaks throughout the CGI scripts.

That said, it clearly could be my environment, but I've debugged enough different versions of things to think that the Windows hack above is required on both 2.x and 3.x to ensure proper bytestreams.... and others must think so too, because I found the code by searching on Google, not because I learned enough Python internals to figure it out on my own.  The question I'm attempting to address here, is only that 3.x still needs the same hack that 2.x needs, on Windows, to create bytestreams.

----------

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

From report at bugs.python.org  Mon Jan  3 21:48:27 2011
From: report at bugs.python.org (Gregory P. Smith)
Date: Mon, 03 Jan 2011 20:48:27 +0000
Subject: [issue6643] Throw away more radioactive locks that could be held
	across a fork in threading.py
In-Reply-To: <1249412209.9.0.200329347238.issue6643@psf.upfronthosting.co.za>
Message-ID: <1294087707.2.0.335722071685.issue6643@psf.upfronthosting.co.za>


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

fwiw a unified fork-and-exec API implemented in C is what I added in Modules/_posixsubprocess.c to at least avoid this issue as much as possible when using subprocess.

----------

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

From report at bugs.python.org  Mon Jan  3 21:51:03 2011
From: report at bugs.python.org (Glenn Linderman)
Date: Mon, 03 Jan 2011 20:51:03 +0000
Subject: [issue4953] cgi module cannot handle POST with multipart/form-data
	in	3.0
In-Reply-To: <1232010166.79.0.972664060868.issue4953@psf.upfronthosting.co.za>
Message-ID: <1294087863.33.0.0914154392199.issue4953@psf.upfronthosting.co.za>


Glenn Linderman <v+python at g.nevcal.com> added the comment:

(and I should mention that all the "hacked to work" issues in my copy of http.server have been reported as bugs, on 2010-11-21. The ones of most interest related to this binary bytestream stuff are issue 10479 and issue 10480)

----------

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

From report at bugs.python.org  Mon Jan  3 21:52:21 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 03 Jan 2011 20:52:21 +0000
Subject: [issue6293] Have regrtest.py echo back sys.flags
In-Reply-To: <1245173731.34.0.991251966726.issue6293@psf.upfronthosting.co.za>
Message-ID: <1294087941.77.0.297654912976.issue6293@psf.upfronthosting.co.za>


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

A variant of the patch was committed in r87704 (3.2), r87706 (3.1) and r87707 (2.7). Thank you.

----------
nosy: +pitrou
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed
versions: +Python 3.1, Python 3.2

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

From report at bugs.python.org  Mon Jan  3 21:58:20 2011
From: report at bugs.python.org (SilentGhost)
Date: Mon, 03 Jan 2011 20:58:20 +0000
Subject: [issue8013] time.asctime segfaults when given a time in the far future
In-Reply-To: <1267031714.43.0.416052646257.issue8013@psf.upfronthosting.co.za>
Message-ID: <1294088300.35.0.0852933210318.issue8013@psf.upfronthosting.co.za>


SilentGhost <michael.mischurow+bpo at gmail.com> added the comment:

All tests pass and all works as documented with the latest patch on Ubuntu (glibc 2.11).

----------

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

From report at bugs.python.org  Mon Jan  3 22:01:18 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 03 Jan 2011 21:01:18 +0000
Subject: [issue10809] complex() comments wrongly say it supports NaN and inf
In-Reply-To: <1294003292.33.0.779224851357.issue10809@psf.upfronthosting.co.za>
Message-ID: <1294088478.24.0.57387123417.issue10809@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/issue10809>
_______________________________________

From report at bugs.python.org  Mon Jan  3 22:07:46 2011
From: report at bugs.python.org (Gregory P. Smith)
Date: Mon, 03 Jan 2011 21:07:46 +0000
Subject: [issue6643] Throw away more radioactive locks that could be held
	across a fork in threading.py
In-Reply-To: <1249412209.9.0.200329347238.issue6643@psf.upfronthosting.co.za>
Message-ID: <1294088866.59.0.552226917703.issue6643@psf.upfronthosting.co.za>


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

patch looks good.  committed in r87710 for 3.2.  needs back porting to 3.1 and 2.7 and optionally 2.6.

----------
assignee: rnk -> gregory.p.smith
resolution:  -> accepted

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

From report at bugs.python.org  Mon Jan  3 22:12:55 2011
From: report at bugs.python.org (Pierre Quentel)
Date: Mon, 03 Jan 2011 21:12:55 +0000
Subject: [issue4953] cgi module cannot handle POST with multipart/form-data
	in	3.0
In-Reply-To: <1232010166.79.0.972664060868.issue4953@psf.upfronthosting.co.za>
Message-ID: <1294089175.75.0.289222255123.issue4953@psf.upfronthosting.co.za>


Pierre Quentel <pierre.quentel at gmail.com> added the comment:

Other version of the diff file. Nothing changed but I'm afraid I had left duplicate definitions of some methods in the FieldStorage class
I follow the discussion on this thread, but would like to know if the patch has been tested and works

----------
Added file: http://bugs.python.org/file20244/cgi_diff.txt

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

From report at bugs.python.org  Mon Jan  3 22:13:14 2011
From: report at bugs.python.org (Dev Player)
Date: Mon, 03 Jan 2011 21:13:14 +0000
Subject: [issue10060] python.exe crashes or hangs on help() modules when bad
	modules found
In-Reply-To: <1294062298.52.0.453221053133.issue10060@psf.upfronthosting.co.za>
Message-ID: <AANLkTinDaTZtaJp3xDgYOw3GSkL1pNUx0AF7SBUHEU6Q@mail.gmail.com>


Dev Player <devplayer at gmail.com> added the comment:

It was suggested that a corrupt package would be where I'm experiencing the
lockup or crash of python.exe when issuing help() and then "modules". And
that if I or someone could verify that a corrupt package has this effect by
creating a corrupt package. I have not figured out how to make a package let
a lone a corrupt one. I think the following traceback points to my pywin32
being corrupt. Although I've downloaded that package from sourceforge more
then twice and reinstalled that package.

I included the information in the previous posts in case it helps in the
following mannger;
I expect others here in this forum are likely to have pywin32 version 214
installed. They could compare what I get from the traceback (returned when
using help() modules) the "dir(win32ui.GetMainFrame)" with what they have.
So that if they get something different with their dir(win32ui.GetmainFrame)
then we at least are more sure of where this issue is occuring.

Why does python.exe help() fail when an object, in this case win32ui, in the
traceback does not have a certain attribute, GetMainframe?

The dir() outputs in my previous posts show an object pywin32 package
doesn't have all the expected member attributes. It calls
win32ui.GetMainFrame.GetWindowText() method which doesn't exist.

Why would help() fail on that?
I'm no expert but I figured the information could help point someone in the
right direction.

BTW I've created a ticket in the pywin32 at sourceforge.net. - Because I
only suspect it's a corrupt package, I'm not sure and thought others there
would be able to tell me if it's the distro file or my installation.

Traceback reprinted:

Traceback (most recent call last):
  File "<input>", line 1, in <module>
  File "Q:\Python27\lib\site.py", line 453, in __call__
    return pydoc.help(*args, **kwds)
  File "Q:\Python27\lib\pydoc.py", line 1723, in __call__
    self.interact()
  File "Q:\Python27\lib\pydoc.py", line 1735, in interact
    request = self.getline('help> ')
  File "Q:\Python27\lib\pydoc.py", line 1746, in getline
    return raw_input(prompt)
  File "Q:\Python27\Lib\site-packages\pythonwin\pywin\framework\app.py",
line 367, in Win32RawInput
    ret=dialog.GetSimpleInput(prompt)
  File "Q:\Python27\Lib\site-packages\pythonwin\pywin\mfc\dialog.py", line
223, in GetSimpleInput
    if title is None: title=win32ui.GetMainFrame().GetWindowText()
error: The frame does not exist

----------
Added file: http://bugs.python.org/file20245/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10060>
_______________________________________
-------------- next part --------------
<div>It was suggested that a corrupt package would be where I&#39;m experiencing the lockup or crash of python.exe when issuing help() and then &quot;modules&quot;. And that if I or someone could verify that a corrupt package has this effect by creating a corrupt package. I have not figured out how to make a package let a lone a corrupt one. I think the following traceback points to my pywin32 being corrupt. Although I&#39;ve downloaded that package from sourceforge more then twice and reinstalled that package. </div>

<div>??</div>
<div>I included the information in the previous posts in case it helps in the following mannger;</div>
<div>I expect others here in this forum are likely to have pywin32 version 214 installed. They could compare what I get from the traceback (returned when using help() modules) the &quot;dir(win32ui.GetMainFrame)&quot; with what they have. So that if they get something different??with their dir(win32ui.GetmainFrame) then we at least are more sure of where this issue is occuring.</div>

<div>??</div>
<div>Why does python.exe help() fail when an object, in this case win32ui, in the traceback does not have a certain attribute, GetMainframe?</div>
<div>??</div>
<div>The dir() outputs in my previous posts show an object pywin32??package doesn&#39;t have all the expected member attributes. It calls win32ui.GetMainFrame.GetWindowText() method which doesn&#39;t exist.</div>
<div>??</div>
<div>Why would help() fail on that? </div>
<div>I&#39;m no expert but I figured the information could help point someone in the right direction.</div>
<div>??</div>
<div>BTW I&#39;ve created a ticket in the pywin32 at <a href="http://sourceforge.net">sourceforge.net</a>. - Because I only suspect it&#39;s a corrupt package, I&#39;m not sure and thought others there would be able to tell me if it&#39;s the distro file or my installation.</div>

<div>??</div>
<div>Traceback reprinted:</div>
<div>??</div>
<div>Traceback (most recent call last):<br>?? File &quot;&lt;input&gt;&quot;, line 1, in &lt;module&gt;<br>?? File &quot;Q:\Python27\lib\site.py&quot;, line 453, in __call__<br>?????? return pydoc.help(*args, **kwds)<br>?? File &quot;Q:\Python27\lib\pydoc.py&quot;, line 1723, in __call__<br>
?????? self.interact()<br>?? File &quot;Q:\Python27\lib\pydoc.py&quot;, line 1735, in interact<br>?????? request = self.getline(&#39;help&gt; &#39;)<br>?? File &quot;Q:\Python27\lib\pydoc.py&quot;, line 1746, in getline<br>?????? return raw_input(prompt)<br>
?? File &quot;Q:\Python27\Lib\site-packages\pythonwin\pywin\framework\app.py&quot;, line 367, in Win32RawInput<br>?????? ret=dialog.GetSimpleInput(prompt)<br>?? File &quot;Q:\Python27\Lib\site-packages\pythonwin\pywin\mfc\dialog.py&quot;, line 223, in GetSimpleInput<br>
?????? if title is None: title=win32ui.GetMainFrame().GetWindowText()<br>error: The frame does not exist<br></div>

From report at bugs.python.org  Mon Jan  3 22:16:25 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 03 Jan 2011 21:16:25 +0000
Subject: [issue1187] pipe fd handling issues in subprocess.py on POSIX
In-Reply-To: <1190400129.03.0.21752289973.issue1187@psf.upfronthosting.co.za>
Message-ID: <1294089385.91.0.15020624161.issue1187@psf.upfronthosting.co.za>


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

Additional test modified and committed in r87712, thank you!

----------
nosy: +pitrou
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed
versions:  -Python 2.7, Python 3.1

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

From report at bugs.python.org  Mon Jan  3 22:19:12 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 03 Jan 2011 21:19:12 +0000
Subject: [issue9854] SocketIO should return None on EWOULDBLOCK
In-Reply-To: <1284481211.95.0.424459514211.issue9854@psf.upfronthosting.co.za>
Message-ID: <1294089552.57.0.437278061757.issue9854@psf.upfronthosting.co.za>


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

Was committed in r84887.

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

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

From report at bugs.python.org  Mon Jan  3 22:26:18 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 03 Jan 2011 21:26:18 +0000
Subject: [issue9535] Pending signals are inherited by child processes
In-Reply-To: <1281105795.17.0.408658965128.issue9535@psf.upfronthosting.co.za>
Message-ID: <1294089978.75.0.727466681139.issue9535@psf.upfronthosting.co.za>


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

Shouldn't the clearing of signals be done in PyOS_AfterFork() directly?
Gregory, what do you think about the semantics?

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

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

From report at bugs.python.org  Mon Jan  3 22:40:06 2011
From: report at bugs.python.org (Gregory P. Smith)
Date: Mon, 03 Jan 2011 21:40:06 +0000
Subject: [issue9535] Pending signals are inherited by child processes
In-Reply-To: <1281105795.17.0.408658965128.issue9535@psf.upfronthosting.co.za>
Message-ID: <1294090806.93.0.692619217619.issue9535@psf.upfronthosting.co.za>


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

Doing this makes sense, i'm taking to closer look to see where it should be done.

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

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

From report at bugs.python.org  Mon Jan  3 22:49:21 2011
From: report at bugs.python.org (Ned Deily)
Date: Mon, 03 Jan 2011 21:49:21 +0000
Subject: [issue10079] idlelib for Python 3 with Guilherme Polo GSoC
	enhancements
In-Reply-To: <1286939996.87.0.346411752414.issue10079@psf.upfronthosting.co.za>
Message-ID: <1294091361.24.0.213278130457.issue10079@psf.upfronthosting.co.za>


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

Not dead, just pining for the fjords.  The two versions of the patch as submitted need some work before being ready for review. One issue is that the patches were originally applied to earlier snapshots of IDLE, so some subsequent changes have been reverted in the patches.  Also the patches contains a collection of mostly disparate features and changes: some appear to be straightforwardly compatible while other parts appeared to change existing behavior and may need to be discussed.  Rather than troubling Bruce again, I'd be happy to refresh them and perhaps split them up into more manageable pieces.  I'll try to find some time to do so in the near future.

----------

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

From report at bugs.python.org  Mon Jan  3 22:56:03 2011
From: report at bugs.python.org (=?utf-8?q?Andreas_St=C3=BChrk?=)
Date: Mon, 03 Jan 2011 21:56:03 +0000
Subject: [issue10756] Error in atexit._run_exitfuncs [...] Exception expected
	for value, str found
In-Reply-To: <1293004716.16.0.718567163143.issue10756@psf.upfronthosting.co.za>
Message-ID: <1294091763.95.0.263047116172.issue10756@psf.upfronthosting.co.za>


Andreas St?hrk <andy-python at hammerhartes.de> added the comment:

So I guess someone should feel responsible and commit that patch. For convenience, I updated the patch to inline the raise.

----------
Added file: http://bugs.python.org/file20246/issue10756_normalize_exceptions_v2.diff

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

From report at bugs.python.org  Mon Jan  3 23:18:48 2011
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 03 Jan 2011 22:18:48 +0000
Subject: [issue10756] Error in atexit._run_exitfuncs [...] Exception expected
	for value, str found
In-Reply-To: <1293004716.16.0.718567163143.issue10756@psf.upfronthosting.co.za>
Message-ID: <1294093128.18.0.779532713158.issue10756@psf.upfronthosting.co.za>


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

I think Antoine might be interested.

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

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

From report at bugs.python.org  Mon Jan  3 23:39:47 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 03 Jan 2011 22:39:47 +0000
Subject: [issue10798] test_concurrent_futures fails on FreeBSD
In-Reply-To: <1293740054.42.0.931376139757.issue10798@psf.upfronthosting.co.za>
Message-ID: <1294094387.68.0.398124896532.issue10798@psf.upfronthosting.co.za>


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

test_multiprocessing is still failing with "OSError: [Errno 23] Too many open files in system" on "x86 FreeBSD 7.2 3.x":

http://www.python.org/dev/buildbot/builders/x86%20FreeBSD%207.2%203.x/builds/1396/steps/test/logs/stdio

I don't know the maximum number of POSIX semaphores on this buildbot.

----------
nosy: +haypo

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

From report at bugs.python.org  Mon Jan  3 23:48:26 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 03 Jan 2011 22:48:26 +0000
Subject: [issue5846] Deprecate obsolete functions in unittest
In-Reply-To: <1240703100.05.0.329458142097.issue5846@psf.upfronthosting.co.za>
Message-ID: <1294094906.77.0.593237525938.issue5846@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/issue5846>
_______________________________________

From report at bugs.python.org  Tue Jan  4 00:36:27 2011
From: report at bugs.python.org (Bruce Sherwood)
Date: Mon, 03 Jan 2011 23:36:27 +0000
Subject: [issue10079] idlelib for Python 3 with Guilherme Polo GSoC
	enhancements
In-Reply-To: <1286939996.87.0.346411752414.issue10079@psf.upfronthosting.co.za>
Message-ID: <1294097787.9.0.700728986618.issue10079@psf.upfronthosting.co.za>


Bruce Sherwood <bruce.sherwood at gmail.com> added the comment:

Thanks for the reassurance, Ned. I would be happy to help, but frankly I don't know my way around in IDLE very well, and I pretty much tried simply to get Polo's changes into the hopper. Presumably if you want a view of the separate issues he addressed, you can get some guidance from his GSoC work.

----------

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

From report at bugs.python.org  Tue Jan  4 00:46:01 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Mon, 03 Jan 2011 23:46:01 +0000
Subject: [issue10512] regrtest ResourceWarning - unclosed sockets and files
In-Reply-To: <1290506536.77.0.313292165719.issue10512@psf.upfronthosting.co.za>
Message-ID: <1294098361.43.0.144990752572.issue10512@psf.upfronthosting.co.za>


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

The fix for test_normalization was committed as r87441. As for test_cgi, I still seem to get the leak (also on Linux; Ubuntu 10.10 64-bit). I'll poke around with it some more tomorrow.

In addition to the ResourceWarnings, some of tests have been raising DeprecationWarnings:
* test_unittest
* test_array
* test_httplib (trivial fix - replace assertEquals with assertEqual)

----------

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

From report at bugs.python.org  Tue Jan  4 00:48:54 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 03 Jan 2011 23:48:54 +0000
Subject: [issue10312] intcatcher() can deadlock
In-Reply-To: <1288874942.68.0.464773855859.issue10312@psf.upfronthosting.co.za>
Message-ID: <1294098534.64.0.213679243651.issue10312@psf.upfronthosting.co.za>


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


----------
nosy: +haypo

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

From report at bugs.python.org  Tue Jan  4 00:51:33 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 03 Jan 2011 23:51:33 +0000
Subject: [issue10819] ValueError on repr(closed_socket_file)
In-Reply-To: <1294098693.54.0.480300363848.issue10819@psf.upfronthosting.co.za>
Message-ID: <1294098693.54.0.480300363848.issue10819@psf.upfronthosting.co.za>


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

The following code raise a ValueError('I/O operation on closed file.'):
---
import socket
socket.socket(socket.SOCK_STREAM, socket.AF_INET)
s=socket.socket(socket.SOCK_STREAM, socket.AF_INET)
f=s.makefile("rb")
f.close()
print(repr(f))
---

io.BufferedReader.__repr__() reads self.name (self.buffer.name), but self.buffer is closed.

io.BufferedReader.__repr__() catchs AttributeError when reading self.name. It should also maybe catch ValueError: attached patch does that.

socket.repr(x) returns a string with "[closed]". BufferedReader.repr() should maybe do the same.

Note: TextIOWrapper has the same issue.

----------
components: IO
messages: 125253
nosy: haypo, pitrou
priority: normal
severity: normal
status: open
title: ValueError on repr(closed_socket_file)
versions: Python 3.2

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

From report at bugs.python.org  Tue Jan  4 00:52:10 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 03 Jan 2011 23:52:10 +0000
Subject: [issue10819] ValueError on repr(closed_socket_file)
In-Reply-To: <1294098693.54.0.480300363848.issue10819@psf.upfronthosting.co.za>
Message-ID: <1294098730.55.0.0423678107391.issue10819@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
keywords: +patch
Added file: http://bugs.python.org/file20247/issue10819.patch

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

From report at bugs.python.org  Tue Jan  4 00:59:57 2011
From: report at bugs.python.org (Miki Tebeka)
Date: Mon, 03 Jan 2011 23:59:57 +0000
Subject: [issue3548] subprocess.pipe function
In-Reply-To: <1218561839.36.0.810217326739.issue3548@psf.upfronthosting.co.za>
Message-ID: <1294099197.23.0.4752575085.issue3548@psf.upfronthosting.co.za>


Changes by Miki Tebeka <miki.tebeka at gmail.com>:


----------
nosy:  -tebeka

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

From report at bugs.python.org  Tue Jan  4 01:02:41 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 04 Jan 2011 00:02:41 +0000
Subject: [issue10333] Remove ancient backwards compatibility GC API
In-Reply-To: <1288998341.4.0.536091524037.issue10333@psf.upfronthosting.co.za>
Message-ID: <1294099361.64.0.202540272844.issue10333@psf.upfronthosting.co.za>


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

pyexpat.c needed a little fix (!). Committed in r87718, thank you!

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

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

From report at bugs.python.org  Tue Jan  4 01:05:36 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 04 Jan 2011 00:05:36 +0000
Subject: [issue10512] regrtest ResourceWarning - unclosed sockets and files
In-Reply-To: <1290506536.77.0.313292165719.issue10512@psf.upfronthosting.co.za>
Message-ID: <1294099536.67.0.587124803767.issue10512@psf.upfronthosting.co.za>


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

DeprecationWarnings:
* test_unittest: fixed by r87717
* test_array: fixed by r87719
* test_httplib: fixed by r87720

----------

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

From report at bugs.python.org  Tue Jan  4 01:12:35 2011
From: report at bugs.python.org (Gregory P. Smith)
Date: Tue, 04 Jan 2011 00:12:35 +0000
Subject: [issue4188] test_threading hang when running as verbose
In-Reply-To: <1224793703.28.0.169476277835.issue4188@psf.upfronthosting.co.za>
Message-ID: <1294099955.19.0.212208527268.issue4188@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Tue Jan  4 01:15:12 2011
From: report at bugs.python.org (Gregory P. Smith)
Date: Tue, 04 Jan 2011 00:15:12 +0000
Subject: [issue4188] test_threading hang when running as verbose
In-Reply-To: <1224793703.28.0.169476277835.issue4188@psf.upfronthosting.co.za>
Message-ID: <1294100112.18.0.72156814514.issue4188@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Tue Jan  4 01:17:44 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 04 Jan 2011 00:17:44 +0000
Subject: [issue10819] ValueError on repr(closed_socket_file)
In-Reply-To: <1294098693.54.0.480300363848.issue10819@psf.upfronthosting.co.za>
Message-ID: <1294100264.1.0.207308393484.issue10819@psf.upfronthosting.co.za>


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

Antoine suggested me to patch SocketIO.name property instead of the BufferedReader.__repr__() method: socketio_name.patch implements this idea.

----------
Added file: http://bugs.python.org/file20248/socketio_name.patch

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

From report at bugs.python.org  Tue Jan  4 01:20:02 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 04 Jan 2011 00:20:02 +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: <1294100402.5.0.114550329545.issue10181@psf.upfronthosting.co.za>


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


----------
assignee:  -> mark.dickinson
nosy: +mark.dickinson

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

From report at bugs.python.org  Tue Jan  4 01:31:27 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 04 Jan 2011 00:31:27 +0000
Subject: [issue9671] test_executable_without_cwd fails: AssertionError: 1 != 47
In-Reply-To: <1282668033.06.0.983312258691.issue9671@psf.upfronthosting.co.za>
Message-ID: <1294101087.89.0.753997193946.issue9671@psf.upfronthosting.co.za>


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


----------
nosy: +dmalcolm

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

From report at bugs.python.org  Tue Jan  4 01:32:51 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 04 Jan 2011 00:32:51 +0000
Subject: [issue9611] FileIO not 64-bit safe under Windows
In-Reply-To: <1281893142.91.0.972520708976.issue9611@psf.upfronthosting.co.za>
Message-ID: <1294101171.59.0.294327638422.issue9611@psf.upfronthosting.co.za>


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

As asked by Antoine, I commited my patch: r87722.

... But I don't know if it fixes the issue or not, I don't have access to a Windows with more than 4 GB of memory.

----------

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

From report at bugs.python.org  Tue Jan  4 01:33:30 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 04 Jan 2011 00:33:30 +0000
Subject: [issue10267] test_ttk_guionly leaks many references
In-Reply-To: <1288542306.75.0.249495592657.issue10267@psf.upfronthosting.co.za>
Message-ID: <1294101210.8.0.444873636332.issue10267@psf.upfronthosting.co.za>


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

Patch committed in r87721 (3.2), r87723 (2.7) and r87724 (3.1). Thanks!

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

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

From report at bugs.python.org  Tue Jan  4 01:33:30 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 04 Jan 2011 00:33:30 +0000
Subject: [issue9015] f.write(s) for s > 2GB hangs in win64 (and win32?)
In-Reply-To: <1276730446.48.0.255465495583.issue9015@psf.upfronthosting.co.za>
Message-ID: <1294101210.8.0.135135038239.issue9015@psf.upfronthosting.co.za>


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

r87722 should fix the issue, but I didn't tested the fix... see #9611 for more information.

----------
nosy: +haypo

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

From report at bugs.python.org  Tue Jan  4 01:34:46 2011
From: report at bugs.python.org (Gregory P. Smith)
Date: Tue, 04 Jan 2011 00:34:46 +0000
Subject: [issue8458] buildbot: test_cmd_line failure on Tiger: [Errno 9] Bad
	file descriptor
In-Reply-To: <1271678026.95.0.894433016298.issue8458@psf.upfronthosting.co.za>
Message-ID: <1294101286.3.0.590897370477.issue8458@psf.upfronthosting.co.za>


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

The code surrounding the p2c file descriptors in subprocess has changed a bit recently since this issue was filed.  someone still needs to come up with a way to reproduce it.

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

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

From report at bugs.python.org  Tue Jan  4 01:36:07 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 04 Jan 2011 00:36:07 +0000
Subject: [issue8651] "s#" and friends can silently truncate buffer length
In-Reply-To: <1273253096.48.0.301498355728.issue8651@psf.upfronthosting.co.za>
Message-ID: <1294101367.98.0.556983104676.issue8651@psf.upfronthosting.co.za>


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

Could you add a proper unit test?

----------

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

From report at bugs.python.org  Tue Jan  4 01:39:30 2011
From: report at bugs.python.org (Dave Malcolm)
Date: Tue, 04 Jan 2011 00:39:30 +0000
Subject: [issue9671] test_executable_without_cwd fails: AssertionError: 1 != 47
In-Reply-To: <1282668033.06.0.983312258691.issue9671@psf.upfronthosting.co.za>
Message-ID: <1294101570.79.0.773746876111.issue9671@psf.upfronthosting.co.za>


Dave Malcolm <dmalcolm at redhat.com> added the comment:

Note that for that test case to be run, it must be on an installed python:
    @unittest.skipIf(sysconfig.is_python_build(),
                     "need an installed Python. See #7774")

Am testing the 2.7 branch now on an x86_64 Fedora 13 box

----------

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

From report at bugs.python.org  Tue Jan  4 01:41:07 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 04 Jan 2011 00:41:07 +0000
Subject: [issue8458] buildbot: test_cmd_line failure on Tiger: [Errno 9] Bad
	file descriptor
In-Reply-To: <1271678026.95.0.894433016298.issue8458@psf.upfronthosting.co.za>
Message-ID: <1294101667.02.0.00806610216365.issue8458@psf.upfronthosting.co.za>


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

Well, it occurred today again :)
http://www.python.org/dev/buildbot/all/builders/x86%20Tiger%203.x/builds/1884/steps/test/logs/stdio

test test_cmd_line failed -- Traceback (most recent call last):
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/test/test_cmd_line.py", line 95, in test_run_code
    assert_python_failure('-c')
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/test/script_helper.py", line 57, in assert_python_failure
    return _assert_python(False, *args, **env_vars)
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/test/script_helper.py", line 30, in _assert_python
    env=env)
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/subprocess.py", line 721, in __init__
    self.stdin = io.open(p2cwrite, 'wb', bufsize)
OSError: [Errno 9] Bad file descriptor


But I would suggest an OS X bug instead. My random guess is that the child process exits very quickly (as you see, it runs "python -c" which is an immediate error), therefore the other end of the pipe gets closed and OS X then returns EBADF when we try to do something with our end of the pipe.

----------

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

From report at bugs.python.org  Tue Jan  4 01:45:40 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 04 Jan 2011 00:45:40 +0000
Subject: [issue10000] mark more tests as CPython specific
In-Reply-To: <1285861695.5.0.301447830736.issue10000@psf.upfronthosting.co.za>
Message-ID: <1294101940.32.0.75644718987.issue10000@psf.upfronthosting.co.za>


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

Patch?

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

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

From report at bugs.python.org  Tue Jan  4 01:48:54 2011
From: report at bugs.python.org (Dave Malcolm)
Date: Tue, 04 Jan 2011 00:48:54 +0000
Subject: [issue9671] test_executable_without_cwd fails: AssertionError: 1 != 47
In-Reply-To: <1282668033.06.0.983312258691.issue9671@psf.upfronthosting.co.za>
Message-ID: <1294102134.05.0.718047038541.issue9671@psf.upfronthosting.co.za>


Dave Malcolm <dmalcolm at redhat.com> added the comment:

That test works for me on this x86_64 Fedora 13 box (using latest 2.7 code from SVN, built and installed to a test prefix):

[david at surprise bin]$ ./python -m test.regrtest -v test_subprocess
== CPython 2.7.1+ (release27-maint:87724, Jan 3 2011, 19:39:26) [GCC 4.4.4 20100630 (Red Hat 4.4.4-10)]
==   Linux-2.6.33.3-84.fc13.x86_64-x86_64-with-fedora-13-Goddard little-endian
==   /tmp/test_python_24104
Testing with flags: sys.flags(debug=0, py3k_warning=0, division_warning=0, division_new=0, inspect=0, interactive=0, optimize=0, dont_write_bytecode=0, no_user_site=0, no_site=0, ignore_environment=0, tabcheck=0, verbose=0, unicode=0, bytes_warning=0)
test_subprocess
...
test_executable_without_cwd (test.test_subprocess.ProcessTestCase) ... ok
...
test_executable_without_cwd (test.test_subprocess.ProcessTestCaseNoPoll) ... ok
...

though I do see another failure:
======================================================================
FAIL: test_wait_when_sigchild_ignored (test.test_subprocess.POSIXProcessTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/david/coding/python-svn-anon/2.7-clean/tmp-prefix/lib/python2.7/test/test_subprocess.py", line 841, in test_wait_when_sigchild_ignored
    " non-zero with this error:\n%s" % stderr)
AssertionError: sigchild_ignore.py exited non-zero with this error:
/home/david/coding/python-svn-anon/2.7-clean/tmp-prefix/bin/python: can't open file 'subprocessdata/sigchild_ignore.py': [Errno 2] No such file or directory


----------------------------------------------------------------------
Ran 123 tests in 17.621s

FAILED (failures=1, skipped=14)

----------

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

From report at bugs.python.org  Tue Jan  4 01:51:59 2011
From: report at bugs.python.org (Dave Malcolm)
Date: Tue, 04 Jan 2011 00:51:59 +0000
Subject: [issue9671] test_executable_without_cwd fails: AssertionError: 1 != 47
In-Reply-To: <1282668033.06.0.983312258691.issue9671@psf.upfronthosting.co.za>
Message-ID: <1294102319.66.0.147936344777.issue9671@psf.upfronthosting.co.za>


Dave Malcolm <dmalcolm at redhat.com> added the comment:

I should note that Fedora Core 4 reached its "End of Life" at August 2006:
http://fedoraproject.org/wiki/End_of_life

Do you see this with a more up-to-date version of Fedora?

----------

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

From report at bugs.python.org  Tue Jan  4 01:55:23 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 04 Jan 2011 00:55:23 +0000
Subject: [issue10104] test_socket failures on Debian unstable
In-Reply-To: <1287072573.8.0.312091305807.issue10104@psf.upfronthosting.co.za>
Message-ID: <1294102523.92.0.368031389451.issue10104@psf.upfronthosting.co.za>


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

Fixed some time ago.

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

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

From report at bugs.python.org  Tue Jan  4 01:59:01 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 04 Jan 2011 00:59:01 +0000
Subject: [issue7537] test_format fails with -j combined with -v
In-Reply-To: <1261107735.71.0.830554169199.issue7537@psf.upfronthosting.co.za>
Message-ID: <1294102741.45.0.229798505548.issue7537@psf.upfronthosting.co.za>


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

Seems to work, even when forcing LANG=C.

----------
status: pending -> closed

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

From report at bugs.python.org  Tue Jan  4 02:03:14 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 04 Jan 2011 01:03:14 +0000
Subject: [issue6691] Support for nested classes and function for pyclbr
In-Reply-To: <1250117262.14.0.353515413158.issue6691@psf.upfronthosting.co.za>
Message-ID: <1294102994.48.0.70122512285.issue6691@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Tue Jan  4 02:03:42 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 04 Jan 2011 01:03:42 +0000
Subject: [issue10001] ~Py_buffer.obj field is undocumented, though not hidden
In-Reply-To: <1285868807.58.0.617972550499.issue10001@psf.upfronthosting.co.za>
Message-ID: <1294103022.48.0.840664872016.issue10001@psf.upfronthosting.co.za>


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


----------
nosy: +mark.dickinson, ncoghlan

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

From report at bugs.python.org  Tue Jan  4 02:04:31 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 04 Jan 2011 01:04:31 +0000
Subject: [issue9975] Incorrect use of flowinfo and scope_id in IPv6 sockaddr
	tuple
In-Reply-To: <1285698946.58.0.377750793336.issue9975@psf.upfronthosting.co.za>
Message-ID: <1294103071.35.0.900771975121.issue9975@psf.upfronthosting.co.za>


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


----------
nosy: +exarkun

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

From report at bugs.python.org  Tue Jan  4 02:04:52 2011
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Tue, 04 Jan 2011 01:04:52 +0000
Subject: [issue9671] test_executable_without_cwd fails: AssertionError: 1 != 47
In-Reply-To: <1294102319.66.0.147936344777.issue9671@psf.upfronthosting.co.za>
Message-ID: <4D22722D.1030204@activestate.com>


Sridhar Ratnakumar <sridharr at activestate.com> added the comment:

Dave Malcolm wrote:
> I should note that Fedora Core 4 reached its "End of Life" at August 2006:
> http://fedoraproject.org/wiki/End_of_life
>
> Do you see this with a more up-to-date version of Fedora?

I don't have access to other versions of FC at the moment.

Hmm, if this bug is specific to a EoL'ed version FC, then perhaps this 
issue can be closed as WontFix?

----------

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

From report at bugs.python.org  Tue Jan  4 02:08:27 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 04 Jan 2011 01:08:27 +0000
Subject: [issue1615376] subprocess doesn\'t handle SIGPIPE
Message-ID: <1294103307.3.0.101308832823.issue1615376@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Tue Jan  4 02:10:45 2011
From: report at bugs.python.org (Gregory P. Smith)
Date: Tue, 04 Jan 2011 01:10:45 +0000
Subject: [issue6643] Throw away more radioactive locks that could be held
	across a fork in threading.py
In-Reply-To: <1249412209.9.0.200329347238.issue6643@psf.upfronthosting.co.za>
Message-ID: <1294103445.2.0.34656416898.issue6643@psf.upfronthosting.co.za>


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

r87726 for release31-maint
r87727 for release27-maint - this required a bit more fiddling as _block and _started and _cond were __ private.

----------
versions:  -Python 3.1, Python 3.2

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

From report at bugs.python.org  Tue Jan  4 02:13:01 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 04 Jan 2011 01:13:01 +0000
Subject: [issue1452] subprocess's popen.stdout.seek(0) doesn't raise an error
In-Reply-To: <1195225008.73.0.984849336269.issue1452@psf.upfronthosting.co.za>
Message-ID: <1294103581.27.0.776384760056.issue1452@psf.upfronthosting.co.za>


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

Looks like it's a platform bug, nothing Python can do about.

----------
nosy: +pitrou
resolution:  -> rejected
status: open -> closed

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

From report at bugs.python.org  Tue Jan  4 02:20:56 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 04 Jan 2011 01:20:56 +0000
Subject: [issue9660] PEP 383: socket module doesn't handle undecodable
	protocol or service names
In-Reply-To: <1282501562.64.0.000983913636939.issue9660@psf.upfronthosting.co.za>
Message-ID: <1294104056.07.0.991094273797.issue9660@psf.upfronthosting.co.za>


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


----------
nosy: +haypo, loewis

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

From report at bugs.python.org  Tue Jan  4 02:23:36 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 04 Jan 2011 01:23:36 +0000
Subject: [issue1170766] weakref.proxy incorrect behaviour
Message-ID: <1294104216.91.0.0918302486239.issue1170766@psf.upfronthosting.co.za>


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

Works in 2.7 and 3.2.

----------
nosy: +pitrou
resolution:  -> out of date
status: open -> closed

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

From report at bugs.python.org  Tue Jan  4 02:25:21 2011
From: report at bugs.python.org (Gregory P. Smith)
Date: Tue, 04 Jan 2011 01:25:21 +0000
Subject: [issue6643] Throw away more radioactive locks that could be held
	across a fork in threading.py
In-Reply-To: <1249412209.9.0.200329347238.issue6643@psf.upfronthosting.co.za>
Message-ID: <1294104321.94.0.285021355211.issue6643@psf.upfronthosting.co.za>


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

Attached is a patch for Python 2.6 release26_maint for reference incase someone wants it.  That branch is closed - security fixes only.

----------
keywords: +patch
status: open -> closed
versions:  -Python 2.7
Added file: http://bugs.python.org/file20249/issue6643-release26_maint_gps01.diff

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

From report at bugs.python.org  Tue Jan  4 02:28:56 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 04 Jan 2011 01:28:56 +0000
Subject: [issue1054041] Python doesn't exit with proper resultcode on SIGINT
Message-ID: <1294104536.97.0.672540253277.issue1054041@psf.upfronthosting.co.za>


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


----------
nosy: +gregory.p.smith -BreamoreBoy
stage: unit test needed -> needs patch
type: behavior -> feature request
versions: +Python 3.3 -Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Tue Jan  4 02:29:01 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 04 Jan 2011 01:29:01 +0000
Subject: [issue1054041] Python doesn't exit with proper resultcode on SIGINT
Message-ID: <1294104541.92.0.172154845303.issue1054041@psf.upfronthosting.co.za>


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


----------
nosy: +rnk

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

From report at bugs.python.org  Tue Jan  4 02:31:00 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 04 Jan 2011 01:31:00 +0000
Subject: [issue1075356] exceeding obscure weakproxy bug
Message-ID: <1294104660.95.0.535590691822.issue1075356@psf.upfronthosting.co.za>


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

Works fine under 3.x.

----------
nosy: +pitrou
stage: unit test needed -> needs patch
versions:  -Python 3.1, Python 3.2

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

From report at bugs.python.org  Tue Jan  4 02:33:30 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 04 Jan 2011 01:33:30 +0000
Subject: [issue1038591] Python 2.3+ socket._fileobject handles EAGAIN with
	data loss
Message-ID: <1294104810.67.0.495996930439.issue1038591@psf.upfronthosting.co.za>


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

Should work fine under 3.x.

----------
nosy: +pitrou
versions:  -Python 3.1, Python 3.2

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

From report at bugs.python.org  Tue Jan  4 02:35:34 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 04 Jan 2011 01:35:34 +0000
Subject: [issue976613] socket timeout problems on Solaris
Message-ID: <1294104934.28.0.120955330389.issue976613@psf.upfronthosting.co.za>


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


----------
resolution:  -> duplicate
status: open -> closed
superseder:  -> On Mac / BSD sockets returned by accept inherit the parent's FD flags

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

From report at bugs.python.org  Tue Jan  4 02:37:03 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 04 Jan 2011 01:37:03 +0000
Subject: [issue7995] On Mac / BSD sockets returned by accept inherit the
	parent's FD flags
In-Reply-To: <1266876583.45.0.97810567794.issue7995@psf.upfronthosting.co.za>
Message-ID: <1294105023.99.0.562451363086.issue7995@psf.upfronthosting.co.za>


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

Issue 976613 (duplicate) has a very simple patch, will see if it's sufficient.

----------

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

From report at bugs.python.org  Tue Jan  4 02:39:48 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 04 Jan 2011 01:39:48 +0000
Subject: [issue4142] smtplib doesn't clear helo/ehlo flags on quit
In-Reply-To: <1224273762.79.0.0391835714009.issue4142@psf.upfronthosting.co.za>
Message-ID: <1294105188.94.0.00335801177024.issue4142@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Tue Jan  4 02:40:04 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 04 Jan 2011 01:40:04 +0000
Subject: [issue9592] Limitations in objects returned by multiprocessing Pool
In-Reply-To: <1281726168.11.0.648826556363.issue9592@psf.upfronthosting.co.za>
Message-ID: <1294105204.65.0.0962077747454.issue9592@psf.upfronthosting.co.za>


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


----------
nosy: +asksol
versions: +Python 2.7 -Python 2.6

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

From report at bugs.python.org  Tue Jan  4 02:43:37 2011
From: report at bugs.python.org (Gregory P. Smith)
Date: Tue, 04 Jan 2011 01:43:37 +0000
Subject: [issue8458] buildbot: test_cmd_line failure on Tiger: [Errno 9] Bad
	file descriptor
In-Reply-To: <1271678026.95.0.894433016298.issue8458@psf.upfronthosting.co.za>
Message-ID: <1294105417.53.0.0559658306804.issue8458@psf.upfronthosting.co.za>


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

that race condition, if thats what this is, is likely not OS X specific.  the child process could complete or close its fds before we reach that code on any OS.  We either need to guard these io.open(p2c*...) lines against EBADF OSError's or we should create the io wrappers before _execute_child() is called.

----------

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

From report at bugs.python.org  Tue Jan  4 02:44:06 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 04 Jan 2011 01:44:06 +0000
Subject: [issue5231] Change format of a memoryview
In-Reply-To: <1234474743.76.0.794318305676.issue5231@psf.upfronthosting.co.za>
Message-ID: <1294105446.93.0.579946847296.issue5231@psf.upfronthosting.co.za>


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


----------
assignee:  -> mark.dickinson
nosy: +mark.dickinson

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

From report at bugs.python.org  Tue Jan  4 02:48:08 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 04 Jan 2011 01:48:08 +0000
Subject: [issue8052] subprocess close_fds behavior should only close open fds
In-Reply-To: <1267672679.06.0.725064778002.issue8052@psf.upfronthosting.co.za>
Message-ID: <1294105688.09.0.376122499091.issue8052@psf.upfronthosting.co.za>


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

Is it still a problem now that there's a C path?
Furthermore, how do you plan to get a list of open fds?

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

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

From report at bugs.python.org  Tue Jan  4 02:57:23 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 04 Jan 2011 01:57:23 +0000
Subject: [issue9419] RUNSHARED needs LDFLAGS
In-Reply-To: <1280423222.23.0.51081739049.issue9419@psf.upfronthosting.co.za>
Message-ID: <1294106243.33.0.565391557194.issue9419@psf.upfronthosting.co.za>


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


----------
assignee:  -> barry
nosy: +barry

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

From report at bugs.python.org  Tue Jan  4 02:58:24 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 04 Jan 2011 01:58:24 +0000
Subject: [issue5945] PyMapping_Check returns 1 for lists
In-Reply-To: <1241560036.33.0.817766851688.issue5945@psf.upfronthosting.co.za>
Message-ID: <1294106304.35.0.525301893353.issue5945@psf.upfronthosting.co.za>


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

Guido, can we have your take on this?

----------
nosy: +gvanrossum
priority: normal -> high

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

From report at bugs.python.org  Tue Jan  4 03:02:43 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 04 Jan 2011 02:02:43 +0000
Subject: [issue5223] infinite recursion in PyErr_WriteUnraisable
In-Reply-To: <1234412915.77.0.527314714811.issue5223@psf.upfronthosting.co.za>
Message-ID: <1294106563.33.0.113792507734.issue5223@psf.upfronthosting.co.za>


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

Works fine under 2.7-3.2. Not sure this is worth fixing in 2.6.

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

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

From report at bugs.python.org  Tue Jan  4 03:04:11 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 04 Jan 2011 02:04:11 +0000
Subject: [issue2454] sha and md5 fixer
In-Reply-To: <1206147643.89.0.60936055638.issue2454@psf.upfronthosting.co.za>
Message-ID: <1294106651.57.0.677826978655.issue2454@psf.upfronthosting.co.za>


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


----------
assignee: collinwinter -> benjamin.peterson

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

From report at bugs.python.org  Tue Jan  4 03:06:01 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 04 Jan 2011 02:06:01 +0000
Subject: [issue6642] returning after forking a child thread doesn't call
	Py_Finalize
In-Reply-To: <1249410110.52.0.861898541816.issue6642@psf.upfronthosting.co.za>
Message-ID: <1294106761.23.0.452943041736.issue6642@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Tue Jan  4 03:06:45 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 04 Jan 2011 02:06:45 +0000
Subject: [issue8013] time.asctime segfaults when given a time in the far future
In-Reply-To: <1267031714.43.0.416052646257.issue8013@psf.upfronthosting.co.za>
Message-ID: <1294106805.39.0.3864673858.issue8013@psf.upfronthosting.co.za>


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

Following Guido's response [1] to my inquiry on python-dev, I am attaching a new patch that makes time.asctime and time.ctime produce longer than 24-character strings for large years. 

[1] http://mail.python.org/pipermail/python-dev/2011-January/107187.html

----------
Added file: http://bugs.python.org/file20250/issue8013-long-year.diff

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

From report at bugs.python.org  Tue Jan  4 03:08:31 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 04 Jan 2011 02:08:31 +0000
Subject: [issue8651] "s#" and friends can silently truncate buffer length
In-Reply-To: <1273253096.48.0.301498355728.issue8651@psf.upfronthosting.co.za>
Message-ID: <1294106911.44.0.839821929945.issue8651@psf.upfronthosting.co.za>


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

Fixed by r87728.

Wait for the buildbots before backporting to other versions.

----------

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

From report at bugs.python.org  Tue Jan  4 03:09:01 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 04 Jan 2011 02:09:01 +0000
Subject: [issue8650] zlibmodule.c isn't 64-bit clean
In-Reply-To: <1273252861.66.0.962857738541.issue8650@psf.upfronthosting.co.za>
Message-ID: <1294106941.46.0.848613228026.issue8650@psf.upfronthosting.co.za>


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

Fixed by r87729.

Wait for the buildbots before backporting to other versions.

----------

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

From report at bugs.python.org  Tue Jan  4 03:12:40 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 04 Jan 2011 02:12:40 +0000
Subject: [issue5424] Packed IPaddr conversion tests should be extended
In-Reply-To: <1236260237.37.0.149966249724.issue5424@psf.upfronthosting.co.za>
Message-ID: <1294107160.25.0.0247925152314.issue5424@psf.upfronthosting.co.za>


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


----------
nosy: +exarkun, loewis, pitrou -BreamoreBoy

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

From report at bugs.python.org  Tue Jan  4 03:15:15 2011
From: report at bugs.python.org (Thijs Triemstra)
Date: Tue, 04 Jan 2011 02:15:15 +0000
Subject: [issue1410680] Add 'surgical editing' to ConfigParser
Message-ID: <1294107315.33.0.286215983476.issue1410680@psf.upfronthosting.co.za>


Changes by Thijs Triemstra <lists at collab.nl>:


----------
nosy: +thijs

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

From report at bugs.python.org  Tue Jan  4 03:19:07 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 04 Jan 2011 02:19:07 +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: <1294107547.42.0.577090124403.issue7433@psf.upfronthosting.co.za>


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


----------
assignee:  -> mark.dickinson
nosy: +mark.dickinson

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

From report at bugs.python.org  Tue Jan  4 03:26:23 2011
From: report at bugs.python.org (R. David Murray)
Date: Tue, 04 Jan 2011 02:26:23 +0000
Subject: [issue4188] test_threading hang when running as verbose
In-Reply-To: <1224793703.28.0.169476277835.issue4188@psf.upfronthosting.co.za>
Message-ID: <1294107983.83.0.982839464653.issue4188@psf.upfronthosting.co.za>


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

The hanging test still hangs for me with _VERBOSE set to True on py3k trunk.

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

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

From report at bugs.python.org  Tue Jan  4 03:39:03 2011
From: report at bugs.python.org (Gregory P. Smith)
Date: Tue, 04 Jan 2011 02:39:03 +0000
Subject: [issue8052] subprocess close_fds behavior should only close open fds
In-Reply-To: <1267672679.06.0.725064778002.issue8052@psf.upfronthosting.co.za>
Message-ID: <1294108743.52.0.692379749851.issue8052@psf.upfronthosting.co.za>


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

its still a problem, even the C path has to call close() a million times in that case.  thats a huge number of wasted syscalls.  fixing this is blocking on a good way to get the list of open fds.

I have seen other subprocess code do it using the race condition method of having the parent process get the list from os.listdir('/prod/self/fds') but that isn't guaranteed to get everything due to the race and we I don't believe we have enough posix async signal safe syscalls to do that in between the fork+exec.

I heard talk of actual system calls to do this type of thing (getting a list of a processes open fds) being added to future Linux kernels but I have not followed up on that to see if any have or if they are what we need.

----------

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

From report at bugs.python.org  Tue Jan  4 03:42:59 2011
From: report at bugs.python.org (Gregory P. Smith)
Date: Tue, 04 Jan 2011 02:42:59 +0000
Subject: [issue4188] test_threading hang when running as verbose
In-Reply-To: <1224793703.28.0.169476277835.issue4188@psf.upfronthosting.co.za>
Message-ID: <1294108979.38.0.253562071857.issue4188@psf.upfronthosting.co.za>


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

sorry, i saw the patches committed and thought that had fixed it.  oops.  still more to be done.

----------

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

From report at bugs.python.org  Tue Jan  4 04:21:13 2011
From: report at bugs.python.org (Gregory P. Smith)
Date: Tue, 04 Jan 2011 03:21:13 +0000
Subject: [issue1054041] Python doesn't exit with proper resultcode on SIGINT
Message-ID: <1294111273.67.0.380013678584.issue1054041@psf.upfronthosting.co.za>


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

Here's a patch that implements this behavior.  It is too late in the 3.2 beta/rc cycle to get this into 3.2.  Consider it for 3.3.  I'd like a review.

----------
keywords: +needs review, patch
Added file: http://bugs.python.org/file20251/issue1054041-sigint-exit-gps01.diff

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

From report at bugs.python.org  Tue Jan  4 04:22:19 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 04 Jan 2011 03:22:19 +0000
Subject: [issue5945] PyMapping_Check returns 1 for lists
In-Reply-To: <1241560036.33.0.817766851688.issue5945@psf.upfronthosting.co.za>
Message-ID: <1294111339.79.0.649086794838.issue5945@psf.upfronthosting.co.za>


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

Here's a code search link:

 http://www.google.com/codesearch?as_q=PyMapping_Check

And here's how it currently used internal to the Python codebase:

$ ack --cc PyMapping_CheckInclude/abstract.h
1125:     PyAPI_FUNC(int) PyMapping_Check(PyObject *o);

Modules/posixmodule.c
3585:    if (!PyMapping_Check(env)) {
3764:    if (!PyMapping_Check(env)) {
3950:    if (!PyMapping_Check(env)) {

Objects/abstract.c
1987:PyMapping_Check(PyObject *o)

Objects/frameobject.c
605:        (locals != NULL && !PyMapping_Check(locals))) {

PC/_subprocess.c
340:    if (! PyMapping_Check(environment)) {

Python/bltinmodule.c
700:    if (locals != Py_None && !PyMapping_Check(locals)) {
705:        PyErr_SetString(PyExc_TypeError, PyMapping_Check(globals) ?
794:    if (!PyMapping_Check(locals)) {

----------

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

From report at bugs.python.org  Tue Jan  4 04:46:40 2011
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 04 Jan 2011 03:46:40 +0000
Subject: [issue5945] PyMapping_Check returns 1 for lists
In-Reply-To: <1241560036.33.0.817766851688.issue5945@psf.upfronthosting.co.za>
Message-ID: <1294112800.64.0.291636048575.issue5945@psf.upfronthosting.co.za>


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

> Why did the list implementation get changed in Py3.x?

Because we decided to get rid of the sq_slice and sq_ass_slice slots
in PySequenceMethods, and that in turn was because we got rid of the
slice-related opcodes and the separate __getslice__ and __setslice__
magic methods.

> Is it now necessary for any subscripting type to put the same method
> in both the sequence methods and mapping methods?

Yes, if the type wants to support slicing.  The reason is that while
we changed many things, we didn't want to change the signature of the
methods that we kept, and the sq_item/sq_ass_item signatures have
arguments that make it impossible to pass the info necessary for a
slice.

> Was this change necessary?

The changes are briefly mentioned in PEP 3100 without any motivation.
However I think the rationale was the observation that the old
sq_slice / sq_ass_slice took only integers (really ssize_t), meaning
that it was impossible to implement a sequence type taking a slice
with arguments outside the range supported by ssize_t (e.g. a custom
range type supporting huge longs).  Or with non-integral arguments.
This problem never existed for non-slice __get__ since one could
always implement mp_subscript / mp_ass_subscript.

Was it necessary?  I'm not sure	-- but that's water under the bridge. 	

Was it a good change?  From the	POV of Python code, yes.  The old
approach caused some	odd problems for classes implementing
__getslice__ / __setslice__ (since those were invoked after the
arguments had been pushed through the sq_slice / sq_ass_slice API).

> Personally, I think PyMapping_Check and PySequence_Check should be
> deprecated and removed. Like their Python counterparts,
> operator.isMappingType() and operation.isSequenceType(), they are
> unreliable at best in the face of not LBYL and abcs.

Right, calling PyMapping_Check() was never particularly reliable, and
extension modules depending on it probably always had subtle bugs. 

Perhaps it would be nice if we provided a C API to at least some of
the ABC package.

----------

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

From report at bugs.python.org  Tue Jan  4 04:46:45 2011
From: report at bugs.python.org (Gregory P. Smith)
Date: Tue, 04 Jan 2011 03:46:45 +0000
Subject: [issue9535] Pending signals are inherited by child processes
In-Reply-To: <1281105795.17.0.408658965128.issue9535@psf.upfronthosting.co.za>
Message-ID: <1294112805.38.0.45308731439.issue9535@psf.upfronthosting.co.za>


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

Yes I'd do it in PyOS_AfterFork.  Simpler patch based on gdb's attached.

This could also use a test but as it involves signals and race conditions, making a deterministic test for this is difficult as it.

If we added testing hooks to the python interpreter internals to allow test code to do things like set the signal tripped flags directly it's be much easier.

----------
keywords: +needs review
Added file: http://bugs.python.org/file20252/issue9535-clear_signals_afterfork-gps01.diff

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

From report at bugs.python.org  Tue Jan  4 04:56:26 2011
From: report at bugs.python.org (Matthew Barnett)
Date: Tue, 04 Jan 2011 03:56:26 +0000
Subject: [issue2636] Regexp 2.7 (modifications to current re 2.2.2)
In-Reply-To: <1208260672.14.0.711874677361.issue2636@psf.upfronthosting.co.za>
Message-ID: <1294113386.27.0.366439251466.issue2636@psf.upfronthosting.co.za>


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

I've just done a bug fix. The issue is at:

    https://code.google.com/p/mrab-regex-hg/

BTW, Jacques, I trust that your regression tests don't test how long a regex takes to fail to match, because a bug could cause such a non-match to occur too quickly, before the regex has tried all that it should! :-)

----------

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

From report at bugs.python.org  Tue Jan  4 05:11:48 2011
From: report at bugs.python.org (Brian Curtin)
Date: Tue, 04 Jan 2011 04:11:48 +0000
Subject: [issue9332] Document requirements for os.symlink usage on Windows
In-Reply-To: <1279824339.14.0.912688887592.issue9332@psf.upfronthosting.co.za>
Message-ID: <1294114308.63.0.948710205603.issue9332@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

Closed. I'll be adding this in #10608.

----------
resolution:  -> duplicate
stage: needs patch -> committed/rejected
status: open -> closed
superseder:  -> Add a section to Windows FAQ explaining os.symlink

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

From report at bugs.python.org  Tue Jan  4 05:13:06 2011
From: report at bugs.python.org (Brian Curtin)
Date: Tue, 04 Jan 2011 04:13:06 +0000
Subject: [issue8879] Implement os.link on Windows
In-Reply-To: <1275504458.06.0.136411734773.issue8879@psf.upfronthosting.co.za>
Message-ID: <1294114386.15.0.705486646419.issue8879@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
stage: patch review -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Tue Jan  4 06:19:38 2011
From: report at bugs.python.org (Ross Lagerwall)
Date: Tue, 04 Jan 2011 05:19:38 +0000
Subject: [issue9344] please add posix.getgrouplist()
In-Reply-To: <1279890657.77.0.804697326433.issue9344@psf.upfronthosting.co.za>
Message-ID: <1294118378.74.0.421765913094.issue9344@psf.upfronthosting.co.za>


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

A slightly updated patch. Targeting for 3.3.

----------
versions: +Python 3.3 -Python 3.2
Added file: http://bugs.python.org/file20253/9344_v2.patch

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

From report at bugs.python.org  Tue Jan  4 06:57:19 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Tue, 04 Jan 2011 05:57:19 +0000
Subject: [issue10798] test_concurrent_futures fails on FreeBSD
In-Reply-To: <1293740054.42.0.931376139757.issue10798@psf.upfronthosting.co.za>
Message-ID: <1294120639.39.0.250318214406.issue10798@psf.upfronthosting.co.za>


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

Interesting. I wonder whether a reboot of the system would help (as it may have old semaphores hanging around).

----------

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

From report at bugs.python.org  Tue Jan  4 08:18:57 2011
From: report at bugs.python.org (Ned Deily)
Date: Tue, 04 Jan 2011 07:18:57 +0000
Subject: [issue10820] 3.2 Makefile changes for versioned scripts break OS X
	framework installs
In-Reply-To: <1294125537.03.0.564909640075.issue10820@psf.upfronthosting.co.za>
Message-ID: <1294125537.03.0.564909640075.issue10820@psf.upfronthosting.co.za>


New submission from Ned Deily <nad at acm.org>:

The changes for Issue10679 (r87525) to installed versioned scripts break OS X framework installs.  The install_versionedtools target in Mac/Makefile already did most of this work and is now superfluous.  The attached patch fixes the problem.

----------
assignee: ronaldoussoren
components: Build, Macintosh
messages: 125295
nosy: georg.brandl, ned.deily, ronaldoussoren
priority: release blocker
severity: normal
stage: patch review
status: open
title: 3.2 Makefile changes for versioned scripts break OS X framework installs
versions: Python 3.2

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

From report at bugs.python.org  Tue Jan  4 08:21:00 2011
From: report at bugs.python.org (Ned Deily)
Date: Tue, 04 Jan 2011 07:21:00 +0000
Subject: [issue10820] 3.2 Makefile changes for versioned scripts break OS X
	framework installs
In-Reply-To: <1294125537.03.0.564909640075.issue10820@psf.upfronthosting.co.za>
Message-ID: <1294125660.97.0.0108287286697.issue10820@psf.upfronthosting.co.za>


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


----------
keywords: +patch
Added file: http://bugs.python.org/file20254/issue10820-py3k.patch

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

From report at bugs.python.org  Tue Jan  4 09:18:59 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 04 Jan 2011 08:18:59 +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: <1294129139.32.0.392452458502.issue10181@psf.upfronthosting.co.za>


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

It might be instructive to look at how NumPy itself manages sharing of ndarray data and ownership of the corresponding structs.  I meant to find time to look at this over the break.

----------

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

From report at bugs.python.org  Tue Jan  4 09:22:39 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 04 Jan 2011 08:22:39 +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: <1294129359.78.0.512276814191.issue10181@psf.upfronthosting.co.za>


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

BTW, I agree that it looks as though significant changes might be needed.  I wonder whether it would make sense to exclude the Py_buffer struct fro m the Stable ABI PEP for now.

----------

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

From report at bugs.python.org  Tue Jan  4 09:25:35 2011
From: report at bugs.python.org (=?utf-8?q?Lars_Gust=C3=A4bel?=)
Date: Tue, 04 Jan 2011 08:25:35 +0000
Subject: [issue10760] tarfile doesn't handle sysfs well
In-Reply-To: <1293037554.87.0.808780630488.issue10760@psf.upfronthosting.co.za>
Message-ID: <1294129535.33.0.759203125933.issue10760@psf.upfronthosting.co.za>


Changes by Lars Gust?bel <lars at gustaebel.de>:


----------
assignee:  -> lars.gustaebel
components: +Library (Lib) -None
nosy: +lars.gustaebel

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

From report at bugs.python.org  Tue Jan  4 09:25:53 2011
From: report at bugs.python.org (=?utf-8?q?Lars_Gust=C3=A4bel?=)
Date: Tue, 04 Jan 2011 08:25:53 +0000
Subject: [issue10761] tarfile.extractall fails to overwrite symlinks
In-Reply-To: <1293063436.61.0.0994372418071.issue10761@psf.upfronthosting.co.za>
Message-ID: <1294129553.63.0.977065495534.issue10761@psf.upfronthosting.co.za>


Changes by Lars Gust?bel <lars at gustaebel.de>:


----------
assignee:  -> lars.gustaebel
nosy: +lars.gustaebel

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

From report at bugs.python.org  Tue Jan  4 10:19:37 2011
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 04 Jan 2011 09:19:37 +0000
Subject: [issue10516] Add list.clear() and list.copy()
In-Reply-To: <1290555468.47.0.0329661397161.issue10516@psf.upfronthosting.co.za>
Message-ID: <1294132777.22.0.069473897234.issue10516@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Tue Jan  4 11:18:18 2011
From: report at bugs.python.org (=?utf-8?b?UGV0ciBTa2xlbsOhxZk=?=)
Date: Tue, 04 Jan 2011 10:18:18 +0000
Subject: [issue10821] gethostbyname(gethostname()) is wrong when IP is changed
In-Reply-To: <1294136298.58.0.0957564280259.issue10821@psf.upfronthosting.co.za>
Message-ID: <1294136298.58.0.0957564280259.issue10821@psf.upfronthosting.co.za>


New submission from Petr Sklen?? <psklenar at redhat.com>:

version:
tried python 2.6 on rhel55
tried python-2.7-8 on fedora14

Steps to Reproduce:
1. install machine, have a fixed hostname up to mac address
1.1.1.1 = machine.something.com

2. wait a week or longer when your local dhcp server changes your IP but not
hostname
1.1.1.159 = machine.something.com

[root at machine.something.com ~]# host machine.something.com
machine.something.com has address 1.1.1.159

ifconfig shows the same

3.   gethostbyname(gethostname()) shows wrong IP, the original one

Actual results:
[root at machine.something.com ~]# python
Python 2.4.3 (#1, Jun 11 2009, 14:09:37)
[GCC 4.1.2 20080704 (Red Hat 4.1.2-44)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from socket import gethostname
>>> from socket import gethostbyname
>>> gethostname()
'machine.something.com'
>>> gethostbyname(gethostname())
'1.1.1.1'
>>>

Expected results:
gethostbyname(gethostname()) will return your actual IP, 1.1.1.159

Other:
1.1.1.1 = machine.something.com is added in /etc/hosts in the time of OS installation , then its not changed

----------
components: IO
messages: 125298
nosy: psklenar
priority: normal
severity: normal
status: open
title: gethostbyname(gethostname()) is wrong when IP is changed
versions: Python 2.7

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

From report at bugs.python.org  Tue Jan  4 11:31:23 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 04 Jan 2011 10:31:23 +0000
Subject: [issue5945] PyMapping_Check returns 1 for lists
In-Reply-To: <1241560036.33.0.817766851688.issue5945@psf.upfronthosting.co.za>
Message-ID: <1294137083.13.0.410855543979.issue5945@psf.upfronthosting.co.za>


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

> Right, calling PyMapping_Check() was never particularly reliable, and
> extension modules depending on it probably always had subtle bugs. 

> Perhaps it would be nice if we provided a C API to at least some of
> the ABC package.

In the meantime, would it be reasonable to add the moral equivalent of `hasattr(type(op), 'items')` to PyMapping_Check()?

----------

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

From report at bugs.python.org  Tue Jan  4 11:32:32 2011
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 04 Jan 2011 10:32:32 +0000
Subject: [issue10821] gethostbyname(gethostname()) is wrong when IP is changed
In-Reply-To: <1294136298.58.0.0957564280259.issue10821@psf.upfronthosting.co.za>
Message-ID: <1294137152.34.0.0908219685369.issue10821@psf.upfronthosting.co.za>


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

This is not a Python issue.  gethostbyname() and gethostname() are just a wrapper for the OS's functions of the same name; you'd get the same result when coding the example in C.

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

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

From report at bugs.python.org  Tue Jan  4 12:01:01 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 04 Jan 2011 11:01:01 +0000
Subject: [issue10819] ValueError on repr(closed_socket_file)
In-Reply-To: <1294098693.54.0.480300363848.issue10819@psf.upfronthosting.co.za>
Message-ID: <1294138861.5.0.795553312805.issue10819@psf.upfronthosting.co.za>


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

Fixed by r87730.

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

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

From report at bugs.python.org  Tue Jan  4 12:02:43 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 04 Jan 2011 11:02:43 +0000
Subject: [issue10785] parser: store the filename as an unicode object
In-Reply-To: <1293504022.51.0.668746175929.issue10785@psf.upfronthosting.co.za>
Message-ID: <1294138963.3.0.728974128079.issue10785@psf.upfronthosting.co.za>


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

err_clear() should set err->filename to NULL.

----------
versions:  -Python 3.2

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

From report at bugs.python.org  Tue Jan  4 12:08:39 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 04 Jan 2011 11:08:39 +0000
Subject: [issue10822] test_getgroups failure under Solaris
In-Reply-To: <1294139319.03.0.190267830849.issue10822@psf.upfronthosting.co.za>
Message-ID: <1294139319.03.0.190267830849.issue10822@psf.upfronthosting.co.za>


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

Under OpenSolaris, I get the following failure:

$ pfexec ./python -m test test_posix
[1/1] test_posix
test test_posix failed -- Traceback (most recent call last):
  File "/home/antoine/py3k/cc/Lib/test/test_posix.py", line 402, in test_getgroups
    set(posix.getgroups()))
AssertionError: Items in the first set but not the second:
0

----------
components: Tests
messages: 125303
nosy: jcea, laca, pitrou, ronaldoussoren
priority: normal
severity: normal
stage: needs patch
status: open
title: test_getgroups failure under Solaris
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Tue Jan  4 12:09:23 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 04 Jan 2011 11:09:23 +0000
Subject: [issue9344] please add posix.getgrouplist()
In-Reply-To: <1279890657.77.0.804697326433.issue9344@psf.upfronthosting.co.za>
Message-ID: <1294139363.17.0.471377887535.issue9344@psf.upfronthosting.co.za>


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

I can't say anything about the functionality, but the patch looks good to me (works under Linux and Solaris - the latter missing getgrouplist()).

----------
nosy: +pitrou
stage: needs patch -> commit review

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

From report at bugs.python.org  Tue Jan  4 12:11:22 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 04 Jan 2011 11:11:22 +0000
Subject: [issue9535] Pending signals are inherited by child processes
In-Reply-To: <1294112805.38.0.45308731439.issue9535@psf.upfronthosting.co.za>
Message-ID: <1294139479.3669.1.camel@localhost.localdomain>


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

> Yes I'd do it in PyOS_AfterFork.  Simpler patch based on gdb's
> attached.

Private functions shouldn't use the PyXX_CamelCase() convention :)
Otherwise, looks good.

----------

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

From report at bugs.python.org  Tue Jan  4 12:15:05 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 04 Jan 2011 11:15:05 +0000
Subject: [issue8458] buildbot: test_cmd_line failure on Tiger: [Errno 9] Bad
	file descriptor
In-Reply-To: <1271678026.95.0.894433016298.issue8458@psf.upfronthosting.co.za>
Message-ID: <1294139705.88.0.555064127553.issue8458@psf.upfronthosting.co.za>


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

> that race condition, if thats what this is, is likely not OS X
> specific.  the child process could complete or close its fds before we
> reach that code on any OS.  We either need to guard these
> io.open(p2c*...) lines against EBADF OSError's or we should create the
> io wrappers before _execute_child() is called.

Creating them before _execute_child() is the obvious and simple solution
(if my diagnosis is correct). Is there any downside to doing so?

----------

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

From report at bugs.python.org  Tue Jan  4 12:17:00 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 04 Jan 2011 11:17:00 +0000
Subject: [issue8992] convertsimple() doesn't need to call converterr() if an
	exception was already raised
In-Reply-To: <1276463733.12.0.346579334159.issue8992@psf.upfronthosting.co.za>
Message-ID: <1294139820.03.0.886191646575.issue8992@psf.upfronthosting.co.za>


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

Fixed by r87732

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

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

From report at bugs.python.org  Tue Jan  4 12:17:11 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 04 Jan 2011 11:17:11 +0000
Subject: [issue8992] convertsimple() doesn't need to call converterr() if an
	exception was already raised
In-Reply-To: <1276463733.12.0.346579334159.issue8992@psf.upfronthosting.co.za>
Message-ID: <1294139831.63.0.11885642926.issue8992@psf.upfronthosting.co.za>


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

(and by r87731)

----------

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

From report at bugs.python.org  Tue Jan  4 12:29:46 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 04 Jan 2011 11:29:46 +0000
Subject: [issue8719] buildbot: segfault on FreeBSD (signal 11)
In-Reply-To: <1273875581.36.0.231394687131.issue8719@psf.upfronthosting.co.za>
Message-ID: <1294140586.16.0.202341201338.issue8719@psf.upfronthosting.co.za>


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

> That may be what you meant, but "installed on this host" made me think
> I could do something external on the buildbot which I don't 
> think would work given that the module has to be called from within
> the tests themselves?

If you install faulthandler on "x86 FreeBSD 7.2 3.x" buildbot, I can create a special branch to add specific code.

Or I can add:

try:
    import faulthandler
except ImportError:
    pass
else:
    faulthandler.enable()

In py3k (eg. in Lib/test/support.py).

But the problem is now different: it looks like the bug was fixed, I don't see crashes anymore on  "x86 FreeBSD 7.2 3.x" buildbot :-)

There was failures on test_concurrent_futures, but Martin fixed it in #10798 (not completly (?) but it's better).

I close the issue because it looks like the crash was fixed. Reopen the issue if the crash occurs again.

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

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

From report at bugs.python.org  Tue Jan  4 13:04:34 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 04 Jan 2011 12:04:34 +0000
Subject: [issue10823] "conversion from 'Py_ssize_t' to 'int',
	possible loss of data" in various files
In-Reply-To: <1294142673.84.0.738838324131.issue10823@psf.upfronthosting.co.za>
Message-ID: <1294142673.84.0.738838324131.issue10823@psf.upfronthosting.co.za>


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

On "AMD64 Windows Server 2008 3.x", there are many "conversion from 'Py_ssize_t' to 'int', possible loss of data" errors:


Python\Python-ast.c(3403) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data
Python\Python-ast.c(3409) : warning C4244: 'initializing' : conversion from 'Py_ssize_t' to 'int', possible loss of data
Python\Python-ast.c(3439) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data
Python\Python-ast.c(3445) : warning C4244: 'initializing' : conversion from 'Py_ssize_t' to 'int', possible loss of data
Python\Python-ast.c(3498) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data
Python\Python-ast.c(3504) : warning C4244: 'initializing' : conversion from 'Py_ssize_t' to 'int', possible loss of data
Python\Python-ast.c(3606) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data
Python\Python-ast.c(3612) : warning C4244: 'initializing' : conversion from 'Py_ssize_t' to 'int', possible loss of data
Python\Python-ast.c(3631) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data
Python\Python-ast.c(3637) : warning C4244: 'initializing' : conversion from 'Py_ssize_t' to 'int', possible loss of data
Python\Python-ast.c(3697) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data
Python\Python-ast.c(3703) : warning C4244: 'initializing' : conversion from 'Py_ssize_t' to 'int', possible loss of data
Python\Python-ast.c(3722) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data
Python\Python-ast.c(3728) : warning C4244: 'initializing' : conversion from 'Py_ssize_t' to 'int', possible loss of data
Python\Python-ast.c(3769) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data
Python\Python-ast.c(3775) : warning C4244: 'initializing' : conversion from 'Py_ssize_t' to 'int', possible loss of data
Python\Python-ast.c(3794) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data
Python\Python-ast.c(3800) : warning C4244: 'initializing' : conversion from 'Py_ssize_t' to 'int', possible loss of data
Python\Python-ast.c(3853) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data
Python\Python-ast.c(3859) : warning C4244: 'initializing' : conversion from 'Py_ssize_t' to 'int', possible loss of data
Python\Python-ast.c(3890) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data
Python\Python-ast.c(3896) : warning C4244: 'initializing' : conversion from 'Py_ssize_t' to 'int', possible loss of data
Python\Python-ast.c(4014) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data
Python\Python-ast.c(4020) : warning C4244: 'initializing' : conversion from 'Py_ssize_t' to 'int', possible loss of data
Python\Python-ast.c(4039) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data
Python\Python-ast.c(4045) : warning C4244: 'initializing' : conversion from 'Py_ssize_t' to 'int', possible loss of data
Python\Python-ast.c(4090) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data
Python\Python-ast.c(4096) : warning C4244: 'initializing' : conversion from 'Py_ssize_t' to 'int', possible loss of data
Python\Python-ast.c(4115) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data
Python\Python-ast.c(4121) : warning C4244: 'initializing' : conversion from 'Py_ssize_t' to 'int', possible loss of data
Python\Python-ast.c(4165) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data
Python\Python-ast.c(4171) : warning C4244: 'initializing' : conversion from 'Py_ssize_t' to 'int', possible loss of data
Python\Python-ast.c(4190) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data
Python\Python-ast.c(4196) : warning C4244: 'initializing' : conversion from 'Py_ssize_t' to 'int', possible loss of data
Python\Python-ast.c(4251) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data
Python\Python-ast.c(4257) : warning C4244: 'initializing' : conversion from 'Py_ssize_t' to 'int', possible loss of data
Python\Python-ast.c(4324) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data
Python\Python-ast.c(4330) : warning C4244: 'initializing' : conversion from 'Py_ssize_t' to 'int', possible loss of data
Python\Python-ast.c(4349) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data
Python\Python-ast.c(4355) : warning C4244: 'initializing' : conversion from 'Py_ssize_t' to 'int', possible loss of data
Python\Python-ast.c(4374) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data
Python\Python-ast.c(4380) : warning C4244: 'initializing' : conversion from 'Py_ssize_t' to 'int', possible loss of data
Python\Python-ast.c(4412) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data
Python\Python-ast.c(4418) : warning C4244: 'initializing' : conversion from 'Py_ssize_t' to 'int', possible loss of data
Python\Python-ast.c(4437) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data
Python\Python-ast.c(4443) : warning C4244: 'initializing' : conversion from 'Py_ssize_t' to 'int', possible loss of data
Python\Python-ast.c(4508) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data
Python\Python-ast.c(4514) : warning C4244: 'initializing' : conversion from 'Py_ssize_t' to 'int', possible loss of data
Python\Python-ast.c(4557) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data
Python\Python-ast.c(4563) : warning C4244: 'initializing' : conversion from 'Py_ssize_t' to 'int', possible loss of data
Python\Python-ast.c(4605) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data
Python\Python-ast.c(4611) : warning C4244: 'initializing' : conversion from 'Py_ssize_t' to 'int', possible loss of data
Python\Python-ast.c(4641) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data
Python\Python-ast.c(4647) : warning C4244: 'initializing' : conversion from 'Py_ssize_t' to 'int', possible loss of data
Python\Python-ast.c(4787) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data
Python\Python-ast.c(4793) : warning C4244: 'initializing' : conversion from 'Py_ssize_t' to 'int', possible loss of data
Python\Python-ast.c(4994) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data
Python\Python-ast.c(5000) : warning C4244: 'initializing' : conversion from 'Py_ssize_t' to 'int', possible loss of data
Python\Python-ast.c(5019) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data
Python\Python-ast.c(5025) : warning C4244: 'initializing' : conversion from 'Py_ssize_t' to 'int', possible loss of data
Python\Python-ast.c(5055) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data
Python\Python-ast.c(5061) : warning C4244: 'initializing' : conversion from 'Py_ssize_t' to 'int', possible loss of data
Python\Python-ast.c(5104) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data
Python\Python-ast.c(5110) : warning C4244: 'initializing' : conversion from 'Py_ssize_t' to 'int', possible loss of data
Python\Python-ast.c(5153) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data
Python\Python-ast.c(5159) : warning C4244: 'initializing' : conversion from 'Py_ssize_t' to 'int', possible loss of data
Python\Python-ast.c(5215) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data
Python\Python-ast.c(5221) : warning C4244: 'initializing' : conversion from 'Py_ssize_t' to 'int', possible loss of data
Python\Python-ast.c(5265) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data
Python\Python-ast.c(5271) : warning C4244: 'initializing' : conversion from 'Py_ssize_t' to 'int', possible loss of data
Python\Python-ast.c(5337) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data
Python\Python-ast.c(5343) : warning C4244: 'initializing' : conversion from 'Py_ssize_t' to 'int', possible loss of data
Python\Python-ast.c(5362) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data
Python\Python-ast.c(5368) : warning C4244: 'initializing' : conversion from 'Py_ssize_t' to 'int', possible loss of data
Python\Python-ast.c(5415) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data
Python\Python-ast.c(5421) : warning C4244: 'initializing' : conversion from 'Py_ssize_t' to 'int', possible loss of data
Python\Python-ast.c(5440) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data
Python\Python-ast.c(5446) : warning C4244: 'initializing' : conversion from 'Py_ssize_t' to 'int', possible loss of data
Python\Python-ast.c(5749) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data
Python\Python-ast.c(5755) : warning C4244: 'initializing' : conversion from 'Py_ssize_t' to 'int', possible loss of data
Python\Python-ast.c(5798) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data
Python\Python-ast.c(5804) : warning C4244: 'initializing' : conversion from 'Py_ssize_t' to 'int', possible loss of data
Python\Python-ast.c(5968) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data
Python\Python-ast.c(5974) : warning C4244: 'initializing' : conversion from 'Py_ssize_t' to 'int', possible loss of data
Python\Python-ast.c(6323) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data
Python\Python-ast.c(6329) : warning C4244: 'initializing' : conversion from 'Py_ssize_t' to 'int', possible loss of data
Python\Python-ast.c(6423) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data
Python\Python-ast.c(6429) : warning C4244: 'initializing' : conversion from 'Py_ssize_t' to 'int', possible loss of data
Python\Python-ast.c(6473) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data
Python\Python-ast.c(6479) : warning C4244: 'initializing' : conversion from 'Py_ssize_t' to 'int', possible loss of data
Python\Python-ast.c(6520) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data
Python\Python-ast.c(6526) : warning C4244: 'initializing' : conversion from 'Py_ssize_t' to 'int', possible loss of data
Python\Python-ast.c(6567) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data
Python\Python-ast.c(6573) : warning C4244: 'initializing' : conversion from 'Py_ssize_t' to 'int', possible loss of data
Python\Python-ast.c(6592) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data
Python\Python-ast.c(6598) : warning C4244: 'initializing' : conversion from 'Py_ssize_t' to 'int', possible loss of data

Python\pystrtod.c(902) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data
Python\pystrtod.c(1023) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data

Python\peephole.c(82) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'unsigned char', possible loss of data
Python\peephole.c(185) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'unsigned char', possible loss of data
Python\peephole.c(239) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'unsigned char', possible loss of data
Python\peephole.c(311) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'unsigned char', possible loss of data
Python\peephole.c(354) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data
Python\peephole.c(405) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'unsigned char', possible loss of data
Python\peephole.c(420) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'unsigned char', possible loss of data
Python\peephole.c(461) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data
Python\peephole.c(546) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data
Python\peephole.c(557) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'unsigned char', possible loss of data
Python\peephole.c(589) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data
Python\peephole.c(603) : warning C4244: '-=' : conversion from 'Py_ssize_t' to 'int', possible loss of data
Python\peephole.c(634) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data
Python\peephole.c(663) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'unsigned char', possible loss of data
Python\peephole.c(673) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'unsigned char', possible loss of data

Python\getargs.c(374) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data
Python\getargs.c(486) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data
Python\getargs.c(860) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data
Python\getargs.c(915) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data
Python\getargs.c(923) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data
Python\getargs.c(967) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data
Python\getargs.c(1117) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data
Python\getargs.c(1444) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data
Python\getargs.c(1445) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data

Python\compile.c(340) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'long', possible loss of data
Python\compile.c(385) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'long', possible loss of data
Python\compile.c(480) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data
Python\compile.c(535) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data
Python\compile.c(949) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'long', possible loss of data
Python\compile.c(964) : warning C4244: 'return' : conversion from 'Py_ssize_t' to 'int', possible loss of data
Python\compile.c(1256) : warning C4244: 'initializing' : conversion from 'Py_ssize_t' to 'int', possible loss of data
Python\compile.c(1401) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data
Python\compile.c(3687) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data
Python\compile.c(3713) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data
Python\compile.c(3739) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data
Python\compile.c(3907) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data
Python\compile.c(3911) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data
Python\compile.c(3951) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data
Python\compile.c(3958) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data

Python\ceval.c(3970) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data
Python\ceval.c(4158) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data

Objects/stringlib/formatter.h(979) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data
Objects/stringlib/formatter.h(1151) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data
Objects/stringlib/formatter.h(1155) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data


Objects\typeobject.c(6226) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data

Objects\listobject.c(1955) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data

Objects\funcobject.c(632) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data
Objects\funcobject.c(633) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data
Objects\funcobject.c(633) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data

Objects\frameobject.c(480) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data
Objects\frameobject.c(513) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data
Objects\frameobject.c(871) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data
Objects\frameobject.c(872) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data
Objects\frameobject.c(918) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data
Objects\frameobject.c(919) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data

Objects\fileobject.c(393) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'unsigned int', possible loss of data

Objects\codeobject.c(495) : warning C4244: 'initializing' : conversion from 'Py_ssize_t' to 'int', possible loss of data
Objects\codeobject.c(517) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data

Modules\_io\fileio.c(522) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'unsigned int', possible loss of data
Modules\_io\fileio.c(661) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'unsigned int', possible loss of data
Modules\_io\fileio.c(701) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'unsigned int', possible loss of data

Modules\zlibmodule.c(127) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data
Modules\zlibmodule.c(211) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data
Modules\zlibmodule.c(217) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'uInt', possible loss of data
Modules\zlibmodule.c(271) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'uInt', possible loss of data
Modules\zlibmodule.c(422) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data
Modules\zlibmodule.c(434) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'uInt', possible loss of data
Modules\zlibmodule.c(451) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'uInt', possible loss of data
Modules\zlibmodule.c(505) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data
Modules\zlibmodule.c(526) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'uInt', possible loss of data
Modules\zlibmodule.c(556) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'uInt', possible loss of data
Modules\zlibmodule.c(935) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'uInt', possible loss of data
Modules\zlibmodule.c(938) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'uInt', possible loss of data
Modules\zlibmodule.c(963) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'uInt', possible loss of data
Modules\zlibmodule.c(966) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'uInt', possible loss of data

Modules\sha512module.c(558) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data
Modules\sha512module.c(710) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data
Modules\sha512module.c(751) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data

Modules\sha256module.c(492) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data
Modules\sha256module.c(644) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data
Modules\sha256module.c(685) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data

Modules\sha1module.c(399) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'unsigned long', possible loss of data
Modules\sha1module.c(520) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'unsigned long', possible loss of data

Modules\md5module.c(423) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'unsigned long', possible loss of data
Modules\md5module.c(544) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'unsigned long', possible loss of data

Modules\audioop.c(332) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data
Modules\audioop.c(354) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data
Modules\audioop.c(376) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data
Modules\audioop.c(398) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data
Modules\audioop.c(423) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data
Modules\audioop.c(632) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data
Modules\audioop.c(687) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data
Modules\audioop.c(737) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data
Modules\audioop.c(763) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data
Modules\audioop.c(810) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data
Modules\audioop.c(868) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data
Modules\audioop.c(928) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data
Modules\audioop.c(984) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data
Modules\audioop.c(1018) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data
Modules\audioop.c(1053) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data
Modules\audioop.c(1284) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data
Modules\audioop.c(1316) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data
Modules\audioop.c(1353) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data
Modules\audioop.c(1385) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data
Modules\audioop.c(1424) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data
Modules\audioop.c(1530) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data

modules\_sre.c(1895) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data
modules\_sre.c(1898) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data
modules\_sre.c(1932) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data
modules\_sre.c(1935) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data
modules\_sre.c(2079) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data
modules\_sre.c(2082) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data
modules\_sre.c(2209) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data
modules\_sre.c(2212) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data
modules\_sre.c(2361) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data
modules\_sre.c(2364) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data
modules\_sre.c(3750) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data
modules\_sre.c(3753) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data
modules\_sre.c(3783) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data
modules\_sre.c(3786) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data

Modules\_pickle.c(156) : warning C4244: 'initializing' : conversion from 'Py_ssize_t' to 'int', possible loss of data
Modules\_pickle.c(195) : warning C4244: 'initializing' : conversion from 'Py_ssize_t' to 'int', possible loss of data
Modules\_pickle.c(754) : warning C4244: 'return' : conversion from 'Py_ssize_t' to 'int', possible loss of data
Modules\_pickle.c(1283) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'long', possible loss of data
Modules\_pickle.c(1957) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data
Modules\_pickle.c(2238) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data
Modules\_pickle.c(2496) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data
Modules\_pickle.c(4331) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data
Modules\_pickle.c(4596) : warning C4244: 'initializing' : conversion from 'Py_ssize_t' to 'int', possible loss of data
Modules\_pickle.c(4636) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data
Modules\_pickle.c(4877) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data
Modules\_pickle.c(4924) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data
Modules\_pickle.c(4941) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data
Modules\_pickle.c(4972) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data
Modules\_pickle.c(5128) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data

Modules\_ctypes\_ctypes.c(3984) : warning C4244: 'return' : conversion from 'Py_ssize_t' to 'int', possible loss of data

Modules\_elementtree.c(1239) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data
Modules\_elementtree.c(1372) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data
Modules\_elementtree.c(1414) : warning C4244: '+=' : conversion from 'Py_ssize_t' to 'int', possible loss of data
Modules\_elementtree.c(2666) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data

Modules\socketmodule.c(2274) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data
Modules\socketmodule.c(2489) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data
Modules\socketmodule.c(2644) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data
Modules\socketmodule.c(2696) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data
Modules\socketmodule.c(2778) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data

Modules\_sqlite\statement.c(140) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data
Modules\_sqlite\statement.c(186) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data
Modules\_sqlite\statement.c(188) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data
Modules\_sqlite\statement.c(190) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data
Modules\_sqlite\row.c(89) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data
Modules\_sqlite\row.c(147) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data
Modules\_sqlite\connection.c(506) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data

Modules\_testcapimodule.c(2191) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'long', possible loss of data

Modules\_tkinter.c(398) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data
Modules\_tkinter.c(501) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data
Modules\_tkinter.c(953) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data
Modules\_tkinter.c(973) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data
Modules\_tkinter.c(1007) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data
Modules\_tkinter.c(1159) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data
Modules\_tkinter.c(2808) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data
Modules\_tkinter.c(2830) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data
Modules\_tkinter.c(2864) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data

Modules\bz2module.c(735) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data
Modules\bz2module.c(830) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data
Modules\bz2module.c(878) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data
Modules\bz2module.c(1443) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data
Modules\bz2module.c(1739) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data
Modules\bz2module.c(1958) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data
Modules\bz2module.c(2050) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data

Modules\selectmodule.c(98) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data

Modules\pyexpat.c(830) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data

Modules\_multiprocessing\socket_connection.c(126) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data
Modules\_multiprocessing\socket_connection.c(137) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data
Modules\_multiprocessing\socket_connection.c(145) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data
modules\_multiprocessing\connection.h(139) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data
modules\_multiprocessing\connection.h(183) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data
modules\_multiprocessing\connection.h(237) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data
modules\_multiprocessing\connection.h(285) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data
modules\_multiprocessing\connection.h(323) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data
modules\_multiprocessing\connection.h(139) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data
modules\_multiprocessing\connection.h(183) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data
modules\_multiprocessing\connection.h(237) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data
modules\_multiprocessing\connection.h(285) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data
modules\_multiprocessing\connection.h(323) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data

Modules\_ssl.c(1095) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data

--

See also #8650 and #8651.

----------
components: Build, Windows
messages: 125310
nosy: haypo, pitrou
priority: normal
severity: normal
status: open
title: "conversion from 'Py_ssize_t' to 'int', possible loss of data" in various files
versions: Python 3.2, Python 3.3

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

From report at bugs.python.org  Tue Jan  4 13:09:51 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 04 Jan 2011 12:09:51 +0000
Subject: [issue10823] "conversion from 'Py_ssize_t' to 'int',
	possible loss of data" in various files
In-Reply-To: <1294142673.84.0.738838324131.issue10823@psf.upfronthosting.co.za>
Message-ID: <1294142991.62.0.134766258242.issue10823@psf.upfronthosting.co.za>


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


----------
resolution:  -> duplicate
status: open -> closed
superseder:  -> Compilation warnings under x64 Windows

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

From report at bugs.python.org  Tue Jan  4 13:30:06 2011
From: report at bugs.python.org (Ralf Schmitt)
Date: Tue, 04 Jan 2011 12:30:06 +0000
Subject: [issue9566] Compilation warnings under x64 Windows
In-Reply-To: <1281484786.91.0.306555541292.issue9566@psf.upfronthosting.co.za>
Message-ID: <1294144206.79.0.656374786183.issue9566@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Tue Jan  4 14:06:08 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 04 Jan 2011 13:06:08 +0000
Subject: [issue9566] Compilation warnings under x64 Windows
In-Reply-To: <1281484786.91.0.306555541292.issue9566@psf.upfronthosting.co.za>
Message-ID: <1294146368.41.0.166511853443.issue9566@psf.upfronthosting.co.za>


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

r87733 fixes some conversions in:

 * Python/pythonrun.c
 * Objects/codeobject.c
 * Objects/typeobject.c
 * Objects/listobject.c
 * Modules/_ctypes/_ctypes.c
 * Modules/sha512module.c
 * Modules/unicodedata.c
 * Modules/selectmodule.c
 * Modules/pyexpat.c
 * Modules/audioop.c
 * Modules/sha1module.c
 * Modules/sha256module.c
 * Modules/_testcapimodule.c
 * Modules/md5module.c

For md5, sha1, sha256 and sha512: a smaller type (int) can be used for the local n variable. I don't know if it impacts performances or not. md5 and sha1 used "unsigned long", sha256 and sha512 used "int".

----------
nosy: +haypo

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

From report at bugs.python.org  Tue Jan  4 14:06:54 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Tue, 04 Jan 2011 13:06:54 +0000
Subject: [issue10512] regrtest ResourceWarning - unclosed sockets and files
In-Reply-To: <1290506536.77.0.313292165719.issue10512@psf.upfronthosting.co.za>
Message-ID: <1294146414.09.0.32520768914.issue10512@psf.upfronthosting.co.za>


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

r87710 introduces a ResourceWarning in test_threading. Fix attached.

----------

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

From report at bugs.python.org  Tue Jan  4 14:07:31 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Tue, 04 Jan 2011 13:07:31 +0000
Subject: [issue10512] regrtest ResourceWarning - unclosed sockets and files
In-Reply-To: <1290506536.77.0.313292165719.issue10512@psf.upfronthosting.co.za>
Message-ID: <1294146451.11.0.993125939078.issue10512@psf.upfronthosting.co.za>


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


Added file: http://bugs.python.org/file20255/test_threading.diff

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

From report at bugs.python.org  Tue Jan  4 14:15:56 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 04 Jan 2011 13:15:56 +0000
Subject: [issue9611] FileIO not 64-bit safe under Windows
In-Reply-To: <1281893142.91.0.972520708976.issue9611@psf.upfronthosting.co.za>
Message-ID: <1294146956.4.0.0399626502848.issue9611@psf.upfronthosting.co.za>


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

r87734 fixes stdprinter.write().

----------

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

From report at bugs.python.org  Tue Jan  4 14:24:07 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Tue, 04 Jan 2011 13:24:07 +0000
Subject: [issue9554] test_argparse.py: use new unittest features
In-Reply-To: <1281408827.47.0.183260667114.issue9554@psf.upfronthosting.co.za>
Message-ID: <1294147447.26.0.579613380575.issue9554@psf.upfronthosting.co.za>


Sandro Tosi <sandro.tosi at gmail.com> added the comment:

Hi, I've applied the patch and it goes fine (except for some offsets and the fact it was generated inside Lib/test) and the tests are still all ok. I'd suggest to apply it.

----------
nosy: +sandro.tosi
stage:  -> commit review

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

From report at bugs.python.org  Tue Jan  4 14:37:31 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Tue, 04 Jan 2011 13:37:31 +0000
Subject: [issue9671] test_executable_without_cwd fails: AssertionError: 1 != 47
In-Reply-To: <1282668033.06.0.983312258691.issue9671@psf.upfronthosting.co.za>
Message-ID: <1294148251.42.0.0619235174586.issue9671@psf.upfronthosting.co.za>


Sandro Tosi <sandro.tosi at gmail.com> added the comment:

Ok, so the situation is:

- I've test on debian sid and it works fine
- Dave on a Fedora 13 and it works
- I asked a couple of guys to try it on their systems, that's Fedora14 and Gentoo and it works fine

So I think we can conclude it's a Fedora Core 4 specific problem (that's EOL tho).

I'm closing this report (if someone thinks it's too early, please reopen it :)

Cheers,
Sandro

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

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

From report at bugs.python.org  Tue Jan  4 14:42:44 2011
From: report at bugs.python.org (=?utf-8?b?TWljaGFsIMSMaWhhxZk=?=)
Date: Tue, 04 Jan 2011 13:42:44 +0000
Subject: [issue10824] urandom should not block
In-Reply-To: <1294148564.76.0.493970702032.issue10824@psf.upfronthosting.co.za>
Message-ID: <1294148564.76.0.493970702032.issue10824@psf.upfronthosting.co.za>


New submission from Michal ?iha? <michal at cihar.com>:

Currently if /dev/urandom does not provide any data, unradom() call is just stuck infinitely waiting for data.

I actually faced this issue when /dev/urandom was empty regular file (due to bug in pbuilder, but I don't think it matters how it did happen) and urandom() call just hang. I think it would be much saner in such case to throw an error and let user know that something it wrong than waiting infinitely.

----------
components: Library (Lib)
messages: 125316
nosy: nijel
priority: normal
severity: normal
status: open
title: urandom should not block
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Tue Jan  4 14:49:04 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Tue, 04 Jan 2011 13:49:04 +0000
Subject: [issue10825] use assertIsNone(...) instead of assertEquals(None, ...)
In-Reply-To: <1294148944.07.0.481041700804.issue10825@psf.upfronthosting.co.za>
Message-ID: <1294148944.07.0.481041700804.issue10825@psf.upfronthosting.co.za>


New submission from Sandro Tosi <sandro.tosi at gmail.com>:

Hello, after I saw that in issue9554, I created a small patch to replace all

  assertEquals(None, ...)

with

  assertIsNone(...)

It's not rocket science, but I think it makes test suite "better" and leverage new unittest features.

Cheers,
Sandro

----------
assignee: sandro.tosi
components: Tests
files: use_assertIsNone-py3k.patch
keywords: patch
messages: 125317
nosy: sandro.tosi
priority: normal
severity: normal
stage: patch review
status: open
title: use assertIsNone(...) instead of assertEquals(None, ...)
versions: Python 3.3
Added file: http://bugs.python.org/file20256/use_assertIsNone-py3k.patch

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

From report at bugs.python.org  Tue Jan  4 14:49:47 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 04 Jan 2011 13:49:47 +0000
Subject: [issue10824] urandom should not block
In-Reply-To: <1294148564.76.0.493970702032.issue10824@psf.upfronthosting.co.za>
Message-ID: <1294148987.42.0.913332342643.issue10824@psf.upfronthosting.co.za>


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

This would change semantics of the library call, though.
I see two possible solutions:
- do nothing and let users tackle the issue if necessary (e.g. by calling open() themselves and using select() on the resulting fd)
- add an optional "blocking" parameter to os.urandom() that, if False, would return None when no data is available

----------
nosy: +pitrou
type: behavior -> feature request
versions: +Python 3.3 -Python 2.7

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

From report at bugs.python.org  Tue Jan  4 14:55:58 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 04 Jan 2011 13:55:58 +0000
Subject: [issue10825] use assertIsNone(...) instead of assertEquals(None, ...)
In-Reply-To: <1294148944.07.0.481041700804.issue10825@psf.upfronthosting.co.za>
Message-ID: <1294149358.87.0.0820727536864.issue10825@psf.upfronthosting.co.za>


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

Looks good.

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

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

From report at bugs.python.org  Tue Jan  4 14:59:40 2011
From: report at bugs.python.org (=?utf-8?b?TWljaGFsIMSMaWhhxZk=?=)
Date: Tue, 04 Jan 2011 13:59:40 +0000
Subject: [issue10824] urandom should not block
In-Reply-To: <1294148564.76.0.493970702032.issue10824@psf.upfronthosting.co.za>
Message-ID: <1294149580.02.0.313179187349.issue10824@psf.upfronthosting.co.za>


Michal ?iha? <michal at cihar.com> added the comment:

Well in this particular case (/dev/urandom is regular file), it might make sense to simply raise NotImplementedError

----------

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

From report at bugs.python.org  Tue Jan  4 15:01:47 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 04 Jan 2011 14:01:47 +0000
Subject: [issue10824] urandom should not block
In-Reply-To: <1294149580.02.0.313179187349.issue10824@psf.upfronthosting.co.za>
Message-ID: <1294149702.3669.6.camel@localhost.localdomain>


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

> Well in this particular case (/dev/urandom is regular file), it might
> make sense to simply raise NotImplementedError

IMO it would be quite fragile to try to detect regular files vs special
files. I suppose you noticed the issue quite quickly anyway, since you
had the blocking issue.

----------

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

From report at bugs.python.org  Tue Jan  4 15:06:35 2011
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 04 Jan 2011 14:06:35 +0000
Subject: [issue10824] urandom should not block
In-Reply-To: <1294148564.76.0.493970702032.issue10824@psf.upfronthosting.co.za>
Message-ID: <1294149995.25.0.190718760034.issue10824@psf.upfronthosting.co.za>


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

Is it really necessary to do something about this?  /dev/urandom being a regular file is clearly a bug in your system configuration, and I don't want to know what all the other programs will do that rely on it...

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

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

From report at bugs.python.org  Tue Jan  4 15:10:26 2011
From: report at bugs.python.org (Charles-Francois Natali)
Date: Tue, 04 Jan 2011 14:10:26 +0000
Subject: [issue10824] urandom should not block
In-Reply-To: <1294148564.76.0.493970702032.issue10824@psf.upfronthosting.co.za>
Message-ID: <1294150226.55.0.0361811565036.issue10824@psf.upfronthosting.co.za>


Charles-Francois Natali <neologix at free.fr> added the comment:

>From the documentation:
"This function returns random bytes from an OS-specific randomness source."

In your case, this problem shows up because of an OS misconfiguration : in that case, the behaviour is undefined (not much Python can do about it). Note that since /dev/urandom is used, with a properly configured system, this should never block (contrarily to /dev/random which might block until enough entropy has been gathered).

----------
nosy: +neologix

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

From report at bugs.python.org  Tue Jan  4 15:11:33 2011
From: report at bugs.python.org (=?utf-8?b?TWljaGFsIMSMaWhhxZk=?=)
Date: Tue, 04 Jan 2011 14:11:33 +0000
Subject: [issue10824] urandom should not block
In-Reply-To: <1294148564.76.0.493970702032.issue10824@psf.upfronthosting.co.za>
Message-ID: <1294150293.87.0.0508903746599.issue10824@psf.upfronthosting.co.za>


Michal ?iha? <michal at cihar.com> added the comment:

Yes, it was blocking, but deep in some program (which was actually called by dpkg postinst script), so it took some time to figure out.

I don't think it's that fragile to figure out whether it is regular file using os.path.isfile.

Indeed it was bug in a system, but actually this was only thing which got stuck because of it.

----------

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

From report at bugs.python.org  Tue Jan  4 15:13:20 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 04 Jan 2011 14:13:20 +0000
Subject: [issue10824] urandom should not block
In-Reply-To: <1294148564.76.0.493970702032.issue10824@psf.upfronthosting.co.za>
Message-ID: <1294150400.2.0.761771125381.issue10824@psf.upfronthosting.co.za>


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

> Note that since /dev/urandom is used, with a properly configured
> system, this should never block

Ok, suggesting closing then.

----------
resolution:  -> invalid
status: open -> pending

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

From report at bugs.python.org  Tue Jan  4 15:15:18 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 04 Jan 2011 14:15:18 +0000
Subject: [issue9554] test_argparse.py: use new unittest features
In-Reply-To: <1281408827.47.0.183260667114.issue9554@psf.upfronthosting.co.za>
Message-ID: <1294150518.85.0.839729668318.issue9554@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Tue Jan  4 15:44:50 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 04 Jan 2011 14:44:50 +0000
Subject: [issue10826] pass_fds sometimes fails
In-Reply-To: <1294152290.71.0.646502628705.issue10826@psf.upfronthosting.co.za>
Message-ID: <1294152290.71.0.646502628705.issue10826@psf.upfronthosting.co.za>


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

This happens selectively (and intermittently) on the Solaris buildbot:

test_pass_fds (test.test_subprocess.POSIXProcessTestCase) ...  -- maxfd = 256
[36787 refs]
 -- fds that should have been closed: {5, 6, 7, 8, 9, 10, 11, 12, 13}
 -- fds that remained open: {0, 1, 2, 3, 5}
FAIL

test_pass_fds (test.test_subprocess.ProcessTestCasePOSIXPurePython) ...  -- maxfd = 256
[36787 refs]
 -- fds that should have been closed: {5, 6, 7, 8, 9, 10, 11, 12, 13}
 -- fds that remained open: {0, 1, 2, 3, 5}
FAIL

As you see (thanks to debug output), all fds have been closed except number 5.

(http://www.python.org/dev/buildbot/all/builders/sparc%20solaris10%20gcc%203.x/builds/2466/steps/test/logs/stdio)

----------
components: Library (Lib), Tests
messages: 125326
nosy: gregory.p.smith, pitrou
priority: normal
severity: normal
status: open
title: pass_fds sometimes fails
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Tue Jan  4 15:49:22 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 04 Jan 2011 14:49:22 +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: <1294152562.16.0.830931052591.issue10181@psf.upfronthosting.co.za>


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

Agreed. I'll put something on python-dev about that, so MvL sees it.

----------

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

From report at bugs.python.org  Tue Jan  4 15:54:42 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 04 Jan 2011 14:54:42 +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: <1294152882.35.0.707448361917.issue10181@psf.upfronthosting.co.za>


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

More direct - added MvL to nosy list.

Martin, we would like to exclude Py_buffer from the stable ABI for Python 3.2, until we have a chance to thrash out the missing pieces of the documentation for 3.3. I *think* it is a documentation problem, but until we're certain, it seems safer to leave it out.

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

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

From report at bugs.python.org  Tue Jan  4 15:55:09 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 04 Jan 2011 14:55:09 +0000
Subject: [issue10826] pass_fds sometimes fails
In-Reply-To: <1294152290.71.0.646502628705.issue10826@psf.upfronthosting.co.za>
Message-ID: <1294152909.61.0.607556885132.issue10826@psf.upfronthosting.co.za>


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

Another (perhaps more likely) possibility is that fd 5 was properly closed, but another one created at startup by the child Python interpreter. How could we diagnose that?

----------

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

From report at bugs.python.org  Tue Jan  4 15:56:26 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 04 Jan 2011 14:56:26 +0000
Subject: [issue10001] ~Py_buffer.obj field is undocumented, though not hidden
In-Reply-To: <1285868807.58.0.617972550499.issue10001@psf.upfronthosting.co.za>
Message-ID: <1294152986.17.0.101948520227.issue10001@psf.upfronthosting.co.za>


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

Closing as a dupe of 10181, but transferring Lenard's comments over there.

----------
resolution:  -> duplicate
status: open -> closed
superseder:  -> Problems with Py_buffer management in memoryobject.c (and elsewhere?)

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

From report at bugs.python.org  Tue Jan  4 15:56:36 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 04 Jan 2011 14:56:36 +0000
Subject: [issue7995] On Mac / BSD sockets returned by accept inherit the
	parent's FD flags
In-Reply-To: <1266876583.45.0.97810567794.issue7995@psf.upfronthosting.co.za>
Message-ID: <1294152996.59.0.561095708368.issue7995@psf.upfronthosting.co.za>


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

A new patch combining Ross' test with the simple approach from issue 976613. Works under Linux, OpenSolaris and Windows.

----------
Added file: http://bugs.python.org/file20257/nonblock2.patch

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

From report at bugs.python.org  Tue Jan  4 15:58:48 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 04 Jan 2011 14:58:48 +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: <1294153128.02.0.785761120279.issue10181@psf.upfronthosting.co.za>


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

>From Lenard Lindstrom in issue 10001 (closed as dupe of this issue):

The ~Py_buffer.obj field is undocumented. Yet memoryview, that acts as a wrapper, includes the field in gc traversal. Also, if the field is not initialized by bf_getbuffer its value can be indeterminate. For memoryview the gc can crash (see attached C demo program).

----------

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

From report at bugs.python.org  Tue Jan  4 16:01:59 2011
From: report at bugs.python.org (Mher Movsisyan)
Date: Tue, 04 Jan 2011 15:01:59 +0000
Subject: [issue985064] plistlib crashes too easily on bad files
Message-ID: <1294153319.0.0.214049828326.issue985064@psf.upfronthosting.co.za>


Mher Movsisyan <mher.movsisyan at gmail.com> added the comment:

I've replaced plistlib.InvalidPlistError with ValueError

----------
Added file: http://bugs.python.org/file20258/plist_validation_v2.diff

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

From report at bugs.python.org  Tue Jan  4 16:03:28 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 04 Jan 2011 15:03:28 +0000
Subject: [issue9566] Compilation warnings under x64 Windows
In-Reply-To: <1281484786.91.0.306555541292.issue9566@psf.upfronthosting.co.za>
Message-ID: <1294153408.82.0.462984242277.issue9566@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

r87733 in pyexpat.c modified a call to PyErr_Format with a %zi format code.
This format does not seem to be supported. %zd should be used instead.

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9566>
_______________________________________

From report at bugs.python.org  Tue Jan  4 16:55:32 2011
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 04 Jan 2011 15:55:32 +0000
Subject: [issue5945] PyMapping_Check returns 1 for lists
In-Reply-To: <1241560036.33.0.817766851688.issue5945@psf.upfronthosting.co.za>
Message-ID: <1294156532.98.0.986874046422.issue5945@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

> In the meantime, would it be reasonable to add the moral equivalent
> of `hasattr(type(op), 'items')` to PyMapping_Check()?

That all depends on what it is used for.  Which is hard to say without someone following more of the links that Raymond posted.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5945>
_______________________________________

From report at bugs.python.org  Tue Jan  4 17:14:43 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 04 Jan 2011 16:14:43 +0000
Subject: [issue5945] PyMapping_Check returns 1 for lists
In-Reply-To: <1241560036.33.0.817766851688.issue5945@psf.upfronthosting.co.za>
Message-ID: <1294157683.61.0.580559861397.issue5945@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Modules/posixmodule.c: uses PyMapping_Size(), PyMapping_Keys() and PyMapping_Values() to parse an environment mapping (for execve() and friends).

PyFrame_New(): validates the "locals" argument in pydebug mode (only used for module-level code).
Note that functions in frameobject.c have "assert(PyDict_Check(dict))" where "dict" is that same locals argument (copied into f_locals)...

PC/_subprocess.c: uses PyMapping_Size(), PyMapping_Keys() and PyMapping_Values() to parse an environment mapping (for CreateProcessW()).

Python/btninmodule.c: validates the "locals" argument to eval().


There are also a couple of places where the PyMapping API (such PyMapping_Keys()) is used (e.g. _json), but without calling PyMapping_Check first.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5945>
_______________________________________

From report at bugs.python.org  Tue Jan  4 17:24:14 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 04 Jan 2011 16:24:14 +0000
Subject: [issue1075356] exceeding obscure weakproxy bug
Message-ID: <1294158254.12.0.805185156646.issue1075356@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

It's not fixed. range() now uses the tp_index slot, in weakrefs this becomes:
    WRAP_UNARY(proxy_index, PyNumber_Index)
and indeed PyNumber_Index does not accept strings.

But try with time.sleep() instead; here the line
    WRAP_UNARY(proxy_float, PyNumber_Float)
is involved:


import _weakref, time

class U(str): pass
u = U("1")

try:
    time.sleep(u)
except TypeError:
    print("raised, good")
else:
    print("didn't raise, bad")

try:
    time.sleep(_weakref.proxy(u))
except TypeError:
    print("raised, good")
else:
    print("didn't raise, bad")

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1075356>
_______________________________________

From report at bugs.python.org  Tue Jan  4 17:31:45 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Tue, 04 Jan 2011 16:31:45 +0000
Subject: [issue6643] Throw away more radioactive locks that could be held
	across a fork in threading.py
In-Reply-To: <1249412209.9.0.200329347238.issue6643@psf.upfronthosting.co.za>
Message-ID: <1294158705.46.0.068361600421.issue6643@psf.upfronthosting.co.za>


Nadeem Vawda <nadeem.vawda at gmail.com> added the comment:

r87710 introduces an AttributeError in test_thread's TestForkInThread test case. If os.fork() is called from a thread created by the _thread module, threading._after_fork() will get a _DummyThread (with no _block attribute) as the current thread.

I've attached a patch that checks whether the thread has a _block attribute before trying to reinitialize it.

----------
nosy: +nvawda
Added file: http://bugs.python.org/file20259/test_thread.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6643>
_______________________________________

From report at bugs.python.org  Tue Jan  4 17:40:56 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 04 Jan 2011 16:40:56 +0000
Subject: [issue6643] Throw away more radioactive locks that could be held
	across a fork in threading.py
In-Reply-To: <1249412209.9.0.200329347238.issue6643@psf.upfronthosting.co.za>
Message-ID: <1294159256.44.0.27552100148.issue6643@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6643>
_______________________________________

From report at bugs.python.org  Tue Jan  4 17:48:32 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 04 Jan 2011 16:48:32 +0000
Subject: [issue10827] Functions in time module should support year < 1900 when
	accept2dyear = 0
In-Reply-To: <1294159712.85.0.42147185487.issue10827@psf.upfronthosting.co.za>
Message-ID: <1294159712.85.0.42147185487.issue10827@psf.upfronthosting.co.za>


New submission from Alexander Belopolsky <belopolsky at users.sourceforge.net>:

"""
> http://docs.python.org/library/time.html#time-y2kissues
> "Values 100?1899 are always illegal."

Why are these values illegal? The GNU libc accepts year in [1900-2^31; 2^31-1] (tm_year in [-2147483648; 2147481747]). If time.accept2dyear=False, we should at least accept years in [1; 9999]. The system libc would raise an error (return NULL) if it doesn't know how to format years older than 1900.
""" -- Victor Stinner at msg12516

----------
assignee: belopolsky
components: Extension Modules
messages: 125339
nosy: SilentGhost, belopolsky, haypo
priority: normal
severity: normal
status: open
title: Functions in time module should support year < 1900 when accept2dyear = 0
type: behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10827>
_______________________________________

From report at bugs.python.org  Tue Jan  4 17:51:28 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 04 Jan 2011 16:51:28 +0000
Subject: [issue8013] time.asctime segfaults when given a time in the far future
In-Reply-To: <1267031714.43.0.416052646257.issue8013@psf.upfronthosting.co.za>
Message-ID: <1294159888.05.0.0924803584991.issue8013@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Committed in r87736.  I opened a separate issue #10827 to address the lower bound.

----------
resolution:  -> fixed
stage: commit review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8013>
_______________________________________

From report at bugs.python.org  Tue Jan  4 17:54:13 2011
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 04 Jan 2011 16:54:13 +0000
Subject: [issue985064] plistlib crashes too easily on bad files
Message-ID: <1294160053.51.0.215103125812.issue985064@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

LGTM.

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue985064>
_______________________________________

From report at bugs.python.org  Tue Jan  4 17:56:07 2011
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 04 Jan 2011 16:56:07 +0000
Subject: [issue8013] time.asctime segfaults when given a time in the far future
In-Reply-To: <1267031714.43.0.416052646257.issue8013@psf.upfronthosting.co.za>
Message-ID: <1294160167.5.0.648861687669.issue8013@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Thanks!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8013>
_______________________________________

From report at bugs.python.org  Tue Jan  4 18:30:13 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 04 Jan 2011 17:30:13 +0000
Subject: [issue10827] Functions in time module should support year < 1900 when
	accept2dyear = 0
In-Reply-To: <1294159712.85.0.42147185487.issue10827@psf.upfronthosting.co.za>
Message-ID: <1294162213.49.0.928737927372.issue10827@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

> The system libc would raise an error (return NULL) if it doesn't know
> how to format years older than 1900.

As experience with asctime has shown, system libc can do whatever it pleases with out of range values including overrunning a fixed size buffer, returning non-sensical values etc.  However, now that we have control over asctime implemetation (see issue 8013), I don't see any problem in supporting at least year > 999 in time.asctime and time.ctime.  (Supporting full [1900-maxint, maxint] range would involve a decision on whether to fill < 4-digit values.)  Some extra care would be required for time.strftime() because some systems may not support year < 1900 as well as others.

It looks like POSIX does not make any strong mandates:

"tm_year is a signed value; therefore, years before 1900 may be represented." 

http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/time.h.html

and regardless of what POSIX or C standards have to say, this is the area where systems a known to have spotty compliance records.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10827>
_______________________________________

From report at bugs.python.org  Tue Jan  4 18:32:00 2011
From: report at bugs.python.org (=?utf-8?q?Andreas_St=C3=BChrk?=)
Date: Tue, 04 Jan 2011 17:32:00 +0000
Subject: [issue10827] Functions in time module should support year < 1900 when
	accept2dyear = 0
In-Reply-To: <1294159712.85.0.42147185487.issue10827@psf.upfronthosting.co.za>
Message-ID: <1294162320.32.0.728338627391.issue10827@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/issue10827>
_______________________________________

From report at bugs.python.org  Tue Jan  4 18:55:29 2011
From: report at bugs.python.org (Alex Raitz)
Date: Tue, 04 Jan 2011 17:55:29 +0000
Subject: [issue10751] REMOTE_USER and Remote-User collision in wsgiref
In-Reply-To: <1292971576.27.0.760159303747.issue10751@psf.upfronthosting.co.za>
Message-ID: <1294163729.98.0.975303607741.issue10751@psf.upfronthosting.co.za>


Alex Raitz <alex.raitz at gmail.com> added the comment:

Yes, I was referring to REMOTE_USER, apologies for the conflation with HTTP_REMOTE_USER, which was one of the HTTP headers that a proxy which we were testing was setting.

The customer that reported this issue to us was using FireFox with Tamper Data to set REMOTE-USER, AdNovum Nevis as the proxy, and Splunk as the server.  

For example, the following is received by the proxy in question:

Host: foobar:42000
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101203 Firefox/3.6.13
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Cookie: session_id_4200=69e6b6e33510fa64d8b18c34aa73b4b50eff37dc
remote-user: USER-SUPPLIED
Cache-Control: max-age=0 
Connection: Keep-Alive

The proxy sends the following to the server:

Host: localhost:4200
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101203 Firefox/3.6.13
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
REMOTE_USER: normal_user
X-Forwarded-For: 10.3.1.53
X-Forwarded-Host: foobar:42000
X-Forwarded-Server: foobar <http://foobar>
Cookie: session_id_4200=69e6b6e33510fa64d8b18c34aa73b4b50eff37dc
Authorization: Basic Z2FyZXRoOjUzMjc5 
Cache-Control: max-age=0
remote-user: USER-SUPPLIED
Connection: Keep-Alive

In this case, replacing '-' with '_' in wsgiref would overload 'remote_user=normal_user' with 'remote_user=user-supplied'.

When testing with Apache, we found that all user-supplied variables were placed above the proxy-added variables, so that overloading was not an issue.  This seems like the appropriate and expected behavior.

However, given that the customer's chosen proxy did not exhibit this behavior, and searching for a specification for proxy behavior in this situation was inconclusive, our team deemed it advisable to file this issue.

Ideally, Python wsgiref should ensure that the proxy-supplied REMOTE_USER cannot be overloaded by a user-supplied REMOTE-USER that is passed to the server after the proxy-supplied REMOTE_USER.

Please note that Splunk uses wsgiref from the CherryPy framework, but when we investigated the issue we noticed that the replacement of '-' with '_' is the same in both Python and CherryPy wsgiref.  A bug has also been filed against CherryPy.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10751>
_______________________________________

From report at bugs.python.org  Tue Jan  4 19:30:47 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 04 Jan 2011 18:30:47 +0000
Subject: [issue10827] Functions in time module should support year < 1900 when
	accept2dyear = 0
In-Reply-To: <1294159712.85.0.42147185487.issue10827@psf.upfronthosting.co.za>
Message-ID: <1294165847.38.0.45421650534.issue10827@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

I am attaching a patch.  While working on the patch, I noticed that although time.accept2dyear is documented as boolean, the current code expects int and treats any non-int including True as 0:

>>> time.accept2dyear = True; time.asctime((99,) + (0,)*8)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: year >= 1900 required

>>> time.accept2dyear = 1; time.asctime((99,) + (0,)*8)
'Mon Jan  1 00:00:00 1999'

This is clearly a bug.  (Although Y2K note contradicts time.accept2dyear documentation.)

Supporting year < 1900 would be a feature in my view, but I agree with SilentGhost that once we extended support to 5+ digit years, it is odd to keep year >= 1900 restriction.

----------
keywords: +patch
Added file: http://bugs.python.org/file20260/issue10827.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10827>
_______________________________________

From report at bugs.python.org  Tue Jan  4 19:34:44 2011
From: report at bugs.python.org (Gregory P. Smith)
Date: Tue, 04 Jan 2011 18:34:44 +0000
Subject: [issue6643] Throw away more radioactive locks that could be held
	across a fork in threading.py
In-Reply-To: <1249412209.9.0.200329347238.issue6643@psf.upfronthosting.co.za>
Message-ID: <1294166084.57.0.57138332758.issue6643@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

eek, thanks for noticing that!

r87740 fixes this in py3k.  backporting to 3.1 and 2.7 now.

----------
nosy: +barry
priority: normal -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6643>
_______________________________________

From report at bugs.python.org  Tue Jan  4 19:35:33 2011
From: report at bugs.python.org (Armin Rigo)
Date: Tue, 04 Jan 2011 18:35:33 +0000
Subject: [issue1170766] weakref.proxy incorrect behaviour
Message-ID: <1294166133.9.0.0162351402873.issue1170766@psf.upfronthosting.co.za>


Armin Rigo <arigo at users.sourceforge.net> added the comment:

Not for me (the last example I posted, on 2.7 head).  But I will not fight for this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1170766>
_______________________________________

From report at bugs.python.org  Tue Jan  4 19:36:58 2011
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 04 Jan 2011 18:36:58 +0000
Subject: [issue5945] PyMapping_Check returns 1 for lists
In-Reply-To: <1241560036.33.0.817766851688.issue5945@psf.upfronthosting.co.za>
Message-ID: <1294166218.01.0.70748676517.issue5945@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

The question is, if PyMapping_Check() returns True, and a list is passed, will the code segfault or raise an exception?  A segfault would be unacceptable; an exception would be acceptable assuming that the code would have raised an exception anyway if PyMapping_Check() had returned False.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5945>
_______________________________________

From report at bugs.python.org  Tue Jan  4 19:38:57 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 04 Jan 2011 18:38:57 +0000
Subject: [issue10827] Functions in time module should support year < 1900 when
	accept2dyear = 0
In-Reply-To: <1294165847.38.0.45421650534.issue10827@psf.upfronthosting.co.za>
Message-ID: <AANLkTi=EyfMaXP=L4MS_FA2aK0UpDwZssOmjT0YKhqBH@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Tue, Jan 4, 2011 at 1:30 PM, Alexander Belopolsky
<report at bugs.python.org> wrote:
..
> This is clearly a bug. ?(Although Y2K note contradicts time.accept2dyear documentation.)
>

PyObject_IsTrue() may fail - this is probably the reason for the
current odd logic.  My patch should be fixed top respect that, but I
still maintain that time.accept2dyear = True should work as expected.
(Would also make True the default rather 1.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10827>
_______________________________________

From report at bugs.python.org  Tue Jan  4 19:44:22 2011
From: report at bugs.python.org (Gregory P. Smith)
Date: Tue, 04 Jan 2011 18:44:22 +0000
Subject: [issue6643] Throw away more radioactive locks that could be held
	across a fork in threading.py
In-Reply-To: <1249412209.9.0.200329347238.issue6643@psf.upfronthosting.co.za>
Message-ID: <1294166662.41.0.174947145447.issue6643@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

r87741 3.1
r87742 2.7

----------
resolution: accepted -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6643>
_______________________________________

From report at bugs.python.org  Tue Jan  4 19:47:33 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 04 Jan 2011 18:47:33 +0000
Subject: [issue5945] PyMapping_Check returns 1 for lists
In-Reply-To: <1241560036.33.0.817766851688.issue5945@psf.upfronthosting.co.za>
Message-ID: <1294166853.71.0.818172321515.issue5945@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Exceptions seem to be raised (for code that can be exercised in Python), but not very obvious ones:

>>> eval("x", {}, [])
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<string>", line 1, in <module>
TypeError: list indices must be integers, not str

$ ./python -c "import os; os.execle('/bin/ls', 'ls', [])"
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/home/antoine/py3k/__svn__/Lib/os.py", line 320, in execle
    execve(file, args[:-1], env)
AttributeError: values

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5945>
_______________________________________

From report at bugs.python.org  Tue Jan  4 19:47:42 2011
From: report at bugs.python.org (Gregory P. Smith)
Date: Tue, 04 Jan 2011 18:47:42 +0000
Subject: [issue8458] buildbot: test_cmd_line failure on Tiger: [Errno 9] Bad
	file descriptor
In-Reply-To: <1271678026.95.0.894433016298.issue8458@psf.upfronthosting.co.za>
Message-ID: <1294166862.86.0.755979055054.issue8458@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

Off the top of my head I don't _think_ so.. at least for posix.  I'm not sure about the implications of the if mswindows: code in there though.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8458>
_______________________________________

From report at bugs.python.org  Tue Jan  4 19:49:53 2011
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 04 Jan 2011 18:49:53 +0000
Subject: [issue10827] Functions in time module should support year < 1900 when
	accept2dyear = 0
In-Reply-To: <1294159712.85.0.42147185487.issue10827@psf.upfronthosting.co.za>
Message-ID: <1294166993.94.0.856099987124.issue10827@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

But if it fails, why not just let it fail?

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10827>
_______________________________________

From report at bugs.python.org  Tue Jan  4 19:53:31 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 04 Jan 2011 18:53:31 +0000
Subject: [issue8458] buildbot: test_cmd_line failure on Tiger: [Errno 9] Bad
	file descriptor
In-Reply-To: <1271678026.95.0.894433016298.issue8458@psf.upfronthosting.co.za>
Message-ID: <1294167211.79.0.378453629197.issue8458@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Well we could try a run of it on the buildbots, then :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8458>
_______________________________________

From report at bugs.python.org  Tue Jan  4 20:01:45 2011
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 04 Jan 2011 19:01:45 +0000
Subject: [issue5945] PyMapping_Check returns 1 for lists
In-Reply-To: <1241560036.33.0.817766851688.issue5945@psf.upfronthosting.co.za>
Message-ID: <1294167705.93.0.201071629359.issue5945@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

It looks like PyMapping_Check() already checks for the presence of a fairly arbitrary special operation (mp_subscript).  It sounds fine to replace that with a check for the presence of a keys() or items() method (I'm not sure which one is more representative). I wish the check can be done fast -- but I fear that it'll involve a dict lookup.  So be it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5945>
_______________________________________

From report at bugs.python.org  Tue Jan  4 20:02:41 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 04 Jan 2011 19:02:41 +0000
Subject: [issue10827] Functions in time module should support year < 1900 when
	accept2dyear = 0
In-Reply-To: <1294166993.94.0.856099987124.issue10827@psf.upfronthosting.co.za>
Message-ID: <AANLkTinTbu2XFdWvHgyatSV0-OORT4WvzjOhvicmK7VM@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Tue, Jan 4, 2011 at 1:49 PM, Georg Brandl <report at bugs.python.org> wrote:
..
> But if it fails, why not just let it fail?
>

Sure.  That's what I meant by fixing the patch.  See new patch attached.

----------
Added file: http://bugs.python.org/file20261/issue10827a.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10827>
_______________________________________
-------------- next part --------------
Index: Modules/timemodule.c
===================================================================
--- Modules/timemodule.c	(revision 87738)
+++ Modules/timemodule.c	(working copy)
@@ -355,21 +355,20 @@
     if (y < 1900) {
         PyObject *accept = PyDict_GetItemString(moddict,
                                                 "accept2dyear");
-        if (accept == NULL || !PyLong_CheckExact(accept) ||
-            !PyObject_IsTrue(accept)) {
-            PyErr_SetString(PyExc_ValueError,
-                            "year >= 1900 required");
+        int acceptval = accept != NULL && PyObject_IsTrue(accept);
+        if (acceptval == -1)
             return 0;
+        if (acceptval) {
+            if (69 <= y && y <= 99)
+                y += 1900;
+            else if (0 <= y && y <= 68)
+                y += 2000;
+            else {
+                PyErr_SetString(PyExc_ValueError,
+                                "year out of range");
+                return 0;
+            }
         }
-        if (69 <= y && y <= 99)
-            y += 1900;
-        else if (0 <= y && y <= 68)
-            y += 2000;
-        else {
-            PyErr_SetString(PyExc_ValueError,
-                            "year out of range");
-            return 0;
-        }
     }
     p->tm_year = y - 1900;
     p->tm_mon--;

From report at bugs.python.org  Tue Jan  4 20:07:22 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 04 Jan 2011 19:07:22 +0000
Subject: [issue8458] buildbot: test_cmd_line failure on Tiger: [Errno 9] Bad
	file descriptor
In-Reply-To: <1271678026.95.0.894433016298.issue8458@psf.upfronthosting.co.za>
Message-ID: <1294168042.97.0.81371711497.issue8458@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Trying it in r87744.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8458>
_______________________________________

From report at bugs.python.org  Tue Jan  4 20:10:28 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 04 Jan 2011 19:10:28 +0000
Subject: [issue10826] pass_fds sometimes fails
In-Reply-To: <1294152290.71.0.646502628705.issue10826@psf.upfronthosting.co.za>
Message-ID: <1294168228.87.0.705266240557.issue10826@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Happened also on the OpenIndiana buildbot:

http://www.python.org/dev/buildbot/all/builders/x86%20OpenIndiana%203.x/builds/492/steps/test/logs/stdio

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10826>
_______________________________________

From report at bugs.python.org  Tue Jan  4 20:18:38 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 04 Jan 2011 19:18:38 +0000
Subject: [issue9738] Document the encoding of functions bytes arguments of the
	C API
In-Reply-To: <1283380895.91.0.777071955411.issue9738@psf.upfronthosting.co.za>
Message-ID: <1294168718.02.0.32371139578.issue9738@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Victor,

Here is an interesting case for your collection: PyDict_GetItemString.  Note that it is documented as not setting error, but in fact it may if encoding fails.  This rarely an issue because most uses of PyDict_GetItemString are with an ASCII string literal.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9738>
_______________________________________

From report at bugs.python.org  Tue Jan  4 20:44:17 2011
From: report at bugs.python.org (ingemar)
Date: Tue, 04 Jan 2011 19:44:17 +0000
Subject: [issue10828] Cannot use nonascii utf8 in names of files imported from
In-Reply-To: <1294170257.81.0.980912064683.issue10828@psf.upfronthosting.co.za>
Message-ID: <1294170257.81.0.980912064683.issue10828@psf.upfronthosting.co.za>


New submission from ingemar <ingemar at sijohansson.com>:

I have a set of programs written for Python3.1 and running well on Kubuntu. The source files are located on a Samba server on a Kubuntu box.  Several of the programs contain Python/PyQt  code to start other programs in the set (   QtCore.QProcess().startDetached(kommando)   )
I have had no problems using non-ascii filenames in the Linux environment.


When I tried to check the programs in a MS Windows environment  (Win2K with Python 3.1.2 in a VirtualBox in a Kubuntu box) then Python complained:
ImportError: module xxx not found..

The ugly solution has been to refrain from the use of non-ascii characters in the names of files imported from. This involved the filename of the imported file and also one line of code changed in the importing file.

Example: 
1) rename  "gui_j?mf?ra.py"   --->   "gui_jamfora.py"
2) in the importing file  "j?mf?ra.py"  change one line:
"from  gui_j?mf?ra  import  * "   --->   "from  gui_jamfora  import  gui_J?mf?ra"

Is there a beautiful solution that will permit me to use non-ascii utf-8 also in the file names of files imported from?

----------
messages: 125360
nosy: ingemar
priority: normal
severity: normal
status: open
title: Cannot use nonascii utf8 in names of files imported from
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10828>
_______________________________________

From report at bugs.python.org  Tue Jan  4 21:06:17 2011
From: report at bugs.python.org (Ross Lagerwall)
Date: Tue, 04 Jan 2011 20:06:17 +0000
Subject: [issue8052] subprocess close_fds behavior should only close open fds
In-Reply-To: <1267672679.06.0.725064778002.issue8052@psf.upfronthosting.co.za>
Message-ID: <1294171577.63.0.505249919284.issue8052@psf.upfronthosting.co.za>


Ross Lagerwall <rosslagerwall at gmail.com> added the comment:

Does this mean that it's better to call the close() syscall 1000 or 1000 0000 times rather than listing the open fds & closing say a handful?

On Linux, the listdir function results in an open() syscall, 2 or so getdents() calls and a close() call - could this not be done inbetween the fork & exec, even if the actual python function isn't called directly?

----------
nosy: +rosslagerwall

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8052>
_______________________________________

From report at bugs.python.org  Tue Jan  4 22:08:36 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Tue, 04 Jan 2011 21:08:36 +0000
Subject: [issue10824] urandom should not block
In-Reply-To: <1294148564.76.0.493970702032.issue10824@psf.upfronthosting.co.za>
Message-ID: <1294175316.39.0.97149164005.issue10824@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

I wonder why reading from /dev/urandom has a loop in the first place, though - isn't it guaranteed that you can read as many bytes as you want in one go? This goes back to #934711, and apparently, even the original patch had the loop - for reasons that got never questioned.

----------
nosy: +loewis
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10824>
_______________________________________

From report at bugs.python.org  Tue Jan  4 22:24:33 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 04 Jan 2011 21:24:33 +0000
Subject: [issue9566] Compilation warnings under x64 Windows
In-Reply-To: <1281484786.91.0.306555541292.issue9566@psf.upfronthosting.co.za>
Message-ID: <1294176273.28.0.739069627909.issue9566@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

#10823 has been marked as a duplicate of this issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9566>
_______________________________________

From report at bugs.python.org  Tue Jan  4 22:32:30 2011
From: report at bugs.python.org (Roumen Petrov)
Date: Tue, 04 Jan 2011 21:32:30 +0000
Subject: [issue9419] RUNSHARED needs LDFLAGS
In-Reply-To: <1280423222.23.0.51081739049.issue9419@psf.upfronthosting.co.za>
Message-ID: <1294176750.04.0.0826462320446.issue9419@psf.upfronthosting.co.za>


Roumen Petrov <bugtrack at roumenpetrov.info> added the comment:

LDFLAGS make no sense for run time. The patch seems to me bogus.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9419>
_______________________________________

From report at bugs.python.org  Tue Jan  4 22:40:39 2011
From: report at bugs.python.org (R. David Murray)
Date: Tue, 04 Jan 2011 21:40:39 +0000
Subject: [issue10824] urandom should not block
In-Reply-To: <1294148564.76.0.493970702032.issue10824@psf.upfronthosting.co.za>
Message-ID: <1294177239.95.0.576112165818.issue10824@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Agreed that the original issue is invalid.  So either the title should be changed so it can be used to address Martin's question, or it should be closed.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10824>
_______________________________________

From report at bugs.python.org  Tue Jan  4 22:44:13 2011
From: report at bugs.python.org (R. David Murray)
Date: Tue, 04 Jan 2011 21:44:13 +0000
Subject: [issue10828] Cannot use nonascii utf8 in names of files imported from
In-Reply-To: <1294170257.81.0.980912064683.issue10828@psf.upfronthosting.co.za>
Message-ID: <1294177453.95.0.970241990063.issue10828@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Have you tried 3.2b2?

----------
nosy: +haypo, r.david.murray
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10828>
_______________________________________

From report at bugs.python.org  Tue Jan  4 22:47:11 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Tue, 04 Jan 2011 21:47:11 +0000
Subject: [issue9566] Compilation warnings under x64 Windows
In-Reply-To: <1281484786.91.0.306555541292.issue9566@psf.upfronthosting.co.za>
Message-ID: <1294177631.26.0.639346888504.issue9566@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

haypo: please avoid introducing explicit casts (such as the one in pyexpat.c). Use SAFECASTs instead. If you are absolutely certain that a cast cannot possibly truncate, add a comment explaining why that is. In the specific case, I think it actually *is* possible that the cast truncates, because the case that read() returned too many bytes is incorrectly handled (it should set len to -1).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9566>
_______________________________________

From report at bugs.python.org  Tue Jan  4 22:54:44 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Tue, 04 Jan 2011 21:54:44 +0000
Subject: [issue10824] urandom should not block
In-Reply-To: <1294148564.76.0.493970702032.issue10824@psf.upfronthosting.co.za>
Message-ID: <1294178084.65.0.79974547511.issue10824@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Closing it. It seems that people feel more safe when urandom loops until it has enough data (see http://stackoverflow.com/questions/4598507/dev-urandom-maximum-size/4598534#4598534). I might still pursue this idea, but in a different issue.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10824>
_______________________________________

From report at bugs.python.org  Tue Jan  4 22:58:19 2011
From: report at bugs.python.org (Charles-Francois Natali)
Date: Tue, 04 Jan 2011 21:58:19 +0000
Subject: [issue10824] urandom should not block
In-Reply-To: <1294175316.39.0.97149164005.issue10824@psf.upfronthosting.co.za>
Message-ID: <AANLkTi=Wk+hHaf4h=BwbW9mHW8fMuzkmShcmL_o+axur@mail.gmail.com>


Charles-Francois Natali <neologix at free.fr> added the comment:

> Martin v. L?wis <martin at v.loewis.de> added the comment:
>
> I wonder why reading from /dev/urandom has a loop in the first place, though - isn't it guaranteed that you can read as many bytes as you want in one go? This goes back to #934711, and apparently, even the original patch had the loop - for reasons that got never questioned.
>

I found surprising that a read from /dev/urandom would be
uninterruptible, so I digged a little, and found this mail from 1998:

[patch] fix for urandom read(2) not interruptible
http://marc.info/?l=bugtraq&m=91495921611500&w=2

"It's a bug in random.c that doesn' t check for signal pending inside the
read(2) code, so you have no chance to kill the process via signals until
the read(2) syscall is finished, and it could take a lot of time before
return, if the buffer given to the read syscall is very big..."

I've had a quick look at the source code, and indeed, read(2) from
/dev/urandom can now be interrupted by a signal, so looping seems to
be justified.

> ----------
> nosy: +loewis
> status: pending -> open
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue10824>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10824>
_______________________________________

From report at bugs.python.org  Tue Jan  4 23:02:51 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 04 Jan 2011 22:02:51 +0000
Subject: [issue9566] Compilation warnings under x64 Windows
In-Reply-To: <1281484786.91.0.306555541292.issue9566@psf.upfronthosting.co.za>
Message-ID: <1294178571.15.0.908274924182.issue9566@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

amaury> r87733 in pyexpat.c modified a call to PyErr_Format with a %zi
amaury> format code. This format does not seem to be supported. %zd
amaury> should be used instead.

Oh, that's surprising. Why %zd is supported but not %zi?

PyUnicode_FromFormatV() supports %d, %ld, %lld, %zd, %i, but not %li, %lli or %zi. Before fixing PyUnicode_FromFormatV(), I fixed pyexpat.c: r87747.

MvL> If you are absolutely certain that a cast cannot possibly truncate, 
MvL> add a comment explaining why that is.

Ah yes, sorry, I forgot to add a comment: done in r87746.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9566>
_______________________________________

From report at bugs.python.org  Tue Jan  4 23:05:28 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 04 Jan 2011 22:05:28 +0000
Subject: [issue9566] Compilation warnings under x64 Windows
In-Reply-To: <1281484786.91.0.306555541292.issue9566@psf.upfronthosting.co.za>
Message-ID: <1294178728.05.0.432308050845.issue9566@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> Python\pystrtod.c(902) : 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data
> Python\pystrtod.c(1023) : '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data

I asked dmalcolm on IRC if int or Py_ssize_t should be used:

"this is the number of digits to use in the floating point representation, right? it strikes me that if you're overflowing an int, you're asking for a very very very long string" (yes, INT_MAX is usually 2^31)

"... looking at usage of precision seems to ultimately land in Python/dtoa.c, which uses int..."

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9566>
_______________________________________

From report at bugs.python.org  Tue Jan  4 23:10:07 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Tue, 04 Jan 2011 22:10:07 +0000
Subject: [issue7995] On Mac / BSD sockets returned by accept inherit the
	parent's FD flags
In-Reply-To: <1266876583.45.0.97810567794.issue7995@psf.upfronthosting.co.za>
Message-ID: <1294179007.28.0.5244445338.issue7995@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

I think this patch (nonblock2.patch) is wrong. If I have a non-blocking server socket on *BSD, and do accept, with no default timeout: IIUC, under the patch, I will get a blocking connection socket. However, according to the operating system API, I'm entitled to get a non-blocking socket (i.e. O_NONBLOCK must be inherited across accept).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7995>
_______________________________________

From report at bugs.python.org  Tue Jan  4 23:29:52 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 04 Jan 2011 22:29:52 +0000
Subject: [issue7995] On Mac / BSD sockets returned by accept inherit the
	parent's FD flags
In-Reply-To: <1294179007.28.0.5244445338.issue7995@psf.upfronthosting.co.za>
Message-ID: <1294180186.3669.23.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> I think this patch (nonblock2.patch) is wrong. If I have a
> non-blocking server socket on *BSD, and do accept, with no default
> timeout: IIUC, under the patch, I will get a blocking connection
> socket. However, according to the operating system API, I'm entitled
> to get a non-blocking socket (i.e. O_NONBLOCK must be inherited across
> accept).

Well, either the defaulttimeout should have the priority over the parent
socket's settings (your argument in msg125135), or it shouldn't. I'm
fine with both, but I think any more complicated combination would end
up puzzling for the user :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7995>
_______________________________________

From report at bugs.python.org  Tue Jan  4 23:31:38 2011
From: report at bugs.python.org (Phillip J. Eby)
Date: Tue, 04 Jan 2011 22:31:38 +0000
Subject: [issue10751] REMOTE_USER and Remote-User collision in wsgiref
In-Reply-To: <1292971576.27.0.760159303747.issue10751@psf.upfronthosting.co.za>
Message-ID: <1294180298.85.0.396148215626.issue10751@psf.upfronthosting.co.za>


Phillip J. Eby <pje at telecommunity.com> added the comment:

I'm still baffled.  How does this matter to anything?

The HTTP headers you describe would end up in an HTTP_REMOTE_USER environment variable, with no impact on REMOTE_USER.  REMOTE_USER could only be set by an actual web server, not via an HTTP header.

So I don't get how this is a security issue, or even a bug at all.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10751>
_______________________________________

From report at bugs.python.org  Tue Jan  4 23:31:46 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 04 Jan 2011 22:31:46 +0000
Subject: [issue7995] On Mac / BSD sockets returned by accept inherit the
	parent's FD flags
In-Reply-To: <1294180186.3669.23.camel@localhost.localdomain>
Message-ID: <1294180302.3669.25.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Antoine Pitrou <pitrou at free.fr> added the comment:
> 
> > I think this patch (nonblock2.patch) is wrong. If I have a
> > non-blocking server socket on *BSD, and do accept, with no default
> > timeout: IIUC, under the patch, I will get a blocking connection
> > socket. However, according to the operating system API, I'm entitled
> > to get a non-blocking socket (i.e. O_NONBLOCK must be inherited across
> > accept).
> 
> Well, either the defaulttimeout should have the priority over the parent
> socket's settings (your argument in msg125135), or it shouldn't. I'm
> fine with both, but I think any more complicated combination would end
> up puzzling for the user :)

I would add that, since flags inheritance through accept() is
platform-dependent while the default timeout is a well-defined Python
feature, I would lean slightly towards applying the default timeout.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7995>
_______________________________________

From report at bugs.python.org  Tue Jan  4 23:37:41 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Tue, 04 Jan 2011 22:37:41 +0000
Subject: [issue10824] urandom should not block
In-Reply-To: <AANLkTi=Wk+hHaf4h=BwbW9mHW8fMuzkmShcmL_o+axur@mail.gmail.com>
Message-ID: <4D23A133.9090906@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> "It's a bug in random.c that doesn' t check for signal pending inside the
> read(2) code, so you have no chance to kill the process via signals until
> the read(2) syscall is finished, and it could take a lot of time before
> return, if the buffer given to the read syscall is very big..."
> 
> I've had a quick look at the source code, and indeed, read(2) from
> /dev/urandom can now be interrupted by a signal, so looping seems to
> be justified.

No: if read(2) is interrupted, no data is returned, and exception is
raised. So it won't loop in that case, but raise the exception out of
urandom also (which is the right thing to do).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10824>
_______________________________________

From report at bugs.python.org  Tue Jan  4 23:40:34 2011
From: report at bugs.python.org (Alex Raitz)
Date: Tue, 04 Jan 2011 22:40:34 +0000
Subject: [issue10751] REMOTE_USER and Remote-User collision in wsgiref
In-Reply-To: <1292971576.27.0.760159303747.issue10751@psf.upfronthosting.co.za>
Message-ID: <1294180834.68.0.172225901177.issue10751@psf.upfronthosting.co.za>


Alex Raitz <alex.raitz at gmail.com> added the comment:

Per the first line of my previous comment, please ignore HTTP_REMOTE_USER.

The risk is that if the proxy does not place the user-supplied 'remote-user=VALUE1' before the proxy-supplied 'REMOTE_USER=VALUE2', wsgiref will overload REMOTE_USER with the value of REMOTE-USER.

1) Client supplies 'REMOTE-USER=admin'
2) Proxy adds 'REMOTE_USER=normal_user' and appends 'REMOTE-USER=admin'
3) Server using wsgiref processes header key/value 'REMOTE_USER=normal_user' and performs lowercase/replace, resulting in 'remote_user=normal_user'
4) Server using wsgiref continues to process the header, performs lowercase/replace on 'REMOTE-USER=admin', resulting in 'remote_user=admin', which overloads the proxy-supplied value for 'remote_user' and allows for arbitrary privilege escalation.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10751>
_______________________________________

From report at bugs.python.org  Tue Jan  4 23:40:34 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Tue, 04 Jan 2011 22:40:34 +0000
Subject: [issue9566] Compilation warnings under x64 Windows
In-Reply-To: <1294178571.15.0.908274924182.issue9566@psf.upfronthosting.co.za>
Message-ID: <4D23A1DC.7040508@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> MvL> If you are absolutely certain that a cast cannot possibly truncate, 
> MvL> add a comment explaining why that is.
> 
> Ah yes, sorry, I forgot to add a comment: done in r87746.

But the comment is actually wrong: It says

len <= buf_size <= INT_MAX (see above)

however, len > buf_size may happen, after this code:

    if (len > buf_size) {
        PyErr_Format(PyExc_ValueError,
                     "read() returned too much data: "
                     "%i bytes requested, %zd returned",
                     buf_size, len);
        goto finally;
    }

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9566>
_______________________________________

From report at bugs.python.org  Tue Jan  4 23:51:16 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Tue, 04 Jan 2011 22:51:16 +0000
Subject: [issue7995] On Mac / BSD sockets returned by accept inherit the
	parent's FD flags
In-Reply-To: <1294180186.3669.23.camel@localhost.localdomain>
Message-ID: <4D23A461.9050409@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> Well, either the defaulttimeout should have the priority over the parent
> socket's settings (your argument in msg125135), or it shouldn't. I'm
> fine with both, but I think any more complicated combination would end
> up puzzling for the user :)

Applying the default timeout if set is fine, and I agree it should have
precedence. In case no default timeout is configured, the platform
semantics should prevail. This is tradition in Python: when we define
some behavior (i.e. default timeout), we are entitled to consistently
define all aspects of it. In the other places we use the platform
semantics (leaning towards standards such as POSIX in case the platform
offers alternative semantics).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7995>
_______________________________________

From report at bugs.python.org  Tue Jan  4 23:53:18 2011
From: report at bugs.python.org (Phillip J. Eby)
Date: Tue, 04 Jan 2011 22:53:18 +0000
Subject: [issue10751] REMOTE_USER and Remote-User collision in wsgiref
In-Reply-To: <1292971576.27.0.760159303747.issue10751@psf.upfronthosting.co.za>
Message-ID: <1294181598.72.0.0844770953545.issue10751@psf.upfronthosting.co.za>


Phillip J. Eby <pje at telecommunity.com> added the comment:

You say it "would" do this.  Have you actually *tested* it?

Looking at the code in wsgiref again, I don't think it does what you think it does.  The '_' substitution is done to keyword arguments for header *parameters* only; it's not done to header *names*.

Please write a test case for wsgiref.headers.Headers that demonstrates the behavior you think it would be doing.  AFAICT, you will not even be able to get the replace() calls to execute without writing explicit add_header() calls, and even then, you *still* won't get the results you're describing.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10751>
_______________________________________

From report at bugs.python.org  Tue Jan  4 23:59:46 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 04 Jan 2011 22:59:46 +0000
Subject: [issue10828] Cannot use nonascii utf8 in names of files imported from
In-Reply-To: <1294170257.81.0.980912064683.issue10828@psf.upfronthosting.co.za>
Message-ID: <1294181986.81.0.446791678039.issue10828@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

I think that this issue is a duplicate of #8611 (and #9425), it should be fixed in Python 3.2.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10828>
_______________________________________

From report at bugs.python.org  Wed Jan  5 00:28:28 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Tue, 04 Jan 2011 23:28:28 +0000
Subject: [issue5485] pyexpat has no unit tests for UseForeignDTD functionality
In-Reply-To: <1236963062.63.0.579203765421.issue5485@psf.upfronthosting.co.za>
Message-ID: <1294183708.76.0.516839907618.issue5485@psf.upfronthosting.co.za>


Sandro Tosi <sandro.tosi at gmail.com> added the comment:

Hi all, I think this patch would be nice to be applied, but before start working on it (like adapt it to new code & stuff), I'd like to know if we are really targetting 2.7 or should we instead targer 3.3.

Cheers, Sandro

----------
nosy: +sandro.tosi
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5485>
_______________________________________

From report at bugs.python.org  Wed Jan  5 00:52:07 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Tue, 04 Jan 2011 23:52:07 +0000
Subject: [issue5485] pyexpat has no unit tests for UseForeignDTD functionality
In-Reply-To: <1236963062.63.0.579203765421.issue5485@psf.upfronthosting.co.za>
Message-ID: <1294185127.02.0.499914903127.issue5485@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

I don't think we should adding tests to 2.7, perhaps unless there are also fixes for it. So targetting 3.3+ only seems reasonable.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5485>
_______________________________________

From report at bugs.python.org  Wed Jan  5 00:55:11 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 04 Jan 2011 23:55:11 +0000
Subject: [issue9566] Compilation warnings under x64 Windows
In-Reply-To: <4D23A1DC.7040508@v.loewis.de>
Message-ID: <1294185406.20722.2.camel@marge>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> But the comment is actually wrong: It says
> 
> len <= buf_size <= INT_MAX (see above)
> 
> however, len > buf_size may happen, after this code:
> 
>     if (len > buf_size) {
>         PyErr_Format(PyExc_ValueError,
>                      "read() returned too much data: "
>                      "%i bytes requested, %zd returned",
>                      buf_size, len);
>         goto finally;
>     }

Oh. Not only is the comment is wrong, but the code is also wrong. It
should return a negative value on error, whereas it returns the string
length which is always positive (except on a unlikely Py_ssize_t => int
overflow?).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9566>
_______________________________________

From report at bugs.python.org  Wed Jan  5 01:01:29 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Wed, 05 Jan 2011 00:01:29 +0000
Subject: [issue9566] Compilation warnings under x64 Windows
In-Reply-To: <1294185406.20722.2.camel@marge>
Message-ID: <4D23B4CF.8090201@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> Oh. Not only is the comment is wrong, but the code is also wrong. It
> should return a negative value on error, whereas it returns the string
> length which is always positive (except on a unlikely Py_ssize_t => int
> overflow?).

Right. See msg125367.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9566>
_______________________________________

From report at bugs.python.org  Wed Jan  5 01:24:53 2011
From: report at bugs.python.org (Alex Raitz)
Date: Wed, 05 Jan 2011 00:24:53 +0000
Subject: [issue10751] REMOTE_USER and Remote-User collision in wsgiref
In-Reply-To: <1292971576.27.0.760159303747.issue10751@psf.upfronthosting.co.za>
Message-ID: <1294187093.01.0.826748591544.issue10751@psf.upfronthosting.co.za>


Alex Raitz <alex.raitz at gmail.com> added the comment:

I had previously tested it against simple_server.  However, in reviewing my test, I realized that you are correct that wsgiref headers is not misbehaving.  

It appears that in simple_server, the values of remote-user and remote_user both end up in HTTP_REMOTE_USER because of the replacement behavior in simple_server (not in headers).

I am withdrawing this bug and will submit a subsequent ticket with the required details.  Thank you for your patience.

----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10751>
_______________________________________

From report at bugs.python.org  Wed Jan  5 01:46:43 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 05 Jan 2011 00:46:43 +0000
Subject: [issue10829] PyUnicode_FromFormatV() bugs with "%" and "%%" format
	strings
In-Reply-To: <1294188403.72.0.24360709681.issue10829@psf.upfronthosting.co.za>
Message-ID: <1294188403.72.0.24360709681.issue10829@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

Steps 1 and 3 of PyUnicode_FromFormatV() doesn't handle the format string "%%" correctly. The loop responsible to skip the precision moves outside the format string, and the function will then read uninitialized memory. The loop:

             while (*++f && *f != '%' && !Py_ISALPHA((unsigned)*f))
                 ;

This is another issue:

    for (f = format; *f; f++) {
         if (*f == '%') {
             if (*(f+1)=='%')
                 continue;
    ...

continue only skips the first %: with "%%", the second % will be interpreted (and not escaped).

Attached patch fixes the issue, but I don't feal confortable with this ugly function, and I would appreciate a review :-) The patch adds unit tests.

I found the bug when trying to add new tests before trying to implement "%zi" format. I was first surprised that "%zi" (and %li and %lli) is not supported, but now I am surprised because I found bugs :-)

----------
components: Interpreter Core, Unicode
files: pyunicode_fromformatv.patch
keywords: patch
messages: 125387
nosy: amaury.forgeotdarc, haypo
priority: normal
severity: normal
status: open
title: PyUnicode_FromFormatV() bugs with "%" and "%%" format strings
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file20262/pyunicode_fromformatv.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10829>
_______________________________________

From report at bugs.python.org  Wed Jan  5 01:54:38 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Wed, 05 Jan 2011 00:54:38 +0000
Subject: [issue8052] subprocess close_fds behavior should only close open fds
In-Reply-To: <1267672679.06.0.725064778002.issue8052@psf.upfronthosting.co.za>
Message-ID: <1294188878.62.0.873682623406.issue8052@psf.upfronthosting.co.za>


Nadeem Vawda <nadeem.vawda at gmail.com> added the comment:

According to POSIX [1], if a multi-threaded program calls fork(), the child process may only use async-signal-safe system calls between fork() and exec*(). readdir() is not required to be async-safe [2], so reading /proc/self/fds in the child process is undefined behaviour. This is a pity, since it would IMO be a much cleaner solution than the current code.

Of course, procfs isn't standard in any case; would it be necessary to have a fallback for systems without it? Or do all *nix systems that we care about provide it? In the former case, I suppose it might be possible to use the procfs on systems where readdir() is known to be safe, and use the fallback where it isn't. But such special cases would complicate the code rather than simplifying it...

[1] http://pubs.opengroup.org/onlinepubs/009695399/functions/fork.html
[2] http://pubs.opengroup.org/onlinepubs/009695399/functions/xsh_chap02_04.html

----------
nosy: +nvawda

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8052>
_______________________________________

From report at bugs.python.org  Wed Jan  5 02:01:25 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 05 Jan 2011 01:01:25 +0000
Subject: [issue8052] subprocess close_fds behavior should only close open fds
In-Reply-To: <1294188878.62.0.873682623406.issue8052@psf.upfronthosting.co.za>
Message-ID: <1294189279.3669.28.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Of course, procfs isn't standard in any case; would it be necessary to
> have a fallback for systems without it? Or do all *nix systems that we
> care about provide it?

/proc/self doesn't exist under OpenSolaris. You have to use /proc/<pid>.
And I suppose there can be circumstances where /proc isn't available at
all (chroot perhaps?). So we would definitely have to provide a
fallback.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8052>
_______________________________________

From report at bugs.python.org  Wed Jan  5 02:02:43 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 05 Jan 2011 01:02:43 +0000
Subject: [issue9566] Compilation warnings under x64 Windows
In-Reply-To: <1281484786.91.0.306555541292.issue9566@psf.upfronthosting.co.za>
Message-ID: <1294189363.65.0.0598581815711.issue9566@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

pyexpat.patch: new try, does it look better?

----------
keywords: +patch
Added file: http://bugs.python.org/file20263/pyexpat.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9566>
_______________________________________

From report at bugs.python.org  Wed Jan  5 02:07:36 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Wed, 05 Jan 2011 01:07:36 +0000
Subject: [issue10512] regrtest ResourceWarning - unclosed sockets and files
In-Reply-To: <1290506536.77.0.313292165719.issue10512@psf.upfronthosting.co.za>
Message-ID: <1294189656.54.0.740371257706.issue10512@psf.upfronthosting.co.za>


Nadeem Vawda <nadeem.vawda at gmail.com> added the comment:

r87736 introduces another DeprecationError; this time in test_time (line 150; s/assertEquals/assertEqual/).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10512>
_______________________________________

From report at bugs.python.org  Wed Jan  5 02:27:38 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 05 Jan 2011 01:27:38 +0000
Subject: [issue10829] PyUnicode_FromFormatV() bugs with "%" and "%%" format
	strings
In-Reply-To: <1294188403.72.0.24360709681.issue10829@psf.upfronthosting.co.za>
Message-ID: <1294190858.57.0.562794894419.issue10829@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Oh, my first patch was wrong: it failed on %c format (in zipimport with "%U%c%U"). The second version of the patch should be better.

----------
Added file: http://bugs.python.org/file20264/pyunicode_fromformatv-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10829>
_______________________________________

From report at bugs.python.org  Wed Jan  5 02:43:12 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 05 Jan 2011 01:43:12 +0000
Subject: [issue10830] PyUnicode_FromFormatV("%c") doesn't support non-BMP
	characters on narrow build
In-Reply-To: <1294191792.83.0.0600420394952.issue10830@psf.upfronthosting.co.za>
Message-ID: <1294191792.83.0.0600420394952.issue10830@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

PyUnicode_FromFormatV("%c") supposes that an unicode character is always stored as a single Py_UNICODE word: but that's wrong on narrow build with characters in [U+10000; U+10FFFF].

Attached patch fixes this bug.

See also #10829.

----------
components: Interpreter Core, Unicode
files: pyunicode_fromformatv_c.patch
keywords: patch
messages: 125393
nosy: amaury.forgeotdarc, haypo
priority: normal
severity: normal
status: open
title: PyUnicode_FromFormatV("%c") doesn't support non-BMP characters on narrow build
versions: Python 3.2, Python 3.3
Added file: http://bugs.python.org/file20265/pyunicode_fromformatv_c.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10830>
_______________________________________

From report at bugs.python.org  Wed Jan  5 02:48:50 2011
From: report at bugs.python.org (R. David Murray)
Date: Wed, 05 Jan 2011 01:48:50 +0000
Subject: [issue10790] Header.append's charset logic is bogus,
	'shift_jis' and "euc_jp' don't work as charsets
In-Reply-To: <1293647903.09.0.559364426725.issue10790@psf.upfronthosting.co.za>
Message-ID: <1294192130.07.0.885460243269.issue10790@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Committed to py3k in r87750 and 3.1 in r87751.

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10790>
_______________________________________

From report at bugs.python.org  Wed Jan  5 02:55:17 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 05 Jan 2011 01:55:17 +0000
Subject: [issue10831] PyUnicode_FromFormatV() doesn't support %li, %lli, %zi
In-Reply-To: <1294192517.91.0.585635268064.issue10831@psf.upfronthosting.co.za>
Message-ID: <1294192517.91.0.585635268064.issue10831@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

PyUnicode_FromFormatV() supports %d, %ld, %lld, %zd, %u, %lu, %llu, %zu, %i. But it doesn't support %li, %lli, %zi.

Attached patch implements the 3 missing formats, and add unit tests for all these formats.

----------
components: Interpreter Core, Unicode
files: pyunicode_fromformatv_zi.patch
keywords: patch
messages: 125396
nosy: haypo
priority: normal
severity: normal
status: open
title: PyUnicode_FromFormatV() doesn't support %li, %lli, %zi
versions: Python 3.2, Python 3.3
Added file: http://bugs.python.org/file20266/pyunicode_fromformatv_zi.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10831>
_______________________________________

From report at bugs.python.org  Wed Jan  5 02:55:26 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 05 Jan 2011 01:55:26 +0000
Subject: [issue10831] PyUnicode_FromFormatV() doesn't support %li, %lli, %zi
In-Reply-To: <1294192517.91.0.585635268064.issue10831@psf.upfronthosting.co.za>
Message-ID: <1294192526.69.0.427468258626.issue10831@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10831>
_______________________________________

From report at bugs.python.org  Wed Jan  5 03:18:56 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 05 Jan 2011 02:18:56 +0000
Subject: [issue4953] cgi module cannot handle POST with multipart/form-data
	in	3.0
In-Reply-To: <1232010166.79.0.972664060868.issue4953@psf.upfronthosting.co.za>
Message-ID: <1294193936.37.0.780144225192.issue4953@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4953>
_______________________________________

From report at bugs.python.org  Wed Jan  5 03:45:51 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 05 Jan 2011 02:45:51 +0000
Subject: [issue10829] PyUnicode_FromFormatV() bugs with "%" and "%%" format
	strings
In-Reply-To: <1294188403.72.0.24360709681.issue10829@psf.upfronthosting.co.za>
Message-ID: <1294195551.01.0.536052226324.issue10829@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

PyBytes_FromFormatV() has the same issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10829>
_______________________________________

From report at bugs.python.org  Wed Jan  5 03:55:10 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 05 Jan 2011 02:55:10 +0000
Subject: [issue10832] Add support of bytes objects in PyBytes_FromFormatV()
In-Reply-To: <1294196110.74.0.942895284505.issue10832@psf.upfronthosting.co.za>
Message-ID: <1294196110.74.0.942895284505.issue10832@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

It would be very practical use have a format, eg. '%y', to accept bytes object in PyBytes_FromFormatV().

Example (extracted from posixmodule.c):

        k = PyBytes_AsString(key2);
        v = PyBytes_AsString(val2);
        len = PyBytes_GET_SIZE(key2) + PyBytes_GET_SIZE(val2) + 2;
        p = PyMem_NEW(char, len);
        if (p == NULL) { PyErr_NoMemory(); ... }
        PyOS_snprintf(p, len, "%s=%s", k, v);

With %y, it can be written:

        p = PyBytes_FromFormat("%y=%y", key2, val2);
        if (p == NULL) { PyErr_NoMemory(); ... }

The '%y' may also accept bytearray and any object with the buffer interface (as the 'y' format of PyArg_Parse*() functions).

----------
components: Interpreter Core
messages: 125398
nosy: haypo
priority: normal
severity: normal
status: open
title: Add support of bytes objects in PyBytes_FromFormatV()
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10832>
_______________________________________

From report at bugs.python.org  Wed Jan  5 04:02:35 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 05 Jan 2011 03:02:35 +0000
Subject: [issue10833] Replace %.100s by %s in PyErr_Format(): the arbitrary
	limit of 500 bytes is outdated
In-Reply-To: <1294196554.94.0.785505480291.issue10833@psf.upfronthosting.co.za>
Message-ID: <1294196554.94.0.785505480291.issue10833@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

Guido created the "convenience function" PyErr_Format() 13 years ago (r7580) with a naive implementation using char buffer[500] and vsprintf(). He added a comment:

/* Caller is responsible for limiting the format */

Ok, that was true 13 years ago. But today Python uses dynamically allocated buffers, and so we can simply replace %.100s ("%\.[0-9]+s" regex) by %s.

Anyway, PyUnicode_FromFormatV() doesn't support precision for %s and %U formats :-)

----------
components: Interpreter Core
messages: 125399
nosy: amaury.forgeotdarc, haypo
priority: normal
severity: normal
status: open
title: Replace %.100s by %s in PyErr_Format(): the arbitrary limit of 500 bytes is outdated
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10833>
_______________________________________

From report at bugs.python.org  Wed Jan  5 04:10:13 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 05 Jan 2011 03:10:13 +0000
Subject: [issue10833] Replace %.100s by %s in PyErr_Format(): the arbitrary
	limit of 500 bytes is outdated
In-Reply-To: <1294196554.94.0.785505480291.issue10833@psf.upfronthosting.co.za>
Message-ID: <1294197013.38.0.974972662633.issue10833@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

use_format.patch is a patch to avoid PyOS_snprintf() with a fixed buffer: use directly PyUnicode_FromFormat(), PyErr_Format() or PySys_FormatStderr() instead. This patch is just a draft, it should be tested :-) There are other calls to PyOS_snprintf() that can be replaced.

----------
keywords: +patch
Added file: http://bugs.python.org/file20267/use_format.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10833>
_______________________________________

From report at bugs.python.org  Wed Jan  5 04:10:56 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 05 Jan 2011 03:10:56 +0000
Subject: [issue10829] PyUnicode_FromFormatV() bugs with "%" and "%%" format
	strings
In-Reply-To: <1294188403.72.0.24360709681.issue10829@psf.upfronthosting.co.za>
Message-ID: <1294197056.22.0.704926837043.issue10829@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Removed file: http://bugs.python.org/file20262/pyunicode_fromformatv.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10829>
_______________________________________

From report at bugs.python.org  Wed Jan  5 04:34:12 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 05 Jan 2011 03:34:12 +0000
Subject: [issue10832] Add support of bytes objects in PyBytes_FromFormatV()
In-Reply-To: <1294196110.74.0.942895284505.issue10832@psf.upfronthosting.co.za>
Message-ID: <1294198452.94.0.56016467886.issue10832@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Patch implementing this feature. It only supports bytes.

----------
keywords: +patch
Added file: http://bugs.python.org/file20268/pybytes_fromformat_y.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10832>
_______________________________________

From report at bugs.python.org  Wed Jan  5 04:35:11 2011
From: report at bugs.python.org (R. David Murray)
Date: Wed, 05 Jan 2011 03:35:11 +0000
Subject: [issue4953] cgi module cannot handle POST with multipart/form-data
	in	3.0
In-Reply-To: <1232010166.79.0.972664060868.issue4953@psf.upfronthosting.co.za>
Message-ID: <1294198511.82.0.462258424362.issue4953@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

A day late, but I've looked at the patch.

Now, I'm not all that knowledgeable about CGI, so other people will probably want to chime in here....

First, I'm uploading a new version of the patch as an svn diff (can be applied to a checkout using 'patch -p0 <patchfile' from the top level directory of the checkout).  This includes Pierre's patch unchanged, and includes changes to test_cgi so that Pierre's patch is tested.  Some of the tests fail.

A couple of the failures have to do with file bodies being returned as binary when previously they were returned as strings.  This raises the issue of backward compatibility: if cgi/fieldstorage using applications exist for 3.1, changing this will break them.  There may not be a good solution to that problem.  But it also may not be possible to fix this in 3.2 at this point (which I seem to have already decided earlier, but I can't now remember why...).

>From looking over the cgi code it is not clear to me whether Pierre's approach is simpler or more complex than the alternative approach of starting with binary input and decoding as appropriate.  From a consistency perspective I would prefer the latter, but I don't know if I'll have time to try it out before rc1.

I also wonder if it would be possible to rewrite FieldStorage to take even better advantage of FeedParser, but if so that would *certainly* not happen before rc1.

----------
keywords: +patch
Added file: http://bugs.python.org/file20269/cgi_plus_tests.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4953>
_______________________________________

From report at bugs.python.org  Wed Jan  5 04:38:38 2011
From: report at bugs.python.org (R. David Murray)
Date: Wed, 05 Jan 2011 03:38:38 +0000
Subject: [issue4953] cgi module cannot handle POST with multipart/form-data
	in	3.0
In-Reply-To: <1232010166.79.0.972664060868.issue4953@psf.upfronthosting.co.za>
Message-ID: <1294198718.72.0.631438443771.issue4953@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Here is a modified version of the unittest file from unittest.zip that can be run against Pierre's code (it feeds FieldStorage a text stream with a buffer).  Running the tests require the data files from the zip.

They do not pass, in a very different way from the test_cgi failures.

----------
Added file: http://bugs.python.org/file20270/cgitest-python3.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4953>
_______________________________________

From report at bugs.python.org  Wed Jan  5 04:40:04 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 05 Jan 2011 03:40:04 +0000
Subject: [issue10833] Replace %.100s by %s in PyErr_Format(): the arbitrary
	limit of 500 bytes is outdated
In-Reply-To: <1294196554.94.0.785505480291.issue10833@psf.upfronthosting.co.za>
Message-ID: <1294198804.24.0.373209531384.issue10833@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Woops, I didn't want to do it, but I already commited the simple part of this issue (U format, eg. %.100U): r87753.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10833>
_______________________________________

From report at bugs.python.org  Wed Jan  5 04:57:18 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 05 Jan 2011 03:57:18 +0000
Subject: [issue10756] Error in atexit._run_exitfuncs [...] Exception expected
	for value, str found
In-Reply-To: <1293004716.16.0.718567163143.issue10756@psf.upfronthosting.co.za>
Message-ID: <1294199838.83.0.193115021958.issue10756@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Commited as r87755+r87758. Wait for the buildbot before backporting to other versions.

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10756>
_______________________________________

From report at bugs.python.org  Wed Jan  5 04:57:59 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 05 Jan 2011 03:57:59 +0000
Subject: [issue10512] regrtest ResourceWarning - unclosed sockets and files
In-Reply-To: <1290506536.77.0.313292165719.issue10512@psf.upfronthosting.co.za>
Message-ID: <1294199879.57.0.563119289501.issue10512@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> r87710 introduces a ResourceWarning in test_threading. Fix attached.

Fixed by r87757 (I wrote a different patch).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10512>
_______________________________________

From report at bugs.python.org  Wed Jan  5 04:59:11 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 05 Jan 2011 03:59:11 +0000
Subject: [issue10512] regrtest ResourceWarning - unclosed sockets and files
In-Reply-To: <1290506536.77.0.313292165719.issue10512@psf.upfronthosting.co.za>
Message-ID: <1294199951.04.0.500457939628.issue10512@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> r87736 introduces another DeprecationError; this time in test_time (line 150; s/assertEquals/assertEqual/).

Fixed by r87759.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10512>
_______________________________________

From report at bugs.python.org  Wed Jan  5 05:26:40 2011
From: report at bugs.python.org (ingemar)
Date: Wed, 05 Jan 2011 04:26:40 +0000
Subject: [issue10828] Cannot use nonascii utf8 in names of files imported from
In-Reply-To: <1294170257.81.0.980912064683.issue10828@psf.upfronthosting.co.za>
Message-ID: <1294201600.76.0.758423184023.issue10828@psf.upfronthosting.co.za>


ingemar <ingemar at sijohansson.com> added the comment:

Have I tried 3.2b2?

No. I will have to wait for 3.2, or more exactly for a Windows installer for PyQt for 3.2 to become available.
Compiling that on Windows is beyond my resources and experience.
I will make a point to tell you then.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10828>
_______________________________________

From report at bugs.python.org  Wed Jan  5 05:26:46 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 05 Jan 2011 04:26:46 +0000
Subject: [issue10785] parser: store the filename as an unicode object
In-Reply-To: <1293504022.51.0.668746175929.issue10785@psf.upfronthosting.co.za>
Message-ID: <1294201606.97.0.510996947945.issue10785@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Version 3 of the patch to fix also #9319.

----------
Added file: http://bugs.python.org/file20271/parser_filename_obj-3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10785>
_______________________________________

From report at bugs.python.org  Wed Jan  5 05:26:50 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 05 Jan 2011 04:26:50 +0000
Subject: [issue10785] parser: store the filename as an unicode object
In-Reply-To: <1293504022.51.0.668746175929.issue10785@psf.upfronthosting.co.za>
Message-ID: <1294201610.08.0.79148995974.issue10785@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Removed file: http://bugs.python.org/file20180/parser_filename_obj.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10785>
_______________________________________

From report at bugs.python.org  Wed Jan  5 05:26:52 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 05 Jan 2011 04:26:52 +0000
Subject: [issue10785] parser: store the filename as an unicode object
In-Reply-To: <1293504022.51.0.668746175929.issue10785@psf.upfronthosting.co.za>
Message-ID: <1294201612.5.0.324113537701.issue10785@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Removed file: http://bugs.python.org/file20184/parser_filename_obj-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10785>
_______________________________________

From report at bugs.python.org  Wed Jan  5 05:33:34 2011
From: report at bugs.python.org (Glenn Linderman)
Date: Wed, 05 Jan 2011 04:33:34 +0000
Subject: [issue4953] cgi module cannot handle POST with multipart/form-data
	in	3.0
In-Reply-To: <1232010166.79.0.972664060868.issue4953@psf.upfronthosting.co.za>
Message-ID: <1294202014.38.0.0840529690103.issue4953@psf.upfronthosting.co.za>


Glenn Linderman <v+python at g.nevcal.com> added the comment:

R. David said:
>From looking over the cgi code it is not clear to me whether Pierre's approach is simpler or more complex than the alternative approach of starting with binary input and decoding as appropriate.  From a consistency perspective I would prefer the latter, but I don't know if I'll have time to try it out before rc1.

I say:
I agree with R. David that an approach using the binary input seems more appropriate, as the HTTP byte stream is defined as binary.  Do the 3.2 beta email docs now include documentation for the binary input interfaces required to code that solution?  Or could you provide appropriate guidance and review, should someone endeavor to attempt such a solution?

The remaining concerns below are only concerns; they may be totally irrelevant, and I'm too ignorant of how the code works to realize their irrelevance.  Hopefully someone that understands the code can comment and explain.

I believe that the proper solution is to make cgi work if sys.stdin has already been converted to be a binary stream, or if it hasn't, to dive down to the underlying binary stream, using detach().  Then the data should be processed as binary, and decoded once, when the proper decoding parameters are known.  The default encoding seems to be different on different platforms, but the binary stream is standardized.  It looks like new code was added to attempt to preprocess the MIME data into chunks to be fed to the email parser, and while I can believe code could be written to do such correctly (but I can't speak for whether this patch code is correct or not), it seems redundant/inefficient and error-prone to do it once outside the email parser, and again inside it.

I also doubt that self.fp.encoding is consistent from platform to platform).  But the HTTP bytestream is binary, and self-describing or declared by HTTP or HTML standards for the parts that are not self-describing.  The default platform encoding used for the preopened sys.stdin is not particularly relevant and may introduce mojibake type bugs, decoding errors in the presence of some inputs, and/or platform inconsistencies, and it seems that that is generally where self.fp.encoding, used in various places in this patch, comes from.

Regarding the binary vs. text issue; when using both binary and text interfaces on output streams, there is the need to do flushing between text and binary writes to preserve the proper sequencing of data in the output.  For input, is it possible that mixing text and binary input could result in the binary input missing data that has already been preloaded into the text buffer?  Although, for CGI programs, no one should have done any text inputs before calling the CGI functions, so perhaps this is also not a concern... and there probably isn't any buffering on socket streams (the usual CGI use case) but I see the use of both binary and text input functions in this patch, so this may be another issue that someone could explain why such a mix is or isn't a problem.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4953>
_______________________________________

From report at bugs.python.org  Wed Jan  5 06:41:11 2011
From: report at bugs.python.org (Ron Adam)
Date: Wed, 05 Jan 2011 05:41:11 +0000
Subject: [issue10818] pydoc: Remove old server and tk panel
In-Reply-To: <1294071441.53.0.907267492881.issue10818@psf.upfronthosting.co.za>
Message-ID: <1294206071.27.0.658077513955.issue10818@psf.upfronthosting.co.za>


Ron Adam <ron_adam at users.sourceforge.net> added the comment:

Here is a patch for this.  Not much to it as the hard parts were already done.  Apparently there was no tests for this, test_pydoc still passes without it.

Does there need to be any messages for the -g option? Pydoc help is displayed in the case -g is used.  That already includes the new -b usage.

----------
keywords: +patch
title: pydoc: refactorize duplicate DocHandler and DocServer classes -> pydoc: Remove old server and tk panel
Added file: http://bugs.python.org/file20272/no_tkserve.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10818>
_______________________________________

From report at bugs.python.org  Wed Jan  5 07:06:29 2011
From: report at bugs.python.org (karl)
Date: Wed, 05 Jan 2011 06:06:29 +0000
Subject: [issue2193] Cookie Colon Name Bug
In-Reply-To: <1203992843.27.0.867127322082.issue2193@psf.upfronthosting.co.za>
Message-ID: <1294207589.63.0.816928877108.issue2193@psf.upfronthosting.co.za>


karl <karl+pythonbugs at la-grange.net> added the comment:

The rules for parsing and setting the cookies are different. Server should always produce strict cookies only. So the production rules are to be done accordingly to the specification.

Adam Barth is working right now on an update of the  "HTTP State Management Mechanism" specification. See http://tools.ietf.org/html/draft-ietf-httpstate-cookie

The name production rules are still defined in RFC2696

What browsers ignores or not in characters depends from browsers to browsers. (IETF server is down right now, and I can't link to the appropriate section for parsing the values.)

----------
nosy: +karlcow

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2193>
_______________________________________

From report at bugs.python.org  Wed Jan  5 07:08:18 2011
From: report at bugs.python.org (karl)
Date: Wed, 05 Jan 2011 06:08:18 +0000
Subject: [issue2193] Cookie Colon Name Bug
In-Reply-To: <1203992843.27.0.867127322082.issue2193@psf.upfronthosting.co.za>
Message-ID: <1294207698.21.0.296017689412.issue2193@psf.upfronthosting.co.za>


karl <karl+pythonbugs at la-grange.net> added the comment:

Ah the server is back the rules for the User Agents are defined here 
http://tools.ietf.org/html/draft-ietf-httpstate-cookie#section-5

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2193>
_______________________________________

From report at bugs.python.org  Wed Jan  5 07:16:56 2011
From: report at bugs.python.org (Ross Lagerwall)
Date: Wed, 05 Jan 2011 06:16:56 +0000
Subject: [issue10812] Add some posix functions
In-Reply-To: <1294058752.01.0.285856626146.issue10812@psf.upfronthosting.co.za>
Message-ID: <1294208216.25.0.611338845875.issue10812@psf.upfronthosting.co.za>


Ross Lagerwall <rosslagerwall at gmail.com> added the comment:

This patch:

Fixes test_lutimes(),
Ignores a posix_fallocate() failure on Solaris due to ZFS,
Changes readv() & writev() signatures such that they take sequences instead of tuples,
Changes readv() so that it takes a number of writable buffers, fills them and returns the total number of bytes read.

----------
Added file: http://bugs.python.org/file20273/10812_v2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10812>
_______________________________________

From report at bugs.python.org  Wed Jan  5 08:30:22 2011
From: report at bugs.python.org (Lenard Lindstrom)
Date: Wed, 05 Jan 2011 07:30:22 +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: <1294212622.96.0.505381644292.issue10181@psf.upfronthosting.co.za>


Changes by Lenard Lindstrom <len-l at telus.net>:


----------
nosy: +kermode

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10181>
_______________________________________

From report at bugs.python.org  Wed Jan  5 11:29:50 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 05 Jan 2011 10:29:50 +0000
Subject: [issue8033] sqlite: broken long integer handling for arguments to
	user-defined functions
In-Reply-To: <1267408991.73.0.408537758811.issue8033@psf.upfronthosting.co.za>
Message-ID: <1294223390.65.0.543644752437.issue8033@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
components: +Extension Modules -Library (Lib)
stage: needs patch -> unit test needed
versions: +Python 2.7, Python 3.2 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8033>
_______________________________________

From report at bugs.python.org  Wed Jan  5 11:41:03 2011
From: report at bugs.python.org (Peter Heiberg)
Date: Wed, 05 Jan 2011 10:41:03 +0000
Subject: [issue10834] Python 2.7 x86 fails to run in Windows 7
In-Reply-To: <1294224063.9.0.656095341139.issue10834@psf.upfronthosting.co.za>
Message-ID: <1294224063.9.0.656095341139.issue10834@psf.upfronthosting.co.za>


New submission from Peter Heiberg <peter at sveumsondre.no>:

I recently installed Win7 on my laptop, and installed the x86 Python 2.7 package.  IDLE fails to even start, and shows nothing but a process in task manager.  I've tried compatibility modes both to Vista and XPSP2, with no luck.

I ran 2.7 x86 on the same laptop in XPSP2, and I am also able to run 2.7 x86 on another computer using the exact same version of Win7.

Command line works fine, by the way.

----------
components: None
messages: 125415
nosy: excubated
priority: normal
severity: normal
status: open
title: Python 2.7 x86 fails to run in Windows 7
type: crash
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10834>
_______________________________________

From report at bugs.python.org  Wed Jan  5 12:00:58 2011
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 05 Jan 2011 11:00:58 +0000
Subject: [issue10130] Create epub format docs and offer them on the download
	page
In-Reply-To: <1293282928.77.0.893563694653.issue10130@psf.upfronthosting.co.za>
Message-ID: <1294225258.94.0.812682399442.issue10130@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Thanks, I've committed this as r87760 and r87761.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10130>
_______________________________________

From report at bugs.python.org  Wed Jan  5 13:14:20 2011
From: report at bugs.python.org (John J Lee)
Date: Wed, 05 Jan 2011 12:14:20 +0000
Subject: [issue2193] Cookie Colon Name Bug
In-Reply-To: <1203992843.27.0.867127322082.issue2193@psf.upfronthosting.co.za>
Message-ID: <1294229660.31.0.534987030911.issue2193@psf.upfronthosting.co.za>


John J Lee <jjlee at users.sourceforge.net> added the comment:

karl: I'm not clear precisely what it is that you want to draw our attention to.  Note this bug is about parsing of Cookie headers by servers, not production of Set-Cookie headers by servers.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2193>
_______________________________________

From report at bugs.python.org  Wed Jan  5 13:25:07 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 05 Jan 2011 12:25:07 +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: <1294230307.22.0.269593881562.issue10181@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Added Travis to nosy list - even if he doesn't have time to finish this off himself, hopefully he can point us in the right direction.

----------
nosy: +teoliphant

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10181>
_______________________________________

From report at bugs.python.org  Wed Jan  5 13:38:16 2011
From: report at bugs.python.org (R. David Murray)
Date: Wed, 05 Jan 2011 12:38:16 +0000
Subject: [issue4953] cgi module cannot handle POST with multipart/form-data
	in	3.0
In-Reply-To: <1232010166.79.0.972664060868.issue4953@psf.upfronthosting.co.za>
Message-ID: <1294231096.27.0.694046761747.issue4953@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Yeah, the documentation for the email stuff is in the dev docs.  There's a short summary in the changes section of the email intro with links to the classes and methods that are affected.  But basically you call BinaryFeedParser and feed it a binary data, and everything else works just like it did before, including the fact that get_payload() with no arguments returns a string.  If there is non-ASCII data in that string and no charset was specified the binary data will get trashed though.  To get the binary data out you call it with decode=True.

I believe you are right that the io module does not support intermixing calls to the main object and its buffer attribute; that's why detach was introduced, I believe.  Antoine is nosy on this issue now; he can correct me if I'm wrong.

So unfortunately I think we do need to come at this starting from binary at the beginning and *decoding* as needed (I believe http uses latin-1 when no charset is specified, but I need to double check that).  That still leaves the problem of what if anything to do about existing programs that expect every value in a FieldStorage to be a string.  Introduce a new method or parameter for getting the binary version of the value, possibly with some flag indicating that parsing detected non-ascii data?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4953>
_______________________________________

From report at bugs.python.org  Wed Jan  5 13:51:34 2011
From: report at bugs.python.org (Allan McRae)
Date: Wed, 05 Jan 2011 12:51:34 +0000
Subject: [issue10835] sys.executable default and altinstall
In-Reply-To: <1294231894.7.0.0581440878919.issue10835@psf.upfronthosting.co.za>
Message-ID: <1294231894.7.0.0581440878919.issue10835@psf.upfronthosting.co.za>


New submission from Allan McRae <allan at archlinux.org>:

when sys.executable is run with a modified argv[0] such as:

> sh -c "exec -a '' /usr/bin/python2.7 -c 'import sys; print(sys.executable)'"

it returns some a hardcoded value.   In this case, it returns /usr/bin/python.   This value is likely wrong when python is installed with "make altinstall".

A possible solution is to modify the "progname" variable in Python/pythonrun.c to include the version in it so that the hardcoded return value is the most version specific binary.  I.e.

static char *progname = "python2.7";

----------
components: Interpreter Core
messages: 125420
nosy: allan
priority: normal
severity: normal
status: open
title: sys.executable default and altinstall
versions: Python 2.5, Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10835>
_______________________________________

From report at bugs.python.org  Wed Jan  5 14:03:28 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 05 Jan 2011 13:03:28 +0000
Subject: [issue8033] sqlite: broken long integer handling for arguments to
	user-defined functions
In-Reply-To: <1267408991.73.0.408537758811.issue8033@psf.upfronthosting.co.za>
Message-ID: <1294232608.41.0.584251351029.issue8033@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

- unit tests are needed.
- Py_LONG_LONG should be used instead of "long long", and the cast removed.
- The patch assumes that longlong == int64, but is it true on all platforms?

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8033>
_______________________________________

From report at bugs.python.org  Wed Jan  5 14:21:11 2011
From: report at bugs.python.org (Eric Smith)
Date: Wed, 05 Jan 2011 13:21:11 +0000
Subject: [issue10833] Replace %.100s by %s in PyErr_Format(): the arbitrary
	limit of 500 bytes is outdated
In-Reply-To: <1294196554.94.0.785505480291.issue10833@psf.upfronthosting.co.za>
Message-ID: <1294233671.39.0.26680108495.issue10833@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

I always thought that one of the reasons for specifying the length was in case a pointer pointed to garbage: at least you'd be limiting how much trash was printed. But maybe that's just my imagination and there is no such reason.

----------
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10833>
_______________________________________

From report at bugs.python.org  Wed Jan  5 14:23:38 2011
From: report at bugs.python.org (karl)
Date: Wed, 05 Jan 2011 13:23:38 +0000
Subject: [issue2193] Cookie Colon Name Bug
In-Reply-To: <1203992843.27.0.867127322082.issue2193@psf.upfronthosting.co.za>
Message-ID: <1294233818.15.0.106426649592.issue2193@psf.upfronthosting.co.za>


karl <karl+pythonbugs at la-grange.net> added the comment:

John: Ah sorry, if I misunderstood. The bug seems to say that it is about the Cookie Name and legal chars for this cookie name. What I was trying to say is that the processing of the Cookie Name is different depending if you are a client or a server *and* that there is a specification being developed by Adam Barth (part of browser vendors) to obsolete RFC 2109. 

In the case of Server sending to the Client
    Set-Cookie: Name=Value

The rules for production of the cookies must be strict. Always. aka the module is used for creating a cookie and indeed the "colon" character is forbidden. The "token" syntax for valid chars and invalid chars are defined now in RFC2696. It means that any US-ASCII characters EXCEPT those are authorized: 

control characters (octets 0-31) and DEL (octet 127) and, the following characters ?(?, ?)?, ?<?, ?>?, ?@?, ?,?, ?;?, ?:?, ?", ?/?, ?[?, ?]?, ???, ?=?, ?{?, ?}?, the double quote character itself, US-ASCII SP (octet 32) or the tabulation (octet 9)

Then if you use the Cookie Module for a client it is not anymore the same story.


In the case of Client storing the value of the cookie sent by a server.
See the section "5.2.  The Set-Cookie Header", 
http://tools.ietf.org/html/draft-ietf-httpstate-cookie-20#section-5.2

quote:
  
    If the user agent does not ignore the Set-Cookie header
    field in its entirety, the user agent MUST parse the
    field-value of the Set-Cookie header field as a
    set-cookie-string (defined below).
    
    NOTE: The algorithm below is more permissive than the
    grammar in Section 4.1. For example, the algorithm strips
    leading and trailing whitespace from the cookie name and
    value (but maintains internal whitespace), whereas the
    grammar in Section 4.1 forbids whitespace in these
    positions. User agents use this algorithm so as to
    interoperate with servers that do not follow the
    recommendations in Section 4."

/quote

then the algorithm is described. Which means that what the server will parse will not be necessary what the server have generated. 

Section 5.4 says how the Cookie Header should be sent to the server with an algorithm for what will receive the server.

John, do you think there is a missing algorithm for parsing the value of cookie header when sent by the client?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2193>
_______________________________________

From report at bugs.python.org  Wed Jan  5 14:51:12 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 05 Jan 2011 13:51:12 +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: <1294235472.46.0.552919343366.issue10181@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Nick, it sounds as though you have an idea of how you think things should be working here---perhaps you can help me out.  I'd really like to understand what the implementation should look like from the POV of a 3rd party module that defines some object exporting the buffer interface.

Here's a specific scenario I'd like to understand:  module foo defines a type Foo that implements the buffer protocol.  For simplicity, suppose it's exporting 1-dim buffers. When I do:

>>> from foo import Foo
>>> foo_object = Foo()
>>> m = memoryview(foo_object)
>>> n = m[::2]  # take a slice of m
>>> del m       # delete the objects, in whichever order.
>>> del n

what's the sequence of getbuffer and releasebuffer calls that foo_object should expect to see?

Q1. Does foo get 2 requests to getbuffer (and 2 to releasebuffer), or just one each?  I'm assuming at least that getbuffer and releasebuffer calls should be paired.

Q2. For each pair of getbuffer/releasebuffer calls, should the 'view' parameter passed into releasebuffer be identical to that provided to getbuffer?  Or is it acceptable for the actual Py_buffer* pointers to be distinct, but the pointed-to Py_buffers to be exact copies.  (The existence of the smalltable field complicates the notion of an exact copy a little bit, but I think that's a detail that can be ignored for these questions.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10181>
_______________________________________

From report at bugs.python.org  Wed Jan  5 15:27:09 2011
From: report at bugs.python.org (Ross Lagerwall)
Date: Wed, 05 Jan 2011 14:27:09 +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: <1294237629.97.0.872138564575.issue4489@psf.upfronthosting.co.za>


Ross Lagerwall <rosslagerwall at gmail.com> added the comment:

Here is a draft patch.

It uses the *at functions and fdlistdir consequently it only makes it safe if those functions are available. It works using a recursive implementation and an open file descriptor pointing to a directory, instead of maintaining state by changing the current directory. If the *at functions are unavailable, it falls back to the unsafe implementation.

It requires the patches from issue4761 and issue10755 to work.

----------
nosy: +rosslagerwall
Added file: http://bugs.python.org/file20274/i4489.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4489>
_______________________________________

From report at bugs.python.org  Wed Jan  5 15:32:48 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 05 Jan 2011 14:32:48 +0000
Subject: [issue4953] cgi module cannot handle POST with multipart/form-data
	in	3.0
In-Reply-To: <1232010166.79.0.972664060868.issue4953@psf.upfronthosting.co.za>
Message-ID: <1294237968.83.0.575823248971.issue4953@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> I believe you are right that the io module does not support intermixing calls to the main object and its buffer attribute

I?ve learned in a recent discussion on web-sig that you can mix them, provided that you call stream.flush() before using stream.buffer.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4953>
_______________________________________

From report at bugs.python.org  Wed Jan  5 15:42:43 2011
From: report at bugs.python.org (John J Lee)
Date: Wed, 05 Jan 2011 14:42:43 +0000
Subject: [issue2193] Cookie Colon Name Bug
In-Reply-To: <1203992843.27.0.867127322082.issue2193@psf.upfronthosting.co.za>
Message-ID: <1294238563.35.0.0394987290393.issue2193@psf.upfronthosting.co.za>


John J Lee <jjlee at users.sourceforge.net> added the comment:

Again, I don't think this is relevant, because the bug is about servers parsing Cookie: headers.  Note that that string (the value of the Cookie: header) may be generated by a different server than the server that parses it (see the trac example mentioned in the bug comments).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2193>
_______________________________________

From report at bugs.python.org  Wed Jan  5 16:10:54 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 05 Jan 2011 15:10:54 +0000
Subject: [issue4953] cgi module cannot handle POST with multipart/form-data
	in	3.0
In-Reply-To: <1232010166.79.0.972664060868.issue4953@psf.upfronthosting.co.za>
Message-ID: <1294240254.36.0.270395632197.issue4953@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> I believe you are right that the io module does not support intermixing 
> calls to the main object and its buffer attribute; that's why detach
> was introduced, I believe.

Writing is ok as long as you call flush() on the text layer when necessary. Reading is not since there's no official way to flush the input buffer on the text layer (assuming some input has been consumed, that is). detach() doesn't do anything special AFAIR.

(this is all funny in the light of the web-sig discussion where people explain that CGI is such a natural model)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4953>
_______________________________________

From report at bugs.python.org  Wed Jan  5 16:21:18 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 05 Jan 2011 15:21:18 +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: <1294240878.18.0.239867867805.issue4489@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Thanks for the patch.

There seems to be a race remaining here:

+        try:
+            if os.path.islink(path):
+                # symlinks to directories are forbidden, see bug #1669
+                raise OSError("Cannot call rmtree on a symbolic link")
+        except OSError:
+            onerror(os.path.islink, path, sys.exc_info())
+            # can't continue even if onerror hook returns
+            return
+        fd = os.open(path, os.O_RDONLY)

Someone could change `path` to be a symlink between the calls to islink() and open(). You probably need to stat the fd instead.

Some other things:
- if close() is meant to be a private helper, it should be named _close()
- instead of a bare "except" in close(), use "except EnvironmentError" or "except OSError"

I haven't looked at the tests yet.

----------
stage: needs patch -> patch review
versions:  -Python 2.5, Python 2.6, Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4489>
_______________________________________

From report at bugs.python.org  Wed Jan  5 16:36:17 2011
From: report at bugs.python.org (Ralf Schmitt)
Date: Wed, 05 Jan 2011 15:36:17 +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: <1294241777.7.0.118655772899.issue4489@psf.upfronthosting.co.za>


Changes by Ralf Schmitt <schmir at gmail.com>:


----------
nosy: +schmir

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4489>
_______________________________________

From report at bugs.python.org  Wed Jan  5 17:19:02 2011
From: report at bugs.python.org (Brian Curtin)
Date: Wed, 05 Jan 2011 16:19:02 +0000
Subject: [issue10834] Python 2.7 x86 fails to run in Windows 7
In-Reply-To: <1294224063.9.0.656095341139.issue10834@psf.upfronthosting.co.za>
Message-ID: <1294244342.89.0.883500294953.issue10834@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

Can you start IDLE from the command line and see if there is any output?

c:\python27\python.exe -m idlelib.idle

----------
components: +Windows -None
nosy: +brian.curtin
type: crash -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10834>
_______________________________________

From report at bugs.python.org  Wed Jan  5 17:30:57 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 05 Jan 2011 16:30:57 +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: <1294245057.59.0.77479060851.issue10181@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

PEP 3118 makes it clear that the underlying object should see *two* pairs of calls to the buffer methods:
http://www.python.org/dev/peps/pep-3118/#the-py-buffer-struct

Even if we ignore the undocumented "obj" field, the target object needs to ensure the exported buffer remains valid as long as any memory views are referencing it. The only way to do that is to treat GetBuffer/ReleaseBuffer as the moral equivalent of INCREF/DECREF.

However, I believe the current memoryview implementation does the wrong thing and only calls them once, and then duplicates the Py_buffer structures without ever going back to the original objects (that opinion was based on a quick scan of the code a while back, but it would fit with the uncomplimentary sentiments Antoine has expressed in trying to get all this to exhibit some kind of consistency)

For point 2, it must be the same pointer. When the PEP says "the same", I agree it could be taken as ambiguous, but the later reference to the exporter managing a linked-list of exported views makes it clear that identity is what matters.

As far as I can see, some of things in the PEP were found to be a PITA in practice (such as every consumer of the API having to implement the equivalent of the "base" attribute in the original memoryview design), so Travis changed them. Unfortunately, those changes never made it back into the protocol documentation, leading to the current confusion.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10181>
_______________________________________

From report at bugs.python.org  Wed Jan  5 17:50:56 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 05 Jan 2011 16:50:56 +0000
Subject: [issue10827] Functions in time module should support year < 1900 when
	accept2dyear = 0
In-Reply-To: <1294159712.85.0.42147185487.issue10827@psf.upfronthosting.co.za>
Message-ID: <1294246256.63.0.203574599968.issue10827@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Attached patch, issue10827b.diff, fixes the accept2dyear = True issue and removes unnecessary struct_time to tuple conversion, but otherwise does not change the Y2K behavior.  The code handling accept2dyear is refactored so that it is now easy to accept y < 1900 in accept2dyear = False mode.  The patch also includes unit tests.

----------
stage:  -> commit review
Added file: http://bugs.python.org/file20275/issue10827b.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10827>
_______________________________________

From report at bugs.python.org  Wed Jan  5 17:52:49 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 05 Jan 2011 16:52:49 +0000
Subject: [issue10181] Problems with Py_buffer management in memoryobject.c
	(and elsewhere?)
In-Reply-To: <1294245057.59.0.77479060851.issue10181@psf.upfronthosting.co.za>
Message-ID: <1294246363.3701.11.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> However, I believe the current memoryview implementation does the
> wrong thing and only calls them once, and then duplicates the
> Py_buffer structures without ever going back to the original objects
> (that opinion was based on a quick scan of the code a while back, but
> it would fit with the uncomplimentary sentiments Antoine has expressed
> in trying to get all this to exhibit some kind of consistency)

Actually, and unless I made a mistake, it does call them twice.
(and does the slicing by hand afterwards, which explains part of the
hilarity with smalltable and friends :-))

> For point 2, it must be the same pointer. When the PEP says "the
> same", I agree it could be taken as ambiguous, but the later reference
> to the exporter managing a linked-list of exported views makes it
> clear that identity is what matters.

The common idiom (including in code not written by me :-)) is currently
to use Py_buffer variables allocated on the C stack.

Also, we have the C API function PyMemoryView_FromBuffer() which
basically mandates that Py_buffer structs can be copied around. And it's
a very useful function since it allows to create a memoryview from a
chunk of anonymous memory.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10181>
_______________________________________

From report at bugs.python.org  Wed Jan  5 17:56:12 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Wed, 05 Jan 2011 16:56:12 +0000
Subject: [issue5485] pyexpat has no unit tests for UseForeignDTD functionality
In-Reply-To: <1236963062.63.0.579203765421.issue5485@psf.upfronthosting.co.za>
Message-ID: <1294246572.0.0.612771957304.issue5485@psf.upfronthosting.co.za>


Sandro Tosi <sandro.tosi at gmail.com> added the comment:

Ok, I've changed the version field and refreshed the patch against py3k.

----------
versions: +Python 3.3 -Python 2.7
Added file: http://bugs.python.org/file20276/issue5485-py3k.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5485>
_______________________________________

From report at bugs.python.org  Wed Jan  5 17:58:18 2011
From: report at bugs.python.org (Ross Lagerwall)
Date: Wed, 05 Jan 2011 16:58:18 +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: <1294246698.05.0.388210070558.issue4489@psf.upfronthosting.co.za>


Ross Lagerwall <rosslagerwall at gmail.com> added the comment:

Updated patch removes the race condition. Since an open follows symlinks, you can't just fstat the fd to see if it is a link. I followed the following to overcome this:
https://www.securecoding.cert.org/confluence/display/seccode/POS35-C.+Avoid+race+conditions+while+checking+for+the+existence+of+a+symbolic+link

----------
Added file: http://bugs.python.org/file20277/i4489_v2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4489>
_______________________________________

From report at bugs.python.org  Wed Jan  5 18:06:03 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 05 Jan 2011 17:06:03 +0000
Subject: [issue4489] shutil.rmtree is vulnerable to a symlink attack
In-Reply-To: <1294246698.05.0.388210070558.issue4489@psf.upfronthosting.co.za>
Message-ID: <1294247158.3701.14.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

Le mercredi 05 janvier 2011 ? 16:58 +0000, Ross Lagerwall a ?crit :
> Ross Lagerwall <rosslagerwall at gmail.com> added the comment:
> 
> Updated patch removes the race condition. Since an open follows symlinks, you can't just fstat the fd to see if it is a link. I followed the following to overcome this:
> https://www.securecoding.cert.org/confluence/display/seccode/POS35-C.+Avoid+race+conditions+while+checking+for+the+existence+of+a+symbolic+link

Nice. I am unsure about the following piece of code:

+        if stat.S_ISDIR(mode):
+            if stat.S_ISLNK(mode):
+                try:
+                    raise OSError("Cannot call rmtree on a symbolic
link")
+                except OSError:
+                    onerror(os.fstatat, (dirfd, name), sys.exc_info())

If rmtree() encounters a symlink *inside* the tree, I would expect it to
simply remove the symlink, rather than choke and abort (it's also what
the unsafe implementation does).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4489>
_______________________________________

From report at bugs.python.org  Wed Jan  5 18:07:20 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 05 Jan 2011 17:07:20 +0000
Subject: [issue7995] On Mac / BSD sockets returned by accept inherit the
	parent's FD flags
In-Reply-To: <1266876583.45.0.97810567794.issue7995@psf.upfronthosting.co.za>
Message-ID: <1294247240.84.0.919013006118.issue7995@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Ok, here is a patch which prefers the default timeout (if set) over fixing of inherited flags. Tested under Linux, Windows, OpenSolaris.

----------
Added file: http://bugs.python.org/file20278/nonblock3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7995>
_______________________________________

From report at bugs.python.org  Wed Jan  5 18:08:56 2011
From: report at bugs.python.org (karl)
Date: Wed, 05 Jan 2011 17:08:56 +0000
Subject: [issue2193] Cookie Colon Name Bug
In-Reply-To: <1203992843.27.0.867127322082.issue2193@psf.upfronthosting.co.za>
Message-ID: <1294247336.24.0.937478136065.issue2193@psf.upfronthosting.co.za>


karl <karl+pythonbugs at la-grange.net> added the comment:

agreed. :)

Then my question about parsing rules for libraries. Is interoperability a plus here.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2193>
_______________________________________

From report at bugs.python.org  Wed Jan  5 18:49:54 2011
From: report at bugs.python.org (John J Lee)
Date: Wed, 05 Jan 2011 17:49:54 +0000
Subject: [issue2193] Cookie Colon Name Bug
In-Reply-To: <1203992843.27.0.867127322082.issue2193@psf.upfronthosting.co.za>
Message-ID: <1294249794.16.0.14462685538.issue2193@psf.upfronthosting.co.za>


John J Lee <jjlee at users.sourceforge.net> added the comment:

Yes, interoperability is good.  Do you have a specific concern about the change that I proposed?

If not, and you're instead just trying to ensure conformance, by all means read the draft specification that you pointed out and look for reasons why my suggested change would be the wrong thing to do -- that would certainly be useful.  Otherwise, it's hard to respond to non-specific "are you doing the right thing" questions with anything other than "yes" ;-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2193>
_______________________________________

From report at bugs.python.org  Wed Jan  5 18:51:28 2011
From: report at bugs.python.org (John J Lee)
Date: Wed, 05 Jan 2011 17:51:28 +0000
Subject: [issue2193] Cookie Colon Name Bug
In-Reply-To: <1203992843.27.0.867127322082.issue2193@psf.upfronthosting.co.za>
Message-ID: <1294249888.6.0.0656199884206.issue2193@psf.upfronthosting.co.za>


John J Lee <jjlee at users.sourceforge.net> added the comment:

Yes, interoperability is good.  Do you have a specific concern about the change that I proposed?

If not, and you're instead just trying to ensure conformance, by all means read the draft specification that you pointed out and look for reasons why my suggested change would be the wrong thing to do -- that would certainly be useful.  Otherwise, it's hard to respond to non-specific "are you doing the right thing" questions with anything other than "yes" ;-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2193>
_______________________________________

From report at bugs.python.org  Wed Jan  5 18:55:43 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Wed, 05 Jan 2011 17:55:43 +0000
Subject: [issue8499] Set a timeout in test_urllibnet
In-Reply-To: <1271948172.1.0.95585075241.issue8499@psf.upfronthosting.co.za>
Message-ID: <1294250143.37.0.474607959697.issue8499@psf.upfronthosting.co.za>


Sandro Tosi <sandro.tosi at gmail.com> added the comment:

This was already fixed (in an unrelated commit) with r85630 and prevoious, so I'm marking this issue as closed.

----------
nosy: +sandro.tosi
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8499>
_______________________________________

From report at bugs.python.org  Wed Jan  5 19:03:39 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 05 Jan 2011 18:03:39 +0000
Subject: [issue6532] thread.get_ident() should return unsigned value
In-Reply-To: <1248186325.01.0.817161707988.issue6532@psf.upfronthosting.co.za>
Message-ID: <1294250619.14.0.844991284552.issue6532@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Well, the issue is that signedness differs depending on the platform. Under Windows, thread ids are signed (DWORD). Satisfying all cases would complicate things quite a bit.

----------
nosy: +gregory.p.smith, pitrou, rnk

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6532>
_______________________________________

From report at bugs.python.org  Wed Jan  5 19:07:50 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 05 Jan 2011 18:07:50 +0000
Subject: [issue6532] thread.get_ident() should return unsigned value
In-Reply-To: <1248186325.01.0.817161707988.issue6532@psf.upfronthosting.co.za>
Message-ID: <1294250870.13.0.344159981633.issue6532@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

no, DWORD is a 32-bit unsigned integer
http://msdn.microsoft.com/en-us/library/aa383751(VS.85).aspx

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6532>
_______________________________________

From report at bugs.python.org  Wed Jan  5 19:14:38 2011
From: report at bugs.python.org (R. David Murray)
Date: Wed, 05 Jan 2011 18:14:38 +0000
Subject: [issue10835] sys.executable default and altinstall
In-Reply-To: <1294231894.7.0.0581440878919.issue10835@psf.upfronthosting.co.za>
Message-ID: <1294251278.88.0.754285019865.issue10835@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Another alternative might be to return "None" ("refuse the temptation to guess").  But, given the long standing nature of the current guessing, having it return the specific version string may indeed make sense.

----------
keywords: +easy
nosy: +r.david.murray
stage:  -> unit test needed
type:  -> behavior
versions:  -Python 2.5, Python 2.6, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10835>
_______________________________________

From report at bugs.python.org  Wed Jan  5 19:17:03 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 05 Jan 2011 18:17:03 +0000
Subject: [issue6532] thread.get_ident() should return unsigned value
In-Reply-To: <1294250870.13.0.344159981633.issue6532@psf.upfronthosting.co.za>
Message-ID: <1294251415.3701.15.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> no, DWORD is a 32-bit unsigned integer
> http://msdn.microsoft.com/en-us/library/aa383751(VS.85).aspx

Oops, my bad.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6532>
_______________________________________

From report at bugs.python.org  Wed Jan  5 19:19:27 2011
From: report at bugs.python.org (Ross Lagerwall)
Date: Wed, 05 Jan 2011 18:19:27 +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: <1294251567.22.0.0128027592369.issue4489@psf.upfronthosting.co.za>


Ross Lagerwall <rosslagerwall at gmail.com> added the comment:

I think I misread the original implementation. Here is an updated version with that code just taken out.

----------
Added file: http://bugs.python.org/file20279/i4489_v3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4489>
_______________________________________

From report at bugs.python.org  Wed Jan  5 19:20:58 2011
From: report at bugs.python.org (R. David Murray)
Date: Wed, 05 Jan 2011 18:20:58 +0000
Subject: [issue10835] sys.executable default and altinstall
In-Reply-To: <1294231894.7.0.0581440878919.issue10835@psf.upfronthosting.co.za>
Message-ID: <1294251658.38.0.692599889247.issue10835@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
nosy: +ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10835>
_______________________________________

From report at bugs.python.org  Wed Jan  5 19:21:22 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 05 Jan 2011 18:21:22 +0000
Subject: [issue5424] Packed IPaddr conversion tests should be extended
In-Reply-To: <1236260237.37.0.149966249724.issue5424@psf.upfronthosting.co.za>
Message-ID: <1294251682.33.0.443134840548.issue5424@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I'm not sure what the point of this patch is, since it's basically testing operating system behaviour, rather than Python behaviour. I think that we could have a single additional test case for bad inputs and leave it at that.
But in any case, here's the original patch ported to 3.x. Please comment.

----------
Added file: http://bugs.python.org/file20280/issue5424.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5424>
_______________________________________

From report at bugs.python.org  Wed Jan  5 19:25:45 2011
From: report at bugs.python.org (Peter Heiberg)
Date: Wed, 05 Jan 2011 18:25:45 +0000
Subject: [issue10834] Python 2.7 x86 fails to run in Windows 7
In-Reply-To: <1294224063.9.0.656095341139.issue10834@psf.upfronthosting.co.za>
Message-ID: <1294251945.5.0.21852960765.issue10834@psf.upfronthosting.co.za>


Peter Heiberg <peter at sveumsondre.no> added the comment:

The command line opens, but displays nothing but the white flashing underscore..

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10834>
_______________________________________

From report at bugs.python.org  Wed Jan  5 19:27:16 2011
From: report at bugs.python.org (=?utf-8?q?Alexandru_Mo=C8=99oi?=)
Date: Wed, 05 Jan 2011 18:27:16 +0000
Subject: [issue10836] TypeError during exception handling in
	urllib.request.urlretrieve
In-Reply-To: <1294252036.56.0.144119584231.issue10836@psf.upfronthosting.co.za>
Message-ID: <1294252036.56.0.144119584231.issue10836@psf.upfronthosting.co.za>


New submission from Alexandru Mo?oi <alexandru at mosoi.ro>:

If I try to download a inexistent file I get a TypeError which is thrown during exception handling.

>>> import urllib.request
>>> urllib.request.urlretrieve('missing')
Traceback (most recent call last):
  File "/usr/lib/python3.1/urllib/request.py", line 1705, in open_local_file
    stats = os.stat(localname)
OSError: [Errno 2] No such file or directory: 'missing'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python3.1/urllib/request.py", line 133, in urlretrieve
    return _urlopener.retrieve(url, filename, reporthook, data)
  File "/usr/lib/python3.1/urllib/request.py", line 1507, in retrieve
    fp = self.open_local_file(url1)
  File "/usr/lib/python3.1/urllib/request.py", line 1707, in open_local_file
    raise URLError(e.errno, e.strerror, e.filename)
TypeError: __init__() takes at most 3 positional arguments (4 given)

----------
components: Library (Lib)
messages: 125449
nosy: Alexandru.Mo?oi
priority: normal
severity: normal
status: open
title: TypeError during exception handling in urllib.request.urlretrieve
type: behavior
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10836>
_______________________________________

From report at bugs.python.org  Wed Jan  5 19:27:18 2011
From: report at bugs.python.org (Peter Heiberg)
Date: Wed, 05 Jan 2011 18:27:18 +0000
Subject: [issue10834] Python 2.7 x86 fails to run in Windows 7
In-Reply-To: <1294224063.9.0.656095341139.issue10834@psf.upfronthosting.co.za>
Message-ID: <1294252038.69.0.430435168439.issue10834@psf.upfronthosting.co.za>


Peter Heiberg <peter at sveumsondre.no> added the comment:

I'd like to add that I had the exact same problem on my other laptop running Win7 x64, but the same laptop (as mentioned earlier) now runs Win7 x86 and IDLE works fine on that.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10834>
_______________________________________

From report at bugs.python.org  Wed Jan  5 19:29:12 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 05 Jan 2011 18:29:12 +0000
Subject: [issue10836] TypeError during exception handling in
	urllib.request.urlretrieve
In-Reply-To: <1294252036.56.0.144119584231.issue10836@psf.upfronthosting.co.za>
Message-ID: <1294252152.48.0.759596924283.issue10836@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
assignee:  -> orsenthil
nosy: +orsenthil
stage:  -> needs patch
versions: +Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10836>
_______________________________________

From report at bugs.python.org  Wed Jan  5 19:31:26 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 05 Jan 2011 18:31:26 +0000
Subject: [issue10835] sys.executable default and altinstall
In-Reply-To: <1294231894.7.0.0581440878919.issue10835@psf.upfronthosting.co.za>
Message-ID: <1294252286.8.0.0614673531921.issue10835@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +barry

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10835>
_______________________________________

From report at bugs.python.org  Wed Jan  5 19:37:45 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 05 Jan 2011 18:37:45 +0000
Subject: [issue5485] pyexpat has no unit tests for UseForeignDTD functionality
In-Reply-To: <1236963062.63.0.579203765421.issue5485@psf.upfronthosting.co.za>
Message-ID: <1294252665.71.0.0810037383673.issue5485@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Doc patch committed in r87762.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5485>
_______________________________________

From report at bugs.python.org  Wed Jan  5 19:45:05 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 05 Jan 2011 18:45:05 +0000
Subject: [issue5485] pyexpat has no unit tests for UseForeignDTD functionality
In-Reply-To: <1236963062.63.0.579203765421.issue5485@psf.upfronthosting.co.za>
Message-ID: <1294253105.98.0.756833058959.issue5485@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Ok, I've changed "assertEquals" to "assertEqual" and committed the tests in r87765. Thank you!

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed
versions: +Python 3.2 -Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5485>
_______________________________________

From report at bugs.python.org  Wed Jan  5 19:48:07 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 05 Jan 2011 18:48:07 +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: <1294253287.23.0.0419902951467.issue4489@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
dependencies: +Add posix.fdlistdir, create Python wrappers for openat() and others

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4489>
_______________________________________

From report at bugs.python.org  Wed Jan  5 20:00:05 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Wed, 05 Jan 2011 19:00:05 +0000
Subject: [issue7995] On Mac / BSD sockets returned by accept inherit the
	parent's FD flags
In-Reply-To: <1294247240.84.0.919013006118.issue7995@psf.upfronthosting.co.za>
Message-ID: <4D24BFAE.80003@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> Ok, here is a patch which prefers the default timeout (if set) over fixing of inherited flags. Tested under Linux, Windows, OpenSolaris.

This patch looks fine to me. Please also update the accept documentation
to explain the situation (new socket gets
default timeout if given, else is blocking if server socket
has timeout, else inherits flags according to system defaults).

I then think that gettimeout is also incorrect: it really
fetch the O_NONBLOCK flag from the socket.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7995>
_______________________________________

From report at bugs.python.org  Wed Jan  5 20:01:17 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 05 Jan 2011 19:01:17 +0000
Subject: [issue10812] Add some posix functions
In-Reply-To: <1294058752.01.0.285856626146.issue10812@psf.upfronthosting.co.za>
Message-ID: <1294254077.64.0.067274733586.issue10812@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

The patch contains a lot of repeated boilerplate code.  I wonder if some of it can be factored out and reused.  For example iov buffer allocation code appears to be identical in writev and readv.

----------
nosy: +belopolsky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10812>
_______________________________________

From report at bugs.python.org  Wed Jan  5 20:12:54 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Wed, 05 Jan 2011 19:12:54 +0000
Subject: [issue8033] sqlite: broken long integer handling for arguments to
	user-defined functions
In-Reply-To: <1267408991.73.0.408537758811.issue8033@psf.upfronthosting.co.za>
Message-ID: <1294254774.53.0.93021776915.issue8033@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Alternatively, val_int should have type sqlite3_int64, which is the return type of sqlite3_value_int64.

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8033>
_______________________________________

From report at bugs.python.org  Wed Jan  5 20:20:26 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 05 Jan 2011 19:20:26 +0000
Subject: [issue10350] errno is read too late
In-Reply-To: <1289206098.51.0.17539694799.issue10350@psf.upfronthosting.co.za>
Message-ID: <1294255226.58.0.750555042215.issue10350@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

The patch seems a bit confused at times. For example, you need to restore errno before calling PyErr_SetFromErrno().
Here is a new patch for py3k.

----------
nosy: +pitrou
Added file: http://bugs.python.org/file20281/late_errno.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10350>
_______________________________________

From report at bugs.python.org  Wed Jan  5 20:22:44 2011
From: report at bugs.python.org (Brian Curtin)
Date: Wed, 05 Jan 2011 19:22:44 +0000
Subject: [issue10834] Python 2.7 x86 fails to run in Windows 7
In-Reply-To: <1294224063.9.0.656095341139.issue10834@psf.upfronthosting.co.za>
Message-ID: <1294255364.27.0.664989739714.issue10834@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

Have you confirmed that the IDLE window isn't just opened behind another window or possibly minimized? I don't know the cause of this, but a coworker has seen a few times where IDLE will open but it isn't the main focused window (hiding behind a full-screen browser, for instance).

I haven't been able to reproduce this on any of the versions I have here, and did a fresh install of 2.7.1 where it also didn't happen. I'm on Windows 7 x64.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10834>
_______________________________________

From report at bugs.python.org  Wed Jan  5 20:25:31 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 05 Jan 2011 19:25:31 +0000
Subject: [issue10350] errno is read too late
In-Reply-To: <1289206098.51.0.17539694799.issue10350@psf.upfronthosting.co.za>
Message-ID: <1294255531.81.0.60301261509.issue10350@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10350>
_______________________________________

From report at bugs.python.org  Wed Jan  5 20:30:17 2011
From: report at bugs.python.org (Barry A. Warsaw)
Date: Wed, 05 Jan 2011 19:30:17 +0000
Subject: [issue10835] sys.executable default and altinstall
In-Reply-To: <1294231894.7.0.0581440878919.issue10835@psf.upfronthosting.co.za>
Message-ID: <1294255817.09.0.726632334421.issue10835@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

For Python < 3.2, I think adding the version number alone makes sense.  Can you think of any situations where the trailing digits could break something?

For Python 3.2 I'd suggest also adding the build flags to sys.executable.  If you want the most specific binary, that would make the most sense.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10835>
_______________________________________

From report at bugs.python.org  Wed Jan  5 20:31:28 2011
From: report at bugs.python.org (Peter Heiberg)
Date: Wed, 05 Jan 2011 19:31:28 +0000
Subject: [issue10834] Python 2.7 x86 fails to run in Windows 7
In-Reply-To: <1294224063.9.0.656095341139.issue10834@psf.upfronthosting.co.za>
Message-ID: <1294255888.31.0.804661180258.issue10834@psf.upfronthosting.co.za>


Peter Heiberg <peter at sveumsondre.no> added the comment:

The IDLE window doesn't open, the taskbar shows no icons and IDLE does not show up under Task Manager's Application tab..

Also, whenever I open an instance of IDLE, two instances of the .exe shows up under the Processes tab:

one instance is completely inactive on CPU use, and uses 9788K of memory,
the other instance runs at 1-2% CPU with a constant 5892K memory usage.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10834>
_______________________________________

From report at bugs.python.org  Wed Jan  5 20:37:05 2011
From: report at bugs.python.org (Brian Curtin)
Date: Wed, 05 Jan 2011 19:37:05 +0000
Subject: [issue10834] Python 2.7 x86 fails to run in Windows 7
In-Reply-To: <1294224063.9.0.656095341139.issue10834@psf.upfronthosting.co.za>
Message-ID: <1294256225.82.0.0512858564307.issue10834@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

Weird. I'm not sure what could be happening here, and I'm not an IDLE user so I don't really have anything else to try out here.

I noticed your email address is for what I think is a Norwegian domain. Is your Windows install set to be a language other than English? It may be possible that something on startup isn't being encoded/decoded properly. Not really sure...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10834>
_______________________________________

From report at bugs.python.org  Wed Jan  5 20:38:35 2011
From: report at bugs.python.org (Barry A. Warsaw)
Date: Wed, 05 Jan 2011 19:38:35 +0000
Subject: [issue9419] RUNSHARED needs LDFLAGS
In-Reply-To: <1280423222.23.0.51081739049.issue9419@psf.upfronthosting.co.za>
Message-ID: <1294256315.71.0.00275667999983.issue9419@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

Peter, please explain exactly how you built Python to trigger this bug.  I.e. include the exact commands and directories you used.  I cannot reproduce this yet.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9419>
_______________________________________

From report at bugs.python.org  Wed Jan  5 20:40:44 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Wed, 05 Jan 2011 19:40:44 +0000
Subject: [issue10181] Problems with Py_buffer management in memoryobject.c
	(and elsewhere?)
In-Reply-To: <1294152882.35.0.707448361917.issue10181@psf.upfronthosting.co.za>
Message-ID: <4D24C938.50100@v.loewis.de>


Martin v. L??wis <martin at v.loewis.de> added the comment:

> Martin, we would like to exclude Py_buffer from the stable ABI for
> Python 3.2, until we have a chance to thrash out the missing pieces
> of the documentation for 3.3. I *think* it is a documentation
> problem, but until we're certain, it seems safer to leave it out.

Fine with me. Attached is a patch; it would be good if someone could
confirm that this exactly comprises the API that should be hidden.

----------
keywords: +patch
Added file: http://bugs.python.org/file20282/pybuffer.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10181>
_______________________________________
-------------- next part --------------
Index: Include/abstract.h
===================================================================
--- Include/abstract.h	(Revision 87765)
+++ Include/abstract.h	(Arbeitskopie)
@@ -488,6 +488,7 @@
 
     /* new buffer API */
 
+#ifndef Py_LIMITED_API
 #define PyObject_CheckBuffer(obj) \
     (((obj)->ob_type->tp_as_buffer != NULL) &&  \
      ((obj)->ob_type->tp_as_buffer->bf_getbuffer != NULL))
@@ -575,6 +576,7 @@
 
        /* Releases a Py_buffer obtained from getbuffer ParseTuple's s*.
     */
+#endif /* Py_LIMITED_API */
 
      PyAPI_FUNC(PyObject *) PyObject_Format(PyObject* obj,
                                             PyObject *format_spec);
Index: Include/object.h
===================================================================
--- Include/object.h	(Revision 87765)
+++ Include/object.h	(Arbeitskopie)
@@ -143,7 +143,7 @@
 typedef int(*ssizessizeobjargproc)(PyObject *, Py_ssize_t, Py_ssize_t, PyObject *);
 typedef int(*objobjargproc)(PyObject *, PyObject *, PyObject *);
 
-
+#ifndef Py_LIMITED_API
 /* buffer interface */
 typedef struct bufferinfo {
     void *buf;
@@ -195,6 +195,7 @@
 #define PyBUF_WRITE 0x200
 
 /* End buffer interface */
+#endif /* Py_LIMITED_API */
 
 typedef int (*objobjproc)(PyObject *, PyObject *);
 typedef int (*visitproc)(PyObject *, void *);
Index: Include/memoryobject.h
===================================================================
--- Include/memoryobject.h	(Revision 87765)
+++ Include/memoryobject.h	(Arbeitskopie)
@@ -55,9 +55,11 @@
 
 PyAPI_FUNC(PyObject *) PyMemoryView_FromObject(PyObject *base);
 
+#ifndef Py_LIMITED_API
 PyAPI_FUNC(PyObject *) PyMemoryView_FromBuffer(Py_buffer *info);
     /* create new if bufptr is NULL 
         will be a new bytesobject in base */
+#endif
 
 
 /* The struct is declared here so that macros can work, but it shouldn't
Index: PC/python3.def
===================================================================
--- PC/python3.def	(Revision 87765)
+++ PC/python3.def	(Arbeitskopie)
@@ -10,13 +10,6 @@
   PyBaseObject_Type=python32.PyBaseObject_Type DATA
   PyBool_FromLong=python32.PyBool_FromLong
   PyBool_Type=python32.PyBool_Type DATA
-  PyBuffer_FillContiguousStrides=python32.PyBuffer_FillContiguousStrides
-  PyBuffer_FillInfo=python32.PyBuffer_FillInfo
-  PyBuffer_FromContiguous=python32.PyBuffer_FromContiguous
-  PyBuffer_GetPointer=python32.PyBuffer_GetPointer
-  PyBuffer_IsContiguous=python32.PyBuffer_IsContiguous
-  PyBuffer_Release=python32.PyBuffer_Release
-  PyBuffer_ToContiguous=python32.PyBuffer_ToContiguous
   PyByteArrayIter_Type=python32.PyByteArrayIter_Type DATA
   PyByteArray_AsString=python32.PyByteArray_AsString
   PyByteArray_Concat=python32.PyByteArray_Concat
@@ -317,7 +310,6 @@
   PyMem_Malloc=python32.PyMem_Malloc
   PyMem_Realloc=python32.PyMem_Realloc
   PyMemberDescr_Type=python32.PyMemberDescr_Type DATA
-  PyMemoryView_FromBuffer=python32.PyMemoryView_FromBuffer
   PyMemoryView_FromObject=python32.PyMemoryView_FromObject
   PyMemoryView_GetContiguous=python32.PyMemoryView_GetContiguous
   PyMemoryView_Type=python32.PyMemoryView_Type DATA
@@ -399,7 +391,6 @@
   PyObject_CallObject=python32.PyObject_CallObject
   PyObject_CheckReadBuffer=python32.PyObject_CheckReadBuffer
   PyObject_ClearWeakRefs=python32.PyObject_ClearWeakRefs
-  PyObject_CopyData=python32.PyObject_CopyData
   PyObject_DelItem=python32.PyObject_DelItem
   PyObject_DelItemString=python32.PyObject_DelItemString
   PyObject_Dir=python32.PyObject_Dir
@@ -412,7 +403,6 @@
   PyObject_GenericSetAttr=python32.PyObject_GenericSetAttr
   PyObject_GetAttr=python32.PyObject_GetAttr
   PyObject_GetAttrString=python32.PyObject_GetAttrString
-  PyObject_GetBuffer=python32.PyObject_GetBuffer
   PyObject_GetItem=python32.PyObject_GetItem
   PyObject_GetIter=python32.PyObject_GetIter
   PyObject_HasAttr=python32.PyObject_HasAttr

From report at bugs.python.org  Wed Jan  5 21:02:06 2011
From: report at bugs.python.org (Josh Hanson)
Date: Wed, 05 Jan 2011 20:02:06 +0000
Subject: [issue10837] Issue catching KeyboardInterrupt while reading stdin
In-Reply-To: <1294257725.97.0.863829105509.issue10837@psf.upfronthosting.co.za>
Message-ID: <1294257725.97.0.863829105509.issue10837@psf.upfronthosting.co.za>


New submission from Josh Hanson <surely.you.jest at gmail.com>:

Example code:
    try:
        sys.stdin.read()
    except KeyboardInterrupt:
        print "Interrupted!"
    except:
        print "Some other exception?"
    finally:
        print "cleaning up..."
        print "done."

Test: run the code and hit ctrl-c while the read is blocking.
Expected behavior: program should print:
    Interrupted!
    cleaning up...
    done.

Actual behavior: On linux, behaves as expected. On windows, prints:
    cleaning up... 
    Traceback (most recent call last):
      File "filename.py", line 119, in <module>
        print 'cleaning up...'
    KeyboardInterrupt

As you can see, neither of the "except" blocks was executed, and the "finally" block was erroneously interrupted.

If I add one line inside the try block, as follows:
    try:
        sys.stdin.read()
        print "Done reading."
    ... [etc.]

Then this is the output:
    Done reading. Interrupted!
    cleaning up...
    done.

Here, the exception handler and finally block were executed as expected. This is still mildly unusual because the "done reading" print statement was reached when it probably shouldn't have been, but much more surprising because a newline was not printed after "Done reading.", and for some reason a space was.

This has been tested and found in 32-bit python versions 2.6.5, 2.6.6, 2.7.1, and 3.1.3 on 64-bit Win7.

----------
components: IO, Windows
messages: 125463
nosy: Josh.Hanson
priority: normal
severity: normal
status: open
title: Issue catching KeyboardInterrupt while reading stdin
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10837>
_______________________________________

From report at bugs.python.org  Wed Jan  5 21:06:16 2011
From: report at bugs.python.org (Peter Heiberg)
Date: Wed, 05 Jan 2011 20:06:16 +0000
Subject: [issue10834] Python 2.7 x86 fails to run in Windows 7
In-Reply-To: <1294224063.9.0.656095341139.issue10834@psf.upfronthosting.co.za>
Message-ID: <1294257976.63.0.222715784608.issue10834@psf.upfronthosting.co.za>


Peter Heiberg <peter at sveumsondre.no> added the comment:

I am running the EN-US version of Win7, with Norwegian regional and keyboard settings.  Tried changing everything to EN-US, with no change in results.  Also tried deactivating visual themes and desktop composition for the .exe.

What text editor do you personally prefer?  I have tried setting up Notepad++ for the job, but I can't seem to get the "Run" function to work properly..

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10834>
_______________________________________

From report at bugs.python.org  Wed Jan  5 21:23:28 2011
From: report at bugs.python.org (Peter Heiberg)
Date: Wed, 05 Jan 2011 20:23:28 +0000
Subject: [issue10834] Python 2.7 x86 fails to run in Windows 7
In-Reply-To: <1294224063.9.0.656095341139.issue10834@psf.upfronthosting.co.za>
Message-ID: <1294259008.57.0.728378639939.issue10834@psf.upfronthosting.co.za>


Peter Heiberg <peter at sveumsondre.no> added the comment:

Hey, progress!  I ran python.exe, typed "import idlelib.idle", pressed enter - same blinking underscore as before.  Then i pressed Ctrl+C, and WHOA, python.exe prints 25 lines of something, and the Python Shell (pythonw.exe) pops up!

There is no functionality in the Python Shell (=IDLE?) tho, and Ctrl+C'ing the window promts me to terminate the running program.

Posting the python.exe output:

>>> import idlelib.idle
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "C:\Python27\lib\idlelib\idle.py", line 11, in <module>
    idlelib.PyShell.main()
  File "C:\Python27\lib\idlelib\PyShell.py", line 1403, in main
    shell = flist.open_shell()
  File "C:\Python27\lib\idlelib\PyShell.py", line 281, in open_shell
    if not self.pyshell.begin():
  File "C:\Python27\lib\idlelib\PyShell.py", line 992, in begin
    client = self.interp.start_subprocess()
  File "C:\Python27\lib\idlelib\PyShell.py", line 417, in start_subprocess
    self.transfer_path()
  File "C:\Python27\lib\idlelib\PyShell.py", line 499, in transfer_path
    \n""" % (sys.path,))
  File "C:\Python27\lib\idlelib\PyShell.py", line 709, in runcommand
    self.rpcclt.remotequeue("exec", "runcode", (code,), {})
  File "C:\Python27\lib\idlelib\rpc.py", line 216, in remotequeue
    return self.asyncreturn(seq)
  File "C:\Python27\lib\idlelib\rpc.py", line 240, in asyncreturn
    response = self.getresponse(seq, wait=0.05)
  File "C:\Python27\lib\idlelib\rpc.py", line 280, in getresponse
    response = self._getresponse(myseq, wait)
  File "C:\Python27\lib\idlelib\rpc.py", line 300, in _getresponse
    response = self.pollresponse(myseq, wait)
  File "C:\Python27\lib\idlelib\rpc.py", line 424, in pollresponse
    message = self.pollmessage(wait)
  File "C:\Python27\lib\idlelib\rpc.py", line 376, in pollmessage
    packet = self.pollpacket(wait)
  File "C:\Python27\lib\idlelib\rpc.py", line 347, in pollpacket
    r, w, x = select.select([self.sock.fileno()], [], [], wait)
KeyboardInterrupt

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10834>
_______________________________________

From report at bugs.python.org  Wed Jan  5 21:27:30 2011
From: report at bugs.python.org (Brian Curtin)
Date: Wed, 05 Jan 2011 20:27:30 +0000
Subject: [issue10834] Python 2.7 x86 fails to run in Windows 7
In-Reply-To: <1294224063.9.0.656095341139.issue10834@psf.upfronthosting.co.za>
Message-ID: <1294259250.25.0.86851608072.issue10834@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

Ah! You might want to take a look at #6941. Your firewall might be blocking IDLE's communications.

In Windows 7, if you go to Control Panel and search for "firewall" in the top right search box, it'll show an option to make an exception for a program.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10834>
_______________________________________

From report at bugs.python.org  Wed Jan  5 21:47:03 2011
From: report at bugs.python.org (Peter Heiberg)
Date: Wed, 05 Jan 2011 20:47:03 +0000
Subject: [issue10834] Python 2.7 x86 fails to run in Windows 7
In-Reply-To: <1294224063.9.0.656095341139.issue10834@psf.upfronthosting.co.za>
Message-ID: <1294260423.97.0.353325670294.issue10834@psf.upfronthosting.co.za>


Peter Heiberg <peter at sveumsondre.no> added the comment:

My Windows Firewall have been turned off from the day I installed Win7, so that couldn't cause it..  I also tried deactivating UAC, with no luck.  Running with administrative privileges, without any results.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10834>
_______________________________________

From report at bugs.python.org  Wed Jan  5 21:52:50 2011
From: report at bugs.python.org (Toshio Kuratomi)
Date: Wed, 05 Jan 2011 20:52:50 +0000
Subject: [issue10838] subprocess __all__ is incomplete
In-Reply-To: <1294260769.5.0.0970426129524.issue10838@psf.upfronthosting.co.za>
Message-ID: <1294260769.5.0.0970426129524.issue10838@psf.upfronthosting.co.za>


New submission from Toshio Kuratomi <a.badger at gmail.com>:

I have a compatibility module for subprocess in python-2.7 for people who are stuck on python-2.4 (without check_call) and they got a traceback from trying to use compat.subprocess.list2cmdline().

In order to use the stdlib's subprocess if it's of a recent enough version, I check the version and import the symbols from there using from subprocess import * in the compat module.  Unfortunately, one of the people is using list2cmdline() in their code and list2cmdline() is not in __all__.  Comparing the output, there's a few things not in __all__ in both python-2.7 and in python-3.1:

(From python-2.7, but python-3.1 boils down to the same list):

>>> sorted([d for d in  dir (subprocess) if not d.startswith('_')])
['CalledProcessError', 'MAXFD', 'PIPE', 'Popen', 'STDOUT', 'call', 'check_call', 'check_output', 'errno', 'fcntl', 'gc', 'list2cmdline', 'mswindows', 'os', 'pickle', 'select', 'signal', 'sys', 'traceback', 'types']
>>> sorted(subprocess.__all__)
['CalledProcessError', 'PIPE', 'Popen', 'STDOUT', 'call', 'check_call', 'check_output']

So, MAXFD, list2cmdline, and mswindows seem to be left out.

These could either be made private (prepend with "_"), or added to __all__ to resolve this bug.  (I note that searching for "subprocess.any of those three" leads to some hits so whether or not they're intended to be public, they are being used :-(

----------
components: Library (Lib)
messages: 125468
nosy: a.badger
priority: normal
severity: normal
status: open
title: subprocess __all__ is incomplete
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10838>
_______________________________________

From report at bugs.python.org  Wed Jan  5 22:02:40 2011
From: report at bugs.python.org (R. David Murray)
Date: Wed, 05 Jan 2011 21:02:40 +0000
Subject: [issue10835] sys.executable default and altinstall
In-Reply-To: <1294231894.7.0.0581440878919.issue10835@psf.upfronthosting.co.za>
Message-ID: <1294261360.44.0.420572764053.issue10835@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Well, the digits are there if they are there in the name when that's actually what is in argv[0], so as long as that's the name the binary is actually installed under I don't think it will break anything.  I presume the same applies to the abi flags but haven't checked.

That said, I don't know for sure that progname is the right thing to change; I haven't looked through the code to see how sys.executable is generated or if there is anything else GetPythonName is used for.

Hmm.  I suppose there could be an issue if Python is invoked through a wrapper...I know Gentoo does that, so I've added Arfrever to nosy to see if he has an opinion.

----------
nosy: +Arfrever

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10835>
_______________________________________

From report at bugs.python.org  Wed Jan  5 22:05:29 2011
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 05 Jan 2011 21:05:29 +0000
Subject: [issue10838] subprocess __all__ is incomplete
In-Reply-To: <1294260769.5.0.0970426129524.issue10838@psf.upfronthosting.co.za>
Message-ID: <1294261529.2.0.153574400699.issue10838@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

IMO none of these three are meant to be public, and neither are they documented.  (Although the docs make a reference to "the list2cmdline *method*", which should probably just be removed.)

I remember a thread on python-dev about public-API-ness.  Did we really conclude that all non-underscored names must be public and therefore added to __all__?

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10838>
_______________________________________

From report at bugs.python.org  Wed Jan  5 22:21:57 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 05 Jan 2011 21:21:57 +0000
Subject: [issue7995] On Mac / BSD sockets returned by accept inherit the
	parent's FD flags
In-Reply-To: <1266876583.45.0.97810567794.issue7995@psf.upfronthosting.co.za>
Message-ID: <1294262517.09.0.678280995816.issue7995@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Ok, I committed the patch in r87768 and overhauled the timeout docs in r87769. I'm not sure this should be backported (because of the very slight behaviour change), so I'm closing.

----------
keywords:  -needs review
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
versions:  -Python 2.7, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7995>
_______________________________________

From report at bugs.python.org  Wed Jan  5 22:26:50 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Wed, 05 Jan 2011 21:26:50 +0000
Subject: [issue10512] regrtest ResourceWarning - unclosed sockets and files
In-Reply-To: <1290506536.77.0.313292165719.issue10512@psf.upfronthosting.co.za>
Message-ID: <1294262810.5.0.868587043376.issue10512@psf.upfronthosting.co.za>


Nadeem Vawda <nadeem.vawda at gmail.com> added the comment:

Fix attached for test_imaplib. Most of the warnings were simply due to reap_server() not closing the server object correctly. The remaining warning was due a genuine leak in imaplib.IMAP4.__init__() - if an exception is raised after the connection is opened, the socket is not closed.

----------
Added file: http://bugs.python.org/file20283/test_imaplib.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10512>
_______________________________________

From report at bugs.python.org  Wed Jan  5 22:40:03 2011
From: report at bugs.python.org (Adrien Saladin)
Date: Wed, 05 Jan 2011 21:40:03 +0000
Subject: [issue10839] email module should not allow some header field
	repetitions
In-Reply-To: <1294263603.86.0.308955870327.issue10839@psf.upfronthosting.co.za>
Message-ID: <1294263603.86.0.308955870327.issue10839@psf.upfronthosting.co.za>


New submission from Adrien Saladin <adrien.saladin at gmail.com>:

Hi,

The following script shows two problems with email.mime.text.MIMEText:

- first the use of msg['To'] seems confusing because its dictionnary-like syntax made me think it acts as a "set or replace", but in fact is working as a stream operation
- second this behavior allows for the same field to be repeated several times in a header which is discouraged in rfc-822 and forbidden for many fields in rfc-2822. 



#########################################"
from email.mime.text import MIMEText

msg = MIMEText("""Hello World""")

dest = ["one at example.com", "two at example.com", "three at example.com", "four at example.com"]
 
for d in dest:
    msg["From"] = "myself at example.com"
    msg["To"] = d
    msg["subject"] = "just a test"
    print (msg)
    # + send the buggy mail...
###################################

the last sent mail will looks like this: 

---------------------
Hello World
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: myself at example.com
To: one at example.com
subject: just a test
From: myself at example.com
To: two at example.com
subject: just a test
From: myself at example.com
To: three at example.com
subject: just a test
From: myself at example.com
To: four at example.com
subject: just a test

Hello World
----------------------


I see some possible modifications:

* make the [] operator work as a dictionnary-like syntax. So calling msg['To'] multiple times would simply replace the previous 'To:' field. The additional constraint is that some fields like 'comments' or 'keywords' can be repeated

* (or) throw an error when some fields are repeated in this list: 
  from,  sender, reply-to, to, cc, bcc, message-id, in-reply-to, references, subject

----------
components: Library (Lib)
messages: 125473
nosy: adrien-saladin
priority: normal
severity: normal
status: open
title: email module should not allow some header field repetitions
versions: Python 2.6, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10839>
_______________________________________

From report at bugs.python.org  Wed Jan  5 22:47:23 2011
From: report at bugs.python.org (Pierre Quentel)
Date: Wed, 05 Jan 2011 21:47:23 +0000
Subject: [issue4953] cgi module cannot handle POST with multipart/form-data
	in	3.0
In-Reply-To: <1232010166.79.0.972664060868.issue4953@psf.upfronthosting.co.za>
Message-ID: <1294264043.01.0.580903663876.issue4953@psf.upfronthosting.co.za>


Pierre Quentel <pierre.quentel at gmail.com> added the comment:

I agree that the only consistent solution is to impose that the attribute self.fp must read bytes in all cases, all required conversions should occur inside FieldStorage, using "some" encoding (not sure how to define it...)

If no argument fp is passed to __init__(), the instance uses the binary version of sys.stdin. In my patch I use sys.stdin.buffer, but it also works if I set it to sys.stdin.detach()

In all cases the interpreter must be launched with the -u option. As stated in the documentation, the effect of this option is to "force the binary layer of the stdin, stdout and stderr streams (which is available as their buffer attribute) to be unbuffered. The text I/O layer will still be line-buffered.". On my PC (Windows XP) this is required to be able to read all the data stream ; otherwise, only the beginning is read. I tried Glenn's suggestion with mscvrt, with no effect

I am working on the cgi.py module so that all tests (test_cgi and cgi_test) pass with binary streams. It's almost finished ; I had to adapt the tests, and sometimes fix bugs in them

Problems in test_cgi.py :
- in testQSAndFormData() string "data" should not begin with a line feed
- in testQSAndFormDataFile() : same thing as above + the argument to update result should be {'upload': b'this is the content of the fake file\n'} : bytes, ending with a line feed as in the string "data"
- in do_test(), for POST method, fp must be a BytesIO
- in test_fieldstorage_multipart(), expected value should be b'Testing 123.\n' for the third case (filename is not None, bytes expected, there is a line feed in string "data")

Problems in cgi_test.py
- data files mix headers (which should be strings) and POST data which should be read as bytes. In setup(), the file is opened in binary mode, the first two lines are read to initialize Content-Length and Content-Type, and an attribute encoding = 'latin-1' is set
- the tests showed warnings "ResourceWarning: unclosed file <_io.BufferedReader name='zenASCII.txt'>", I changed the code to avoid these warnings

I will send the results (diff for new version of cgi + tests) hopefully tomorrow

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4953>
_______________________________________

From report at bugs.python.org  Wed Jan  5 22:58:27 2011
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Wed, 05 Jan 2011 21:58:27 +0000
Subject: [issue10835] sys.executable default and altinstall
In-Reply-To: <1294231894.7.0.0581440878919.issue10835@psf.upfronthosting.co.za>
Message-ID: <1294264707.21.0.366627956186.issue10835@psf.upfronthosting.co.za>


Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com> added the comment:

I rather doubt that there will be any problem with Python invoked through a wrapper.
Gentoo's python-wrapper isn't used when target executable (e.g. /usr/bin/python3.1) is directly called.  A side effect of python-wrapper is that sys.executable is the target executable:
$ readlink /usr/bin/python
python-wrapper
$ /usr/bin/python -c 'import sys; print(sys.executable)'
/usr/bin/python3.1
$ /usr/bin/python-wrapper -c 'import sys; print(sys.executable)'
/usr/bin/python3.1
$ sh -c "exec -a '' /usr/bin/python -c 'import sys; print(sys.executable)'"
/usr/bin/python3.1
$ sh -c "exec -a '' /usr/bin/python3.1 -c 'import sys; print(sys.executable)'"
/usr/bin/python

If there is a patch, then I can test it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10835>
_______________________________________

From report at bugs.python.org  Wed Jan  5 23:03:08 2011
From: report at bugs.python.org (Adrien Saladin)
Date: Wed, 05 Jan 2011 22:03:08 +0000
Subject: [issue10839] email module should not allow some header field
	repetitions
In-Reply-To: <1294263603.86.0.308955870327.issue10839@psf.upfronthosting.co.za>
Message-ID: <1294264988.95.0.168720538647.issue10839@psf.upfronthosting.co.za>


Changes by Adrien Saladin <adrien.saladin at gmail.com>:


----------
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10839>
_______________________________________

From report at bugs.python.org  Wed Jan  5 23:11:06 2011
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 05 Jan 2011 22:11:06 +0000
Subject: [issue10839] email module should not allow some header field
	repetitions
In-Reply-To: <1294263603.86.0.308955870327.issue10839@psf.upfronthosting.co.za>
Message-ID: <1294265466.92.0.824596775182.issue10839@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
assignee:  -> r.david.murray
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10839>
_______________________________________

From report at bugs.python.org  Wed Jan  5 23:12:01 2011
From: report at bugs.python.org (Toshio Kuratomi)
Date: Wed, 05 Jan 2011 22:12:01 +0000
Subject: [issue10838] subprocess __all__ is incomplete
In-Reply-To: <1294260769.5.0.0970426129524.issue10838@psf.upfronthosting.co.za>
Message-ID: <1294265521.32.0.746583867135.issue10838@psf.upfronthosting.co.za>


Toshio Kuratomi <a.badger at gmail.com> added the comment:

IIRC, it was more along the lines of: all private names should be underscored.  The difference being that we get to choose whether currently non-underscored names should get underscored, should be deprecated and then underscored, or should be made public, put into __all__, and properly documented.

I think there was general agreement that leaving them non-underscored but expecting people to treat them as private wasn't a good idea.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10838>
_______________________________________

From report at bugs.python.org  Wed Jan  5 23:29:03 2011
From: report at bugs.python.org (R. David Murray)
Date: Wed, 05 Jan 2011 22:29:03 +0000
Subject: [issue10839] email module should not allow some header field
	repetitions
In-Reply-To: <1294263603.86.0.308955870327.issue10839@psf.upfronthosting.co.za>
Message-ID: <1294266543.85.0.485431504882.issue10839@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

The behaviour you observe is by design, and documented.  The email package needs to be able to handle RFC-invalid input, which includes messages with multiple instances of fields that are supposed to be singletons.  It also needs to keep track of the order of headers.  Thus its interface is, as documented, a "mapping-like" interface with duplicable keys and an element order.

That said, it would be a valid feature request to have a way to have it generate errors if a field that is supposed to be a singleton per-RFC is added more than once.  This will require a registry of such headers...a registry of headers is planned for the next version of the email package (email6), so that would be an appropriate time for this to be implemented.  email6 will also have strict and lenient modes, which will also be useful in this context.

----------
stage:  -> unit test needed
type: behavior -> feature request
versions: +Python 3.3 -Python 2.6, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10839>
_______________________________________

From report at bugs.python.org  Thu Jan  6 00:20:00 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 05 Jan 2011 23:20:00 +0000
Subject: [issue1777412] Python's strftime dislikes years before 1900
Message-ID: <1294269600.14.0.0190911486477.issue1777412@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

I would like to push this for 3.2.  Recent discussions at issue10827 and on python-dev seem to favor removal of arbitrary limits on year range.

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1777412>
_______________________________________

From report at bugs.python.org  Thu Jan  6 00:20:30 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 05 Jan 2011 23:20:30 +0000
Subject: [issue1777412] datetime.strftime dislikes years before 1900
Message-ID: <1294269630.4.0.222232240611.issue1777412@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


----------
title: Python's strftime dislikes years before 1900 -> datetime.strftime dislikes years before 1900

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1777412>
_______________________________________

From report at bugs.python.org  Thu Jan  6 00:40:27 2011
From: report at bugs.python.org (Dave Malcolm)
Date: Wed, 05 Jan 2011 23:40:27 +0000
Subject: [issue10655] Wrong powerpc define in Python/ceval.c
In-Reply-To: <1291845027.1.0.195055674772.issue10655@psf.upfronthosting.co.za>
Message-ID: <1294270827.35.0.730520166607.issue10655@psf.upfronthosting.co.za>


Dave Malcolm <dmalcolm at redhat.com> added the comment:

FWIW, I just added this patch downstream to Fedora's python 3 builds:
http://pkgs.fedoraproject.org/gitweb/?p=python3.git;a=blob_plain;f=python-3.2b2-fix-ppc-debug-build.patch;hb=5659c63442be2e91eb42e60284d7a9a9ab0b80dd

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10655>
_______________________________________

From report at bugs.python.org  Thu Jan  6 00:41:25 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 05 Jan 2011 23:41:25 +0000
Subject: [issue10655] Wrong powerpc define in Python/ceval.c
In-Reply-To: <1294270827.35.0.730520166607.issue10655@psf.upfronthosting.co.za>
Message-ID: <1294270879.3701.17.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> FWIW, I just added this patch downstream to Fedora's python 3 builds:
> http://pkgs.fedoraproject.org/gitweb/?p=python3.git;a=blob_plain;f=python-3.2b2-fix-ppc-debug-build.patch;hb=5659c63442be2e91eb42e60284d7a9a9ab0b80dd

Any reason not to commit it here?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10655>
_______________________________________

From report at bugs.python.org  Thu Jan  6 00:41:29 2011
From: report at bugs.python.org (Glenn Linderman)
Date: Wed, 05 Jan 2011 23:41:29 +0000
Subject: [issue4953] cgi module cannot handle POST with multipart/form-data
	in	3.0
In-Reply-To: <1232010166.79.0.972664060868.issue4953@psf.upfronthosting.co.za>
Message-ID: <1294270889.3.0.958185591738.issue4953@psf.upfronthosting.co.za>


Glenn Linderman <v+python at g.nevcal.com> added the comment:

R. David said:
(I believe http uses latin-1 when no charset is specified, but I need to double check that)

See http://bugs.python.org/issue4953#msg121864 ASCII and UTF-8 are what HTTP defines. Some implementations may, in fact, use latin-1 instead of ASCII in some places.  Not sure if we want Python CGI to do that or not.

Thanks for getting the email APIs in the docs... shouldn't have to bug you as much that way :)

Antoine said:
(this is all funny in the light of the web-sig discussion where people explain that CGI is such a natural model)

Thanks for clarifying the stdin buffering vs. binary issue... it is as I suspected.  Maybe you can also explain the circumstances in which "my" Windows code is needed, and whether Python's "-u" does it automatically, but I still believe that "-u" shouldn't be necessary for a properly functioning program, not even a CGI program... it seems like a hack to allow some programs to work without other changes, so might be a useful feature, but hopefully not a required part of invoking a CGI program.

The CGI interface is "self describing", when you follow the standards, and use the proper decoding for the proper pieces.  In that way, it is similar to email.  It is certainly not as simple as using UTF-8 everywhere, but compatibility with things invented before UTF-8 even existed somewhat prevents the simplest solution, and then not everything is text, either.  At least it is documented, and permits full UNICODE data to be passed around where needed, and permits binary to be passed around where that is needed, when the specs are adhered to.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4953>
_______________________________________

From report at bugs.python.org  Thu Jan  6 00:47:15 2011
From: report at bugs.python.org (Toshio Kuratomi)
Date: Wed, 05 Jan 2011 23:47:15 +0000
Subject: [issue10838] subprocess __all__ is incomplete
In-Reply-To: <1294260769.5.0.0970426129524.issue10838@psf.upfronthosting.co.za>
Message-ID: <1294271235.41.0.546549393078.issue10838@psf.upfronthosting.co.za>


Toshio Kuratomi <a.badger at gmail.com> added the comment:

For other's reference, there were three threads in November2010 that touch on this:

  :About removing argparse.__all__ or adding more methods to it:
    http://mail.python.org/pipermail/python-dev/2010-November/105147.html

  :Removing tk interface in pydoc:
    http://mail.python.org/pipermail/python-dev/2010-November/105375.html

The most on topic thread is the one with Subject:
  :[Python-Dev] Breaking undocumented API:
    http://mail.python.org/pipermail/python-dev/2010-November/105392.html

People broke threading a few times so you might have to search on the subject.

And ick.  The thread's more of a mess than I remembered.  Reading what Guido wrote last it seems like:

All private names should be prepended with "_" .  Imported modules are the exception to this -- they're private unless included in __all__.  Reading between the lines I think it's also saying that not all public names need to be in __all__.

So to resolve this ticket:

1) Is this the actual consensus from the end of those threads?
2) Are the three names mentioned in this ticket public or private?
3a) If private, initiate deprecation and create underscore versions of the variables.
3b) If public, documentation and adding to __all__ are good but not necessary.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10838>
_______________________________________

From report at bugs.python.org  Thu Jan  6 00:53:02 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 05 Jan 2011 23:53:02 +0000
Subject: [issue4953] cgi module cannot handle POST with multipart/form-data
	in	3.0
In-Reply-To: <1294270889.3.0.958185591738.issue4953@psf.upfronthosting.co.za>
Message-ID: <1294271574.3701.19.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Antoine said:
> (this is all funny in the light of the web-sig discussion where people
> explain that CGI is such a natural model)
> 
> Thanks for clarifying the stdin buffering vs. binary issue... it is as
> I suspected.  Maybe you can also explain the circumstances in which
> "my" Windows code is needed, and whether Python's "-u" does it
> automatically, but I still believe that "-u" shouldn't be necessary
> for a properly functioning program, not even a CGI program...

Could you open a separate bug with a simple piece of code to reproduce
the issue (preferably without launching an HTTP server :))?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4953>
_______________________________________

From report at bugs.python.org  Thu Jan  6 01:10:49 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 06 Jan 2011 00:10:49 +0000
Subject: [issue10512] regrtest ResourceWarning - unclosed sockets and files
In-Reply-To: <1290506536.77.0.313292165719.issue10512@psf.upfronthosting.co.za>
Message-ID: <1294272649.99.0.300388319324.issue10512@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> Fix attached for test_imaplib

Oh thanks! Commited as r87777 and r87778. I just changed the name of the subfunction.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10512>
_______________________________________

From report at bugs.python.org  Thu Jan  6 01:15:26 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 06 Jan 2011 00:15:26 +0000
Subject: [issue10838] subprocess __all__ is incomplete
In-Reply-To: <1294260769.5.0.0970426129524.issue10838@psf.upfronthosting.co.za>
Message-ID: <1294272926.8.0.857948886182.issue10838@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> So, MAXFD, list2cmdline, and mswindows seem to be left out.

IMO they should all be prefixed with an underscore. Greg?

----------
nosy: +gregory.p.smith, pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10838>
_______________________________________

From report at bugs.python.org  Thu Jan  6 01:15:30 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 06 Jan 2011 00:15:30 +0000
Subject: [issue10838] subprocess __all__ is incomplete
In-Reply-To: <1294260769.5.0.0970426129524.issue10838@psf.upfronthosting.co.za>
Message-ID: <1294272930.63.0.449794307055.issue10838@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
versions: +Python 3.2 -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10838>
_______________________________________

From report at bugs.python.org  Thu Jan  6 01:18:18 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 06 Jan 2011 00:18:18 +0000
Subject: [issue8458] buildbot: test_cmd_line failure on Tiger: [Errno 9] Bad
	file descriptor
In-Reply-To: <1271678026.95.0.894433016298.issue8458@psf.upfronthosting.co.za>
Message-ID: <1294273098.0.0.525052557649.issue8458@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I'm closing it in the hope that it's fixed. If it reappears, we'll have to reopen.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8458>
_______________________________________

From report at bugs.python.org  Thu Jan  6 01:23:30 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 06 Jan 2011 00:23:30 +0000
Subject: [issue10492] test_doctest fails with iso-8859-15 locale
In-Reply-To: <1290360243.96.0.603687934233.issue10492@psf.upfronthosting.co.za>
Message-ID: <1294273410.4.0.175324195208.issue10492@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> set the trace function later. Eg. replace exec(cmd, ...)
> by code=compile(cmd, ...) + exec(code) and set the trace function 
> after the call to compile.

Implemented in the attached patch, bdb.patch: trace the execution of the code, not the compilation of the code.

> I don't know if both codes are equivalent.

I still don't know :-p

----------
keywords: +patch
Added file: http://bugs.python.org/file20284/bdb.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10492>
_______________________________________

From report at bugs.python.org  Thu Jan  6 01:32:18 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 06 Jan 2011 00:32:18 +0000
Subject: [issue10840] pyarg_parsetuple docs and py_buffer
In-Reply-To: <1294273938.78.0.510835761549.issue10840@psf.upfronthosting.co.za>
Message-ID: <1294273938.78.0.510835761549.issue10840@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

The docs for "s*" and friends should mention that contiguity of the buffer is automatically enforced.

----------
assignee: docs at python
components: Documentation
messages: 125488
nosy: docs at python, exarkun, mark.dickinson, pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: pyarg_parsetuple docs and py_buffer
versions: Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10840>
_______________________________________

From report at bugs.python.org  Thu Jan  6 01:33:07 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 06 Jan 2011 00:33:07 +0000
Subject: [issue10840] pyarg_parsetuple docs and py_buffer
In-Reply-To: <1294273938.78.0.510835761549.issue10840@psf.upfronthosting.co.za>
Message-ID: <1294273987.97.0.424024474793.issue10840@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/issue10840>
_______________________________________

From report at bugs.python.org  Thu Jan  6 01:35:53 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 06 Jan 2011 00:35:53 +0000
Subject: [issue10840] pyarg_parsetuple docs and py_buffer
In-Reply-To: <1294273938.78.0.510835761549.issue10840@psf.upfronthosting.co.za>
Message-ID: <1294274153.1.0.720018261144.issue10840@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

See also #8991.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10840>
_______________________________________

From report at bugs.python.org  Thu Jan  6 01:36:49 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 06 Jan 2011 00:36:49 +0000
Subject: [issue10840] pyarg_parsetuple docs and py_buffer
In-Reply-To: <1294273938.78.0.510835761549.issue10840@psf.upfronthosting.co.za>
Message-ID: <1294274209.22.0.797938303688.issue10840@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

See also #8215.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10840>
_______________________________________

From report at bugs.python.org  Thu Jan  6 01:44:43 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 06 Jan 2011 00:44:43 +0000
Subject: [issue10840] pyarg_parsetuple docs and py_buffer
In-Reply-To: <1294273938.78.0.510835761549.issue10840@psf.upfronthosting.co.za>
Message-ID: <1294274683.55.0.453917649776.issue10840@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Ah ok, now I remember the story. I cleaned up getargs.c recently. r83197 (#8991) removes the support of discontinious buffers. I guess that most developers don't know what a discontinious buffer is and so they don't support this kind of buffer. Moreover, most PyArg_Parse*() formats don't provide information about the buffer (how it is stored in memory), and so the caller cannot handle discontinious anyway.

I think that even Python code developers don't know what a discontinious buffer is... I think that today there is just no program or library using Python discontinious buffer. And maybe the authors of the PEP forgot it too :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10840>
_______________________________________

From report at bugs.python.org  Thu Jan  6 01:51:28 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 06 Jan 2011 00:51:28 +0000
Subject: [issue10492] test_doctest fails with iso-8859-15 locale
In-Reply-To: <1290360243.96.0.603687934233.issue10492@psf.upfronthosting.co.za>
Message-ID: <1294275088.02.0.254251079298.issue10492@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

bdb.patch doesn't work if cmd is not a string (if cmd is a code object).

r87780 fixes this issue: bdb.Bdb.run() only traces the execution of the code, not the compilation (if the input is a string).

With this fix, the whole test suite pass on Linux with ISO-8859-1, ISO-8859-15 and UTF-8 locale encodings (I only tested in an ASCII path).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10492>
_______________________________________

From report at bugs.python.org  Thu Jan  6 01:52:53 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 06 Jan 2011 00:52:53 +0000
Subject: [issue10492] test_doctest fails with iso-8859-15 locale
In-Reply-To: <1290360243.96.0.603687934233.issue10492@psf.upfronthosting.co.za>
Message-ID: <1294275173.95.0.60234099259.issue10492@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/issue10492>
_______________________________________

From report at bugs.python.org  Thu Jan  6 02:00:07 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 06 Jan 2011 01:00:07 +0000
Subject: [issue10720] test_threadsignals hang on FreeBSD 6.4
In-Reply-To: <1292522526.66.0.947822056177.issue10720@psf.upfronthosting.co.za>
Message-ID: <1294275607.35.0.749303936637.issue10720@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

test_threadsignals hang on "x86 FreeBSD 3.x" buildbot since at least the 17th december (build 1030, r87341).

What is "FreeBSD 6.4"? Another buildbot?

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10720>
_______________________________________

From report at bugs.python.org  Thu Jan  6 02:03:35 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 06 Jan 2011 01:03:35 +0000
Subject: [issue10720] test_threadsignals hang on FreeBSD 6.4
In-Reply-To: <1292522526.66.0.947822056177.issue10720@psf.upfronthosting.co.za>
Message-ID: <1294275815.18.0.352920034513.issue10720@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

test_threadsignals hang also on "x86 gentoo 3.x" since at least the 17th december (build 3681, r87348).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10720>
_______________________________________

From report at bugs.python.org  Thu Jan  6 02:10:08 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 06 Jan 2011 01:10:08 +0000
Subject: [issue10720] test_threadsignals hang on FreeBSD 6.4
In-Reply-To: <1292522526.66.0.947822056177.issue10720@psf.upfronthosting.co.za>
Message-ID: <1294276208.94.0.710197001644.issue10720@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

"x86 gentoo 3.x" is an old Linux setup, see #4970: glibc 2.3.4, linuxthreads-0.10 and Linux kernel 2.6.9-gentoo-r1. linuxthreads is the old implementation of threads on Linux. It was replaced by NPTL with Linux kernel 2.6 and the GNU libc 2.4.

#4970 was fixed by r80108: skip the test if linuxthreads is used.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10720>
_______________________________________

From report at bugs.python.org  Thu Jan  6 02:11:51 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 06 Jan 2011 01:11:51 +0000
Subject: [issue10492] test_doctest fails with iso-8859-15 locale
In-Reply-To: <1290360243.96.0.603687934233.issue10492@psf.upfronthosting.co.za>
Message-ID: <1294276311.64.0.416459986507.issue10492@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

"x86 debian parallel 3.x" buildbot is green again! :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10492>
_______________________________________

From report at bugs.python.org  Thu Jan  6 02:13:07 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 06 Jan 2011 01:13:07 +0000
Subject: [issue10720] test_threadsignals hang on FreeBSD 6.4
In-Reply-To: <1292522526.66.0.947822056177.issue10720@psf.upfronthosting.co.za>
Message-ID: <1294276387.76.0.0616957729607.issue10720@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

I am unable to reproduce test_threadsignals hang with my FreeBSD 8.0 VM. A bug was maybe fixed between FreeBSD 7.2 and FreeBSD 8.0?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10720>
_______________________________________

From report at bugs.python.org  Thu Jan  6 02:17:13 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Thu, 06 Jan 2011 01:17:13 +0000
Subject: [issue10512] regrtest ResourceWarning - unclosed sockets and files
In-Reply-To: <1290506536.77.0.313292165719.issue10512@psf.upfronthosting.co.za>
Message-ID: <1294276633.48.0.488180071689.issue10512@psf.upfronthosting.co.za>


Nadeem Vawda <nadeem.vawda at gmail.com> added the comment:

Awesome. That just leaves test_urllibnet, test_urllib2net, and test_cgi. I'm hoping to post patches for the first two tomorrow.

About test_cgi, I've fiddled around with it a bit more. The leak manifests itself with any set of tests including test_cgi and test___all__, for example:

  ? ./python -Wd -E -bb -m test.regrtest test___all__ test_cgi
  [1/2] test___all__
  [2/2] test_cgi
  All 2 tests OK.
  sys:1: ResourceWarning: unclosed file <_io.TextIOWrapper name='/dev/null' encoding='UTF-8'>

... but not with any other 2-test combination. This led me to think it was something specific to test___all__, but it does also come up when running all tests *except* test___all__.

I'm guessing there's something somewhere that's causing the cgi module to be garbage-collected between the tests finishing and the process terminating. Without some familiarity with unittest's internals, I can't say anything more, though.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10512>
_______________________________________

From report at bugs.python.org  Thu Jan  6 03:10:02 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 06 Jan 2011 02:10:02 +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: <1294279802.37.0.800965322257.issue10181@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

It's OK if the Py_buffer is on the stack - it's just a unique identifier for the exporter to use as a key, not something the exporter controls the lifecycle of (the latter is true only for the pointers *inside* the struct, such as buf, shape, strides, etc).

PyMemoryView_FromBuffer should be calling PyObject_Getbuffer on the view->obj member (it's one of the things that embedding the reference allows, just as it allowed removal of the separate obj argument from the PyObject_ReleaseBuffer signature). That way the source object knows there is now a *second* Py_buffer struct kicking around, and can decide whether to re-use the same internal pointers or create new ones.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10181>
_______________________________________

From report at bugs.python.org  Thu Jan  6 03:11:57 2011
From: report at bugs.python.org (Glenn Linderman)
Date: Thu, 06 Jan 2011 02:11:57 +0000
Subject: [issue10841] binary stdio
In-Reply-To: <1294279917.2.0.685442041198.issue10841@psf.upfronthosting.co.za>
Message-ID: <1294279917.2.0.685442041198.issue10841@psf.upfronthosting.co.za>


New submission from Glenn Linderman <v+python at g.nevcal.com>:

Per Antoine's request, I wrote this test code, it isn't elegant, I whipped it together quickly; but it shows the issue.  The issue may be one of my ignorance, but it does show the behavior I described in issue 4953. Here's the output from the various test parameters that might be useful in running the test.

>c:\python32\python.exe test.py test 1
['c:\\python32\\python.exe', 'test.py', '1']
All OK

>c:\python32\python.exe test.py test 2
['c:\\python32\\python.exe', 'test.py', '2']
Not OK: b'abc\r\r\ndef\r\r\n'

>c:\python32\python.exe test.py test 3
['c:\\python32\\python.exe', 'test.py', '3']
All OK

>c:\python32\python.exe test.py test 4
['c:\\python32\\python.exe', 'test.py', '4']
Not OK: b'abc\r\r\ndef\r\r\n'

>c:\python32\python.exe test.py test 1-u
['c:\\python32\\python.exe', '-u', 'test.py', '1-u']
All OK

>c:\python32\python.exe test.py test 2-u
['c:\\python32\\python.exe', '-u', 'test.py', '2-u']
All OK

>c:\python32\python.exe test.py test 3-u
['c:\\python32\\python.exe', '-u', 'test.py', '3-u']
All OK

>c:\python32\python.exe test.py test 4-u
['c:\\python32\\python.exe', '-u', 'test.py', '4-u']
All OK

>

Note that test 2 and 4, which do not use the mscvrt stuff, have double \r: one sent by the code, and another added, apparently by MSC newline processing.  test 2-u and 4-u, which are invoking the subprocess with Python's -u parameter, also do not exhibit the problem, even though the mscvrt stuff is not used.  This seems to indicate that Python's -u parameter does approximately the same thing as my windows_binary function.

Seems like if Python already has code for this, that it would be nice to either make it more easily available to the user as an API (like my windows_binary function, invoked with a single line) in the io or sys modules (since it is used to affect sys.std* files).

And it would be nice if the function "worked cross-platform", even if it is a noop on most platforms.

----------
files: test.py
messages: 125500
nosy: v+python
priority: normal
severity: normal
status: open
title: binary stdio
Added file: http://bugs.python.org/file20285/test.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10841>
_______________________________________

From report at bugs.python.org  Thu Jan  6 03:12:49 2011
From: report at bugs.python.org (Glenn Linderman)
Date: Thu, 06 Jan 2011 02:12:49 +0000
Subject: [issue4953] cgi module cannot handle POST with multipart/form-data
	in	3.0
In-Reply-To: <1232010166.79.0.972664060868.issue4953@psf.upfronthosting.co.za>
Message-ID: <1294279969.31.0.288182440886.issue4953@psf.upfronthosting.co.za>


Glenn Linderman <v+python at g.nevcal.com> added the comment:

Pierre said:
In all cases the interpreter must be launched with the -u option. As stated in the documentation, the effect of this option is to "force the binary layer of the stdin, stdout and stderr streams (which is available as their buffer attribute) to be unbuffered. The text I/O layer will still be line-buffered.". On my PC (Windows XP) this is required to be able to read all the data stream ; otherwise, only the beginning is read. I tried Glenn's suggestion with mscvrt, with no effect

I say:
If you start the interpreter with -u, then my mscvrt has no effect.  Without it, there is an effect.  Read on...

Antoine said:
Could you open a separate bug with a simple piece of code to reproduce
the issue (preferably without launching an HTTP server :))?

I say:
issue 10841

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4953>
_______________________________________

From report at bugs.python.org  Thu Jan  6 03:15:40 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 06 Jan 2011 02:15:40 +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: <1294280140.93.0.620836404084.issue10181@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Martin's patch for the PEP 384 adjustments looks good to me.

A note in the PEP that we've deliberately excluded this on a temporary basis due to the implementation/documentation mismatch and expect to have it back in for 3.3 might be helpful, too.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10181>
_______________________________________

From report at bugs.python.org  Thu Jan  6 03:16:45 2011
From: report at bugs.python.org (Glenn Linderman)
Date: Thu, 06 Jan 2011 02:16:45 +0000
Subject: [issue10841] binary stdio
In-Reply-To: <1294279917.2.0.685442041198.issue10841@psf.upfronthosting.co.za>
Message-ID: <1294280205.11.0.6133579689.issue10841@psf.upfronthosting.co.za>


Glenn Linderman <v+python at g.nevcal.com> added the comment:

tested on Windows, for those that aren't following issue 4953

----------
components: +IO
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10841>
_______________________________________

From report at bugs.python.org  Thu Jan  6 03:23:45 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 06 Jan 2011 02:23:45 +0000
Subject: [issue10512] regrtest ResourceWarning - unclosed sockets and files
In-Reply-To: <1290506536.77.0.313292165719.issue10512@psf.upfronthosting.co.za>
Message-ID: <1294280625.68.0.998301529304.issue10512@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

test___all__ just loads ALL modules... and it doesn't unload them. I patched test___all__ to unload modules: the "ResourceWarning: unclosed file ... '/dev/null' ..." disappears, but a new error occurs. The multiprocessing module registers _exit_function() in the atexit module. If this module is unloaded, the callback stays in atexit, but the callback will raise an error when it is called because all module variables were cleared (set to None)...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10512>
_______________________________________

From report at bugs.python.org  Thu Jan  6 06:34:49 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 06 Jan 2011 05:34:49 +0000
Subject: [issue10825] use assertIsNone(...) instead of assertEquals(None, ...)
In-Reply-To: <1294148944.07.0.481041700804.issue10825@psf.upfronthosting.co.za>
Message-ID: <1294292089.86.0.818350693642.issue10825@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Applied in r87783.

----------
nosy: +rhettinger
resolution:  -> accepted
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10825>
_______________________________________

From report at bugs.python.org  Thu Jan  6 06:42:54 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 06 Jan 2011 05:42:54 +0000
Subject: [issue10813] Suppress adding decimal point for places=0 in moneyfmt()
In-Reply-To: <1294059487.44.0.656415691247.issue10813@psf.upfronthosting.co.za>
Message-ID: <1294292574.84.0.285281580082.issue10813@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

I think I prefer the code as-is.  If you need to blank out the decimal point, set dp to the empty string.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10813>
_______________________________________

From report at bugs.python.org  Thu Jan  6 07:14:03 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 06 Jan 2011 06:14:03 +0000
Subject: [issue10181] Problems with Py_buffer management in memoryobject.c
	(and elsewhere?)
In-Reply-To: <1294279802.37.0.800965322257.issue10181@psf.upfronthosting.co.za>
Message-ID: <1294294437.3716.0.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> PyMemoryView_FromBuffer should be calling PyObject_Getbuffer on the
> view->obj member (it's one of the things that embedding the reference
> allows, just as it allowed removal of the separate obj argument from
> the PyObject_ReleaseBuffer signature).

One use case is anonymous memory, i.e. view->obj == NULL.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10181>
_______________________________________

From report at bugs.python.org  Thu Jan  6 07:24:03 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 06 Jan 2011 06:24:03 +0000
Subject: [issue10841] binary stdio
In-Reply-To: <1294279917.2.0.685442041198.issue10841@psf.upfronthosting.co.za>
Message-ID: <1294295043.51.0.453781329866.issue10841@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
components: +Windows
nosy: +amaury.forgeotdarc, brian.curtin
versions: +Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10841>
_______________________________________

From report at bugs.python.org  Thu Jan  6 07:24:19 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 06 Jan 2011 06:24:19 +0000
Subject: [issue10841] binary stdio
In-Reply-To: <1294279917.2.0.685442041198.issue10841@psf.upfronthosting.co.za>
Message-ID: <1294295059.71.0.523992662634.issue10841@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/issue10841>
_______________________________________

From report at bugs.python.org  Thu Jan  6 07:33:27 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Thu, 06 Jan 2011 06:33:27 +0000
Subject: [issue10512] regrtest ResourceWarning - unclosed sockets and files
In-Reply-To: <1290506536.77.0.313292165719.issue10512@psf.upfronthosting.co.za>
Message-ID: <1294295607.8.0.249851241667.issue10512@psf.upfronthosting.co.za>


Nadeem Vawda <nadeem.vawda at gmail.com> added the comment:

Have you tried my patch (resourcewarning-fixes-3.diff)? It fixes the warning for me without breaking anything.

I was just worried that the warning was something triggered by my specific system configuration when you said that you couldn't reproduce it. I was trying to see if I could find a reason why it might appear on one system but not another. If you *have* been able to reproduce it, then I needn't look any further :P

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10512>
_______________________________________

From report at bugs.python.org  Thu Jan  6 07:36:26 2011
From: report at bugs.python.org (Gregory P. Smith)
Date: Thu, 06 Jan 2011 06:36:26 +0000
Subject: [issue2320] Race condition in subprocess using stdin
In-Reply-To: <1205760712.39.0.906940637593.issue2320@psf.upfronthosting.co.za>
Message-ID: <1294295786.81.0.302896471561.issue2320@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

This is likely solved in py3k 3.2 with the C _posixsubprocess.c module.  The pipe creation and cloexec flag setting is all done atomically when possible, and at least with the GIL held when not.  close_fds also now defaults to True.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2320>
_______________________________________

From report at bugs.python.org  Thu Jan  6 07:52:59 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 06 Jan 2011 06:52:59 +0000
Subject: [issue10841] binary stdio
In-Reply-To: <1294279917.2.0.685442041198.issue10841@psf.upfronthosting.co.za>
Message-ID: <1294296779.02.0.825383014875.issue10841@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

What are the results if, instead of piping through subprocess, you simply redirect stdout to a file (using "... > myfile.txt")?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10841>
_______________________________________

From report at bugs.python.org  Thu Jan  6 08:06:29 2011
From: report at bugs.python.org (Glenn Linderman)
Date: Thu, 06 Jan 2011 07:06:29 +0000
Subject: [issue10841] binary stdio
In-Reply-To: <1294279917.2.0.685442041198.issue10841@psf.upfronthosting.co.za>
Message-ID: <1294297589.37.0.318616016657.issue10841@psf.upfronthosting.co.za>


Glenn Linderman <v+python at g.nevcal.com> added the comment:

The same.  This can be tested with the same test program,

c:\python32\python.exe test.py 1 > test1.txt

similar for 2, 3, 4.  Then add -u and repeat.  All 8 cases produce the same results, either via a pipe, or with a redirected stdout.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10841>
_______________________________________

From report at bugs.python.org  Thu Jan  6 08:13:24 2011
From: report at bugs.python.org (Glenn Linderman)
Date: Thu, 06 Jan 2011 07:13:24 +0000
Subject: [issue10841] binary stdio
In-Reply-To: <1294279917.2.0.685442041198.issue10841@psf.upfronthosting.co.za>
Message-ID: <1294298004.48.0.41628391159.issue10841@psf.upfronthosting.co.za>


Glenn Linderman <v+python at g.nevcal.com> added the comment:

Actually, it seems like this "-u" behaviour, should simply be the default for Python 3.x on Windows.  The new IO subsystem seems to be able to add \r when desired anyway.  And except for Notepad, most programs on Windows can deal with \r\n or solo \n anyway.  \r\r\n doesn't cause too many problems for very many programs, but is (1) non-standard (2) wasteful of bytes (3) does cause problems for CGI programs, and likely some others... I haven't done a lot of testing with that case, but tried a few programs, and they dealt with it gracefully.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10841>
_______________________________________

From report at bugs.python.org  Thu Jan  6 08:20:29 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 06 Jan 2011 07:20:29 +0000
Subject: [issue10841] binary stdio
In-Reply-To: <1294298004.48.0.41628391159.issue10841@psf.upfronthosting.co.za>
Message-ID: <1294298425.3716.2.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Actually, it seems like this "-u" behaviour, should simply be the
> default for Python 3.x on Windows.

There is nothing in "-u" which should explain the behaviour you're
observing, so either way it's a bug. Making "-u" the default is quite
orthogonal.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10841>
_______________________________________

From report at bugs.python.org  Thu Jan  6 08:22:02 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 06 Jan 2011 07:22:02 +0000
Subject: [issue10840] pyarg_parsetuple docs and py_buffer
In-Reply-To: <1294273938.78.0.510835761549.issue10840@psf.upfronthosting.co.za>
Message-ID: <1294298522.3.0.0123027788531.issue10840@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Done in 3.2 and 3.1. For 2.7 the structure of the doc page would lead to too much repetition IMO.

----------
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/issue10840>
_______________________________________

From report at bugs.python.org  Thu Jan  6 08:30:25 2011
From: report at bugs.python.org (Glenn Linderman)
Date: Thu, 06 Jan 2011 07:30:25 +0000
Subject: [issue10841] binary stdio
In-Reply-To: <1294279917.2.0.685442041198.issue10841@psf.upfronthosting.co.za>
Message-ID: <1294299025.84.0.898729521572.issue10841@psf.upfronthosting.co.za>


Glenn Linderman <v+python at g.nevcal.com> added the comment:

Is there an easy way for me to find the code for -u?  I haven't learned my way around the Python sources much, just peeked in modules that I've needed to fix or learn something from a little.  I'm just surprised you think it is orthogonal, but I'm glad you agree it is a bug.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10841>
_______________________________________

From report at bugs.python.org  Thu Jan  6 08:51:33 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 06 Jan 2011 07:51:33 +0000
Subject: [issue10841] binary stdio
In-Reply-To: <1294299025.84.0.898729521572.issue10841@psf.upfronthosting.co.za>
Message-ID: <1294300288.3716.9.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Is there an easy way for me to find the code for -u?

"-u" just passes 0 for the "buffering" argument to open() when creating
stdout and stderr. Otherwise "buffering" equals -1.
You can find equivalent code for open() in Lib/_pyio.py (the actual code
in is in C).

The practical difference is that "-u" removes the binary buffering layer
between the unicode layer and the raw file object:

$ ./python -c "import sys; print(sys.stdout, sys.stdout.buffer)"
<_io.TextIOWrapper name='<stdout>' encoding='UTF-8'> <_io.BufferedWriter name='<stdout>'>
$ ./python -u -c "import sys; print(sys.stdout, sys.stdout.buffer)"
<_io.TextIOWrapper name='<stdout>' encoding='UTF-8'> <_io.FileIO name='<stdout>' mode='wb'>

This should make absolutely no difference as to newline handling, since
that is handled exclusively in TextIOWrapper (binary layers are
transparent by construction).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10841>
_______________________________________

From report at bugs.python.org  Thu Jan  6 08:52:10 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 06 Jan 2011 07:52:10 +0000
Subject: [issue5945] PyMapping_Check returns 1 for lists
In-Reply-To: <1241560036.33.0.817766851688.issue5945@psf.upfronthosting.co.za>
Message-ID: <1294300330.52.0.543209371085.issue5945@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Actually, making PyMapping_Check() more robust produces a test failure in test_builtin, because of the following code:

        # Verify locals stores (used by list comps)
        eval('[locals() for i in (2,3)]', g, d)
        eval('[locals() for i in (2,3)]', g, collections.UserDict())

        class SpreadSheet:
            "Sample application showing nested, calculated lookups."
            _cells = {}
            def __setitem__(self, key, formula):
                self._cells[key] = formula
            def __getitem__(self, key):
                return eval(self._cells[key], globals(), self)

        ss = SpreadSheet()
        ss['a1'] = '5'
        ss['a2'] = 'a1*6'
        ss['a3'] = 'a2*7'
        self.assertEqual(ss['a3'], 210)


Should I fix the example to include a keys() method?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5945>
_______________________________________

From report at bugs.python.org  Thu Jan  6 09:17:25 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 06 Jan 2011 08:17:25 +0000
Subject: [issue5945] PyMapping_Check returns 1 for lists
In-Reply-To: <1241560036.33.0.817766851688.issue5945@psf.upfronthosting.co.za>
Message-ID: <1294301845.6.0.883618467961.issue5945@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Rather than introduce "fixes" that break code and hurt performance, I think it would be better to deprecate PyMapping_Check() and wait for a fast, clean C version of the ABCs (that is supposed to be our one obvious way to do it).

FWIW, the spreadsheet example has been around for years and I know of more than one private company that has made heavy use of code modeled on that example (not for spreadsheets, but as a hook for eval).  So, I don't think the new "keys" check should be backported.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5945>
_______________________________________

From report at bugs.python.org  Thu Jan  6 09:18:43 2011
From: report at bugs.python.org (Charles-Francois Natali)
Date: Thu, 06 Jan 2011 08:18:43 +0000
Subject: [issue10824] urandom should not block
In-Reply-To: <4D23A133.9090906@v.loewis.de>
Message-ID: <AANLkTimQ0hz17QtsjAtR4t=0pF2Nvqt19ZNK5YXAf_9F@mail.gmail.com>


Charles-Francois Natali <neologix at free.fr> added the comment:

> Martin v. L?wis <martin at v.loewis.de> added the comment:
>
>> "It's a bug in random.c that doesn' t check for signal pending inside the
>> read(2) code, so you have no chance to kill the process via signals until
>> the read(2) syscall is finished, and it could take a lot of time before
>> return, if the buffer given to the read syscall is very big..."
>>
>> I've had a quick look at the source code, and indeed, read(2) from
>> /dev/urandom can now be interrupted by a signal, so looping seems to
>> be justified.
>
> No: if read(2) is interrupted, no data is returned, and exception is
> raised. So it won't loop in that case, but raise the exception out of
> urandom also (which is the right thing to do).
>

(Sorry for being a little off-topic, but since there's not dedicated thread)
Try with this:
dd if=/dev/urandom of=/dev/null bs=100M count=1

Then, in another terminal:
pkill -USR1 -xn dd

You'll see that read returns less that 100M bytes when interrupted.
You can also try with the following python code:

---
import os

d = os.open('/dev/urandom', os.O_RDONLY)
data = os.read(d, 1 << 28)
os.close(d)
print('read %d bytes' % len(data))
---

and in another terminal
pkill -STOP -xn python
then
pkill -CONT -xn python

Same thing, read returns less bytes than requested.
Anyway, since /dev/urandom is not part of any standard (AFAIK), it's
probably better to use the common idiom
while len(data) < expected:
    read(expected - len(data))

So we're sure it won't break under some systems/conditions.

Cheers

> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue10824>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10824>
_______________________________________

From report at bugs.python.org  Thu Jan  6 09:27:53 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 06 Jan 2011 08:27:53 +0000
Subject: [issue5945] PyMapping_Check returns 1 for lists
In-Reply-To: <1294301845.6.0.883618467961.issue5945@psf.upfronthosting.co.za>
Message-ID: <1294302468.3716.12.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Rather than introduce "fixes" that break code and hurt performance, I
> think it would be better to deprecate PyMapping_Check() and wait for a
> fast, clean C version of the ABCs (that is supposed to be our one
> obvious way to do it).

Do you also advocate deprecating PySequence_Check()? Both are useful
APIs to know what you're dealing with.

As for the "clean C version of the ABCs", I'm afraid we could wait quite
a bit, since that's a lot more work and nobody seems really interested
in the matter.

> FWIW, the spreadsheet example has been around for years and I know of
> more than one private company that has made heavy use of code modeled
> on that example (not for spreadsheets, but as a hook for eval).  So, I
> don't think the new "keys" check should be backported.

Well, I'm not proposing to backport it, but to fix things in 3.2.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5945>
_______________________________________

From report at bugs.python.org  Thu Jan  6 09:42:29 2011
From: report at bugs.python.org (Glenn Linderman)
Date: Thu, 06 Jan 2011 08:42:29 +0000
Subject: [issue10841] binary stdio
In-Reply-To: <1294279917.2.0.685442041198.issue10841@psf.upfronthosting.co.za>
Message-ID: <1294303349.28.0.311754248837.issue10841@psf.upfronthosting.co.za>


Glenn Linderman <v+python at g.nevcal.com> added the comment:

I can read and understand C well enough, having coded in it for about 40 years now... but I left C for Perl and Perl for Python, I try not to code in C when I don't have to, these days, as the P languages are more productive, overall.

But there has to be special handling somewhere for opening std*, because they are already open, unlike other files.  That is no doubt where the bug is.  Can you point me at that code?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10841>
_______________________________________

From report at bugs.python.org  Thu Jan  6 09:47:00 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 06 Jan 2011 08:47:00 +0000
Subject: [issue5945] PyMapping_Check returns 1 for lists
In-Reply-To: <1241560036.33.0.817766851688.issue5945@psf.upfronthosting.co.za>
Message-ID: <1294303620.79.0.302455564344.issue5945@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

> Do you also advocate deprecating PySequence_Check()? 

Perhaps just document PyMapping_Check() as being less informative than before (now it has false positives for sequences).

> As for the "clean C version of the ABCs", 
> I'm afraid we could wait quite a bit

That may be true.  I hope not.  The ABCs were meant to solve exactly this problem.  At this point, I would rather ignore the problem for 3.2 than to implement a less clean alternative.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5945>
_______________________________________

From report at bugs.python.org  Thu Jan  6 09:48:20 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 06 Jan 2011 08:48:20 +0000
Subject: [issue10841] binary stdio
In-Reply-To: <1294303349.28.0.311754248837.issue10841@psf.upfronthosting.co.za>
Message-ID: <1294303695.3716.13.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> But there has to be special handling somewhere for opening std*,
> because they are already open, unlike other files.  That is no doubt
> where the bug is.  Can you point me at that code?

See initstdio() in Python/pythonrun.c

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10841>
_______________________________________

From report at bugs.python.org  Thu Jan  6 09:52:20 2011
From: report at bugs.python.org (Etienne Robillard)
Date: Thu, 06 Jan 2011 08:52:20 +0000
Subject: [issue4953] cgi module cannot handle POST with multipart/form-data
	in	3.0
In-Reply-To: <1294279969.31.0.288182440886.issue4953@psf.upfronthosting.co.za>
Message-ID: <4D258579.3080706@gthcfoundation.org>


Etienne Robillard <erob at gthcfoundation.org> added the comment:

On 05/01/11 09:12 PM, Glenn Linderman wrote:
> Glenn Linderman <v+python at g.nevcal.com> added the comment:
>
> Pierre said:
> In all cases the interpreter must be launched with the -u option. As stated in the documentation, the effect of this option is to "force the binary layer of the stdin, stdout and stderr streams (which is available as their buffer attribute) to be unbuffered. The text I/O layer will still be line-buffered.". On my PC (Windows XP) this is required to be able to read all the data stream ; otherwise, only the beginning is read. I tried Glenn's suggestion with mscvrt, with no effect
>
> I say:
> If you start the interpreter with -u, then my mscvrt has no effect.  Without it, there is an effect.  Read on...
>
> Antoine said:
> Could you open a separate bug with a simple piece of code to reproduce
> the issue (preferably without launching an HTTP server :))?
>
> I say:
> issue 10841
>
> ----------
>
>   

Thats a quite annoying response. whats the purposes of a "option" switch
if it becomes
mandatory ? Are you refering to Windows only users ?

I would prefer a way to programmatically allow FieldStorage to use
HTTP_TRANSFER_ENCODING
if available, to select a matching encoding...

Thanks

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4953>
_______________________________________

From report at bugs.python.org  Thu Jan  6 09:55:14 2011
From: report at bugs.python.org (Glenn Linderman)
Date: Thu, 06 Jan 2011 08:55:14 +0000
Subject: [issue10841] binary stdio
In-Reply-To: <1294279917.2.0.685442041198.issue10841@psf.upfronthosting.co.za>
Message-ID: <1294304114.17.0.333195067028.issue10841@psf.upfronthosting.co.za>


Glenn Linderman <v+python at g.nevcal.com> added the comment:

I suppose the FileIO in _io is next to look at, wherever it can be found.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10841>
_______________________________________

From report at bugs.python.org  Thu Jan  6 09:59:20 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 06 Jan 2011 08:59:20 +0000
Subject: [issue10841] binary stdio
In-Reply-To: <1294304114.17.0.333195067028.issue10841@psf.upfronthosting.co.za>
Message-ID: <1294304355.3716.14.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> I suppose the FileIO in _io is next to look at, wherever it can be found.

I don't get what you're looking for. FileIO is involved in both the
buffered and unbuffered cases, so it shouldn't make a difference.
In any case, please look into Modules/_io

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10841>
_______________________________________

From report at bugs.python.org  Thu Jan  6 10:02:50 2011
From: report at bugs.python.org (David-Sarah Hopwood)
Date: Thu, 06 Jan 2011 09:02:50 +0000
Subject: [issue410547] os.statvfs support for Windows
Message-ID: <1294304570.01.0.28310797432.issue410547@psf.upfronthosting.co.za>


David-Sarah Hopwood <david-sarah at jacaranda.org> added the comment:

"Is there a portable way to get the available disk space by now?"

No, but http://tahoe-lafs.org/trac/tahoe-lafs/browser/src/allmydata/util/fileutil.py?rev=4894#L308 might be helpful (uses pywin32).

----------
nosy: +davidsarah

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue410547>
_______________________________________

From report at bugs.python.org  Thu Jan  6 10:06:21 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 06 Jan 2011 09:06:21 +0000
Subject: [issue1677694] test_timeout refactoring
Message-ID: <1294304781.5.0.704810587898.issue1677694@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I adapted the patch for current py3k and committed it in r87786. Thank you for your patience.

----------
nosy: +pitrou
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1677694>
_______________________________________

From report at bugs.python.org  Thu Jan  6 10:16:24 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 06 Jan 2011 09:16:24 +0000
Subject: [issue5945] PyMapping_Check returns 1 for lists
In-Reply-To: <1294303620.79.0.302455564344.issue5945@psf.upfronthosting.co.za>
Message-ID: <1294305379.3716.20.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> > As for the "clean C version of the ABCs", 
> > I'm afraid we could wait quite a bit
> 
> That may be true.  I hope not.  The ABCs were meant to solve exactly
> this problem.  At this point, I would rather ignore the problem for
> 3.2 than to implement a less clean alternative.

Also, please note that checking for ABCs would not solve the
test_builtin failure, since the class there doesn't implement the
Mapping ABC (and doesn't claim to either).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5945>
_______________________________________

From report at bugs.python.org  Thu Jan  6 10:16:32 2011
From: report at bugs.python.org (Glenn Linderman)
Date: Thu, 06 Jan 2011 09:16:32 +0000
Subject: [issue10841] binary stdio
In-Reply-To: <1294279917.2.0.685442041198.issue10841@psf.upfronthosting.co.za>
Message-ID: <1294305392.18.0.431551244942.issue10841@psf.upfronthosting.co.za>


Glenn Linderman <v+python at g.nevcal.com> added the comment:

Found it.

The file browser doesn't tell what line number it is, but in _io/Fileio.c function fileio_init, there is code like

#ifdef O_BINARY
    flags |= O_BINARY;
#endif

#ifdef O_APPEND
    if (append)
        flags |= O_APPEND;
#endif

    if (fd >= 0) {
        if (check_fd(fd))
            goto error;
        self->fd = fd;
        self->closefd = closefd;
    }


Note that if O_BINARY is defined, it is set into the default flags for opening files by name.  But if "opening" a file by fd, the fd is copied, regardless of whether it has O_BINARY set or not.  The rest of the IO code no doubt assumes the file was opened in O_BINARY mode.  But that isn't true of MSC std* handles by default.

How -u masks or overcomes this problem is not obvious, as yet, but the root bug seems to be the assumption in the above code.  A setmode of O_BINARY should be done, probably #ifdef O_BINARY, when attaching a MS C fd to a Python IO stack.  Otherwise it is going to have \r\r\n problems, it would seem.

Alternately, in the location where the Python IO stacks are attached to std* handles, those specific std* handles should have the setmode done there... other handles, if opened by Python, likely already have it done.

Documentation for open should mention, in the description of the file parameter, that on Windows, it is important to only attach Python IO stack to O_BINARY files, or beware the consequences of two independent newline handling algorithms being applied to the data stream... or to document that setmode O_BINARY will be performed on the handles passed to open.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10841>
_______________________________________

From report at bugs.python.org  Thu Jan  6 10:20:30 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 06 Jan 2011 09:20:30 +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: <1294305630.34.0.488492520797.issue10181@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

[Nick]
> For point 2, it must be the same pointer. When the PEP says "the same", > I agree it could be taken as ambiguous, but the later reference to the 
> exporter managing a linked-list of exported views makes it clear that 
> identity is what matters.

Okay, thanks.  Next point of confusion:  does that mean that in the example I gave, the object 'n' (the memoryview slice) needs to know about *two* distinct Py_buffer structs---one to pass back to releasebuffer and one to store its own information?  It seems to me that these can't be the same, since (a) the Py_buffer for the slice will have different shape and stride from that returned by getbuffer, (b) what's passed back to releasebuffer should be identical to what came from getbuffer, so we can't just modify the shape and stride information in place.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10181>
_______________________________________

From report at bugs.python.org  Thu Jan  6 10:20:37 2011
From: report at bugs.python.org (Ned Deily)
Date: Thu, 06 Jan 2011 09:20:37 +0000
Subject: [issue10842] Update third-party libraries for OS X installer builds
In-Reply-To: <1294305637.23.0.341106753223.issue10842@psf.upfronthosting.co.za>
Message-ID: <1294305637.23.0.341106753223.issue10842@psf.upfronthosting.co.za>


New submission from Ned Deily <nad at acm.org>:

The third-party libraries used by the 32-bit OS X installer are in need of updating.  (Patch follows.)

----------
assignee: ronaldoussoren
components: Build, Macintosh
messages: 125532
nosy: georg.brandl, ned.deily, ronaldoussoren
priority: normal
severity: normal
stage: patch review
status: open
title: Update third-party libraries for OS X installer builds
versions: Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10842>
_______________________________________

From report at bugs.python.org  Thu Jan  6 10:28:30 2011
From: report at bugs.python.org (Glenn Linderman)
Date: Thu, 06 Jan 2011 09:28:30 +0000
Subject: [issue4953] cgi module cannot handle POST with multipart/form-data
	in	3.0
In-Reply-To: <1232010166.79.0.972664060868.issue4953@psf.upfronthosting.co.za>
Message-ID: <1294306110.0.0.541859342242.issue4953@psf.upfronthosting.co.za>


Glenn Linderman <v+python at g.nevcal.com> added the comment:

Etienne, I'm not sure what you are _really_ referring to by HTTP_TRANSFER_ENCODING.  There is a TRANSFER_ENCODING defined by HTTP but it is completely orthogonal to character encoding issues.  There is a CONTENT_ENCODING defined which is a character encoding, but that is either explicit in the MIME data, or assumed to be either ASCII or UTF-8, in certain form data contexts.

Because the HTTP protocol is binary, only selected data, either explicitly or implicitly (by standard definition) should be decoded, using the appropriate encoding.  FieldStorage should be able to (1) read a binary stream (2) do the appropriate decoding operations (3) return the data as bytes or str as appropriate.

Right now, I'm mostly interested in the fact that it doesn't do (1), so it is hard to know what it does for (2) or (3) because it gets an error first.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4953>
_______________________________________

From report at bugs.python.org  Thu Jan  6 10:29:57 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 06 Jan 2011 09:29:57 +0000
Subject: [issue10841] binary stdio
In-Reply-To: <1294279917.2.0.685442041198.issue10841@psf.upfronthosting.co.za>
Message-ID: <1294306197.6.0.655065835397.issue10841@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Ok, actually it boils down to the following code in Modules/main.c:

    if (Py_UnbufferedStdioFlag) {
#if defined(MS_WINDOWS) || defined(__CYGWIN__)
        _setmode(fileno(stdin), O_BINARY);
        _setmode(fileno(stdout), O_BINARY);
#endif

... which explains things quite clearly! Archeology leads to r7409 by Guido in 1997:

changeset:   4916:5af9f8a98d93
branch:      trunk
user:        guido
date:        Sat Jan 11 20:28:55 1997 +0100
files:       Modules/main.c
description:
[svn r7409] On Windows, -u implies binary mode for stdin/stdout
(as well as unbuffered stdout/stderr).

----------
nosy: +gvanrossum
versions: +Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10841>
_______________________________________

From report at bugs.python.org  Thu Jan  6 10:30:52 2011
From: report at bugs.python.org (Philippe Devalkeneer)
Date: Thu, 06 Jan 2011 09:30:52 +0000
Subject: [issue8033] sqlite: broken long integer handling for arguments to
	user-defined functions
In-Reply-To: <1267408991.73.0.408537758811.issue8033@psf.upfronthosting.co.za>
Message-ID: <1294306252.79.0.292196291254.issue8033@psf.upfronthosting.co.za>


Philippe Devalkeneer <phil.le.bienheureux at gmail.com> added the comment:

Ok I will redo a patch in the next few days with possibly type sqlite3_int64, and include tests.

Thank you for the review.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8033>
_______________________________________

From report at bugs.python.org  Thu Jan  6 10:33:50 2011
From: report at bugs.python.org (Ned Deily)
Date: Thu, 06 Jan 2011 09:33:50 +0000
Subject: [issue10842] Update third-party libraries for OS X installer builds
In-Reply-To: <1294305637.23.0.341106753223.issue10842@psf.upfronthosting.co.za>
Message-ID: <1294306430.07.0.815599309086.issue10842@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

1. bzip2 1.0.5 -> 1.0.6 (fixes CVE-2010-0405)
2. GNU Readline 5.1.4 -> 6.1.2
3. SQLite 3.6.11 -> 3.7.4 (also enable FTS3/FTS4 and RTREE extensions)
4. ncurses 5.5 -> ncursesw 5.5 (enable wide-character support)
5. do not build Sleepycat DB (4.7.25) for Python 3 builds
6. zlib (1.2.3) unchanged

Note: When 3rd-party libs are used in the installers is not changed
      by this patch.  In particular, the libs are only built for
      the 32-bit-only installer variant (or any installer built with
      deployment target < OS X 10.5).  For targets >= 10.5,
      as in the 64-/32-bit installer variant, the Apple-supplied
      system versions of the libs are dynamically linked instead,
      with the system BSD editline (libedit) lib used in place
      of GNU readline (which is not shipped by Apple in OS X).

----------
keywords: +patch
priority: normal -> high
Added file: http://bugs.python.org/file20286/issue10842-py3k-27.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10842>
_______________________________________

From report at bugs.python.org  Thu Jan  6 10:37:38 2011
From: report at bugs.python.org (Glenn Linderman)
Date: Thu, 06 Jan 2011 09:37:38 +0000
Subject: [issue10841] binary stdio
In-Reply-To: <1294279917.2.0.685442041198.issue10841@psf.upfronthosting.co.za>
Message-ID: <1294306658.6.0.0273038442936.issue10841@psf.upfronthosting.co.za>


Glenn Linderman <v+python at g.nevcal.com> added the comment:

Don't find "initstdio" "stdio" in pythonrun.c.  Has it moved?  There are precious few references to stdin, stdout, stderr in that module, mostly for attaching the default encoding.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10841>
_______________________________________

From report at bugs.python.org  Thu Jan  6 10:37:44 2011
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 06 Jan 2011 09:37:44 +0000
Subject: [issue10842] Update third-party libraries for OS X installer builds
In-Reply-To: <1294305637.23.0.341106753223.issue10842@psf.upfronthosting.co.za>
Message-ID: <1294306664.21.0.931016317093.issue10842@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Making this a blocker for now; I'd rather not update this during RC phase.

----------
nosy: +benjamin.peterson
priority: high -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10842>
_______________________________________

From report at bugs.python.org  Thu Jan  6 10:44:05 2011
From: report at bugs.python.org (Glenn Linderman)
Date: Thu, 06 Jan 2011 09:44:05 +0000
Subject: [issue10841] binary stdio
In-Reply-To: <1294279917.2.0.685442041198.issue10841@psf.upfronthosting.co.za>
Message-ID: <1294307045.25.0.679082146508.issue10841@psf.upfronthosting.co.za>


Glenn Linderman <v+python at g.nevcal.com> added the comment:

stderr is notable by its absence in the list of O_BINARY adjustments.

So -u does do 2/3 of what my windows_binary() does :)  Should I switch my test case to use stderr to demonstrate that it doesn't help with that?  I vaguely remember that early versions of DOS didn't do stderr, but I thought by the time Windows came along, let's see, was that about 1983?, that stderr was codified for DOS/Windows.  For sure it has never been missing in WinNT 4.0 +.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10841>
_______________________________________

From report at bugs.python.org  Thu Jan  6 10:45:03 2011
From: report at bugs.python.org (Ned Deily)
Date: Thu, 06 Jan 2011 09:45:03 +0000
Subject: [issue10843] OS X installer: install the Tools source directory
In-Reply-To: <1294307103.62.0.440849003452.issue10843@psf.upfronthosting.co.za>
Message-ID: <1294307103.62.0.440849003452.issue10843@psf.upfronthosting.co.za>


New submission from Ned Deily <nad at acm.org>:

As suggested in Issue10502 and now that the former Demos directory has been pruned and moved under the Tools directory, the OS X installer should install the Tools source directory in the /Applications/Python 3.x/Extras directory where Demos was formerly installed.  The existing README file there still applies, i.e. not all of these files are applicable to OS X users.  (patch follows)

----------
assignee: ronaldoussoren
components: Build, Macintosh
messages: 125540
nosy: georg.brandl, michael.foord, ned.deily, ronaldoussoren
priority: high
severity: normal
status: open
title: OS X installer: install the Tools source directory
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10843>
_______________________________________

From report at bugs.python.org  Thu Jan  6 10:50:48 2011
From: report at bugs.python.org (Ned Deily)
Date: Thu, 06 Jan 2011 09:50:48 +0000
Subject: [issue10843] OS X installer: install the Tools source directory
In-Reply-To: <1294307103.62.0.440849003452.issue10843@psf.upfronthosting.co.za>
Message-ID: <1294307448.29.0.577750780193.issue10843@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Patch for py3k.

----------
keywords: +patch
stage:  -> patch review
Added file: http://bugs.python.org/file20287/issue10843-py3k.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10843>
_______________________________________

From report at bugs.python.org  Thu Jan  6 10:55:25 2011
From: report at bugs.python.org (Ned Deily)
Date: Thu, 06 Jan 2011 09:55:25 +0000
Subject: [issue10844] OS X installer: update copyright dates in app bundles
In-Reply-To: <1294307725.56.0.795948655729.issue10844@psf.upfronthosting.co.za>
Message-ID: <1294307725.56.0.795948655729.issue10844@psf.upfronthosting.co.za>


New submission from Ned Deily <nad at acm.org>:

The copyright dates in the plists for the various app bundles installed by the OS X installer need updating.  They are visible with the Finder's Get Info command.  (patch for py3k follows, backport for 2.7 and 3.1 needed)

----------
assignee: ronaldoussoren
components: Build, Macintosh
messages: 125542
nosy: georg.brandl, ned.deily, ronaldoussoren
priority: high
severity: normal
status: open
title: OS X installer: update copyright dates in app bundles
versions: Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10844>
_______________________________________

From report at bugs.python.org  Thu Jan  6 11:02:25 2011
From: report at bugs.python.org (Etienne Robillard)
Date: Thu, 06 Jan 2011 10:02:25 +0000
Subject: [issue4953] cgi module cannot handle POST with multipart/form-data
	in	3.0
In-Reply-To: <1294306110.0.0.541859342242.issue4953@psf.upfronthosting.co.za>
Message-ID: <4D2595E9.6000101@gthcfoundation.org>


Etienne Robillard <erob at gthcfoundation.org> added the comment:

yes, lets not complexify anymore please...
> Because the HTTP protocol is binary, only selected data, either explicitly or implicitly (by standard definition) should be decoded, using the appropriate encoding.  FieldStorage should be able to (1) read a binary stream (2) do the appropriate decoding operations (3) return the data as bytes or str as appropriate.
>
> Right now, I'm mostly interested in the fact that it doesn't do (1), so it is hard to know what it does for (2) or (3) because it gets an error first.
>
> ----------
>   
according to rfc2616...

"Transfer-codings are analogous to the Content-Transfer-Encoding values
of MIME [7], which were designed to enable safe transport of binary data
over a 7-bit transport service. However, safe transport has a different
focus for an 8bit-clean transfer protocol. In HTTP, the only unsafe
characteristic of message-bodies is the difficulty in determining the
exact body length (section 7.2.2
<http://www.w3.org/Protocols/rfc2616/rfc2616-sec7.html#sec7.2.2>), or
the desire to encrypt data over a shared transport."

I may have not fully understood that part. Is "chunked" encoding what's
being used in MIME to allow
large file uploads and properly handle multipart POST requests?

Thanks,

----------
Added file: http://bugs.python.org/file20288/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4953>
_______________________________________
-------------- next part --------------
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
  <title></title>
</head>
<body text="#000000" bgcolor="#ffffff">
On 06/01/11 04:28 AM, Glenn Linderman wrote:
<blockquote
 cite="mid:1294306110.0.0.541859342242.issue4953 at psf.upfronthosting.co.za"
 type="cite">
  <pre wrap="">
Glenn Linderman <a class="moz-txt-link-rfc2396E" href="mailto:v+python at g.nevcal.com">&lt;v+python at g.nevcal.com&gt;</a> added the comment:

Etienne, I'm not sure what you are _really_ referring to by HTTP_TRANSFER_ENCODING.  There is a TRANSFER_ENCODING defined by HTTP but it is completely orthogonal to character encoding issues.  There is a CONTENT_ENCODING defined which is a character encoding, but that is either explicit in the MIME data, or assumed to be either ASCII or UTF-8, in certain form data contexts.
  </pre>
</blockquote>
yes, lets not complexify anymore please... <br>
<blockquote
 cite="mid:1294306110.0.0.541859342242.issue4953 at psf.upfronthosting.co.za"
 type="cite">
  <pre wrap="">Because the HTTP protocol is binary, only selected data, either explicitly or implicitly (by standard definition) should be decoded, using the appropriate encoding.  FieldStorage should be able to (1) read a binary stream (2) do the appropriate decoding operations (3) return the data as bytes or str as appropriate.

Right now, I'm mostly interested in the fact that it doesn't do (1), so it is hard to know what it does for (2) or (3) because it gets an error first.

----------
  </pre>
</blockquote>
according to rfc2616...<br>
<br>
<span class="Apple-style-span"
 style="border-collapse: separate; color: rgb(0, 0, 0); font-family: 'Times New Roman'; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; font-size: medium;">"Transfer-codings
are analogous to the Content-Transfer-Encoding values of MIME [7],
which were designed to enable safe transport of binary data over a
7-bit transport service. However, safe transport has a different focus
for an 8bit-clean transfer protocol. In HTTP, the only unsafe
characteristic of message-bodies is the difficulty in determining the
exact body length (section<span class="Apple-converted-space">??</span><a
 rel="xref"
 href="http://www.w3.org/Protocols/rfc2616/rfc2616-sec7.html#sec7.2.2">7.2.2</a>),
or the desire to encrypt data over a shared transport.</span>"<br>
<br>
I may have not fully understood that part. Is "chunked" encoding what's
being used in MIME to allow<br>
large file uploads and properly handle multipart POST requests?<br>
<br>
Thanks,<br>
<pre class="moz-signature" cols="72">-- 
Etienne Robillard

Company: Green Tea Hackers Club
Occupation: Software Developer
E-mail:     <a class="moz-txt-link-abbreviated" href="mailto:erob at gthcfoundation.org">erob at gthcfoundation.org</a>
Work phone: +1 514-962-7703
Website (Company):  <a class="moz-txt-link-freetext" href="https://www.gthc.org/">https://www.gthc.org/</a>
Website (Blog):     <a class="moz-txt-link-freetext" href="https://www.gthc.org/blog/">https://www.gthc.org/blog/</a>
PGP public key fingerprint:    F2A9 32EA 8E7C 460F 1728  A1A7 649C 7F17 A086 DDEC

During times of universal deceit, telling the truth becomes a revolutionary act. -- George Orwell 
</pre>
</body>
</html>

From report at bugs.python.org  Thu Jan  6 11:03:05 2011
From: report at bugs.python.org (Ned Deily)
Date: Thu, 06 Jan 2011 10:03:05 +0000
Subject: [issue10844] OS X installer: update copyright dates in app bundles
In-Reply-To: <1294307725.56.0.795948655729.issue10844@psf.upfronthosting.co.za>
Message-ID: <1294308185.48.0.970355028521.issue10844@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Patch for py3k. (Patches needed for 31 and 27.)

----------
keywords: +patch
stage:  -> patch review
Added file: http://bugs.python.org/file20289/issue10844-py3k.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10844>
_______________________________________

From report at bugs.python.org  Thu Jan  6 11:05:37 2011
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 06 Jan 2011 10:05:37 +0000
Subject: [issue10844] OS X installer: update copyright dates in app bundles
In-Reply-To: <1294307725.56.0.795948655729.issue10844@psf.upfronthosting.co.za>
Message-ID: <1294308337.93.0.804287333799.issue10844@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

This looks safe enough for me to apply. Fixed in r87791.

----------
resolution:  -> fixed
stage: patch review -> 
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10844>
_______________________________________

From report at bugs.python.org  Thu Jan  6 11:11:27 2011
From: report at bugs.python.org (Glenn Linderman)
Date: Thu, 06 Jan 2011 10:11:27 +0000
Subject: [issue4953] cgi module cannot handle POST with multipart/form-data
	in	3.0
In-Reply-To: <1232010166.79.0.972664060868.issue4953@psf.upfronthosting.co.za>
Message-ID: <1294308687.23.0.90045196161.issue4953@psf.upfronthosting.co.za>


Glenn Linderman <v+python at g.nevcal.com> added the comment:

Etienne said:
yes, lets not complexify anymore please...

Albert Einstein said:
Things should be as simple as possible, but no simpler.

I say:
My "learning" of HTTP predates "chunked".  I've mostly heard of it being used in downloads rather than uploads, but I'm not sure if it pertains to uploads or not.  Since all the data transfer is effectively chunked by TCP/IP into packets, I'm not clear on what the benefit is, but I am pretty sure it is off-topic for this bug, at least until FieldStorage works at all on 3.x, like for small pieces of data.

I meant to say in my preceding response, that the multiple encodings that may be found in an HTTP stream, make it inappropriate to assign an encoding to the file through which the HTTP data streams... that explicit decode calls by FieldStorage should take place on appropriate chunks only.  I almost got there, so maybe you picked it up.  But I didn't quite say it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4953>
_______________________________________

From report at bugs.python.org  Thu Jan  6 11:26:21 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 06 Jan 2011 10:26:21 +0000
Subject: [issue10845] test_multiprocessing failure under Windows
In-Reply-To: <1294309581.41.0.731804987161.issue10845@psf.upfronthosting.co.za>
Message-ID: <1294309581.41.0.731804987161.issue10845@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

This is under a Windows 7 VM. I don't understand what the assertion means:

Z:\>__svn__\PCbuild\amd64\python_d.exe -m test -v test_multiprocessing
== CPython 3.2b2+ (py3k, Jan 6 2011, 10:56:48) [MSC v.1500 64 bit (AMD64)]
==   Windows-7-6.1.7600 little-endian
==   Z:\__svn__\build\test_python_1360
Testing with flags: sys.flags(debug=0, division_warning=0, inspect=0, interactiv
e=0, optimize=0, dont_write_bytecode=0, no_user_site=0, no_site=0, ignore_enviro
nment=0, verbose=0, bytes_warning=0, quiet=0)
[1/1] test_multiprocessing
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "Z:\__svn__\lib\multiprocessing\forking.py", line 369, in main
    prepare(preparation_data)
  File "Z:\__svn__\lib\multiprocessing\forking.py", line 477, in prepare
    assert main_name not in sys.modules, main_name
AssertionError: __main__
[49434 refs]
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "Z:\__svn__\lib\multiprocessing\forking.py", line 369, in main
    prepare(preparation_data)
  File "Z:\__svn__\lib\multiprocessing\forking.py", line 477, in prepare
    assert main_name not in sys.modules, main_name
AssertionError: __main__
[49434 refs]
test test_multiprocessing crashed -- <class 'EOFError'>:
Traceback (most recent call last):
  File "Z:\__svn__\lib\test\regrtest.py", line 969, in runtest_inner
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "Z:\__svn__\lib\multiprocessing\forking.py", line 369, in main
    indirect_test()
  File "Z:\__svn__\lib\test\test_multiprocessing.py", line 2102, in test_main
    prepare(preparation_data)
  File "Z:\__svn__\lib\multiprocessing\forking.py", line 477, in prepare
    assert main_name not in sys.modules, main_name
AssertionError: __main__
    ManagerMixin.manager.start()
  File "/home/antoine/py3k/__svn__/Lib/multiprocessing/managers.py", line 531, i
n start
[49434 refs]
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "Z:\__svn__\lib\multiprocessing\forking.py", line 369, in main
    self._address = reader.recv()
EOFError
Traceback (most recent call last):
  File "<string>", line 1, in <module>
    prepare(preparation_data)
  File "Z:\__svn__\lib\multiprocessing\forking.py", line 477, in prepare
  File "Z:\__svn__\lib\multiprocessing\forking.py", line 369, in main
1 test failed:
    assert main_name not in sys.modules, main_name
AssertionError: __main__
    prepare(preparation_data)
  File "Z:\__svn__\lib\multiprocessing\forking.py", line 477, in prepare
[49434 refs]
    assert main_name not in sys.modules, main_name
AssertionError: __main__
[49434 refs]
    test_multiprocessing
Traceback (most recent call last):
  File "Z:\__svn__\lib\test\support.py", line 468, in temp_cwd
    yield os.getcwd()
  File "Z:\__svn__\lib\test\__main__.py", line 13, in <module>
    regrtest.main()
  File "Z:\__svn__\lib\test\regrtest.py", line 708, in main
    sys.exit(len(bad) > 0 or interrupted)
SystemExit: True

----------
components: Library (Lib), Tests
messages: 125547
nosy: asksol, jnoller, pitrou
priority: normal
severity: normal
status: open
title: test_multiprocessing failure under Windows
type: crash
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10845>
_______________________________________

From report at bugs.python.org  Thu Jan  6 11:28:05 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 06 Jan 2011 10:28:05 +0000
Subject: [issue10845] test_multiprocessing failure under Windows
In-Reply-To: <1294309581.41.0.731804987161.issue10845@psf.upfronthosting.co.za>
Message-ID: <1294309685.45.0.315751669599.issue10845@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +brian.curtin

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10845>
_______________________________________

From report at bugs.python.org  Thu Jan  6 11:35:07 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 06 Jan 2011 10:35:07 +0000
Subject: [issue10845] test_multiprocessing failure under Windows
In-Reply-To: <1294309581.41.0.731804987161.issue10845@psf.upfronthosting.co.za>
Message-ID: <1294310107.76.0.218791107522.issue10845@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Actually, it only happens if I use "-m test". If I use "-m test.regrtest" or "Lib/test/regrtest.py" instead, it works fine.

----------
nosy: +michael.foord, ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10845>
_______________________________________

From report at bugs.python.org  Thu Jan  6 11:36:16 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 06 Jan 2011 10:36:16 +0000
Subject: [issue10845] test_multiprocessing failure under Windows
In-Reply-To: <1294309581.41.0.731804987161.issue10845@psf.upfronthosting.co.za>
Message-ID: <1294310176.1.0.585779355083.issue10845@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

(I guess this means that multiprocessing under Windows is not compatible with execution of a package through a __main__.py file...)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10845>
_______________________________________

From report at bugs.python.org  Thu Jan  6 11:36:24 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 06 Jan 2011 10:36:24 +0000
Subject: [issue10841] binary stdio
In-Reply-To: <1294307045.25.0.679082146508.issue10841@psf.upfronthosting.co.za>
Message-ID: <1294310179.3716.64.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> So -u does do 2/3 of what my windows_binary() does :)  Should I switch
> my test case to use stderr to demonstrate that it doesn't help with
> that?

Well, judging by the history of this code, selectively putting -u in
binary mode may be justified by the fact that Python 2 relied on the C
runtime's stdio FILE pointers, and therefore on the C runtime's own
newline translation. I would say that Python 3 should put all stdio fds
in binary mode, regardless of the -u switch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10841>
_______________________________________

From report at bugs.python.org  Thu Jan  6 11:42:52 2011
From: report at bugs.python.org (Ned Deily)
Date: Thu, 06 Jan 2011 10:42:52 +0000
Subject: [issue8746] os.chflags() and os.lchflags() are not built when they
	should be be
In-Reply-To: <1274173521.53.0.771933425772.issue8746@psf.upfronthosting.co.za>
Message-ID: <1294310572.8.0.202699990557.issue8746@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Ping - Garrett, any progress on updating the tests?  With dispatch, this could still make it into 3.2.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8746>
_______________________________________

From report at bugs.python.org  Thu Jan  6 11:48:57 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 06 Jan 2011 10:48:57 +0000
Subject: [issue10845] test_multiprocessing failure under Windows
In-Reply-To: <1294309581.41.0.731804987161.issue10845@psf.upfronthosting.co.za>
Message-ID: <1294310937.88.0.0762798204379.issue10845@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/issue10845>
_______________________________________

From report at bugs.python.org  Thu Jan  6 12:13:05 2011
From: report at bugs.python.org (Peter Kleiweg)
Date: Thu, 06 Jan 2011 11:13:05 +0000
Subject: [issue10841] binary stdio
In-Reply-To: <1294279917.2.0.685442041198.issue10841@psf.upfronthosting.co.za>
Message-ID: <1294312385.1.0.800154495662.issue10841@psf.upfronthosting.co.za>


Changes by Peter Kleiweg <pkleiweg at xs4all.nl>:


----------
nosy: +pebbe

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10841>
_______________________________________

From report at bugs.python.org  Thu Jan  6 12:15:57 2011
From: report at bugs.python.org (Glenn Linderman)
Date: Thu, 06 Jan 2011 11:15:57 +0000
Subject: [issue10841] binary stdio
In-Reply-To: <1294279917.2.0.685442041198.issue10841@psf.upfronthosting.co.za>
Message-ID: <1294312557.32.0.444504479458.issue10841@psf.upfronthosting.co.za>


Glenn Linderman <v+python at g.nevcal.com> added the comment:

Makes sense to me.  Still should document the open file parameter when passed an fd, and either tell the user that it should be O_BINARY, or that it will be O_BINARYd for them, whichever technique is chosen.  But having two newline techniques is bad, and if Python thinks it is tracking the file pointer, but Windows is doing newline translation for it, then it isn't likely tracking it correctly for random access IO.  So I think the choice should be that any fd passed in to open on Windows should get O_BINARYd immediately.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10841>
_______________________________________

From report at bugs.python.org  Thu Jan  6 13:25:22 2011
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Gaudreault?=)
Date: Thu, 06 Jan 2011 12:25:22 +0000
Subject: [issue10835] sys.executable default and altinstall
In-Reply-To: <1294231894.7.0.0581440878919.issue10835@psf.upfronthosting.co.za>
Message-ID: <1294316722.12.0.862688560848.issue10835@psf.upfronthosting.co.za>


Changes by St?phane Gaudreault <stephane at archlinux.org>:


----------
nosy: +stephane

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10835>
_______________________________________

From report at bugs.python.org  Thu Jan  6 14:03:32 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 06 Jan 2011 13:03:32 +0000
Subject: [issue10785] parser: store the filename as an unicode object
In-Reply-To: <1293504022.51.0.668746175929.issue10785@psf.upfronthosting.co.za>
Message-ID: <1294319012.38.0.974964864776.issue10785@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10785>
_______________________________________

From report at bugs.python.org  Thu Jan  6 14:03:45 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 06 Jan 2011 13:03:45 +0000
Subject: [issue10841] binary stdio
In-Reply-To: <1294279917.2.0.685442041198.issue10841@psf.upfronthosting.co.za>
Message-ID: <1294319025.43.0.338606661166.issue10841@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Attached stdio_binary.patch always set stdin, stdout and stderr in binary mode on Windows (and not only with -u command line flag). I added the following comment, is it correct?

    /* don't translate newlines */

----------
keywords: +patch
nosy: +haypo
Added file: http://bugs.python.org/file20290/stdio_binary.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10841>
_______________________________________

From report at bugs.python.org  Thu Jan  6 15:30:58 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 06 Jan 2011 14:30:58 +0000
Subject: [issue10841] binary stdio
In-Reply-To: <1294279917.2.0.685442041198.issue10841@psf.upfronthosting.co.za>
Message-ID: <1294324258.11.0.128391229187.issue10841@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Using my patch, the interpreter fails with a SyntaxError on \r: attached patch translates newlines to avoid this problem.

----------
Added file: http://bugs.python.org/file20291/parser_translate_newline.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10841>
_______________________________________

From report at bugs.python.org  Thu Jan  6 15:33:28 2011
From: report at bugs.python.org (Ross Lagerwall)
Date: Thu, 06 Jan 2011 14:33:28 +0000
Subject: [issue10812] Add some posix functions
In-Reply-To: <1294058752.01.0.285856626146.issue10812@psf.upfronthosting.co.za>
Message-ID: <1294324408.87.0.519557321036.issue10812@psf.upfronthosting.co.za>


Ross Lagerwall <rosslagerwall at gmail.com> added the comment:

This new patch reuses iov allocation code between readv & writev.
It reuses code between exec, execve & fexecve.
It reuses code for parsing off_t types.

I've tried where possible to reuse code but I think though that the code seems pretty standard for the posix module. Each function pretty much parses args, calls posix function, checks for error and returns result.

----------
Added file: http://bugs.python.org/file20292/10812_v3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10812>
_______________________________________

From report at bugs.python.org  Thu Jan  6 15:46:04 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 06 Jan 2011 14:46:04 +0000
Subject: [issue4953] cgi module cannot handle POST with multipart/form-data
	in	3.0
In-Reply-To: <1232010166.79.0.972664060868.issue4953@psf.upfronthosting.co.za>
Message-ID: <1294325164.9.0.579217171405.issue4953@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

I tried full_source_and_error.zip on Windows and it failed. With stdio_binary.patch (attached to #10841), it works but I get an unicode file instead of a binary file. With stdio_binary.patch+cgi_plus_tests.diff it works as expected: I get a binary file (bytes).

But I don't understand why I have to pass an text stream (sys.stdin) instead of a binary stream (sys.stdin.buffer) to the FieldStorage constructor.

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4953>
_______________________________________

From report at bugs.python.org  Thu Jan  6 16:39:25 2011
From: report at bugs.python.org (R. David Murray)
Date: Thu, 06 Jan 2011 15:39:25 +0000
Subject: [issue4953] cgi module cannot handle POST with multipart/form-data
	in	3.0
In-Reply-To: <1232010166.79.0.972664060868.issue4953@psf.upfronthosting.co.za>
Message-ID: <1294328365.87.0.0827562056057.issue4953@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Haypo: I believe that the consensus we've come to is that you shouldn't have to.  FieldStorage should take a binary stream.  So should cgi.parse.  If defaulting to sys.stdin, then if stdin is text, they should turn it in to a binary stream right at the start.

None of which is true right now, and this presents some backward compatibility problems.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4953>
_______________________________________

From report at bugs.python.org  Thu Jan  6 16:40:34 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 06 Jan 2011 15:40:34 +0000
Subject: [issue4953] cgi module cannot handle POST with multipart/form-data
	in	3.0
In-Reply-To: <1294328365.87.0.0827562056057.issue4953@psf.upfronthosting.co.za>
Message-ID: <1294328430.6006.0.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Haypo: I believe that the consensus we've come to is that you
> shouldn't have to.  FieldStorage should take a binary stream.  So
> should cgi.parse.  If defaulting to sys.stdin, then if stdin is text,
> they should turn it in to a binary stream right at the start.

Is mutating sys.stdin really a good idea? Or am I misunderstand your
proposal?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4953>
_______________________________________

From report at bugs.python.org  Thu Jan  6 16:46:41 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 06 Jan 2011 15:46:41 +0000
Subject: [issue2973] _ssl compiler warnings
In-Reply-To: <1211822122.76.0.619319801709.issue2973@psf.upfronthosting.co.za>
Message-ID: <1294328801.45.0.149311843541.issue2973@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I don't get any warnings with gcc -Wall and OpenSSL 1.0.x.

----------
nosy: +pitrou
resolution:  -> out of date
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2973>
_______________________________________

From report at bugs.python.org  Thu Jan  6 16:49:19 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 06 Jan 2011 15:49:19 +0000
Subject: [issue968063] Add fileinput.islastline()
Message-ID: <1294328959.17.0.820648879001.issue968063@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Anyone wants to produce an up-to-date patch for py3k?

----------
keywords: +easy -patch
nosy: +pitrou
stage:  -> needs patch
type:  -> feature request
versions: +Python 3.3 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue968063>
_______________________________________

From report at bugs.python.org  Thu Jan  6 16:52:21 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 06 Jan 2011 15:52:21 +0000
Subject: [issue10841] binary stdio
In-Reply-To: <1294279917.2.0.685442041198.issue10841@psf.upfronthosting.co.za>
Message-ID: <1294329141.06.0.918576257427.issue10841@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10841>
_______________________________________

From report at bugs.python.org  Thu Jan  6 16:53:56 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 06 Jan 2011 15:53:56 +0000
Subject: [issue3163] module struct support for ssize_t and size_t
In-Reply-To: <1214071551.33.0.650558563727.issue3163@psf.upfronthosting.co.za>
Message-ID: <1294329236.15.0.422344925231.issue3163@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
versions: +Python 3.3 -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3163>
_______________________________________

From report at bugs.python.org  Thu Jan  6 16:54:59 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 06 Jan 2011 15:54:59 +0000
Subject: [issue1158490] locale fails if LANGUAGE has multiple locales
Message-ID: <1294329299.19.0.276753648341.issue1158490@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +haypo
stage: unit test needed -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1158490>
_______________________________________

From report at bugs.python.org  Thu Jan  6 17:02:26 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 06 Jan 2011 16:02:26 +0000
Subject: [issue10841] binary stdio
In-Reply-To: <1294279917.2.0.685442041198.issue10841@psf.upfronthosting.co.za>
Message-ID: <1294329746.57.0.257380733798.issue10841@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> Using my patch, the interpreter fails with a SyntaxError on \r:
> attached patch translates newlines to avoid this problem.

See also issue #4628.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10841>
_______________________________________

From report at bugs.python.org  Thu Jan  6 17:24:25 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 06 Jan 2011 16:24:25 +0000
Subject: [issue1158490] locale fails if LANGUAGE has multiple locales
Message-ID: <1294331065.76.0.263162734007.issue1158490@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

The initial problem (":" in the LANGUAGE variable) was fixed in an independent (?) issue (#1166938) by r39572.

If I understood correctly, locale.getdefaultlocale() is supposed to give the locale settings that we will be active after the first call to locale.setlocale(locale.LC_ALL, ''). In this case, LANGUAGE should be ignored because it has no effect on the active locale. The variable is specific to the gettext library, it is not used by the locale machinery.

About remove-support-for-LANGUAGE--in-locale.patch: you should also update the documentation.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1158490>
_______________________________________

From report at bugs.python.org  Thu Jan  6 17:26:27 2011
From: report at bugs.python.org (R. David Murray)
Date: Thu, 06 Jan 2011 16:26:27 +0000
Subject: [issue4953] cgi module cannot handle POST with multipart/form-data
	in	3.0
In-Reply-To: <1232010166.79.0.972664060868.issue4953@psf.upfronthosting.co.za>
Message-ID: <1294331187.34.0.301393903939.issue4953@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Ah, you are right.  That makes the backward compatibility issue a lot worse :(

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4953>
_______________________________________

From report at bugs.python.org  Thu Jan  6 17:40:52 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 06 Jan 2011 16:40:52 +0000
Subject: [issue6269] threading documentation makes no mention of the GIL
In-Reply-To: <1244752636.53.0.230892071938.issue6269@psf.upfronthosting.co.za>
Message-ID: <1294332052.54.0.22079259565.issue6269@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Ok, done in r87792, r87793 and r87794, thank you.

----------
nosy: +pitrou
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6269>
_______________________________________

From report at bugs.python.org  Thu Jan  6 17:42:23 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 06 Jan 2011 16:42:23 +0000
Subject: [issue9909] request for calendar.dayofyear() function
In-Reply-To: <1285039663.27.0.59327234025.issue9909@psf.upfronthosting.co.za>
Message-ID: <1294332143.17.0.798951417673.issue9909@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +belopolsky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9909>
_______________________________________

From report at bugs.python.org  Thu Jan  6 17:47:12 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 06 Jan 2011 16:47:12 +0000
Subject: [issue4681] mmap offset should be off_t instead of ssize_t,
	and size calculation needs corrected
In-Reply-To: <1229503209.88.0.900633557014.issue4681@psf.upfronthosting.co.za>
Message-ID: <1294332432.55.0.392667949131.issue4681@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
stage:  -> patch review
versions: +Python 3.2, Python 3.3 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4681>
_______________________________________

From report at bugs.python.org  Thu Jan  6 17:48:35 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 06 Jan 2011 16:48:35 +0000
Subject: [issue5369] __ppc__ macro checking is incorrect
In-Reply-To: <1235589968.39.0.392818865305.issue5369@psf.upfronthosting.co.za>
Message-ID: <1294332515.01.0.566017829891.issue5369@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
resolution:  -> duplicate
status: open -> closed
superseder:  -> Wrong powerpc define in Python/ceval.c

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5369>
_______________________________________

From report at bugs.python.org  Thu Jan  6 17:49:24 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 06 Jan 2011 16:49:24 +0000
Subject: [issue10655] Wrong powerpc define in Python/ceval.c
In-Reply-To: <1291845027.1.0.195055674772.issue10655@psf.upfronthosting.co.za>
Message-ID: <1294332564.84.0.00184619294596.issue10655@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Issue5369 is a duplicate with the same patch. Dave, can you apply?

----------
assignee:  -> dmalcolm

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10655>
_______________________________________

From report at bugs.python.org  Thu Jan  6 17:50:03 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 06 Jan 2011 16:50:03 +0000
Subject: [issue1521196] smtplib login fails with aol smtp server
Message-ID: <1294332603.29.0.351781732446.issue1521196@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1521196>
_______________________________________

From report at bugs.python.org  Thu Jan  6 17:53:54 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 06 Jan 2011 16:53:54 +0000
Subject: [issue3466] urllib2 should support HTTPS connections with client keys
In-Reply-To: <1217343215.63.0.226404809794.issue3466@psf.upfronthosting.co.za>
Message-ID: <1294332834.54.0.352710542682.issue3466@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

In 3.2, you can instantiate a HTTPSHandler with a custom SSLContext, on which you can load your client cert:
http://docs.python.org/dev/library/urllib.request.html#urllib.request.HTTPSHandler
http://docs.python.org/dev/library/ssl.html#ssl.SSLContext.load_cert_chain

----------
nosy: +pitrou
resolution:  -> out of date
stage: unit test needed -> 
status: open -> closed
versions: +Python 3.2 -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3466>
_______________________________________

From report at bugs.python.org  Thu Jan  6 17:59:33 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 06 Jan 2011 16:59:33 +0000
Subject: [issue6284] C/API PyErr_AsUnicode()
In-Reply-To: <1244999019.35.0.083174578591.issue6284@psf.upfronthosting.co.za>
Message-ID: <1294333173.65.0.785970828185.issue6284@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +haypo
stage:  -> patch review
type:  -> feature request
versions: +Python 3.3 -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6284>
_______________________________________

From report at bugs.python.org  Thu Jan  6 18:03:44 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 06 Jan 2011 17:03:44 +0000
Subject: [issue1697943] msgfmt cannot cope with BOM
Message-ID: <1294333424.49.0.675512043124.issue1697943@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +haypo
stage: unit test needed -> needs patch
versions: +Python 2.7, Python 3.2, Python 3.3 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1697943>
_______________________________________

From report at bugs.python.org  Thu Jan  6 18:04:12 2011
From: report at bugs.python.org (Dave Malcolm)
Date: Thu, 06 Jan 2011 17:04:12 +0000
Subject: [issue10655] Wrong powerpc define in Python/ceval.c
In-Reply-To: <1291845027.1.0.195055674772.issue10655@psf.upfronthosting.co.za>
Message-ID: <1294333452.56.0.922583822346.issue10655@psf.upfronthosting.co.za>


Dave Malcolm <dmalcolm at redhat.com> added the comment:

Adrian verified in the downstream bug tracker that this fixed the build for him (and the logs show it successfully ran the test suite), so I committed my patch to py3k as r87796.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10655>
_______________________________________

From report at bugs.python.org  Thu Jan  6 18:11:25 2011
From: report at bugs.python.org (anatoly techtonik)
Date: Thu, 06 Jan 2011 17:11:25 +0000
Subject: [issue8927] Handle version conflicts in dependencies
In-Reply-To: <1275853060.23.0.0333552205181.issue8927@psf.upfronthosting.co.za>
Message-ID: <1294333885.31.0.995649789967.issue8927@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/issue8927>
_______________________________________

From report at bugs.python.org  Thu Jan  6 18:15:46 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 06 Jan 2011 17:15:46 +0000
Subject: [issue9909] request for calendar.dayofyear() function
In-Reply-To: <1285039663.27.0.59327234025.issue9909@psf.upfronthosting.co.za>
Message-ID: <1294334146.94.0.284480265394.issue9909@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

This is yet another request for functionality that can be implemented as a simple expression using datetime arithmetics.  Also, issue #9864 is not a compelling use case because "the parsedate() function now returns a datetime object."   See msg117496.

----------
assignee:  -> belopolsky
resolution:  -> rejected
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9909>
_______________________________________

From report at bugs.python.org  Thu Jan  6 18:19:43 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 06 Jan 2011 17:19:43 +0000
Subject: [issue3839] wsgi.simple_server resets 'Content-Length' header on
	empty content even if app defined it.
In-Reply-To: <1221156514.39.0.145827705782.issue3839@psf.upfronthosting.co.za>
Message-ID: <1294334383.25.0.968087431215.issue3839@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Fixed with tests in r87797 (3.2), r87798 (3.1) and r87799 (2.7). Thank you!

----------
nosy: +pitrou -BreamoreBoy
resolution:  -> fixed
stage: unit test needed -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3839>
_______________________________________

From report at bugs.python.org  Thu Jan  6 18:33:05 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 06 Jan 2011 17:33:05 +0000
Subject: [issue1615158] POSIX capabilities support
Message-ID: <1294335185.35.0.411683606682.issue1615158@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +pitrou, rosslagerwall

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1615158>
_______________________________________

From report at bugs.python.org  Thu Jan  6 18:33:14 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 06 Jan 2011 17:33:14 +0000
Subject: [issue4953] cgi module cannot handle POST with multipart/form-data
	in	3.0
In-Reply-To: <1232010166.79.0.972664060868.issue4953@psf.upfronthosting.co.za>
Message-ID: <1294335194.51.0.00892186187554.issue4953@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

About the backward compatibility: does anyone use CGI with Python3? It looks like the module is broken (at least to upload files). If not, it's maybe better to fix it today than having to maintain a "broken" API.

Python 3.2 has many incompatibles changes with Python 3.1 to fix bugs. Some examples:
 - No more sys.setfilesystemencoding() function
 - ctypes and struct doesn't convert implicitly str to bytes
 - mbcs encoding raise an error if the error handler is not supported
 - etc.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4953>
_______________________________________

From report at bugs.python.org  Thu Jan  6 18:34:22 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 06 Jan 2011 17:34:22 +0000
Subject: [issue6064] Add "daemon" argument to threading.Thread constructor
In-Reply-To: <1242760441.53.0.863717257975.issue6064@psf.upfronthosting.co.za>
Message-ID: <1294335262.86.0.397418213784.issue6064@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
assignee: jnoller -> 
stage:  -> patch review
type: behavior -> feature request
versions: +Python 3.3 -Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6064>
_______________________________________

From report at bugs.python.org  Thu Jan  6 18:36:35 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 06 Jan 2011 17:36:35 +0000
Subject: [issue8731] BeOS for 2.7 - add to unsupported
In-Reply-To: <1274012961.91.0.790344514824.issue8731@psf.upfronthosting.co.za>
Message-ID: <1294335395.74.0.0689868076298.issue8731@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

We should do a bit sweep over unsupported platforms in 3.3.

----------
nosy: +pitrou
resolution:  -> out of date
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8731>
_______________________________________

From report at bugs.python.org  Thu Jan  6 18:40:00 2011
From: report at bugs.python.org (Dave Malcolm)
Date: Thu, 06 Jan 2011 17:40:00 +0000
Subject: [issue10655] Wrong powerpc define in Python/ceval.c
In-Reply-To: <1291845027.1.0.195055674772.issue10655@psf.upfronthosting.co.za>
Message-ID: <1294335600.67.0.100395071987.issue10655@psf.upfronthosting.co.za>


Dave Malcolm <dmalcolm at redhat.com> added the comment:

Merged back to 3.1 as r87800 and to 2.7-maint as r87801

----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10655>
_______________________________________

From report at bugs.python.org  Thu Jan  6 18:42:42 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 06 Jan 2011 17:42:42 +0000
Subject: [issue4346] PyObject_CallMethod changes the exception message already
	set by PyObject_GetAttr
In-Reply-To: <1227017720.01.0.112991590053.issue4346@psf.upfronthosting.co.za>
Message-ID: <1294335762.03.0.241108856526.issue4346@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +benjamin.peterson -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4346>
_______________________________________

From report at bugs.python.org  Thu Jan  6 18:48:41 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 06 Jan 2011 17:48:41 +0000
Subject: [issue9373] pulldom has low code coverage
In-Reply-To: <1279976804.16.0.216063093383.issue9373@psf.upfronthosting.co.za>
Message-ID: <1294336121.98.0.146111234375.issue9373@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/issue9373>
_______________________________________

From report at bugs.python.org  Thu Jan  6 18:57:39 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 06 Jan 2011 17:57:39 +0000
Subject: [issue10833] Replace %.100s by %s in PyErr_Format(): the arbitrary
	limit of 500 bytes is outdated
In-Reply-To: <1294196554.94.0.785505480291.issue10833@psf.upfronthosting.co.za>
Message-ID: <1294336659.15.0.537205921814.issue10833@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

I agree with Eric.  Limiting field width when formatting error messages is a good safety measure.  It is not only the amount of garbage that can be spitted in error logs, if garbage is not null-terminated, you may get a SEGV instead of a somewhat meaningful error message.

----------
nosy: +belopolsky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10833>
_______________________________________

From report at bugs.python.org  Thu Jan  6 19:04:08 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 06 Jan 2011 18:04:08 +0000
Subject: [issue10833] Replace %.100s by %s in PyErr_Format(): the arbitrary
	limit of 500 bytes is outdated
In-Reply-To: <1294196554.94.0.785505480291.issue10833@psf.upfronthosting.co.za>
Message-ID: <1294337048.36.0.367464037254.issue10833@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

> /* Caller is responsible for limiting the format */

Note that it is a good idea to avoid memory allocation during exception processing.  Think of out of memory errors: how would you report those if you need more memory to format the error message than the failed operation?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10833>
_______________________________________

From report at bugs.python.org  Thu Jan  6 19:15:59 2011
From: report at bugs.python.org (Eric Smith)
Date: Thu, 06 Jan 2011 18:15:59 +0000
Subject: [issue3173] external strftime for Python?
In-Reply-To: <1214189093.82.0.548435251403.issue3173@psf.upfronthosting.co.za>
Message-ID: <1294337759.25.0.856162597908.issue3173@psf.upfronthosting.co.za>


Changes by Eric Smith <eric at trueblade.com>:


----------
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3173>
_______________________________________

From report at bugs.python.org  Thu Jan  6 19:18:29 2011
From: report at bugs.python.org (Guido van Rossum)
Date: Thu, 06 Jan 2011 18:18:29 +0000
Subject: [issue10841] binary stdio
In-Reply-To: <1294279917.2.0.685442041198.issue10841@psf.upfronthosting.co.za>
Message-ID: <1294337909.04.0.256502808285.issue10841@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

Not sure why I've been added, but I agree that all fds should always be in binary mode in Python 3.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10841>
_______________________________________

From report at bugs.python.org  Thu Jan  6 19:29:36 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 06 Jan 2011 18:29:36 +0000
Subject: [issue4346] PyObject_CallMethod changes the exception message already
	set by PyObject_GetAttr
In-Reply-To: <1227017720.01.0.112991590053.issue4346@psf.upfronthosting.co.za>
Message-ID: <1294338576.12.0.837145903978.issue4346@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

We should probably just kill the LBYL.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4346>
_______________________________________

From report at bugs.python.org  Thu Jan  6 19:31:34 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 06 Jan 2011 18:31:34 +0000
Subject: [issue7858] os.utime(file, (0, 0, )) fails on on vfat,
	but doesn't fail immediately
In-Reply-To: <1265386059.32.0.591513195746.issue7858@psf.upfronthosting.co.za>
Message-ID: <1294338694.67.0.972481863569.issue7858@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Committed in r87802 (3.2), r87803 (3.1) and r87804 (2.7). Will watch the buildbots.

----------
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> pending
versions:  -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7858>
_______________________________________

From report at bugs.python.org  Thu Jan  6 20:00:44 2011
From: report at bugs.python.org (Glenn Linderman)
Date: Thu, 06 Jan 2011 19:00:44 +0000
Subject: [issue10841] binary stdio
In-Reply-To: <1294279917.2.0.685442041198.issue10841@psf.upfronthosting.co.za>
Message-ID: <1294340444.09.0.706889572789.issue10841@psf.upfronthosting.co.za>


Glenn Linderman <v+python at g.nevcal.com> added the comment:

Victor,  Thanks for your interest and patches.

msg125530 points out the location of the code where _all_ fds could be O_BINARYed, when passed in to open.  I think this would make all fds open in binary mode, per Guido's comment... he made exactly the comment I was hoping for, even though I didn't +nosy him... I believe this would catch std* along the way, and render your first patch unnecessary, but your second one would likely still be needed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10841>
_______________________________________

From report at bugs.python.org  Thu Jan  6 20:14:01 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 06 Jan 2011 19:14:01 +0000
Subject: [issue3173] external strftime for Python?
In-Reply-To: <1214189093.82.0.548435251403.issue3173@psf.upfronthosting.co.za>
Message-ID: <1294341241.39.0.0750057487928.issue3173@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> 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

Apparently there is a free implementation for Python out there:

http://babel.edgewall.org/wiki/Documentation/dates.html#pattern-syntax

See also msg107236 on issue #8913.

----------
versions: +Python 3.3 -Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3173>
_______________________________________

From report at bugs.python.org  Thu Jan  6 20:15:47 2011
From: report at bugs.python.org (Vladimir Rutsky)
Date: Thu, 06 Jan 2011 19:15:47 +0000
Subject: [issue10846] typo in threading doc's: "size of the resource size"
In-Reply-To: <1294341347.62.0.125412301486.issue10846@psf.upfronthosting.co.za>
Message-ID: <1294341347.62.0.125412301486.issue10846@psf.upfronthosting.co.za>


New submission from Vladimir Rutsky <altsysrq at gmail.com>:

I think there is a typo in threading documentation:
> In any situation where the size of the resource size is fixed, 
> you should use a bounded semaphore.
 - "size of the resource size", see attached patch for proposed fix.

(Based on official http://svn.python.org/projects/python/branches/py3k/ repository.)

----------
assignee: docs at python
components: Documentation
files: threading_typo_size_of_size.patch
keywords: patch
messages: 125580
nosy: docs at python, rutsky
priority: normal
severity: normal
status: open
title: typo in threading doc's: "size of the resource size"
versions: Python 3.3
Added file: http://bugs.python.org/file20293/threading_typo_size_of_size.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10846>
_______________________________________

From report at bugs.python.org  Thu Jan  6 20:28:25 2011
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 06 Jan 2011 19:28:25 +0000
Subject: [issue10846] typo in threading doc's: "size of the resource size"
In-Reply-To: <1294341347.62.0.125412301486.issue10846@psf.upfronthosting.co.za>
Message-ID: <1294342105.26.0.715954419883.issue10846@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Fixed in r87807.

----------
nosy: +georg.brandl
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10846>
_______________________________________

From report at bugs.python.org  Thu Jan  6 20:35:27 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 06 Jan 2011 19:35:27 +0000
Subject: [issue10181] Problems with Py_buffer management in memoryobject.c
	(and elsewhere?)
In-Reply-To: <1287858158.95.0.0752296181045.issue10181@psf.upfronthosting.co.za>
Message-ID: <1294342527.26.0.868544219248.issue10181@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Removal of the buffer interface from the ABI has been committed as r87805, r87806, r87805, r87808, and r87809.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10181>
_______________________________________

From report at bugs.python.org  Thu Jan  6 20:46:31 2011
From: report at bugs.python.org (Glenn Linderman)
Date: Thu, 06 Jan 2011 19:46:31 +0000
Subject: [issue4953] cgi module cannot handle POST with multipart/form-data
	in	3.0
In-Reply-To: <1232010166.79.0.972664060868.issue4953@psf.upfronthosting.co.za>
Message-ID: <1294343191.98.0.970198841029.issue4953@psf.upfronthosting.co.za>


Glenn Linderman <v+python at g.nevcal.com> added the comment:

We have several, myself included, that can't use CGI under 3.x because it doesn't take a binary stream.

I believe there are several alternatives:
1) Document that CGI needs a binary stream, and expect the user to provide it, either an explicit handle, or by tweaking sys.stdin before calling with a default file stream.
2) Provide a CGI function for tweaking sys.stdin (along with #1)
3) Document that CGI will attempt to convert passed in streams, default or explicit, to binary, if they aren't already, and implement the code to do so.

My choice is #3.  I see CGI as being used only in HTTP environments, where the data stream should be binary anyway.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4953>
_______________________________________

From report at bugs.python.org  Thu Jan  6 20:56:17 2011
From: report at bugs.python.org (Eric Smith)
Date: Thu, 06 Jan 2011 19:56:17 +0000
Subject: [issue3173] external strftime for Python?
In-Reply-To: <1214189093.82.0.548435251403.issue3173@psf.upfronthosting.co.za>
Message-ID: <1294343777.82.0.179553735324.issue3173@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

I think we're stuck with strftime for quite a while, no matter how ugly it is. datetime.__format__ uses it, for example. Although maybe it's possible to write an strftime-format to new-format translator.

If we're going to take this on (re-writing strftime), I think the way to do it is to have it take the locale info as a parameter, and if that parameter is NULL then look up the info in the current locale. It looks like it's still a problem to find all of the info in the locale on all platforms, though. Finding the locale info is no doubt the tricky part, as someone said.

I agree it would be easier to write this from scratch rather than track down the licensing on the existing patch. As it is, there's just not much code there.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3173>
_______________________________________

From report at bugs.python.org  Thu Jan  6 21:07:37 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 06 Jan 2011 20:07:37 +0000
Subject: [issue7858] os.utime(file, (0, 0, )) fails on on vfat,
	but doesn't fail immediately
In-Reply-To: <1265386059.32.0.591513195746.issue7858@psf.upfronthosting.co.za>
Message-ID: <1294344457.06.0.465866795396.issue7858@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7858>
_______________________________________

From report at bugs.python.org  Thu Jan  6 21:22:11 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 06 Jan 2011 20:22:11 +0000
Subject: [issue3173] external strftime for Python?
In-Reply-To: <1294343777.82.0.179553735324.issue3173@psf.upfronthosting.co.za>
Message-ID: <AANLkTim5sD_0zo9uzuq6R1b2EsF5HwuQ+WL6TdXGVkcP@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Thu, Jan 6, 2011 at 2:56 PM, Eric Smith <report at bugs.python.org> wrote:
..
> If we're going to take this on (re-writing strftime), I think the way to do it is to have it take the locale info as a
> parameter, and if that parameter is NULL then look up the info in the current locale.

You may want to take a look at BSD-ish strftime_l function which is
defined by POSIX.1-2008:

http://pubs.opengroup.org/onlinepubs/9699919799/functions/strftime.html

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3173>
_______________________________________

From report at bugs.python.org  Thu Jan  6 21:49:16 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 06 Jan 2011 20:49:16 +0000
Subject: [issue10833] Replace %.100s by %s in PyErr_Format(): the arbitrary
	limit of 500 bytes is outdated
In-Reply-To: <1294196554.94.0.785505480291.issue10833@psf.upfronthosting.co.za>
Message-ID: <1294346956.83.0.829438107968.issue10833@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

eric> I always thought that one of the reasons for specifying the length
eric> was in case a pointer pointed to garbage: at least you'd be limiting 
eric> how much trash was printed.

No, it's because of the old (removed) 500 bytes limit.

There are different types of %s arguments:
 - name of a type, eg. PyType(op)->tp_name
 - constant message (a switch/case or if chose between different messages)
 - function/method name
 - ...
 - and sometimes an argument from the user, eg. codec.lookup(name) repeats the name in the result

belopolsky> Limiting field width when formatting error messages
belopolsky> is a good safety measure.  It is not only the amount
belopolsky> of garbage that can be spitted in error logs, if garbage
belopolsky> is not null-terminated, ...

Can you give me at least one example? I think that it is very unlikely, or just impossible. But if I do replace "%.100s"  by "%s" in all the code base, I accept to check each time that the argument is null-terminated and/or not controlable by the user. And maybe keep "%.100s" if I am not sure.

belopolsky> Think of out of memory errors: ...

PyErr_NoMemory() doesn't use PyErr_Format(), it's message is fixed, and the exception object is preallocated.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10833>
_______________________________________

From report at bugs.python.org  Thu Jan  6 21:52:13 2011
From: report at bugs.python.org (Guido van Rossum)
Date: Thu, 06 Jan 2011 20:52:13 +0000
Subject: [issue3173] external strftime for Python?
In-Reply-To: <1294343777.82.0.179553735324.issue3173@psf.upfronthosting.co.za>
Message-ID: <AANLkTi=GE+cwL96FbA8CSDtC3gk40Xi47h_PYme4NnK0@mail.gmail.com>


Guido van Rossum <guido at python.org> added the comment:

On Thu, Jan 6, 2011 at 11:56 AM, Eric Smith <report at bugs.python.org> wrote:
> If we're going to take this on (re-writing strftime), I think the way to do it is to have it take the locale info as a parameter, and if that parameter is NULL then look up the info in the current locale. It looks like it's still a problem to find all of the info in the locale on all platforms, though. Finding the locale info is no doubt the tricky part, as someone said.

Hm, shouldn't the libc locale support offer the same set of locales
and locale info that the libc strftime uses, on any platform? Or are
there platforms whose libc strftime has better locale support than the
libc getlocale implementation???

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3173>
_______________________________________

From report at bugs.python.org  Thu Jan  6 22:00:37 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 06 Jan 2011 21:00:37 +0000
Subject: [issue3173] external strftime for Python?
In-Reply-To: <1214189093.82.0.548435251403.issue3173@psf.upfronthosting.co.za>
Message-ID: <1294347637.32.0.594475147957.issue3173@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

The Qt library has its own strftime() implementation. The QLocale object has methods providing localized day and month names. For example, day names are implemented using a big ushort array (~20.000 bytes) which contains something like 'Sun;Mon;Tue;Wed;Thu;Fri;Sat;Sunday;Monday;Tuesday;Wednesday;Thursday;Friday;Saturday;S;M;T;W;T;F;S;7;1;2;3;4;5;6;;;;;;;;Dil;Wix;Qib;Rob;Kam;Jim;San;Dilbata;Wiixata;Qibxata;Roobii;Kamiisa;Jimaata;Sanbata;A;E;T;A;K;G;S;Aca;Etl;Tal;Arb;Kam;Gum;Sab;Acaada;Etleeni;Talaata;Arbaqa;Kamiisi;Gumqata;Sabti;1;2;3;4;5;6;7;So;Ma;Di;Wo;Do;Vr;Sa;Sondag;Maandag;Dinsdag;Woensdag;Donderdag;Vrydag;Saterdag;D;H;M;M;E;P;S;Die;H\xebn;Mar;M\xebr;(...)'.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3173>
_______________________________________

From report at bugs.python.org  Thu Jan  6 22:06:28 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 06 Jan 2011 21:06:28 +0000
Subject: [issue3173] external strftime for Python?
In-Reply-To: <1214189093.82.0.548435251403.issue3173@psf.upfronthosting.co.za>
Message-ID: <1294347988.07.0.0545193984696.issue3173@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Is nl_langinfo() function reliable? On any OS? Can we use it to get day name, abbreviated day name, month name and abbreviated month name?

We should maybe start with an implementation in Python? It's easier to write code in Python than in C, and because it can be reused on other Python implementations.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3173>
_______________________________________

From report at bugs.python.org  Thu Jan  6 22:20:49 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 06 Jan 2011 21:20:49 +0000
Subject: [issue10841] binary stdio
In-Reply-To: <1294279917.2.0.685442041198.issue10841@psf.upfronthosting.co.za>
Message-ID: <1294348849.03.0.39524990341.issue10841@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

New patch setting O_BINARY mode using _setmode() (on Windows) to stdin, stdout, stderr, but also to all FileIO() objects.

The patch on Py_Main() is still needed because Python may use sys.stderr when it is still a stdprinter object, before the final TextIOWrapper object is created (before the io module is loaded).

I don't know the effect of _setmode(stderr, O_BINARY) on calls to fputs(stderr, ...) in Py_FatalError().

I would appreciate a review of parser_translate_newline.patch.

----------
Added file: http://bugs.python.org/file20294/io_binary_windows.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10841>
_______________________________________

From report at bugs.python.org  Thu Jan  6 22:21:57 2011
From: report at bugs.python.org (Stefan Krah)
Date: Thu, 06 Jan 2011 21:21:57 +0000
Subject: [issue10847] Distutils drops -fno-strict-aliasing when CFLAGS are set
In-Reply-To: <1294348917.86.0.0652237323155.issue10847@psf.upfronthosting.co.za>
Message-ID: <1294348917.86.0.0652237323155.issue10847@psf.upfronthosting.co.za>


New submission from Stefan Krah <stefan-usenet at bytereef.org>:

When CFLAGS are set, distutils drops -fno-strict-aliasing (among other
flags):


$ python2.7 setup.py build
...
gcc -pthread -fno-strict-aliasing -g -O2 -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -fPIC -I./src -I/usr/local/include -I/usr/local/include/python2.7 -c src/gmpy.c -o build/temp.linux-x86_64-2.7/src/gmpy.o
...

$ CFLAGS="-fomit-frame-pointer" python2.7 setup.py build
...
gcc -pthread -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -fomit-frame-pointer -fPIC -I./src -I/usr/local/include -I/usr/local/include/python2.7 -c src/gmpy.c -o build/temp.linux-x86_64-2.7/src/gmpy.o
src/gmpy.c: In function ?_cmp_to_object?:
src/gmpy.c:4692: warning: dereferencing type-punned pointer will break strict-aliasing rules
...

I'm not sure if this is intentional. The documentation says:

"Compiler flags can also be supplied through setting the CFLAGS
environment variable. If set, the contents of CFLAGS will be added
to the compiler flags specified in the Setup file."

To me, this sounds as if they should be appended to the regular flags.

----------
assignee: tarek
components: Distutils
messages: 125591
nosy: eric.araujo, skrah, tarek
priority: high
severity: normal
status: open
title: Distutils drops -fno-strict-aliasing when CFLAGS are set
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10847>
_______________________________________

From report at bugs.python.org  Thu Jan  6 22:23:06 2011
From: report at bugs.python.org (Peter Kleiweg)
Date: Thu, 06 Jan 2011 21:23:06 +0000
Subject: [issue10841] binary stdio
In-Reply-To: <1294279917.2.0.685442041198.issue10841@psf.upfronthosting.co.za>
Message-ID: <1294348986.49.0.218088805842.issue10841@psf.upfronthosting.co.za>


Changes by Peter Kleiweg <pkleiweg at xs4all.nl>:


----------
nosy:  -pebbe

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10841>
_______________________________________

From report at bugs.python.org  Thu Jan  6 22:31:04 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 06 Jan 2011 21:31:04 +0000
Subject: [issue10833] Replace %.100s by %s in PyErr_Format(): the arbitrary
	limit of 500 bytes is outdated
In-Reply-To: <1294346956.83.0.829438107968.issue10833@psf.upfronthosting.co.za>
Message-ID: <AANLkTikw63aLzGyr7ZY2XHgSinz4EQETZ=k+viW0xN=N@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Thu, Jan 6, 2011 at 3:49 PM, STINNER Victor <report at bugs.python.org> wrote:
..
> eric> I always thought that one of the reasons for specifying the length
> eric> was in case a pointer pointed to garbage: at least you'd be limiting
> eric> how much trash was printed.
>
> No, it's because of the old (removed) 500 bytes limit.
>

How do you know?  I, for one, did use %.100s when formatting strings
long before I knew that there was a 500 bytes limit.

..
> belopolsky> Limiting field width when formatting error messages
> belopolsky> is a good safety measure. ?It is not only the amount
> belopolsky> of garbage that can be spitted in error logs, if garbage
> belopolsky> is not null-terminated, ...
>
> Can you give me at least one example? I think that it is very unlikely, or just impossible.

I am concerned about conditions that are impossible in a valid
program.  However, if you have a buffer overflow that trashes your
tp_name pointer so that it suddenly resolves to a binary code section,
you will need all help you can get to find the bug.  Having the
program spit 100-character garbage in this case is often preferable to
a SEGV.

> But if I do replace "%.100s" ?by "%s" in all the code base, I accept to check each
> time that the argument is null-terminated and/or not controlable by the user.

As long as we have ctypes, everything is controllable by user.  Again,
limiting field width when formatting strings is defensive programming.
 And defensive programming pays off when you have to chase bugs.

> And maybe keep "%.100s" if I am not sure.

Just keep "%.100s" always.  It does not hurt and it is less work for you. :-)

>
> belopolsky> Think of out of memory errors: ...
>
> PyErr_NoMemory() doesn't use PyErr_Format(), it's message is fixed, and the exception object is preallocated.

Indeed, there are no PyErr_Format(PyExc_MemoryError, ..) in the code
base, but there are a few PyErr_SetString(PyExc_MemoryError, ..) such
as PyErr_SetString(PyExc_MemoryError, "math.fsum partials") in
Modules/mathmodule.c.  Maybe these should be reviewed.  Still, there
may be code paths where OOM triggers an error other than MemoryError.
In any case, I don't see anything wrong with using fixed size buffers
in error handling and truncating too long output.

Code cleanup projects like this are rightfully frowned upon because
they are hard to review and usually error-prone.  However, if for each
change that you make, you would make sure that the error path is
covered by unit tests, it will definitely be an improvement.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10833>
_______________________________________

From report at bugs.python.org  Thu Jan  6 22:32:14 2011
From: report at bugs.python.org (Reid Kleckner)
Date: Thu, 06 Jan 2011 21:32:14 +0000
Subject: [issue1054041] Python doesn't exit with proper resultcode on SIGINT
Message-ID: <1294349534.22.0.610481564507.issue1054041@psf.upfronthosting.co.za>


Reid Kleckner <rnk at mit.edu> added the comment:

Looks good to me.  Do you need the TODO(gps)'s in there after implementing the behavior described?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1054041>
_______________________________________

From report at bugs.python.org  Thu Jan  6 23:13:41 2011
From: report at bugs.python.org (Reid Kleckner)
Date: Thu, 06 Jan 2011 22:13:41 +0000
Subject: [issue5673] Add timeout option to subprocess.Popen
In-Reply-To: <1238701276.41.0.515283298202.issue5673@psf.upfronthosting.co.za>
Message-ID: <1294352021.29.0.464027485365.issue5673@psf.upfronthosting.co.za>


Reid Kleckner <rnk at mit.edu> added the comment:

Pablo, so if I understand the issue you've run into correctly, you are using shell redirection to redirect stdout to a file, and then attempting to read from it using stdout=subprocess.PIPE.

It seems to me like this behavior is expected, because the shell will close it's current stdout file descriptor and open a new one pointing at "file".  When python tries to read from its end of the pipe, it complains that the fd has been closed.

I can avoid the problem here either by not reading stdout or by not redirecting to a file.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5673>
_______________________________________

From report at bugs.python.org  Thu Jan  6 23:18:49 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Thu, 06 Jan 2011 22:18:49 +0000
Subject: [issue4681] mmap offset should be off_t instead of ssize_t,
	and size calculation needs corrected
In-Reply-To: <1229503209.88.0.900633557014.issue4681@psf.upfronthosting.co.za>
Message-ID: <1294352329.84.0.962575134391.issue4681@psf.upfronthosting.co.za>


Changes by Nadeem Vawda <nadeem.vawda at gmail.com>:


----------
nosy: +nvawda

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4681>
_______________________________________

From report at bugs.python.org  Thu Jan  6 23:20:53 2011
From: report at bugs.python.org (Guido van Rossum)
Date: Thu, 06 Jan 2011 22:20:53 +0000
Subject: [issue10841] binary stdio
In-Reply-To: <1294348849.03.0.39524990341.issue10841@psf.upfronthosting.co.za>
Message-ID: <AANLkTikMwJq3GxZFHcAnsyPcowe-AwPbiADYgSG+ajNv@mail.gmail.com>


Guido van Rossum <guido at python.org> added the comment:

On Thu, Jan 6, 2011 at 1:20 PM, STINNER Victor <report at bugs.python.org> wrote:
> I don't know the effect of _setmode(stderr, O_BINARY) on calls to fputs(stderr, ...) in Py_FatalError().

On Windows it will write lines ending in LF only instead of CRLF. Most
tools to read text files should be able deal with that by now,
conditioned as they are by many years of Unix developers doing Windows
stuff on the side. (Somebody should test what Notepad does though. :-)

I don't know any other supported platforms where O_BINARY exists and
is not a no-op (but I haven't really looked :-).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10841>
_______________________________________

From report at bugs.python.org  Thu Jan  6 23:29:21 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 06 Jan 2011 22:29:21 +0000
Subject: [issue1054041] Python doesn't exit with proper resultcode on SIGINT
Message-ID: <1294352961.35.0.189353455191.issue1054041@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

- should KeyboardInterrupt always exit with SIGINT, or only if it was actually raised by a signal handler?
- if _Py_UnhandledKeyboardInterrupt is defined in Modules/main.c but used in Python/pythonrun.c, can't it cause linker errors when embedding Python?
- please use PEP 8 (testKeyboardInterruptSignalExit -> test_some_long_name)

----------
nosy: +loewis, pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1054041>
_______________________________________

From report at bugs.python.org  Thu Jan  6 23:34:19 2011
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 06 Jan 2011 22:34:19 +0000
Subject: [issue10848] Move test.regrtest from getopt to argparse
In-Reply-To: <1294353259.48.0.852026284896.issue10848@psf.upfronthosting.co.za>
Message-ID: <1294353259.48.0.852026284896.issue10848@psf.upfronthosting.co.za>


New submission from Brett Cannon <brett at python.org>:

r87812 shows that using getopt is not a good thing; having the short and long versions of an argument separated from each other can lead to bugs. It would be good to move test.regrtest over to argparse to help prevent that from happening again.

----------
components: Tests
keywords: easy
messages: 125597
nosy: brett.cannon
priority: low
severity: normal
status: open
title: Move test.regrtest from getopt to argparse
type: feature request

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10848>
_______________________________________

From report at bugs.python.org  Thu Jan  6 23:36:46 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 06 Jan 2011 22:36:46 +0000
Subject: [issue10835] sys.executable default and altinstall
In-Reply-To: <1294231894.7.0.0581440878919.issue10835@psf.upfronthosting.co.za>
Message-ID: <1294353406.47.0.191580000173.issue10835@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

I fail to see the bug. Garbage in, garbage out. AFAIU, returning /usr/bin/python2.7 still might be the wrong answer.

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10835>
_______________________________________

From report at bugs.python.org  Thu Jan  6 23:38:51 2011
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 06 Jan 2011 22:38:51 +0000
Subject: [issue10845] test_multiprocessing failure under Windows
In-Reply-To: <1294309581.41.0.731804987161.issue10845@psf.upfronthosting.co.za>
Message-ID: <1294353531.54.0.769521326173.issue10845@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
nosy: +brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10845>
_______________________________________

From report at bugs.python.org  Thu Jan  6 23:44:31 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Thu, 06 Jan 2011 22:44:31 +0000
Subject: [issue10848] Move test.regrtest from getopt to argparse
In-Reply-To: <1294353259.48.0.852026284896.issue10848@psf.upfronthosting.co.za>
Message-ID: <1294353871.42.0.607355962431.issue10848@psf.upfronthosting.co.za>


Sandro Tosi <sandro.tosi at gmail.com> added the comment:

I had that in mind since quite some time, so I'm taking ownership of this issue.

----------
assignee:  -> sandro.tosi
nosy: +sandro.tosi
versions: +Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10848>
_______________________________________

From report at bugs.python.org  Thu Jan  6 23:52:31 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 06 Jan 2011 22:52:31 +0000
Subject: [issue10849] Backport test/__main__
In-Reply-To: <1294354350.96.0.765120918707.issue10849@psf.upfronthosting.co.za>
Message-ID: <1294354350.96.0.765120918707.issue10849@psf.upfronthosting.co.za>


New submission from Alexander Belopolsky <belopolsky at users.sourceforge.net>:

It is much easier to remember and to type -m test instead of -m test.regrtest, but the usefulness of this feature is limited by the fact that it only works with the latest version. Since this does not require any user-visible changes, I think it should be ported to all actively maintained branches.  Note that we used to have a similar issue with -m test.regrtest and it was quite annoying to remember a separate incantation for 2.5.

----------
messages: 125600
nosy: belopolsky
priority: normal
severity: normal
status: open
title: Backport test/__main__
versions: Python 2.6, Python 2.7, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10849>
_______________________________________

From report at bugs.python.org  Thu Jan  6 23:53:20 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 06 Jan 2011 22:53:20 +0000
Subject: [issue10824] urandom should not block
In-Reply-To: <AANLkTimQ0hz17QtsjAtR4t=0pF2Nvqt19ZNK5YXAf_9F@mail.gmail.com>
Message-ID: <4D2647DD.7060608@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> You'll see that read returns less that 100M bytes when interrupted.

I see.

> while len(data) < expected:
>     read(expected - len(data))
> 
> So we're sure it won't break under some systems/conditions.

I think this is not quite the idiom we should use if we want to deal
with signals: if read() returns an empty string, we have hit end-of-file.

If there is a signal before anything is read, we should catch the
exception and continue reading (which the loop doesn't do, either).

OTOH, if the signal was due to a user interrupt, we should raise an
exception, anyway, IMO - even if we've read some data already.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10824>
_______________________________________

From report at bugs.python.org  Thu Jan  6 23:55:26 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 06 Jan 2011 22:55:26 +0000
Subject: [issue10849] Backport test/__main__
In-Reply-To: <1294354350.96.0.765120918707.issue10849@psf.upfronthosting.co.za>
Message-ID: <1294354526.77.0.0628338675019.issue10849@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


----------
nosy: +michael.foord

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10849>
_______________________________________

From report at bugs.python.org  Thu Jan  6 23:55:51 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Thu, 06 Jan 2011 22:55:51 +0000
Subject: [issue10849] Backport test/__main__
In-Reply-To: <1294354350.96.0.765120918707.issue10849@psf.upfronthosting.co.za>
Message-ID: <1294354551.89.0.717590962997.issue10849@psf.upfronthosting.co.za>


Changes by Sandro Tosi <sandro.tosi at gmail.com>:


----------
nosy: +sandro.tosi

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10849>
_______________________________________

From report at bugs.python.org  Fri Jan  7 00:18:43 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 06 Jan 2011 23:18:43 +0000
Subject: [issue10849] Backport test/__main__
In-Reply-To: <1294354350.96.0.765120918707.issue10849@psf.upfronthosting.co.za>
Message-ID: <1294355923.05.0.0303175382876.issue10849@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

-0 we don't backport new features

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10849>
_______________________________________

From report at bugs.python.org  Fri Jan  7 00:21:37 2011
From: report at bugs.python.org (Daniel Black)
Date: Thu, 06 Jan 2011 23:21:37 +0000
Subject: [issue2973] _ssl compiler warnings
In-Reply-To: <1211822122.76.0.619319801709.issue2973@psf.upfronthosting.co.za>
Message-ID: <1294356097.4.0.217859765326.issue2973@psf.upfronthosting.co.za>


Daniel Black <daniel at cacert.org> added the comment:

out of date?

still occurs on:
AMD64 Leopard 2.7: http://www.python.org/dev/buildbot/all/builders/AMD64 Leopard 2.7/builds/308/steps/compile/logs/warnings (57)
PPC Leopard 2.7: http://www.python.org/dev/buildbot/all/builders/PPC Leopard 2.7/builds/532/steps/compile/logs/warnings (20)
PPC Tiger 2.7: http://www.python.org/dev/buildbot/all/builders/PPC Tiger 2.7/builds/532/steps/compile/logs/warnings (25)

PPC Leopard 3.1: http://www.python.org/dev/buildbot/all/builders/PPC Leopard 3.1/builds/674/steps/compile/logs/warnings (20)
x86 gentoo 3.1 : http://www.python.org/dev/buildbot/all/builders/x86 gentoo 3.1/builds/1412/steps/compile/logs/warnings (8)
x86 FreeBSD 3.1: http://www.python.org/dev/buildbot/all/builders/x86 FreeBSD 3.1/builds/719/steps/compile/logs/warnings (7)
3.1.dmg: http://www.python.org/dev/buildbot/all/builders/3.1.dmg/builds/339/steps/compile/logs/warnings (20)

btw I don't think the gentoo ones are accurate - old versions of openssl have been gone for a while:
http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/dev-libs/openssl/openssl-0.9.7m.ebuild?hideattic=0&view=log

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2973>
_______________________________________

From report at bugs.python.org  Fri Jan  7 00:30:08 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 06 Jan 2011 23:30:08 +0000
Subject: [issue10812] Add some posix functions
In-Reply-To: <1294324408.87.0.519557321036.issue10812@psf.upfronthosting.co.za>
Message-ID: <4D26507C.5010305@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Patch looks mostly good. Some comments:

- sethostname supports names with embedded null bytes, so
  wrapper should not use strlen
- it's a bit asymmetric that gethostname is in the socket
  module and supports Windows, and sethostname is in the POSIX
  module. It would be useful to have a gethostname in the POSIX
  module also which is a) POSIX only and b) supports embedded
  NUL bytes.
- I think get/sethostname should use the FSDefault encoding.
- gethostid should check for POSIX errors.
- it checks for sethostid but then doesn't implement it.
- parsing id_t with "l" is incorrect, methinks
- siginfo_t should map to a structsequence
- according to my copy of waitid(2), not all of the fields you
  are returning from siginfo_t are actually filled.
- instead of PARSE_OFF_T, I rather recommend to use an O& parser.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10812>
_______________________________________

From report at bugs.python.org  Fri Jan  7 00:44:06 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 06 Jan 2011 23:44:06 +0000
Subject: [issue1054041] Python doesn't exit with proper resultcode on SIGINT
In-Reply-To: <1294352961.35.0.189353455191.issue1054041@psf.upfronthosting.co.za>
Message-ID: <4D2653C3.20303@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

I wonder whether there is a precedent of some system mapping SIGINT to
an exception. We could probably learn something from them.

> - should KeyboardInterrupt always exit with SIGINT, or only if it was
> actually raised by a signal handler?

IMO, if we give the illusion that the interpreter was actually killed,
we should equate KeyboardInterrupt with SIGINT; any uncaught
KeyboardInterrupt should consequently always lead to raising SIGINT.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1054041>
_______________________________________

From report at bugs.python.org  Fri Jan  7 01:32:54 2011
From: report at bugs.python.org (chrysn)
Date: Fri, 07 Jan 2011 00:32:54 +0000
Subject: [issue10850] inconsistent behavior concerning
	multiprocessing.manager.BaseManager._Server
In-Reply-To: <1294360374.53.0.588595674921.issue10850@psf.upfronthosting.co.za>
Message-ID: <1294360374.53.0.588595674921.issue10850@psf.upfronthosting.co.za>


New submission from chrysn <chrysn at fsfe.org>:

The multiprocessing.manager.BaseManager class has a class property called _Server, defaulting to multiprocessing.manager.Server, that is used in the ._run_server method (typically invoked via .run()) to determine the class of the server that is to be created.

On the other hand, the .get_server() method creates an instance of Server independent of what is configured in ._Server. Thus, managers started via .run() behave slightly different than those started with .get_server().serve_forever(), and in a way that is hard to track.

I am aware that the ._Server property is undocumented, but it's quite useful when extending BaseManager in a way that it needs to be configured by the server.

I suggest to have .get_server() use ._Server instead of Server; I can't think of situations in which this does the wrong thing (rather, I assume that up to now, users of ._Server didn't try running with .get_server().serve_forever(); it seems ._Server is not used in the standard library).

----------
components: None
messages: 125606
nosy: chrysn
priority: normal
severity: normal
status: open
title: inconsistent behavior concerning multiprocessing.manager.BaseManager._Server
type: behavior
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10850>
_______________________________________

From report at bugs.python.org  Fri Jan  7 01:38:40 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 07 Jan 2011 00:38:40 +0000
Subject: [issue10849] Backport test/__main__
In-Reply-To: <1294354350.96.0.765120918707.issue10849@psf.upfronthosting.co.za>
Message-ID: <1294360720.44.0.623616887527.issue10849@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

> -0 we don't backport new features

New tests are routinely backported when they accompany bug fixes, so new features under Lib/test are probably a fair game.  Given that this feature is implemented entirely in a file that is not used for any other purpose, I see little risk for stability.

I guess the fate of this request will depend on whether stable release maintainers are annoyed enough by having to remember -m test.regrtest.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10849>
_______________________________________

From report at bugs.python.org  Fri Jan  7 01:42:10 2011
From: report at bugs.python.org (mrjbq7)
Date: Fri, 07 Jan 2011 00:42:10 +0000
Subject: [issue5171] itertools.product docstring missing 'repeat' argument
In-Reply-To: <1233938945.33.0.092220516904.issue5171@psf.upfronthosting.co.za>
Message-ID: <1294360930.91.0.622114960656.issue5171@psf.upfronthosting.co.za>


mrjbq7 <mrjbq7 at users.sourceforge.net> added the comment:

I noticed a Reddit post[1] today that makes the comment that the docstring should read:

    product(*iterables[, repeat]) --> product object

instead of:

    product(*iterables) --> product object
    
---

[1] http://www.reddit.com/r/Python/comments/ex68j/omission_in_docstring_for_itertoolsproduct/

----------
nosy: +mrjbq7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5171>
_______________________________________

From report at bugs.python.org  Fri Jan  7 01:57:17 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 07 Jan 2011 00:57:17 +0000
Subject: [issue10827] Functions in time module should support year < 1900 when
	accept2dyear = 0
In-Reply-To: <1294159712.85.0.42147185487.issue10827@psf.upfronthosting.co.za>
Message-ID: <1294361837.11.0.862709019578.issue10827@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Attached patch, issue10827c.diff, implements the following logic in gettmarg:


    /* If year is specified with less that 4 digits, its interpretation                                                                                                                                       
     * depends on the accept2dyear value.                                                                                                                                                                     
     *                                                                                                                                                                                                        
     * If accept2dyear is true (default), a backward compatibility behavior is                                                                                                                                
     * invoked as follows:                                                                                                                                                                                    
     *                                                                                                                                                                                                        
     *   - for 2-digit year, century is guessed according to POSIX rules for                                                                                                                                  
     *      %y strptime format: 21st century for y < 69, 20th century                                                                                                                                         
     *      otherwise.  A deprecation warning is issued when century                                                                                                                                          
     *      information is guessed in this way.                                                                                                                                                               
     *                                                                                                                                                                                                        
     *   - for 3-digit or negative year, a ValueError exception is raised.                                                                                                                                    
     *                                                                                                                                                                                                        
     * If accept2dyear is false (set by the program or as a result of a                                                                                                                                       
     * non-empty value assigned to PYTHONY2K environment variable) all year                                                                                                                                   
     * values are interpreted as given.                                                                                                                                                                       
     */

It is easy to restore year >= 1900 limit for strftime, but I would rather add tests that time.strftime either produces correct values or raises ValueError and see if buildbots discover any platform bugs.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10827>
_______________________________________

From report at bugs.python.org  Fri Jan  7 02:01:19 2011
From: report at bugs.python.org (R. David Murray)
Date: Fri, 07 Jan 2011 01:01:19 +0000
Subject: [issue10848] Move test.regrtest from getopt to argparse
In-Reply-To: <1294353259.48.0.852026284896.issue10848@psf.upfronthosting.co.za>
Message-ID: <1294362079.02.0.757131754481.issue10848@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Note that based on my experience with the conversion of compileall to argparse,it is important to have good tests.  Of course, regrtest itself has no tests...

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10848>
_______________________________________

From report at bugs.python.org  Fri Jan  7 02:04:57 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 07 Jan 2011 01:04:57 +0000
Subject: [issue10827] Functions in time module should support year < 1900 when
	accept2dyear = 0
In-Reply-To: <1294159712.85.0.42147185487.issue10827@psf.upfronthosting.co.za>
Message-ID: <1294362297.52.0.70201910901.issue10827@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


Added file: http://bugs.python.org/file20295/issue10827c.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10827>
_______________________________________

From report at bugs.python.org  Fri Jan  7 02:13:36 2011
From: report at bugs.python.org (R. David Murray)
Date: Fri, 07 Jan 2011 01:13:36 +0000
Subject: [issue10835] sys.executable default and altinstall
In-Reply-To: <1294231894.7.0.0581440878919.issue10835@psf.upfronthosting.co.za>
Message-ID: <1294362816.18.0.675882837551.issue10835@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I agree that not guessing would be better.  But as long as we *are* guessing, it seems to me that /usr/bin/python2.7 would be less wrong than /usr/bin/python, for almost all modern unix systems.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10835>
_______________________________________

From report at bugs.python.org  Fri Jan  7 02:20:52 2011
From: report at bugs.python.org (Daniel Black)
Date: Fri, 07 Jan 2011 01:20:52 +0000
Subject: [issue10851] further extend ssl SNI and ciphers API
In-Reply-To: <1294363252.79.0.602058607156.issue10851@psf.upfronthosting.co.za>
Message-ID: <1294363252.79.0.602058607156.issue10851@psf.upfronthosting.co.za>


New submission from Daniel Black <daniel.subs at internode.on.net>:

as a further extension to issue #5639 (sni) and issue #8322 this patch provides the ability to set ciphers in the  SSLContext.wrap_socket and server_hostname in ssl.wrap_socket. This just makes all the ssl apis look the same. Restructured the documentation associated with these functions to all be around the wrap_socket method.

----------
components: Library (Lib)
files: p3k-sni-ciphers.patch
keywords: patch
messages: 125612
nosy: grooverdan, pitrou
priority: normal
severity: normal
status: open
title: further extend ssl SNI and ciphers API
versions: Python 3.3
Added file: http://bugs.python.org/file20296/p3k-sni-ciphers.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10851>
_______________________________________

From report at bugs.python.org  Fri Jan  7 02:37:40 2011
From: report at bugs.python.org (Daniel Black)
Date: Fri, 07 Jan 2011 01:37:40 +0000
Subject: [issue8109] Support for TLS Server Name Indication extension
In-Reply-To: <1268234047.5.0.702223567094.issue8109@psf.upfronthosting.co.za>
Message-ID: <1294364260.75.0.368121406709.issue8109@psf.upfronthosting.co.za>


Daniel Black <daniel.subs at internode.on.net> added the comment:

issue #5639 only has functionality for client side SNI. Server side SNI is still missing.

For server side SNI to be supported a server program should be able to retrieve the server name provided by the client call and alter the server certificate/key before the server completes the TLS/SSL connection.

----------
nosy: +grooverdan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8109>
_______________________________________

From report at bugs.python.org  Fri Jan  7 03:19:39 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Fri, 07 Jan 2011 02:19:39 +0000
Subject: [issue10512] regrtest ResourceWarning - unclosed sockets and files
In-Reply-To: <1290506536.77.0.313292165719.issue10512@psf.upfronthosting.co.za>
Message-ID: <1294366779.15.0.0946107332291.issue10512@psf.upfronthosting.co.za>


Nadeem Vawda <nadeem.vawda at gmail.com> added the comment:

Looking at the warnings from test_urllib2net, it seems that they all originate in the FTP tests:
* OtherNetworkTests.test_ftp()
* TimeoutTest.test_ftp_basic()
* TimeoutTest.test_ftp_default_timeout()

Most of these leaks seem to stem from the fact that socket.SocketIO.close() doesn't behave as documented. According to its docstring, it is meant to decrement the underlying socket's refcount, and close it if the refcount drops to zero. However, to do this job it calls socket._decref_socketios(), which is defined as follows:

    def _decref_socketios(self):
        if self._io_refs > 0:
            self._io_refs -= 1
        if self._closed:
            self.close()

Clearly, this doesn't do what the docstring describes. Changing the second conditional from "if self._closed:" to "if self._io_refs <= 0:" disposes of all but one of the ResourceWarnings, but also breaks 8 tests in test_socket. It seems that the tests expect a socket to remain open after all referring SocketIO objects have been closed, which contradicts the docstring for SocketIO.close(). I suppose I should open a separate issue for this.


The remaining warning occurs in test_ftp() when retrieving a non-existent file; I haven't yet managed to figure out what is causing it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10512>
_______________________________________

From report at bugs.python.org  Fri Jan  7 04:31:55 2011
From: report at bugs.python.org (R. David Murray)
Date: Fri, 07 Jan 2011 03:31:55 +0000
Subject: [issue10686] email.Generator should use unknown-8bit encoded words
	for headers with 8 bit data
In-Reply-To: <1292176909.21.0.316774202966.issue10686@psf.upfronthosting.co.za>
Message-ID: <1294371115.69.0.796512899227.issue10686@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Here is a patch.  Three of the tests currently fail due to what appears to be a bug in the Header formatting routines.  I'll have to look in to that before finishing this issue.

Note that doing str on a message with binary headers can produce overlong lines, since str does not limit line widths.  generator.flatten does, though, so in that case the lengthened lines are correctly rewrapped.  (Well, as correctly as Header rewraps any headers, at least, which is not all that well in certain cases).

----------
keywords: +patch
Added file: http://bugs.python.org/file20297/email_unknown-8bit.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10686>
_______________________________________

From report at bugs.python.org  Fri Jan  7 04:32:25 2011
From: report at bugs.python.org (R. David Murray)
Date: Fri, 07 Jan 2011 03:32:25 +0000
Subject: [issue10686] email.Generator should use unknown-8bit encoded words
	for headers with 8 bit data
In-Reply-To: <1292176909.21.0.316774202966.issue10686@psf.upfronthosting.co.za>
Message-ID: <1294371145.86.0.598403688377.issue10686@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
nosy: +barry

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10686>
_______________________________________

From report at bugs.python.org  Fri Jan  7 04:38:10 2011
From: report at bugs.python.org (R. David Murray)
Date: Fri, 07 Jan 2011 03:38:10 +0000
Subject: [issue10686] email.Generator should use unknown-8bit encoded words
	for headers with 8 bit data
In-Reply-To: <1292176909.21.0.316774202966.issue10686@psf.upfronthosting.co.za>
Message-ID: <1294371490.62.0.399985345863.issue10686@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I have a little bit of concern whether or not 'unknown-8bit' is the correct charset to use.  It seems to be the one in the RFCs, but I have a feeling it may not be what is used "in the wild" in headers, so I am looking for opinions.

----------
nosy: +sjt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10686>
_______________________________________

From report at bugs.python.org  Fri Jan  7 04:59:13 2011
From: report at bugs.python.org (Meador Inge)
Date: Fri, 07 Jan 2011 03:59:13 +0000
Subject: [issue3132] implement PEP 3118 struct changes
In-Reply-To: <1213741832.59.0.0620778602246.issue3132@psf.upfronthosting.co.za>
Message-ID: <1294372753.5.0.891772225477.issue3132@psf.upfronthosting.co.za>


Meador Inge <meadori at gmail.com> added the comment:

Attached is the latest version of the struct string patch.  I tested on OS X 10.6.5 (64-bit) and Ubuntu 10.04 (32-bit).  I also scanned for memory problems with Valgrind.  There is one test failing on 32-bit systems ('test_crasher').  This is due to the fact that 'struct.pack("357913941b", ...)' no longer tries to allocate 357913941 format codes.  This implementation just allocates *one* code and assigns a count of 357913941, which is utilized later when packing/unpacking.  Some work could be done to add better large memory consumption checks, though.

Previous feedback has been incorporated:

   1. Multiplicities allowed on struct specifiers.
   2. Maximum alignment rule.
   3. Struct nesting depth limited (64 levels).
   4. The old behavior of only one byte order specified.  However, 
      the code is written in a way such that the scoped behavior
      would be easy to add.

As before, there will surely be more iterations, but this is good enough for general review to see if things are headed in the right direction.  

This is a difficult one for review because the diffs are really large.  I placed a review on Rietveld here: http://codereview.appspot.com/3863042/.  If anyone has any ideas on how to reduce the number number of diffs (perhaps a way to do multiple smaller pataches), then that would be cool.  I don't see an obvious way to do this at this point.

----------
Added file: http://bugs.python.org/file20298/struct-string.py3k.3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3132>
_______________________________________

From report at bugs.python.org  Fri Jan  7 04:59:27 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 07 Jan 2011 03:59:27 +0000
Subject: [issue10181] Problems with Py_buffer management in memoryobject.c
	(and elsewhere?)
In-Reply-To: <1287858158.95.0.0752296181045.issue10181@psf.upfronthosting.co.za>
Message-ID: <1294372767.02.0.395830819855.issue10181@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

@Antoine: I actually had a closer look at the way dup_buffer is used, and I think it is currently legitimate (including for the anonymous memory case). It just isn't documented very well. For the "FromBuffer" case, it assumes the calling code already invoked GetBuffer as necessary when initialising the view, and for the various internal uses the dup_buffer call is immediately preceded by a GetBuffer call when view->obj is not NULL.

@Mark: I don't think that follows. PEP 3118 says that exporting objects own that memory, but it doesn't say that clients have to treat the structures as read-only. The only thing clients are obligated to do is pass the same Py_buffer address to ReleaseBuffer that was passed to GetBuffer. If the exporter actually needs to release buffer specific resources, then it should maintain an internal data structure keyed off the Py_buffer address.

The one thing clients really shouldn't mess with is the obj field (since ReleaseBuffer needs that to find the correct release method to invoke), but the PEP is obviously silent on that matter since it doesn't even acknowledge the existence of that field.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10181>
_______________________________________

From report at bugs.python.org  Fri Jan  7 05:25:24 2011
From: report at bugs.python.org (Stephen J. Turnbull)
Date: Fri, 07 Jan 2011 04:25:24 +0000
Subject: [issue10686] email.Generator should use unknown-8bit encoded words
	for headers with 8 bit data
In-Reply-To: <1292176909.21.0.316774202966.issue10686@psf.upfronthosting.co.za>
Message-ID: <1294374324.64.0.950700234904.issue10686@psf.upfronthosting.co.za>


Stephen J. Turnbull <stephen at xemacs.org> added the comment:

I agree with you that according to RFC1428, use of unknown-8bit is implicitly recommended.  However, note that the RFC itself is not standards-track.  I agree with your interpretation that in this context the email module should be considered a gateway.  I think it is certainly best to convert to MIME words, as you say.

However, if there isn't already, maybe there should be an option to bounce such headers back to the user?  That is, in an interactive application this should be an error.  Of course we should help the user by allowing and documenting (perhaps even defaulting to) whatever we choose for the unknown encoding.

I don't recall ever seeing unknown-8bit in the wild.  What I do see in the wild a lot, and specifically in Mailman moderation traffic, is simply "unknown".

A quick google for "unknown-8bit" pulled up some old (2002) discussion of unknown-8bit causing problems for some MTAs.  I didn't follow up to see what those were.

I don't have time to do it myself today (but would be willing to help out if you can wait up to two weeks -- I have travel coming up), but I suggest checking for IANA registration of "unknown" and "unknown-8bit".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10686>
_______________________________________

From report at bugs.python.org  Fri Jan  7 05:40:13 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 07 Jan 2011 04:40:13 +0000
Subject: [issue10845] test_multiprocessing failure under Windows
In-Reply-To: <1294309581.41.0.731804987161.issue10845@psf.upfronthosting.co.za>
Message-ID: <1294375213.93.0.894919779182.issue10845@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

I'm curious as to the results you get running "python -m test.__main__" and "python Lib/test/__main__.py" as well. I suspect both will fail.

Looking at the forking.py code, I think multiprocessing makes some assumptions that are flat out invalid in the presence of the -m switch - there are no guarantees that you can reverse engineer the name of an arbitrary module from the __file__ attribute. (This actually ties in with the current thread on python-ideas about making the real name of the main module readily available - then the parent process could just pass that through the pipe as a "main_name" value and this problem would go away)

In the short term, however, I think multiprocessing just needs to either special case the situation where "main_name" actually *is* __main__ or just drop the assertion across the board.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10845>
_______________________________________

From report at bugs.python.org  Fri Jan  7 05:43:00 2011
From: report at bugs.python.org (Daniel Black)
Date: Fri, 07 Jan 2011 04:43:00 +0000
Subject: [issue10852] SSL/TLS sni use in smtp, pop, imap, nntp,
	ftp client libs by default
In-Reply-To: <1294375380.08.0.187691378511.issue10852@psf.upfronthosting.co.za>
Message-ID: <1294375380.08.0.187691378511.issue10852@psf.upfronthosting.co.za>


New submission from Daniel Black <daniel.subs at internode.on.net>:

Like r85793, sni is enabled by default for url and https classes. This continues the consistency throughout the python libraries by adding it to other places where wrap_socket is used to instigate a SSL/TLS connection.

----------
components: Library (Lib)
files: sni-pop-smtp-imap-nntp.patch
keywords: patch
messages: 125621
nosy: grooverdan, pitrou
priority: normal
severity: normal
status: open
title: SSL/TLS sni use in smtp,pop,imap,nntp,ftp client libs by default
type: feature request
versions: Python 3.3
Added file: http://bugs.python.org/file20299/sni-pop-smtp-imap-nntp.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10852>
_______________________________________

From report at bugs.python.org  Fri Jan  7 05:44:06 2011
From: report at bugs.python.org (Daniel Black)
Date: Fri, 07 Jan 2011 04:44:06 +0000
Subject: [issue10853] SSL/TLS sni use in smtp, pop, imap, nntp,
	ftp client libs by default
In-Reply-To: <1294375446.18.0.329599270499.issue10853@psf.upfronthosting.co.za>
Message-ID: <1294375446.18.0.329599270499.issue10853@psf.upfronthosting.co.za>


New submission from Daniel Black <daniel.subs at internode.on.net>:

Like r85793, sni is enabled by default for url and https classes. This continues the consistency throughout the python libraries by adding it to other places where wrap_socket is used to instigate a SSL/TLS connection.

----------
components: Library (Lib)
files: sni-pop-smtp-imap-nntp.patch
keywords: patch
messages: 125622
nosy: grooverdan, pitrou
priority: normal
severity: normal
status: open
title: SSL/TLS sni use in smtp,pop,imap,nntp,ftp client libs by default
type: feature request
versions: Python 3.3
Added file: http://bugs.python.org/file20300/sni-pop-smtp-imap-nntp.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10853>
_______________________________________

From report at bugs.python.org  Fri Jan  7 05:54:39 2011
From: report at bugs.python.org (Daniel Black)
Date: Fri, 07 Jan 2011 04:54:39 +0000
Subject: [issue10852] SSL/TLS sni use in smtp, pop, imap, nntp,
	ftp client libs by default
In-Reply-To: <1294375380.08.0.187691378511.issue10852@psf.upfronthosting.co.za>
Message-ID: <1294376079.89.0.339638444863.issue10852@psf.upfronthosting.co.za>


Daniel Black <daniel.subs at internode.on.net> added the comment:

dup #10853

----------
nosy:  -pitrou
resolution:  -> duplicate
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10852>
_______________________________________

From report at bugs.python.org  Fri Jan  7 06:08:17 2011
From: report at bugs.python.org (Gregory P. Smith)
Date: Fri, 07 Jan 2011 05:08:17 +0000
Subject: [issue1054041] Python doesn't exit with proper resultcode on SIGINT
In-Reply-To: <4D2653C3.20303@v.loewis.de>
Message-ID: <AANLkTi=wpSjgxuGL-VaReUFw2SBDG1E1e5aWnYQeAP=C@mail.gmail.com>


Gregory P. Smith <greg at krypto.org> added the comment:

> IMO, if we give the illusion that the interpreter was actually killed,
> we should equate KeyboardInterrupt with SIGINT; any uncaught
> KeyboardInterrupt should consequently always lead to raising SIGINT.

Agreed.  Plus that is easier to implement and what I did.

I'll remove the left over TODO(gps) comments (oops) before this is
ever committed. I'm waiting until after 3.2 is released unless the
release manager jumps in and says otherwise.  remaining items:

 1. I need to add a second test case that writes the code to a file
and launches a subprocess executing that file instead of using -c
given that they are different code paths that each need testing.  For
variety I'll probably make that one send an actual SIGINT to the child
process rather than having it raise KeyboardInterrupt.

 2. The tests probably needs a decorator to limit their execution to posix.

 3. Do the signal and kill calls also need to be conditional based on
platform or is the function I put them in already posix-only?  If
necessary I'll protect them with #ifdefs so they don't break a windows
build.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1054041>
_______________________________________

From report at bugs.python.org  Fri Jan  7 07:08:57 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 07 Jan 2011 06:08:57 +0000
Subject: [issue10848] Move test.regrtest from getopt to argparse
In-Reply-To: <1294353259.48.0.852026284896.issue10848@psf.upfronthosting.co.za>
Message-ID: <1294380537.14.0.157119581472.issue10848@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/issue10848>
_______________________________________

From report at bugs.python.org  Fri Jan  7 07:13:20 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 07 Jan 2011 06:13:20 +0000
Subject: [issue10849] Backport test/__main__
In-Reply-To: <1294354350.96.0.765120918707.issue10849@psf.upfronthosting.co.za>
Message-ID: <1294380800.26.0.774208269829.issue10849@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

FWIW, I?ve already been caught by ?./python -m test? not working with 3.1 and 2.7 when doing backports and using my shell history functionality.  I share Alexander?s viewpoint that adding test.__main__ is a core dev-specific convenience that should not count as a new feature.  I would not add it to the security-only branches, though.

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10849>
_______________________________________

From report at bugs.python.org  Fri Jan  7 07:49:50 2011
From: report at bugs.python.org (Carsten Grohmann)
Date: Fri, 07 Jan 2011 06:49:50 +0000
Subject: [issue10813] Suppress adding decimal point for places=0 in moneyfmt()
In-Reply-To: <1294059487.44.0.656415691247.issue10813@psf.upfronthosting.co.za>
Message-ID: <1294382990.2.0.624045018816.issue10813@psf.upfronthosting.co.za>


Carsten Grohmann <carstengrohmann at gmx.de> added the comment:

Setting dp to an empty string is only a workaround from my perspective.

I get the value of the places parameter from a configuration instance and have to implement an additional check "places == 0" every time I call the original moneyfmt(). To reduce this effort I've changed my moneyfmt() function and applied the patch above.

I see only a valuable posibilities from my perspective: apply the patch. Because it would simplify life a little bit :-)

At end it's up to you because the current documentation stated "dp: ... only specify as blank when places is zero".

Regards,
Carsten

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10813>
_______________________________________

From report at bugs.python.org  Fri Jan  7 07:58:41 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Fri, 07 Jan 2011 06:58:41 +0000
Subject: [issue10835] sys.executable default and altinstall
In-Reply-To: <1294362816.18.0.675882837551.issue10835@psf.upfronthosting.co.za>
Message-ID: <4D26B99E.5040702@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> I agree that not guessing would be better.

Well, on Linux, readlink("/proc/self/exe") would be better than
guessing.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10835>
_______________________________________

From report at bugs.python.org  Fri Jan  7 08:49:03 2011
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 07 Jan 2011 07:49:03 +0000
Subject: [issue10849] Backport test/__main__
In-Reply-To: <1294354350.96.0.765120918707.issue10849@psf.upfronthosting.co.za>
Message-ID: <1294386543.15.0.0343342178688.issue10849@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
assignee:  -> benjamin.peterson
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10849>
_______________________________________

From report at bugs.python.org  Fri Jan  7 09:03:40 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 07 Jan 2011 08:03:40 +0000
Subject: [issue10845] test_multiprocessing failure under Windows
In-Reply-To: <1294309581.41.0.731804987161.issue10845@psf.upfronthosting.co.za>
Message-ID: <1294387420.34.0.83609251304.issue10845@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

On xp, changing from -m test to -m test.regrtest removed the extra craziness during and after the test run that I reported on pydev.

I think making at least a tempory fix to whatever -m test runs should be a release blocker so only individual tests and not the test process are broken. If necessary, just refuse to run under windows and say to use test.regrtest as before. (I believe I did use -m test.regrtest on 3.1 and 2.7 as -m test is not implemented for those.)

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10845>
_______________________________________

From report at bugs.python.org  Fri Jan  7 09:14:27 2011
From: report at bugs.python.org (Pierre Quentel)
Date: Fri, 07 Jan 2011 08:14:27 +0000
Subject: [issue4953] cgi module cannot handle POST with multipart/form-data
	in	3.0
In-Reply-To: <1232010166.79.0.972664060868.issue4953@psf.upfronthosting.co.za>
Message-ID: <1294388067.8.0.33737975649.issue4953@psf.upfronthosting.co.za>


Pierre Quentel <pierre.quentel at gmail.com> added the comment:

Option 1 is impossible, because the CGI script sometimes has no control on the stream : for instance on a shared web host, it will receive sys.stdin as a text stream

I also vote for option 3 ; explaining that if no argument is passed, the program will use sys.stdin.buffer (or the result of sys.stdin.detach() : I guess it's the same ?), and that if an argument is passed, it must provide an attribute "buffer" (or a method detach() ?) as the binary layer of the stream

BTW, I didn't have time to finish the versions of cgi.py and tests, my next slot is this week-end

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4953>
_______________________________________

From report at bugs.python.org  Fri Jan  7 10:04:00 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 07 Jan 2011 09:04:00 +0000
Subject: [issue9920] test_cmath on atan fails on AIX
In-Reply-To: <1285164788.53.0.85582412597.issue9920@psf.upfronthosting.co.za>
Message-ID: <1294391040.71.0.436406864007.issue9920@psf.upfronthosting.co.za>


Changes by Mark Dickinson <dickinsm at gmail.com>:


----------
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9920>
_______________________________________

From report at bugs.python.org  Fri Jan  7 10:05:58 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 07 Jan 2011 09:05:58 +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: <1294391158.28.0.257418315566.issue10181@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

[Nick]
> @Mark: I don't think that follows. [...]
> If the exporter actually needs to release buffer specific 
> resources, then it should maintain an internal data structure keyed off 
> the Py_buffer address.

Ah, okay.  So that would make issue 9990 just a documentation problem, right?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10181>
_______________________________________

From report at bugs.python.org  Fri Jan  7 10:10:25 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 07 Jan 2011 09:10:25 +0000
Subject: [issue10181] Problems with Py_buffer management in memoryobject.c
	(and elsewhere?)
In-Reply-To: <1287858158.95.0.0752296181045.issue10181@psf.upfronthosting.co.za>
Message-ID: <1294391425.36.0.876127100717.issue10181@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> an internal data structure keyed off 
> the Py_buffer address.

If we're using the Py_buffer address coming into getbuffer as a key, then we probably shouldn't be using a stack address, since it would be difficult to guarantee uniqueness that way.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10181>
_______________________________________

From report at bugs.python.org  Fri Jan  7 10:13:14 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 07 Jan 2011 09:13:14 +0000
Subject: [issue10512] regrtest ResourceWarning - unclosed sockets and files
In-Reply-To: <1294366779.15.0.0946107332291.issue10512@psf.upfronthosting.co.za>
Message-ID: <1294391704.14078.0.camel@marge>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Le vendredi 07 janvier 2011 ? 02:19 +0000, Nadeem Vawda a ?crit :
> Most of these leaks seem to stem from the fact that socket.SocketIO.close() doesn't behave as documented. According to its docstring, it is meant to decrement the underlying socket's refcount, and close it if the refcount drops to zero. However, to do this job it calls socket._decref_socketios(), which is defined as follows:
> 
>     def _decref_socketios(self):
>         if self._io_refs > 0:
>             self._io_refs -= 1
>         if self._closed:
>             self.close()
> 
> Clearly, this doesn't do what the docstring describes. Changing the second conditional from "if self._closed:" to "if self._io_refs <= 0:" disposes of all but one of the ResourceWarnings, but also breaks 8 tests in test_socket. It seems that the tests expect a socket to remain open after all referring SocketIO objects have been closed, which contradicts the docstring for SocketIO.close(). I suppose I should open a separate issue for this.

Can you please open a new issue for that?

Victor

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10512>
_______________________________________

From report at bugs.python.org  Fri Jan  7 10:15:48 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 07 Jan 2011 09:15:48 +0000
Subject: [issue4953] cgi module cannot handle POST with multipart/form-data
	in	3.0
In-Reply-To: <1294388067.8.0.33737975649.issue4953@psf.upfronthosting.co.za>
Message-ID: <1294391859.14078.2.camel@marge>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

We may also accept TextIOWrapper (eg. sys.stdin) *and*
BufferedReader/FileIO (eg. sys.stdin.buffer). It is possible to test the
type of the stream. With a TextIOWrapper, the raw buffer can be read
using stream.buffer.

But for StringIO/BytesIO: only BytesIO should be accepted.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4953>
_______________________________________

From report at bugs.python.org  Fri Jan  7 10:19:19 2011
From: report at bugs.python.org (Ross Lagerwall)
Date: Fri, 07 Jan 2011 09:19:19 +0000
Subject: [issue10812] Add some posix functions
In-Reply-To: <1294058752.01.0.285856626146.issue10812@psf.upfronthosting.co.za>
Message-ID: <1294391959.02.0.642168643566.issue10812@psf.upfronthosting.co.za>


Ross Lagerwall <rosslagerwall at gmail.com> added the comment:

>  it's a bit asymmetric that gethostname is in the socket
>  module and supports Windows, and sethostname is in the POSIX
>  module. It would be useful to have a gethostname in the POSIX
>  module also which is a) POSIX only and b) supports embedded
>  NUL bytes.

According to the spec for gethostname(), the hostname that it returns is null-terminated so it won't support embedded NUL bytes. Should we still add it anyway?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10812>
_______________________________________

From report at bugs.python.org  Fri Jan  7 10:34:50 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 07 Jan 2011 09:34:50 +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: <1294392890.91.0.42273220713.issue10181@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

It only needs to be unique for the lifetime of the buffer reference - for a Py_buffer struct on the stack, by the time the relevant C stack frame goes away, ReleaseBuffer should already have been called.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10181>
_______________________________________

From report at bugs.python.org  Fri Jan  7 10:39:49 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 07 Jan 2011 09:39:49 +0000
Subject: [issue9990] PyMemoryView_FromObject alters the Py_buffer after
	calling PyObject_GetBuffer when ndim 1
In-Reply-To: <1285787018.03.0.476755592717.issue9990@psf.upfronthosting.co.za>
Message-ID: <1294393189.36.0.314965457582.issue9990@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

As per the discussion over in issue #10181, I've changed my position on this issue.

Since the PEP isn't explicit on the exact semantics here, I think we should be guided by the memoryview behaviour and make it official that bf_releasebuffer implementations shouldn't trust the contents of the passed in Py_buffer struct. Instead, if that information is important, the exporter should create an internal data structure that preserves the necessary detail and merely use the Py_buffer address as an identifier to locate the internal copy.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9990>
_______________________________________

From report at bugs.python.org  Fri Jan  7 10:50:11 2011
From: report at bugs.python.org (Glenn Linderman)
Date: Fri, 07 Jan 2011 09:50:11 +0000
Subject: [issue4953] cgi module cannot handle POST with multipart/form-data
	in	3.0
In-Reply-To: <1232010166.79.0.972664060868.issue4953@psf.upfronthosting.co.za>
Message-ID: <1294393811.17.0.518382995152.issue4953@psf.upfronthosting.co.za>


Glenn Linderman <v+python at g.nevcal.com> added the comment:

Pierre said:
Option 1 is impossible, because the CGI script sometimes has no control on the stream : for instance on a shared web host, it will receive sys.stdin as a text stream

I say:
It is the user code of the CGI script that calls CGI.FieldStorage.  So the user could be required (option 1) to first tweak the stdin to be bytes, one way or another.  I don't understand any circumstance where a Python CGI script doesn't have control over the settings of the Python IO Stack that it is using to obtain the data... and the CGI spec is defined as a bytestream, so it must be able to read the bytes.

Victor said:
It is possible to test the type of the stream.

I say:
Yes, why just assume (as I have been) that the initial precondition is the defaults that Python imposes.  Other code could have interposed something else.  The user should be allowed to pass in anything that is a TextIOWrapper, or a BytesIO, and CGI should be able to deal with it.  If the user passes some other type, it should be assumed to produce bytes from its read() API, and if it doesn't the user gets what he deserves (an error).  Since the default Python sys.stdin is a TextIOWrapper, having CGI detect that, and extract its .buffer to use for obtaining bytes, should work fine.  If the user already tweaked sys.stdin to be a BytesIO (.buffer or detach()), CGI should detect and use that.  If the user substitutes a different class, it should be bytes, and that should be documented, the three cases that could work.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4953>
_______________________________________

From report at bugs.python.org  Fri Jan  7 11:01:43 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 07 Jan 2011 10:01:43 +0000
Subject: [issue9990] PyMemoryView_FromObject alters the Py_buffer after
	calling PyObject_GetBuffer when ndim 1
In-Reply-To: <1285787018.03.0.476755592717.issue9990@psf.upfronthosting.co.za>
Message-ID: <1294394503.75.0.518735272621.issue9990@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

The alternative (if we declare that clients should treat Py_buffer contents as completely read-only) is to update memoryview to include a separate "orig_view" field that would never be touched. The GetBuffer and ReleaseBuffer calls would then use orig_view, with dup_buffer used to copy the data into the main view field before modifying it.

However, this approach greatly complicates the bf_getbuffer and bf_releasebuffer implementations, since memoryview could no longer pass the supplied Py_buffer pointer straight through to the underlying implementation.

Instead, for each call to bf_getbuffer, it would need to create a new Py_buffer struct, use that for the GetBuffer call to the underlying object, copy the contents over to the passed in buffer (modifying the shape information as appropriate for any slicing that is in effect), then, in bf_releasebuffer, use the passed in pointer to find the right Py_buffer struct to use in the ReleaseBuffer call.

Putting the onus on exporters to be suspicious of the contents of the Py_buffer objects handed to bf_releasebuffer implementations actually seems like the more robust approach in the long run.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9990>
_______________________________________

From report at bugs.python.org  Fri Jan  7 11:11:51 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 07 Jan 2011 10:11:51 +0000
Subject: [issue10813] Suppress adding decimal point for places=0 in moneyfmt()
In-Reply-To: <1294059487.44.0.656415691247.issue10813@psf.upfronthosting.co.za>
Message-ID: <1294395111.11.0.373857410608.issue10813@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <rhettinger at users.sourceforge.net>:


----------
priority: normal -> low

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10813>
_______________________________________

From report at bugs.python.org  Fri Jan  7 11:41:15 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 07 Jan 2011 10:41:15 +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: <1294396875.99.0.782468779691.issue10181@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> by the time the relevant C stack frame goes away, ReleaseBuffer should 
> already have been called.

Hmm. I'm not sure I understand how/when that would happen.  Looking at the current py3k code, in Objects/memoryobject.c at line 92, we have:

PyObject *
PyMemoryView_FromObject(PyObject *base)
{
    PyMemoryViewObject *mview;
    Py_buffer view;

    if (!PyObject_CheckBuffer(base)) {
        PyErr_SetString(PyExc_TypeError,
            "cannot make memory view because object does "
            "not have the buffer interface");
        return NULL;
    }

    if (PyObject_GetBuffer(base, &view, PyBUF_FULL_RO) < 0)
        return NULL;

    mview = (PyMemoryViewObject *)PyMemoryView_FromBuffer(&view);
    if (mview == NULL) {
        PyBuffer_Release(&view);
        return NULL;
    }

    return (PyObject *)mview;
}

So here 'view' is being allocated on the stack, and its address passed to PyObject_GetBuffer;  PyBuffer_Release isn't called (except when an error happens) before the function exits and the stack frame becomes invalid.

Sorry for the odd questions;  it's clear to me that I'm misunderstanding something fundamental, but I'm struggling to figure out what.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10181>
_______________________________________

From report at bugs.python.org  Fri Jan  7 11:13:35 2011
From: report at bugs.python.org (=?utf-8?q?Peter_H=C3=A4ring?=)
Date: Fri, 07 Jan 2011 10:13:35 +0000
Subject: [issue9419] RUNSHARED needs LDFLAGS
In-Reply-To: <1294176750.04.0.0826462320446.issue9419@psf.upfronthosting.co.za>
Message-ID: <201101071113.27276.p.haering@gmx.net>


Peter H??ring <p.haering at gmx.net> added the comment:

Following commands trigger the bug:

tar xf Python-2.7.tar.bz2
mkdir XXXXXXXX	(this is the build-directory outside the source tree)

CFLAGS="-O2 -march=i686"  ../Python-2.7/configure 
--prefix=/sw/Python-2.7-20110107/dest --enable-shared 2>&1 |tee configure.log
make 2>&1 | tee make.log
make test 2>&1 | tee test.log

!!! IMPORTANT !!! The bug is only seen, if there is no Python-2.7 library 
already installed in the standard places.

I have included the three log files configure.log, make.log, test.log
------------------------------------------------
Pfarrer Dr. Peter H??ring
D??rmentinger Str. 15, 88521 Ertingen
Tel.: 07371/129361, Fax: 07371/129360
Email: p.haering at gmx.net

----------
Added file: http://bugs.python.org/file20301/configure.log
Added file: http://bugs.python.org/file20302/make.log
Added file: http://bugs.python.org/file20303/test.log

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9419>
_______________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: configure.log
Type: text/x-log
Size: 18641 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-bugs-list/attachments/20110107/fffa875e/attachment-0003.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: make.log
Type: text/x-log
Size: 88363 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-bugs-list/attachments/20110107/fffa875e/attachment-0004.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test.log
Type: text/x-log
Size: 22697 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-bugs-list/attachments/20110107/fffa875e/attachment-0005.bin>

From report at bugs.python.org  Fri Jan  7 12:22:37 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 07 Jan 2011 11:22:37 +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: <1294399357.11.0.806422230563.issue10181@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Ah, sorry - no, I misunderstood the question. I think that example actually *is* a bug in the memoryview implementation. The GetBuffer call should use the persistent address (&mview->view) that will be used in the ReleaseBuffer call, as per Antoine's patch on issue 9990.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10181>
_______________________________________

From report at bugs.python.org  Fri Jan  7 13:37:19 2011
From: report at bugs.python.org (R. David Murray)
Date: Fri, 07 Jan 2011 12:37:19 +0000
Subject: [issue10686] email.Generator should use unknown-8bit encoded words
	for headers with 8 bit data
In-Reply-To: <1292176909.21.0.316774202966.issue10686@psf.upfronthosting.co.za>
Message-ID: <1294403839.93.0.0914384058855.issue10686@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Well, unknown-8bit is registered as a charset with IANA.  It is registered specifically for use in message bodies, but as a registered charset it "should" be acceptable in headers as well.  There is no similar registration for just 'unknown', but it sounds like mailers may be more likely to accept it if it exists in the wild.

I'm hoping to fix this before the RC (which is tomorrow, which means fixing it today), so your suggestion of making the 'unknown charset' token configurable is a good one.  I'm not so worried about providing a way to reject such headers, since this incarnation of email makes a point of not throwing errors on parsing, and if you read binary messages with unknown bytes the best thing to do is generate the outgoing message with BytesGenerator, in which case you get the unknown bytes back without the rfc2047 munging.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10686>
_______________________________________

From report at bugs.python.org  Fri Jan  7 14:31:21 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 07 Jan 2011 13:31:21 +0000
Subject: [issue2973] _ssl compiler warnings
In-Reply-To: <1211822122.76.0.619319801709.issue2973@psf.upfronthosting.co.za>
Message-ID: <1294407081.15.0.442483645017.issue2973@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Well, it merely means that OpenSSL has changed the const-ness of some of their APIs over time. As I said I see no warnings with the most recent OpenSSL versions. Buildbots will tell you the same story: for example, no warnings under OS X "Snow Leopard", some under OS X "Leopard" (which is older).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2973>
_______________________________________

From report at bugs.python.org  Fri Jan  7 14:42:37 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 07 Jan 2011 13:42:37 +0000
Subject: [issue10851] further extend ssl SNI and ciphers API
In-Reply-To: <1294363252.79.0.602058607156.issue10851@psf.upfronthosting.co.za>
Message-ID: <1294407753.3823.4.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> as a further extension to issue #5639 (sni) and issue #8322 this patch
> provides the ability to set ciphers in the  SSLContext.wrap_socket and
> server_hostname in ssl.wrap_socket. This just makes all the ssl apis
> look the same. Restructured the documentation associated with these
> functions to all be around the wrap_socket method.

Ah! I actually don't want these APIs to look the same. In the long term,
I would like SSLContext to become the preferred API, with
ssl.wrap_socket only being supported for backwards compatibility.
The huge parameter list in ssl.wrap_socket() is really a mistake due to
it having evolved quite organically.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10851>
_______________________________________

From report at bugs.python.org  Fri Jan  7 14:43:22 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 07 Jan 2011 13:43:22 +0000
Subject: [issue8109] Server-side support for TLS Server Name Indication
	extension
In-Reply-To: <1268234047.5.0.702223567094.issue8109@psf.upfronthosting.co.za>
Message-ID: <1294407802.69.0.947191437308.issue8109@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Server side SNI is still missing.

Right, re-opening.

----------
resolution: duplicate -> 
stage:  -> needs patch
status: closed -> open
superseder: Support TLS SNI extension in ssl module -> 
title: Support for TLS Server Name Indication extension -> Server-side support for TLS Server Name Indication extension
versions: +Python 3.3 -Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8109>
_______________________________________

From report at bugs.python.org  Fri Jan  7 14:47:15 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 07 Jan 2011 13:47:15 +0000
Subject: [issue10853] SSL/TLS sni use in smtp, pop, imap, nntp,
	ftp client libs by default
In-Reply-To: <1294375446.18.0.329599270499.issue10853@psf.upfronthosting.co.za>
Message-ID: <1294408035.81.0.324613585195.issue10853@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Duplicate posting of #10852.

----------
resolution:  -> duplicate
status: open -> closed
superseder:  -> SSL/TLS sni use in smtp,pop,imap,nntp,ftp client libs by default

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10853>
_______________________________________

From report at bugs.python.org  Fri Jan  7 14:48:57 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 07 Jan 2011 13:48:57 +0000
Subject: [issue10852] SSL/TLS sni use in smtp, pop, imap, nntp,
	ftp client libs by default
In-Reply-To: <1294375380.08.0.187691378511.issue10852@psf.upfronthosting.co.za>
Message-ID: <1294408137.01.0.581746333439.issue10852@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Oops, I hadn't noticed you had closed it.

----------
nosy: +pitrou
resolution: duplicate -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10852>
_______________________________________

From report at bugs.python.org  Fri Jan  7 15:47:30 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 07 Jan 2011 14:47:30 +0000
Subject: [issue1641] asyncore delayed calls feature
In-Reply-To: <1197908693.3.0.330108725692.issue1641@psf.upfronthosting.co.za>
Message-ID: <1294411650.21.0.0675752777494.issue1641@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/issue1641>
_______________________________________

From report at bugs.python.org  Fri Jan  7 15:49:41 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 07 Jan 2011 14:49:41 +0000
Subject: [issue8684] improvements to sched.py
In-Reply-To: <1273552070.58.0.496415961493.issue8684@psf.upfronthosting.co.za>
Message-ID: <1294411781.14.0.553557927506.issue8684@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/issue8684>
_______________________________________

From report at bugs.python.org  Fri Jan  7 16:41:37 2011
From: report at bugs.python.org (Barry A. Warsaw)
Date: Fri, 07 Jan 2011 15:41:37 +0000
Subject: [issue10686] email.Generator should use unknown-8bit encoded words
	for headers with 8 bit data
In-Reply-To: <1292176909.21.0.316774202966.issue10686@psf.upfronthosting.co.za>
Message-ID: <1294414897.75.0.380379424938.issue10686@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

I'm a little uncomfortable with relying on a non-standards track RFC for this interpretation, and I'm also not sure I'd say that the email package is a "transport agent", but in cases where it's acting on the user's behalf (i.e. headers created programmatically rather than parsed), I can get on board with that.  Your interpretation and approach to the fix seems reasonable, and I don't have any better ideas.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10686>
_______________________________________

From report at bugs.python.org  Fri Jan  7 16:48:45 2011
From: report at bugs.python.org (anatoly techtonik)
Date: Fri, 07 Jan 2011 15:48:45 +0000
Subject: [issue10854] Output DLL name in error message of ImportError when DLL
	is missing
In-Reply-To: <1294415325.09.0.315523226252.issue10854@psf.upfronthosting.co.za>
Message-ID: <1294415325.09.0.315523226252.issue10854@psf.upfronthosting.co.za>


New submission from anatoly techtonik <techtonik at gmail.com>:

When an extension could not be loaded, because it requires some DLL that is missing, Python shows the following error message:

  ImportError: DLL load failed: The specified module could not be found.

It will help tremendously in debugging extension problems if the missing DLL name is specified in error message.

----------
components: Extension Modules
messages: 125649
nosy: techtonik
priority: normal
severity: normal
status: open
title: Output DLL name in error message of ImportError when DLL is missing
type: resource usage
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10854>
_______________________________________

From report at bugs.python.org  Fri Jan  7 16:59:25 2011
From: report at bugs.python.org (Brian Curtin)
Date: Fri, 07 Jan 2011 15:59:25 +0000
Subject: [issue10854] Output DLL name in error message of ImportError when DLL
	is missing
In-Reply-To: <1294415325.09.0.315523226252.issue10854@psf.upfronthosting.co.za>
Message-ID: <1294415965.38.0.648543514332.issue10854@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
type: resource usage -> feature request
versions: +Python 3.3 -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10854>
_______________________________________

From report at bugs.python.org  Fri Jan  7 17:03:29 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 07 Jan 2011 16:03:29 +0000
Subject: [issue10849] Backport test/__main__
In-Reply-To: <1294354350.96.0.765120918707.issue10849@psf.upfronthosting.co.za>
Message-ID: <1294416209.05.0.907308997225.issue10849@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

+0.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10849>
_______________________________________

From report at bugs.python.org  Fri Jan  7 17:21:56 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 07 Jan 2011 16:21:56 +0000
Subject: [issue10854] Output DLL name in error message of ImportError when DLL
	is missing
In-Reply-To: <1294415325.09.0.315523226252.issue10854@psf.upfronthosting.co.za>
Message-ID: <1294417316.18.0.977256998759.issue10854@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Is it even possible? Each time I tried, the only solutions involved an external program like Dependency Walker.

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10854>
_______________________________________

From report at bugs.python.org  Fri Jan  7 17:22:23 2011
From: report at bugs.python.org (Brian Curtin)
Date: Fri, 07 Jan 2011 16:22:23 +0000
Subject: [issue10854] Output DLL name in error message of ImportError when DLL
	is missing
In-Reply-To: <1294415325.09.0.315523226252.issue10854@psf.upfronthosting.co.za>
Message-ID: <1294417343.76.0.416657559674.issue10854@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

I'm pretty sure we can't do this, if I understand your request.

Say you have techtonik.pyd as your extension and it depends on foobar.dll. If we try to load techtonik.pyd and this pyd can't find or successfully load foobar.dll, Python doesn't know about *this* DLL. It just knows that it can't load techtonik.pyd, so that's what we'd be able to output, which isn't that helpful.

----------
nosy: +brian.curtin

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10854>
_______________________________________

From report at bugs.python.org  Fri Jan  7 17:23:15 2011
From: report at bugs.python.org (Brian Curtin)
Date: Fri, 07 Jan 2011 16:23:15 +0000
Subject: [issue10854] Output DLL name in error message of ImportError when DLL
	is missing
In-Reply-To: <1294415325.09.0.315523226252.issue10854@psf.upfronthosting.co.za>
Message-ID: <1294417395.36.0.13031440447.issue10854@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

Agree with Amaury. depends has always been my solution to this type of problem.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10854>
_______________________________________

From report at bugs.python.org  Fri Jan  7 17:23:45 2011
From: report at bugs.python.org (Peter Creath)
Date: Fri, 07 Jan 2011 16:23:45 +0000
Subject: [issue10855] wave.Wave_read.close() doesn't release file
In-Reply-To: <1294417424.98.0.47429499245.issue10855@psf.upfronthosting.co.za>
Message-ID: <1294417424.98.0.47429499245.issue10855@psf.upfronthosting.co.za>


New submission from Peter Creath <pjcreath+python at gmail.com>:

Calling wave.close() fails to release all references to the file passed in via wave.open(filename_or_obj, "rb").  As a result, processing many wave files produces an IOError of too many files open.

This bug is often masked because this dangling reference is collected if the wave object is collected.  However, if the wave object is retained, calling wave_obj.close() won't release the reference, and so the file will never be closed.

There are two solutions:

1) The workaround: the client program can explicitly close the file object it passed to the wave object ("file_obj.close()").

2) The bug fix: the wave module can properly release the extra reference to the file, by setting "self._data_chunk = None" in the close() method.  Explanation:

Trunk code (and 2.7.1, and older):

    def close(self):
        if self._i_opened_the_file:
            self._i_opened_the_file.close()
            self._i_opened_the_file = None
        self._file = None

but note initfp(self, file):
        ...
        self._file = Chunk(file, bigendian = 0)
        ...
                chunk = Chunk(self._file, bigendian = 0)
                ...
                self._data_chunk = chunk
                ...

therefore close needs to add:

        self._data_chunk = None

----------
components: Library (Lib)
messages: 125654
nosy: pjcreath
priority: normal
severity: normal
status: open
title: wave.Wave_read.close() doesn't release file
type: resource usage
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10855>
_______________________________________

From report at bugs.python.org  Fri Jan  7 17:23:48 2011
From: report at bugs.python.org (anatoly techtonik)
Date: Fri, 07 Jan 2011 16:23:48 +0000
Subject: [issue10856] documentation for ImportError parameters and attributes
In-Reply-To: <1294417428.74.0.78747071216.issue10856@psf.upfronthosting.co.za>
Message-ID: <1294417428.74.0.78747071216.issue10856@psf.upfronthosting.co.za>


New submission from anatoly techtonik <techtonik at gmail.com>:

Need documentation for ImportError parameters and exception instance attributes.

----------
assignee: docs at python
components: Documentation
messages: 125655
nosy: docs at python, techtonik
priority: normal
severity: normal
status: open
title: documentation for ImportError parameters and attributes
type: feature request
versions: Python 2.7, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10856>
_______________________________________

From report at bugs.python.org  Fri Jan  7 17:26:24 2011
From: report at bugs.python.org (anatoly techtonik)
Date: Fri, 07 Jan 2011 16:26:24 +0000
Subject: [issue10857] ImportError module attribute
In-Reply-To: <1294417584.32.0.11817196448.issue10857@psf.upfronthosting.co.za>
Message-ID: <1294417584.32.0.11817196448.issue10857@psf.upfronthosting.co.za>


New submission from anatoly techtonik <techtonik at gmail.com>:

Need ImportError.module attribute to get the name of failed import. Right now it requires parsing ImportError.args that is presented in form "('No module named zqwer',)" that is not pythonic.

----------
messages: 125656
nosy: techtonik
priority: normal
severity: normal
status: open
title: ImportError module attribute
type: feature request

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10857>
_______________________________________

From report at bugs.python.org  Fri Jan  7 17:26:36 2011
From: report at bugs.python.org (R. David Murray)
Date: Fri, 07 Jan 2011 16:26:36 +0000
Subject: [issue10686] email.Generator should use unknown-8bit encoded words
	for headers with 8 bit data
In-Reply-To: <1292176909.21.0.316774202966.issue10686@psf.upfronthosting.co.za>
Message-ID: <1294417596.32.0.933147582631.issue10686@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Well, since unknown-8bit is a registered charset, it should be RFC-valid in an encoded word.  Whether or not any other mailer out there is going to be able to handle it is a different question.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10686>
_______________________________________

From report at bugs.python.org  Fri Jan  7 17:28:23 2011
From: report at bugs.python.org (Brian Curtin)
Date: Fri, 07 Jan 2011 16:28:23 +0000
Subject: [issue10857] ImportError module attribute
In-Reply-To: <1294417584.32.0.11817196448.issue10857@psf.upfronthosting.co.za>
Message-ID: <1294417703.82.0.305177453058.issue10857@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

Duplicate of #1559549

----------
nosy: +brian.curtin
resolution:  -> duplicate
stage:  -> committed/rejected
status: open -> closed
superseder:  -> ImportError needs attributes for module and file name

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10857>
_______________________________________

From report at bugs.python.org  Fri Jan  7 18:04:23 2011
From: report at bugs.python.org (anatoly techtonik)
Date: Fri, 07 Jan 2011 17:04:23 +0000
Subject: [issue10857] ImportError module attribute
In-Reply-To: <1294417584.32.0.11817196448.issue10857@psf.upfronthosting.co.za>
Message-ID: <1294419863.46.0.899042890057.issue10857@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

Thanks for the pointer. I couldn't find it myself.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10857>
_______________________________________

From report at bugs.python.org  Fri Jan  7 18:07:45 2011
From: report at bugs.python.org (anatoly techtonik)
Date: Fri, 07 Jan 2011 17:07:45 +0000
Subject: [issue1559549] ImportError needs attributes for module and file name
Message-ID: <1294420065.6.0.803689520273.issue1559549@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

I think we should investigate deeper why this enhancement request didn't get into Python 3.

Another user story is: "from xxx import yyy", if yyy not found, the args message is ('cannot import name yyy',)

Python4?

label:api

----------
nosy: +techtonik

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1559549>
_______________________________________

From report at bugs.python.org  Fri Jan  7 18:10:30 2011
From: report at bugs.python.org (Brian Curtin)
Date: Fri, 07 Jan 2011 17:10:30 +0000
Subject: [issue1559549] ImportError needs attributes for module and file name
Message-ID: <1294420230.59.0.887938563284.issue1559549@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
versions: +Python 3.3 -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1559549>
_______________________________________

From report at bugs.python.org  Fri Jan  7 18:31:26 2011
From: report at bugs.python.org (R. David Murray)
Date: Fri, 07 Jan 2011 17:31:26 +0000
Subject: [issue1559549] ImportError needs attributes for module and file name
Message-ID: <1294421486.25.0.929165630136.issue1559549@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

There's no need for any deeper investigation.  The answer is "nobody wrote the patch".  If someone writes a good patch, it will go in.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1559549>
_______________________________________

From report at bugs.python.org  Fri Jan  7 18:34:33 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 07 Jan 2011 17:34:33 +0000
Subject: [issue1559549] ImportError needs attributes for module and file name
Message-ID: <1294421673.5.0.927043183594.issue1559549@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

> I think we should investigate deeper why this enhancement
> request didn't get into Python 3.

There is nothing to investigate here.  This is a request for a marginal improvement and OP did not follow up even though a core developer responded on the next day after his post.

The only lesson to be learned from this is that Python improvements should be discussed on the tracker or appropriate python mailing lists and not on private blogs.

----------
nosy: +belopolsky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1559549>
_______________________________________

From report at bugs.python.org  Fri Jan  7 18:42:32 2011
From: report at bugs.python.org (anatoly techtonik)
Date: Fri, 07 Jan 2011 17:42:32 +0000
Subject: [issue10854] Output DLL name in error message of ImportError when DLL
	is missing
In-Reply-To: <1294415325.09.0.315523226252.issue10854@psf.upfronthosting.co.za>
Message-ID: <1294422152.0.0.658217083723.issue10854@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

Can you cross reference the part of code where this error is catched?

Why Python can't get information about the reason .DLL is not loaded?

Is it at least possible to add a hook point at the exact time the import fails to insert component that is able to inquiry system about this information (like depends)?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10854>
_______________________________________

From report at bugs.python.org  Fri Jan  7 18:43:46 2011
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 07 Jan 2011 17:43:46 +0000
Subject: [issue10856] documentation for ImportError parameters and attributes
In-Reply-To: <1294417428.74.0.78747071216.issue10856@psf.upfronthosting.co.za>
Message-ID: <1294422226.1.0.476435349909.issue10856@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

What is there to document?  ImportError has no special attributes or parameters.

----------
nosy: +georg.brandl
resolution:  -> works for me
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10856>
_______________________________________

From report at bugs.python.org  Fri Jan  7 18:47:08 2011
From: report at bugs.python.org (Brian Curtin)
Date: Fri, 07 Jan 2011 17:47:08 +0000
Subject: [issue10854] Output DLL name in error message of ImportError when DLL
	is missing
In-Reply-To: <1294415325.09.0.315523226252.issue10854@psf.upfronthosting.co.za>
Message-ID: <1294422428.54.0.93340687464.issue10854@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

See _PyImport_GetDynLoadFunc in Python/dynload_win.c -- that's where this is happening.


> Why Python can't get information about the reason .DLL is not loaded?

Windows does not provide it in the case you are speaking of. If I call LoadLibraryEx for techtonik.pyd, either it succeeds because everything is there, or it fails because something is not there. We get no information about dependency hierarchies failing to load.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10854>
_______________________________________

From report at bugs.python.org  Fri Jan  7 18:48:55 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 07 Jan 2011 17:48:55 +0000
Subject: [issue10849] Backport test/__main__
In-Reply-To: <1294354350.96.0.765120918707.issue10849@psf.upfronthosting.co.za>
Message-ID: <1294422535.4.0.586902679695.issue10849@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

2.6 is right out.

Martin, would you please decide on whether this should be backported to 2.7 and 3.1?   IMO, the rationale is flimsy (its not hard to run the test suite in *any* version) and it goes against our usual policy; however, it is also a trivial and isolated patch, making it somewhat harmless.

Also note that 3.1 is very soon to be closed for anything but security fixes.  Only 2.7 will in long-term maintenance.

----------
assignee: benjamin.peterson -> loewis
nosy: +loewis
versions:  -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10849>
_______________________________________

From report at bugs.python.org  Fri Jan  7 18:51:25 2011
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 07 Jan 2011 17:51:25 +0000
Subject: [issue10849] Backport test/__main__
In-Reply-To: <1294354350.96.0.765120918707.issue10849@psf.upfronthosting.co.za>
Message-ID: <1294422685.83.0.171015572244.issue10849@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

I thought Benjamin was still RM for 2.7 and 3.1?

----------
assignee: loewis -> benjamin.peterson
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10849>
_______________________________________

From report at bugs.python.org  Fri Jan  7 18:53:18 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 07 Jan 2011 17:53:18 +0000
Subject: [issue10854] Output DLL name in error message of ImportError when DLL
	is missing
In-Reply-To: <1294415325.09.0.315523226252.issue10854@psf.upfronthosting.co.za>
Message-ID: <1294422798.48.0.879072167523.issue10854@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

The code is in Python/dynload_win.c

To load an extension module mymodule.pyd, Python calls LoadLibrary('/path/to/mymodule.pyd'); when it returns NULL, the code calls GetLastError() (which returns 126 in this case) then FormatMessage to get an error message.

To get the full path to the .pyd, you can use imp.find_module(), but there is nothing else we can do I fear.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10854>
_______________________________________

From report at bugs.python.org  Fri Jan  7 19:09:30 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 07 Jan 2011 18:09:30 +0000
Subject: [issue10858] Make source code links less proeminent
In-Reply-To: <1294423770.11.0.311474750627.issue10858@psf.upfronthosting.co.za>
Message-ID: <1294423770.11.0.311474750627.issue10858@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

Reading library source code will only be enlightening to expert users, since most modules are not academic but real-world implementations, with all the complications it entails. Therefore, putting a link at the top of module sections is only confusing for most people. I would like to shift these links to the bottom of doc pages, where we already have "see also" links to RFCs and the like.

----------
assignee: docs at python
components: Documentation
messages: 125669
nosy: docs at python, pitrou, rhettinger
priority: normal
severity: normal
status: open
title: Make source code links less proeminent
versions: Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10858>
_______________________________________

From report at bugs.python.org  Fri Jan  7 19:13:54 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 07 Jan 2011 18:13:54 +0000
Subject: [issue10852] SSL/TLS sni use in smtp, pop, imap, nntp,
	ftp client libs by default
In-Reply-To: <1294375380.08.0.187691378511.issue10852@psf.upfronthosting.co.za>
Message-ID: <1294424034.42.0.755068058875.issue10852@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I understand this patch relies on #10851. As I said there, I would rather have SSLContext become the primary API, and the stdlib standardize on it. Part of the stdlib, as you have witnessed, already allows the user to pass a custom SSLContext, which is very simple way of allowing for custom user settings. There are two open issues for imaplib (#8808) and smtplib (#8809).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10852>
_______________________________________

From report at bugs.python.org  Fri Jan  7 19:14:26 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 07 Jan 2011 18:14:26 +0000
Subject: [issue8808] imaplib should support SSL contexts
In-Reply-To: <1274717637.39.0.0073929793702.issue8808@psf.upfronthosting.co.za>
Message-ID: <1294424066.02.0.166027240511.issue8808@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
stage:  -> needs patch
versions: +Python 3.3 -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8808>
_______________________________________

From report at bugs.python.org  Fri Jan  7 19:14:57 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 07 Jan 2011 18:14:57 +0000
Subject: [issue8809] smptlib should support SSL contexts
In-Reply-To: <1274717742.76.0.780111419761.issue8809@psf.upfronthosting.co.za>
Message-ID: <1294424097.52.0.630868266063.issue8809@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
stage:  -> needs patch
versions: +Python 3.3 -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8809>
_______________________________________

From report at bugs.python.org  Fri Jan  7 19:19:09 2011
From: report at bugs.python.org (anatoly techtonik)
Date: Fri, 07 Jan 2011 18:19:09 +0000
Subject: [issue10856] documentation for ImportError parameters and attributes
In-Reply-To: <1294417428.74.0.78747071216.issue10856@psf.upfronthosting.co.za>
Message-ID: <1294424349.55.0.916313024677.issue10856@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

ImportError has args and message attributes containing failed module name.

----------
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10856>
_______________________________________

From report at bugs.python.org  Fri Jan  7 19:23:25 2011
From: report at bugs.python.org (R. David Murray)
Date: Fri, 07 Jan 2011 18:23:25 +0000
Subject: [issue10856] documentation for ImportError parameters and attributes
In-Reply-To: <1294417428.74.0.78747071216.issue10856@psf.upfronthosting.co.za>
Message-ID: <1294424605.47.0.860492938967.issue10856@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

No it doesn't.  It has an arbitrary message string.  That's the same as all other exceptions that don't have special attributes.

----------
nosy: +r.david.murray
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10856>
_______________________________________

From report at bugs.python.org  Fri Jan  7 19:23:30 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 07 Jan 2011 18:23:30 +0000
Subject: [issue10808] ssl unwrap fails with Error 0
In-Reply-To: <1293997937.94.0.348375754935.issue10808@psf.upfronthosting.co.za>
Message-ID: <1294424610.53.0.499288048242.issue10808@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

As we discussed on IRC, there are two things here:

- unwrap() can give an error because it tries to shutdown the SSL layer cleanly, and the other side doesn't support it or is already closed; unwrap() is useful mostly if you plan to use the clear-text layer afterwards, otherwise you can just call shutdown(socket.SHUT_RDWR) and then close()

- the error message and errnos are totally bogus, but I'm afraid that's because of OpenSSL giving us this information.

----------
resolution:  -> wont fix
status: open -> closed
versions: +Python 3.2 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10808>
_______________________________________

From report at bugs.python.org  Fri Jan  7 19:30:25 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 07 Jan 2011 18:30:25 +0000
Subject: [issue9090] Error code 10035 calling socket.recv() on a socket with a
	timeout (WSAEWOULDBLOCK - A non-blocking socket operation could
	not be completed immediately)
In-Reply-To: <1277602727.58.0.118328870924.issue9090@psf.upfronthosting.co.za>
Message-ID: <1294425025.83.0.325707304002.issue9090@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I will not bother backporting myself but an other core developer can do it if (s)he desires.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9090>
_______________________________________

From report at bugs.python.org  Fri Jan  7 19:30:51 2011
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 07 Jan 2011 18:30:51 +0000
Subject: [issue10856] documentation for ImportError parameters and attributes
In-Reply-To: <1294417428.74.0.78747071216.issue10856@psf.upfronthosting.co.za>
Message-ID: <1294425051.49.0.613182325099.issue10856@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

You are right, however, that the "args" argument is not really well documented.  Fixed that in r87820.

----------
resolution: works for me -> fixed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10856>
_______________________________________

From report at bugs.python.org  Fri Jan  7 19:41:21 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 07 Jan 2011 18:41:21 +0000
Subject: [issue10849] Backport test/__main__
In-Reply-To: <1294354350.96.0.765120918707.issue10849@psf.upfronthosting.co.za>
Message-ID: <1294425681.16.0.331845706438.issue10849@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

His +0 isn't a decision.  I would like Martin, the longest term active developer, to make the call about waiving the policy of not backporting features (especially when the only purported benefit saving a couple of core devs from spelling out the path name to the test suite).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10849>
_______________________________________

From report at bugs.python.org  Fri Jan  7 19:43:11 2011
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 07 Jan 2011 18:43:11 +0000
Subject: [issue10849] Backport test/__main__
In-Reply-To: <1294354350.96.0.765120918707.issue10849@psf.upfronthosting.co.za>
Message-ID: <1294425791.89.0.877461988582.issue10849@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Oh, sure. I misinterpreted your comment.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10849>
_______________________________________

From report at bugs.python.org  Fri Jan  7 19:43:50 2011
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 07 Jan 2011 18:43:50 +0000
Subject: [issue10849] Backport test/__main__
In-Reply-To: <1294354350.96.0.765120918707.issue10849@psf.upfronthosting.co.za>
Message-ID: <1294425830.54.0.829730913492.issue10849@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
nosy:  -georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10849>
_______________________________________

From report at bugs.python.org  Fri Jan  7 19:44:24 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 07 Jan 2011 18:44:24 +0000
Subject: [issue10849] Backport test/__main__
In-Reply-To: <1294425681.16.0.331845706438.issue10849@psf.upfronthosting.co.za>
Message-ID: <AANLkTinumhu=0x_obpiczO1YDu_WNJoZ1NVR_ceoowFA@mail.gmail.com>


Benjamin Peterson <benjamin at python.org> added the comment:

2011/1/7 Raymond Hettinger <report at bugs.python.org>:
>
> Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:
>
> His +0 isn't a decision. ?I would like Martin, the longest term active developer, to make the call about waiving the policy of not backporting features (especially when the only purported benefit saving a couple of core devs from spelling out the path name to the test suite).

What are the purported downsides?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10849>
_______________________________________

From report at bugs.python.org  Fri Jan  7 19:48:34 2011
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 07 Jan 2011 18:48:34 +0000
Subject: [issue10808] ssl unwrap fails with Error 0
In-Reply-To: <1293997937.94.0.348375754935.issue10808@psf.upfronthosting.co.za>
Message-ID: <1294426114.02.0.429905876357.issue10808@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

"This information" being no information, is that really all you can get out of OpenSSL?

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10808>
_______________________________________

From report at bugs.python.org  Fri Jan  7 19:50:10 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 07 Jan 2011 18:50:10 +0000
Subject: [issue10841] binary stdio
In-Reply-To: <1294279917.2.0.685442041198.issue10841@psf.upfronthosting.co.za>
Message-ID: <1294426210.2.0.0590134350664.issue10841@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

I commited io_binary_windows.patch + parser_translate_newline.patch as r87824. I fixed the patch on the parser to avoid leak on newtok if translate_newlines() fails.

----------
Added file: http://bugs.python.org/file20304/parser_translate_newline-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10841>
_______________________________________

From report at bugs.python.org  Fri Jan  7 19:50:27 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 07 Jan 2011 18:50:27 +0000
Subject: [issue10808] ssl unwrap fails with Error 0
In-Reply-To: <1294426114.02.0.429905876357.issue10808@psf.upfronthosting.co.za>
Message-ID: <1294426221.3823.7.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> "This information" being no information, is that really all you can get out of OpenSSL?

Well the situation as the same as a system call which would return
failure but leave errno 0 (except that OpenSSL has its own
kind-of-errnos).
OpenSSL's error reporting is unfortunately poorly if at all documented,
and I don't know what to do here.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10808>
_______________________________________

From report at bugs.python.org  Fri Jan  7 19:59:30 2011
From: report at bugs.python.org (anatoly techtonik)
Date: Fri, 07 Jan 2011 18:59:30 +0000
Subject: [issue10854] Output DLL name in error message of ImportError when DLL
	is missing
In-Reply-To: <1294415325.09.0.315523226252.issue10854@psf.upfronthosting.co.za>
Message-ID: <1294426770.45.0.611356155402.issue10854@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

I see. But depends.exe dependency walker somehow finds the exact code that is failing, so there should be a way to do extra investigation in case of error.

py2exe has a custom .dll loader that bypasses LoadLibrary(Ex) calls from that I can see at  http://py2exe.svn.sourceforge.net/viewvc/py2exe/trunk/py2exe/source/

Even if this code can't be used as a replacement for LoadLibrary calls - it can be very useful for troubleshooting problems in case of missing dependencies. It will also help when embedding python or developing extensions.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10854>
_______________________________________

From report at bugs.python.org  Fri Jan  7 20:02:17 2011
From: report at bugs.python.org (Brian Curtin)
Date: Fri, 07 Jan 2011 19:02:17 +0000
Subject: [issue10854] Output DLL name in error message of ImportError when DLL
	is missing
In-Reply-To: <1294415325.09.0.315523226252.issue10854@psf.upfronthosting.co.za>
Message-ID: <1294426937.78.0.728579046861.issue10854@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10854>
_______________________________________

From report at bugs.python.org  Fri Jan  7 20:05:12 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 07 Jan 2011 19:05:12 +0000
Subject: [issue10859] Is GeneratorContextManager public?
In-Reply-To: <1294427112.3.0.241437231702.issue10859@psf.upfronthosting.co.za>
Message-ID: <1294427112.3.0.241437231702.issue10859@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

contextlib.GeneratorContextManager doesn't have an underscore but it's not documented either. Something has to be done (I would say make it private).

----------
components: Library (Lib)
messages: 125683
nosy: michael.foord, ncoghlan, pitrou
priority: normal
severity: normal
status: open
title: Is GeneratorContextManager public?
type: behavior
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10859>
_______________________________________

From report at bugs.python.org  Fri Jan  7 20:06:55 2011
From: report at bugs.python.org (Michael Foord)
Date: Fri, 07 Jan 2011 19:06:55 +0000
Subject: [issue10859] Is GeneratorContextManager public?
In-Reply-To: <1294427112.3.0.241437231702.issue10859@psf.upfronthosting.co.za>
Message-ID: <1294427215.29.0.6328491935.issue10859@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

It isn't in __all__ and it is undocumented - so I'd say its private already.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10859>
_______________________________________

From report at bugs.python.org  Fri Jan  7 20:09:02 2011
From: report at bugs.python.org (Giampaolo Rodola')
Date: Fri, 07 Jan 2011 19:09:02 +0000
Subject: [issue1559549] ImportError needs attributes for module and file name
Message-ID: <1294427342.05.0.300352956354.issue1559549@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/issue1559549>
_______________________________________

From report at bugs.python.org  Fri Jan  7 20:10:26 2011
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 07 Jan 2011 19:10:26 +0000
Subject: [issue10859] Is GeneratorContextManager public?
In-Reply-To: <1294427112.3.0.241437231702.issue10859@psf.upfronthosting.co.za>
Message-ID: <1294427426.3.0.00761824905774.issue10859@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Not clear; see #10838.

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10859>
_______________________________________

From report at bugs.python.org  Fri Jan  7 20:13:05 2011
From: report at bugs.python.org (Michael Foord)
Date: Fri, 07 Jan 2011 19:13:05 +0000
Subject: [issue10859] Is GeneratorContextManager public?
In-Reply-To: <1294427112.3.0.241437231702.issue10859@psf.upfronthosting.co.za>
Message-ID: <1294427585.66.0.943781847523.issue10859@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

There was a discussion on python-dev about naming conventions in the  standard library. There was no clear consensus that everything non-public should start with an underscore. Several developers thought that merely being undocumented or not present in __all__ was sufficient (evidently including Guido at the point he implemented this).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10859>
_______________________________________

From report at bugs.python.org  Fri Jan  7 20:14:30 2011
From: report at bugs.python.org (Shawn Ligocki)
Date: Fri, 07 Jan 2011 19:14:30 +0000
Subject: [issue10860] urllib2 crashes on valid URL
In-Reply-To: <1294427670.55.0.855321383674.issue10860@psf.upfronthosting.co.za>
Message-ID: <1294427670.55.0.855321383674.issue10860@psf.upfronthosting.co.za>


New submission from Shawn Ligocki <sligocki at gmail.com>:

urllib2 crashes with stack trace on legal URL http://118114.cn

Transcript:

Python 2.6.5 (r265:79063, Apr 16 2010, 13:57:41) 
[GCC 4.4.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import urllib2
>>> urllib2.urlopen("http://118114.cn")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python2.6/urllib2.py", line 126, in urlopen
    return _opener.open(url, data, timeout)
  File "/usr/lib/python2.6/urllib2.py", line 397, in open
    response = meth(req, response)
  File "/usr/lib/python2.6/urllib2.py", line 510, in http_response
    'http', request, response, code, msg, hdrs)
  File "/usr/lib/python2.6/urllib2.py", line 429, in error
    result = self._call_chain(*args)
  File "/usr/lib/python2.6/urllib2.py", line 369, in _call_chain
    result = func(*args)
  File "/usr/lib/python2.6/urllib2.py", line 605, in http_error_302
    return self.parent.open(new, timeout=req.timeout)
  File "/usr/lib/python2.6/urllib2.py", line 391, in open
    response = self._open(req, data)
  File "/usr/lib/python2.6/urllib2.py", line 409, in _open
    '_open', req)
  File "/usr/lib/python2.6/urllib2.py", line 369, in _call_chain
    result = func(*args)
  File "/usr/lib/python2.6/urllib2.py", line 1161, in http_open
    return self.do_open(httplib.HTTPConnection, req)
  File "/usr/lib/python2.6/urllib2.py", line 1107, in do_open
    h = http_class(host, timeout=req.timeout) # will parse host:port
  File "/usr/lib/python2.6/httplib.py", line 657, in __init__
    self._set_hostport(host, port)
  File "/usr/lib/python2.6/httplib.py", line 682, in _set_hostport
    raise InvalidURL("nonnumeric port: '%s'" % host[i+1:])
httplib.InvalidURL: nonnumeric port: ''
>>> 


I think the problem is that "http://118114.cn" says it redirects to "http://www.118114.cn:", but it seems like urllib2 should be able to deal with that or at least report back a more useful error message.

$ nc 118114.cn 80
GET / HTTP/1.1
Host: 118114.cn   
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101206 Ubuntu/10.04 (lucid) Firefox/3.6.13

HTTP/1.1 301 Moved Permanently
Server: nginx/0.7.64
Date: Fri, 07 Jan 2011 19:06:32 GMT
Content-Type: text/html
Content-Length: 185
Connection: keep-alive
Keep-Alive: timeout=60
Location: http://www.118114.cn:

<html>
<head><title>301 Moved Permanently</title></head>
<body bgcolor="white">
<center><h1>301 Moved Permanently</h1></center>
<hr><center>nginx/0.7.64</center>
</body>
</html>

----------
components: Library (Lib)
messages: 125687
nosy: sligocki
priority: normal
severity: normal
status: open
title: urllib2 crashes on valid URL
type: crash
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10860>
_______________________________________

From report at bugs.python.org  Fri Jan  7 20:15:43 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 07 Jan 2011 19:15:43 +0000
Subject: [issue10859] Is GeneratorContextManager public?
In-Reply-To: <1294427585.66.0.943781847523.issue10859@psf.upfronthosting.co.za>
Message-ID: <1294427732.3823.9.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> There was a discussion on python-dev about naming conventions in the
> standard library. There was no clear consensus that everything
> non-public should start with an underscore. Several developers thought
> that merely being undocumented or not present in __all__ was
> sufficient (evidently including Guido at the point he implemented
> this).

Underscoring makes it much clearer, though, that people shouldn't rely
on it.
At this point, GCM is only used in copies of the contextlib source code
and our own test_with, so we can still rename it.
(http://www.google.com/codesearch?hl=fr&sa=N&q=GeneratorContextManager )

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10859>
_______________________________________

From report at bugs.python.org  Fri Jan  7 20:18:38 2011
From: report at bugs.python.org (Michael Foord)
Date: Fri, 07 Jan 2011 19:18:38 +0000
Subject: [issue10859] Is GeneratorContextManager public?
In-Reply-To: <1294427112.3.0.241437231702.issue10859@psf.upfronthosting.co.za>
Message-ID: <1294427918.92.0.794782036615.issue10859@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

I have no objection to a rename that adds a leading underscore.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10859>
_______________________________________

From report at bugs.python.org  Fri Jan  7 20:20:01 2011
From: report at bugs.python.org (Ross Lagerwall)
Date: Fri, 07 Jan 2011 19:20:01 +0000
Subject: [issue10812] Add some posix functions
In-Reply-To: <1294058752.01.0.285856626146.issue10812@psf.upfronthosting.co.za>
Message-ID: <1294428001.98.0.478721020834.issue10812@psf.upfronthosting.co.za>


Ross Lagerwall <rosslagerwall at gmail.com> added the comment:

Thanks for the comments.

I implemented sethostid() - its not actually in the posix spec, but linux/*bsd
have it although the signature for FreeBSD is a bit different.

I implemented gethostname(). Both get/sethostname() now use FSDefault encoding.
gethostname() is null-terminated so it doesn't have to deal with embedded NULs.
sethostname() works with embedded NULs.

Since id_t can contain a pid_t, I now parse id_t with _Py_PARSE_PID.
waitid() also now returns a structsequence of the correct fields.

According to the spec, gethostid does not set errno - it now checks anyway.

Instead of PARSE_OFF_T, I use a O& parser.

----------
Added file: http://bugs.python.org/file20305/10812_v4.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10812>
_______________________________________

From report at bugs.python.org  Fri Jan  7 20:23:12 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 07 Jan 2011 19:23:12 +0000
Subject: [issue10860] urllib2 crashes on valid URL
In-Reply-To: <1294427670.55.0.855321383674.issue10860@psf.upfronthosting.co.za>
Message-ID: <1294428192.07.0.324681464606.issue10860@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Thanks for the report.  Can you test it with current versions (2.7, 3.1 or 3.2)?

----------
nosy: +eric.araujo, orsenthil
versions: +Python 2.7, Python 3.1, Python 3.2 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10860>
_______________________________________

From report at bugs.python.org  Fri Jan  7 20:24:24 2011
From: report at bugs.python.org (Michael Foord)
Date: Fri, 07 Jan 2011 19:24:24 +0000
Subject: [issue10859] Is GeneratorContextManager public?
In-Reply-To: <1294427112.3.0.241437231702.issue10859@psf.upfronthosting.co.za>
Message-ID: <1294428264.24.0.688586382975.issue10859@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/issue10859>
_______________________________________

From report at bugs.python.org  Fri Jan  7 20:37:32 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 07 Jan 2011 19:37:32 +0000
Subject: [issue10858] Make source code links less proeminent
In-Reply-To: <1294423770.11.0.311474750627.issue10858@psf.upfronthosting.co.za>
Message-ID: <1294429052.91.0.385132285698.issue10858@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <rhettinger at users.sourceforge.net>:


----------
assignee: docs at python -> rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10858>
_______________________________________

From report at bugs.python.org  Fri Jan  7 20:40:10 2011
From: report at bugs.python.org (R. David Murray)
Date: Fri, 07 Jan 2011 19:40:10 +0000
Subject: [issue10858] Make source code links less proeminent
In-Reply-To: <1294423770.11.0.311474750627.issue10858@psf.upfronthosting.co.za>
Message-ID: <1294429210.14.0.148028461308.issue10858@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

+1

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10858>
_______________________________________

From report at bugs.python.org  Fri Jan  7 20:41:58 2011
From: report at bugs.python.org (Shawn Ligocki)
Date: Fri, 07 Jan 2011 19:41:58 +0000
Subject: [issue10861] urllib2 sporadically falsely claims infinite redirect
In-Reply-To: <1294429318.76.0.578486353319.issue10861@psf.upfronthosting.co.za>
Message-ID: <1294429318.76.0.578486353319.issue10861@psf.upfronthosting.co.za>


New submission from Shawn Ligocki <sligocki at gmail.com>:

urllib2 sporadically falsely claims that http://www.bankofamerica.com/ has infinite redirect:


$ python -c 'import urllib2; print urllib2.urlopen("http://www.bankofamerica.com/").geturl()'
https://www.bankofamerica.com/

$ python -c 'import urllib2; print urllib2.urlopen("http://www.bankofamerica.com/").geturl()'
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/usr/lib/python2.6/urllib2.py", line 126, in urlopen
    return _opener.open(url, data, timeout)
  File "/usr/lib/python2.6/urllib2.py", line 397, in open
    response = meth(req, response)
  File "/usr/lib/python2.6/urllib2.py", line 510, in http_response
    'http', request, response, code, msg, hdrs)
  File "/usr/lib/python2.6/urllib2.py", line 429, in error
    result = self._call_chain(*args)
  File "/usr/lib/python2.6/urllib2.py", line 369, in _call_chain
    result = func(*args)
  File "/usr/lib/python2.6/urllib2.py", line 605, in http_error_302
    return self.parent.open(new, timeout=req.timeout)
  File "/usr/lib/python2.6/urllib2.py", line 397, in open
    response = meth(req, response)
  File "/usr/lib/python2.6/urllib2.py", line 510, in http_response
    'http', request, response, code, msg, hdrs)
  File "/usr/lib/python2.6/urllib2.py", line 429, in error
    result = self._call_chain(*args)
  File "/usr/lib/python2.6/urllib2.py", line 369, in _call_chain
    result = func(*args)
  File "/usr/lib/python2.6/urllib2.py", line 605, in http_error_302
    return self.parent.open(new, timeout=req.timeout)
  File "/usr/lib/python2.6/urllib2.py", line 397, in open
    response = meth(req, response)
  File "/usr/lib/python2.6/urllib2.py", line 510, in http_response
    'http', request, response, code, msg, hdrs)
  File "/usr/lib/python2.6/urllib2.py", line 429, in error
    result = self._call_chain(*args)
  File "/usr/lib/python2.6/urllib2.py", line 369, in _call_chain
    result = func(*args)
  File "/usr/lib/python2.6/urllib2.py", line 605, in http_error_302
    return self.parent.open(new, timeout=req.timeout)
  File "/usr/lib/python2.6/urllib2.py", line 397, in open
    response = meth(req, response)
  File "/usr/lib/python2.6/urllib2.py", line 510, in http_response
    'http', request, response, code, msg, hdrs)
  File "/usr/lib/python2.6/urllib2.py", line 429, in error
    result = self._call_chain(*args)
  File "/usr/lib/python2.6/urllib2.py", line 369, in _call_chain
    result = func(*args)
  File "/usr/lib/python2.6/urllib2.py", line 605, in http_error_302
    return self.parent.open(new, timeout=req.timeout)
  File "/usr/lib/python2.6/urllib2.py", line 397, in open
    response = meth(req, response)
  File "/usr/lib/python2.6/urllib2.py", line 510, in http_response
    'http', request, response, code, msg, hdrs)
  File "/usr/lib/python2.6/urllib2.py", line 429, in error
    result = self._call_chain(*args)
  File "/usr/lib/python2.6/urllib2.py", line 369, in _call_chain
    result = func(*args)
  File "/usr/lib/python2.6/urllib2.py", line 595, in http_error_302
    self.inf_msg + msg, headers, fp)
urllib2.HTTPError: HTTP Error 302: The HTTP server returned a redirect error that would lead to an infinite loop.
The last 30x error message was:
Found



Since it is sporadic, it could just be a problem with bankofamerica.com's servers. Is there an easy way to see what response urllib2 got that made it unhappy?

----------
components: Library (Lib)
messages: 125693
nosy: sligocki
priority: normal
severity: normal
status: open
title: urllib2 sporadically falsely claims infinite redirect
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10861>
_______________________________________

From report at bugs.python.org  Fri Jan  7 20:43:01 2011
From: report at bugs.python.org (xiscu)
Date: Fri, 07 Jan 2011 19:43:01 +0000
Subject: [issue10862] Complete your registration to Python tracker --
	key	yq3FVw0zXbfo3RJCzK2PqphC2n0XTohy
In-Reply-To: <20110107194123.412F61D41A@psf.upfronthosting.co.za>
Message-ID: <4D276CCA.2050406@email.de>


New submission from xiscu <xiscu at email.de>:

On 01/07/2011 08:41 PM, Python tracker wrote:
> To complete your registration of the user "xiscu" with
> Python tracker, please do one of the following:
>
> - send a reply to report at bugs.python.org and maintain the subject line as is (the
> reply's additional "Re:" is ok),
>
> - or visit the following URL:
>
> http://bugs.python.org/?@action=confrego&otk=yq3FVw0zXbfo3RJCzK2PqphC2n0XTohy
>
>
>

----------
messages: 125694
nosy: xiscu
priority: normal
severity: normal
status: open
title: Complete your registration to Python tracker -- key	yq3FVw0zXbfo3RJCzK2PqphC2n0XTohy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10862>
_______________________________________

From report at bugs.python.org  Fri Jan  7 20:43:50 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 07 Jan 2011 19:43:50 +0000
Subject: [issue10862] Complete your registration to Python tracker --
	key	yq3FVw0zXbfo3RJCzK2PqphC2n0XTohy
In-Reply-To: <4D276CCA.2050406@email.de>
Message-ID: <1294429430.8.0.817172317431.issue10862@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10862>
_______________________________________

From report at bugs.python.org  Fri Jan  7 20:46:57 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 07 Jan 2011 19:46:57 +0000
Subject: [issue10861] urllib2 sporadically falsely claims infinite redirect
In-Reply-To: <1294429318.76.0.578486353319.issue10861@psf.upfronthosting.co.za>
Message-ID: <1294429617.36.0.251815728045.issue10861@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Apparently, it's a problem on bankofamerica.com:

$ curl -v https://www.bankofamerica.com/
* About to connect() to www.bankofamerica.com port 443 (#0)
*   Trying 171.161.148.173... connected
* Connected to www.bankofamerica.com (171.161.148.173) port 443 (#0)
* successfully set certificate verify locations:
*   CAfile: /etc/pki/tls/certs/ca-bundle.crt
  CApath: none
* SSLv3, TLS handshake, Client hello (1):
* SSLv3, TLS handshake, Server hello (2):
* SSLv3, TLS handshake, CERT (11):
* SSLv3, TLS handshake, Server finished (14):
* SSLv3, TLS handshake, Client key exchange (16):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSL connection using RC4-MD5
* Server certificate:
* 	 subject: 1.3.6.1.4.1.311.60.2.1.3=US; 1.3.6.1.4.1.311.60.2.1.2=Delaware; businessCategory=V1.0, Clause 5.(b); serialNumber=2927442; C=US; postalCode=75202; ST=Texas; L=Dallas; street=1201 Main Street; O=Bank of America Corporation; OU=WebSphere Ecomm; CN=www.banko
* 	 start date: 2010-02-24 00:00:00 GMT
* 	 expire date: 2011-03-06 23:59:59 GMT
* 	 common name: www.bankofamerica.com (matched)
* 	 issuer: C=US; O=VeriSign, Inc.; OU=VeriSign Trust Network; OU=Terms of use at https://www.verisign.com/rpa (c)06; CN=VeriSign Class 3 Extended Validation SSL CA
* 	 SSL certificate verify ok.
> GET / HTTP/1.1
> User-Agent: curl/7.20.1 (x86_64-mandriva-linux-gnu) libcurl/7.20.1 OpenSSL/1.0.0a zlib/1.2.3 libidn/1.18 libssh2/1.2.5
> Host: www.bankofamerica.com
> Accept: */*
> 
< HTTP/1.1 302 Found
< Server: Sun-ONE-Web-Server/6.1
< Date: Fri, 07 Jan 2011 19:45:49 GMT
< Content-length: 0
< Content-type: text/html
< Set-Cookie: TLTSID=BAA36B1C1A96101A7D01FB668166E60D; Path=/; Domain=.bankofamerica.com
< Set-Cookie: TLTUID=BAA36B1C1A96101A7D01FB668166E60D; Path=/; Domain=.bankofamerica.com; Expires=Fri, 07-01-2021 19:45:49 GMT
< Location: https://www.bankofamerica.com/
< Content-language: en-US
< Set-cookie: JSESSIONID=0000WgLDVaDtim2XXER98OGo6OA:12rfuebu8; Path=/
< Set-cookie: INTL_LANG=en_US
< Set-cookie: ngen_throttle=750; Expires=Wed, 06 Jul 2011 19:45:49 GMT; Path=/; Domain=.bankofamerica.com
< Set-cookie: hp_beta=B; Expires=Wed, 06 Jul 2011 19:45:49 GMT; Path=/; Domain=.bankofamerica.com
< Set-cookie: BOA_0020=20110107:0:E:961E3F55-9482-01f4-00000000BFA6871D; Expires=Wed, 25 Jan 2079 22:59:56 GMT; Domain=.bankofamerica.com
< Set-cookie: BOA_COM_BT_ELIGIBLE=No; Expires=Fri, 14 Jan 2011 19:45:49 GMT; Domain=.bankofamerica.com
< Expires: Thu, 01 Dec 1994 16:00:00 GMT
< Cache-control: no-cache="set-cookie, set-cookie2"
< 
* Connection #0 to host www.bankofamerica.com left intact
* Closing connection #0
* SSLv3, TLS alert, Client hello (1):

----------
nosy: +orsenthil, pitrou
resolution:  -> invalid
status: open -> closed
versions: +Python 2.7, Python 3.1, Python 3.2 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10861>
_______________________________________

From report at bugs.python.org  Fri Jan  7 20:48:13 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 07 Jan 2011 19:48:13 +0000
Subject: [issue10861] urllib2 sporadically falsely claims infinite redirect
In-Reply-To: <1294429318.76.0.578486353319.issue10861@psf.upfronthosting.co.za>
Message-ID: <1294429693.22.0.788400187961.issue10861@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Actually, perhaps the redirection loop would stop if we would send back those cookies which the server sends us. So perhaps it's a feature request rather.
(but this still strikes me as a very poor use of HTTP)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10861>
_______________________________________

From report at bugs.python.org  Fri Jan  7 20:49:12 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 07 Jan 2011 19:49:12 +0000
Subject: [issue10841] binary stdio
In-Reply-To: <1294279917.2.0.685442041198.issue10841@psf.upfronthosting.co.za>
Message-ID: <1294429752.0.0.287687733599.issue10841@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Tests pass on Windows 7 buildbot, the two other XP buildbots have unrelated issues. I also tested on my XP VM: all tests pass. So I close this issue.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10841>
_______________________________________

From report at bugs.python.org  Fri Jan  7 20:50:06 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 07 Jan 2011 19:50:06 +0000
Subject: [issue4953] cgi module cannot handle POST with multipart/form-data
	in	3.0
In-Reply-To: <1232010166.79.0.972664060868.issue4953@psf.upfronthosting.co.za>
Message-ID: <1294429806.97.0.785191977494.issue4953@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

I fixed #10841 (r87824): stdin (and all other files) is now set to binary (instead of text) mode on Windows.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4953>
_______________________________________

From report at bugs.python.org  Fri Jan  7 20:51:39 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 07 Jan 2011 19:51:39 +0000
Subject: [issue10858] Make source code links less proeminent
In-Reply-To: <1294423770.11.0.311474750627.issue10858@psf.upfronthosting.co.za>
Message-ID: <1294429899.15.0.256101038794.issue10858@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Please leave these alone for the time being. I put them high on the page so that people would have a consistent and easy to find view-source link.  It is an experiment and time will tell whether it was a good choice.  For the time being, I don't want it buried.  

The goal is to reacquaint people with the source as an adjunct to the docs.  The phrase use-the-source-luke used to be common in the python community but now many devs don't seem to be able to readily access the source (with it tucked away in a library directory).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10858>
_______________________________________

From report at bugs.python.org  Fri Jan  7 20:56:47 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 07 Jan 2011 19:56:47 +0000
Subject: [issue10858] Make source code links less proeminent
In-Reply-To: <1294429899.15.0.256101038794.issue10858@psf.upfronthosting.co.za>
Message-ID: <1294430201.3823.12.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> The goal is to reacquaint people with the source as an adjunct to the
> docs.  The phrase use-the-source-luke used to be common in the python
> community but now many devs don't seem to be able to readily access
> the source (with it tucked away in a library directory).

I don't think someone "not able to readily access the source" from a
link at the *bottom* of a doc page would be able to understand (or even
be motivated to understand) the stdlib's source code.

While I understand the motivation to encourage reading of the source
code, this should not disrupt the sequential reading of documentation
pages, or make it seem more important than the API docs themselves.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10858>
_______________________________________

From report at bugs.python.org  Fri Jan  7 21:01:32 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 07 Jan 2011 20:01:32 +0000
Subject: [issue10860] Handle empty port after port delimiter in httplib
In-Reply-To: <1294427670.55.0.855321383674.issue10860@psf.upfronthosting.co.za>
Message-ID: <1294430492.33.0.228077408372.issue10860@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

The redirection is a red hearing, the error is clearly that an empty port after a port delimiter (like in http://host:) breaks httplib.  Do you want to work on a patch?  Helpful guidelines are found at http://www.python.org/dev/patches/

----------
stage:  -> needs patch
title: urllib2 crashes on valid URL -> Handle empty port after port delimiter in httplib
type: crash -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10860>
_______________________________________

From report at bugs.python.org  Fri Jan  7 21:02:51 2011
From: report at bugs.python.org (Jose-Luis Fernandez-Barros)
Date: Fri, 07 Jan 2011 20:02:51 +0000
Subject: [issue10863] zlib.compress() fails with string
In-Reply-To: <1294430571.2.0.193589316262.issue10863@psf.upfronthosting.co.za>
Message-ID: <1294430571.2.0.193589316262.issue10863@psf.upfronthosting.co.za>


New submission from Jose-Luis Fernandez-Barros <jlfbarros at gmail.com>:

On "The Python Tutorial", section 10.9. Data Compression
  http://docs.python.org/py3k/tutorial/stdlib.html#data-compression

>>> import zlib
>>> s = 'witch which has which witches wrist watch'
...
>>> t = zlib.compress(s)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: must be bytes or buffer, not str

Possible solution (sorry, newbie) are:
>>> s = b'witch which has which witches wrist watch'
or
>>> s = 'witch which has which witches wrist watch'.encode("utf-8")


At "The Python Standard Library", secction 12. Data Compression and Archiving
  http://docs.python.org/py3k/library/zlib.html#module-zlib
apparently example is correct:
  zlib.compress(string[, level])

----------
assignee: docs at python
components: Documentation
messages: 125702
nosy: docs at python, joseluisfb
priority: normal
severity: normal
status: open
title: zlib.compress() fails with string
type: compile error
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10863>
_______________________________________

From report at bugs.python.org  Fri Jan  7 21:03:34 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 07 Jan 2011 20:03:34 +0000
Subject: [issue10838] subprocess __all__ is incomplete
In-Reply-To: <1294260769.5.0.0970426129524.issue10838@psf.upfronthosting.co.za>
Message-ID: <1294430614.65.0.61796359223.issue10838@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/issue10838>
_______________________________________

From report at bugs.python.org  Fri Jan  7 21:14:43 2011
From: report at bugs.python.org (Glenn Linderman)
Date: Fri, 07 Jan 2011 20:14:43 +0000
Subject: [issue10841] binary stdio
In-Reply-To: <1294279917.2.0.685442041198.issue10841@psf.upfronthosting.co.za>
Message-ID: <1294431283.04.0.102278246998.issue10841@psf.upfronthosting.co.za>


Glenn Linderman <v+python at g.nevcal.com> added the comment:

Thanks for your work on this Victor, and other commenters also.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10841>
_______________________________________

From report at bugs.python.org  Fri Jan  7 21:27:11 2011
From: report at bugs.python.org (Shawn Ligocki)
Date: Fri, 07 Jan 2011 20:27:11 +0000
Subject: [issue10860] Handle empty port after port delimiter in httplib
In-Reply-To: <1294427670.55.0.855321383674.issue10860@psf.upfronthosting.co.za>
Message-ID: <1294432031.43.0.00368797110757.issue10860@psf.upfronthosting.co.za>


Shawn Ligocki <sligocki at gmail.com> added the comment:

Sure, I can work on a patch.

Should an empty port default to 80? In other words does "http://foo.com/" == "http://foo.com:/"?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10860>
_______________________________________

From report at bugs.python.org  Fri Jan  7 21:30:14 2011
From: report at bugs.python.org (Shawn Ligocki)
Date: Fri, 07 Jan 2011 20:30:14 +0000
Subject: [issue10861] urllib2 sporadically falsely claims infinite redirect
In-Reply-To: <1294429318.76.0.578486353319.issue10861@psf.upfronthosting.co.za>
Message-ID: <1294432214.78.0.929334346693.issue10861@psf.upfronthosting.co.za>


Shawn Ligocki <sligocki at gmail.com> added the comment:

Ahha, what a mess, thanks for investigating! I agree, this is bankofamerica's problem.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10861>
_______________________________________

From report at bugs.python.org  Fri Jan  7 21:33:58 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 07 Jan 2011 20:33:58 +0000
Subject: [issue10860] Handle empty port after port delimiter in httplib
In-Reply-To: <1294427670.55.0.855321383674.issue10860@psf.upfronthosting.co.za>
Message-ID: <1294432438.88.0.104653116653.issue10860@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Yes.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10860>
_______________________________________

From report at bugs.python.org  Fri Jan  7 21:39:50 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 07 Jan 2011 20:39:50 +0000
Subject: [issue10827] Functions in time module should support year < 1900 when
	accept2dyear = 0
In-Reply-To: <1294159712.85.0.42147185487.issue10827@psf.upfronthosting.co.za>
Message-ID: <1294432790.29.0.0450002308419.issue10827@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Committed in 87829.

I added a year >= 1900 check in time.strftime for now because removing or relaxing this limit should be done in coordination with similar datetime module issue.  See #1777412.

See also python-dev discussion starting at

http://mail.python.org/pipermail/python-dev/2011-January/107186.html

----------
resolution:  -> fixed
stage: commit review -> committed/rejected
superseder:  -> datetime.strftime dislikes years before 1900
versions: +Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10827>
_______________________________________

From report at bugs.python.org  Fri Jan  7 21:41:53 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 07 Jan 2011 20:41:53 +0000
Subject: [issue10827] Functions in time module should support year < 1900 when
	accept2dyear = 0
In-Reply-To: <1294159712.85.0.42147185487.issue10827@psf.upfronthosting.co.za>
Message-ID: <1294432913.45.0.276059207348.issue10827@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Commit link: r87829

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10827>
_______________________________________

From report at bugs.python.org  Fri Jan  7 22:02:29 2011
From: report at bugs.python.org (xiscu)
Date: Fri, 07 Jan 2011 21:02:29 +0000
Subject: [issue809163] Can't add files with spaces
Message-ID: <1294434149.93.0.914656748962.issue809163@psf.upfronthosting.co.za>


xiscu <xiscu at email.de> added the comment:

This is also my first contribution.

The attached file is a diff against :
- http://code.python.org/hg/branches/py3k/

The actual tip was:
- 9489:4db13b4e76aa

The patch adds only a test that triggers the issue.

Please feel free to comment on that commit (so I can improve)

Thanks

----------
nosy: +xiscu
Added file: http://bugs.python.org/file20306/test_bdist_rpm_filename_with_whitespaces.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue809163>
_______________________________________

From report at bugs.python.org  Fri Jan  7 22:05:00 2011
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 07 Jan 2011 21:05:00 +0000
Subject: [issue10860] Handle empty port after port delimiter in httplib
In-Reply-To: <1294427670.55.0.855321383674.issue10860@psf.upfronthosting.co.za>
Message-ID: <1294434300.17.0.365779581084.issue10860@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Except if it's an HTTPS URL :)

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10860>
_______________________________________

From report at bugs.python.org  Fri Jan  7 22:18:00 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 07 Jan 2011 21:18:00 +0000
Subject: [issue10858] Make source code links less prominent
In-Reply-To: <1294423770.11.0.311474750627.issue10858@psf.upfronthosting.co.za>
Message-ID: <1294435080.29.0.970097612809.issue10858@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

As Raymond explained, he added these links as a kind of social experiment and this issue itself shows that it works. :-)

I have a few suggestions on how to make these links more useful:

1. A ViewVC link is the simplest solution to present the source, but the way it presents the source code looks foreign to sphinx docs.  It would be better if the source was formatted similarly to the source examples embedded in doc pages.

2. It would be great to have at least module names hyperlinked in the source views to aid code navigation.

3. I would rather see source links appear consistently for each module and not just for an ad-hoc selection.

4. The side bar already has a "Show Source" link which takes to the reST source of the page.  I don't think this is very useful.  Maybe this link should point to the Python source or a separate "python source" link should appear next to it.

----------
nosy: +belopolsky
title: Make source code links less proeminent -> Make source code links less prominent

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10858>
_______________________________________

From report at bugs.python.org  Fri Jan  7 22:30:56 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 07 Jan 2011 21:30:56 +0000
Subject: [issue10858] Make source code links less prominent
In-Reply-To: <1294435080.29.0.970097612809.issue10858@psf.upfronthosting.co.za>
Message-ID: <1294435848.3823.15.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> I have a few suggestions on how to make these links more useful:

The question is not how they could be more useful, but *whether* they
are useful at all. An user skilled enough to read the source code is
probably skilled enough not to require a prominently displayed link at
the top of each doc page.

I agree that visual appearance of the ViewVC pages could be better but
that's a separate issue altogether.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10858>
_______________________________________

From report at bugs.python.org  Fri Jan  7 22:32:23 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 07 Jan 2011 21:32:23 +0000
Subject: [issue10858] Make source code links less prominent
In-Reply-To: <1294423770.11.0.311474750627.issue10858@psf.upfronthosting.co.za>
Message-ID: <1294435943.46.0.999211081532.issue10858@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

1: I hope this will just be a matter of using the same Pygments theme in Sphinx and hgweb.

2: I don?t think hgweb can do that.  Mercurial being extensible, this addition may be a fun project.

3: Not all modules are good examples (see threading for some unelegant code), so I support ad-hoc selection.  I also support the real fix of improving the quality of every module, but that?s longer-term. :)

4: ?Show Source? is a link that is easily overlooked IMO, a seealso section makes me think people will actually see the link.  There is also the minor concern of breaking expectations of people accustomed to Sphinx.

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10858>
_______________________________________

From report at bugs.python.org  Fri Jan  7 22:41:59 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 07 Jan 2011 21:41:59 +0000
Subject: [issue10827] Functions in time module should support year < 1900 when
	accept2dyear = 0
In-Reply-To: <1294159712.85.0.42147185487.issue10827@psf.upfronthosting.co.za>
Message-ID: <1294436519.3.0.229541347933.issue10827@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

I tried time.asctime() on Windows 32 bits (compiled with Visual Studio) with accept2dyear=False: it accepts years in [-2^31; 2^31-1], cool.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10827>
_______________________________________

From report at bugs.python.org  Fri Jan  7 22:45:52 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 07 Jan 2011 21:45:52 +0000
Subject: [issue8844] Condition.wait() doesn't raise KeyboardInterrupt
In-Reply-To: <1275065292.27.0.238026363438.issue8844@psf.upfronthosting.co.za>
Message-ID: <1294436752.41.0.474179147135.issue8844@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

The test fails on FreeBSD 6.2 (x86 FreeBSD py3k buildbot) since r87292 => #10720. I reopen the issue.

----------
nosy: +haypo
resolution: fixed -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8844>
_______________________________________

From report at bugs.python.org  Fri Jan  7 22:51:49 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 07 Jan 2011 21:51:49 +0000
Subject: [issue8020] Crash in Py_ADDRESS_IN_RANGE macro
In-Reply-To: <1267133662.17.0.467128574772.issue8020@psf.upfronthosting.co.za>
Message-ID: <1294437109.39.0.110275102961.issue8020@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I've committed Matt's patch in r87835 (3.2), r87836 (3.1) and r87837 (2.7). Thank you for contributing!

----------
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed
versions:  -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8020>
_______________________________________

From report at bugs.python.org  Fri Jan  7 22:52:01 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 07 Jan 2011 21:52:01 +0000
Subject: [issue10858] Make source code links less prominent
In-Reply-To: <1294435943.46.0.999211081532.issue10858@psf.upfronthosting.co.za>
Message-ID: <AANLkTinjsCjNkuGENAe3YXJ-mjyc-g3mCeVUxTAZcCxy@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Fri, Jan 7, 2011 at 4:32 PM, ?ric Araujo <report at bugs.python.org> wrote:
..
> 3: Not all modules are good examples (see threading for some unelegant code), so I support ad-hoc selection.

The problem with ad-hoc selection is that it adds maintenance burden
(someone has to make a call) and it is inherently subjective.  For
example, I find dis.py source code rather uninspiring while
pickletools.py has a trove of valuable information about pickle
opcodes that is not available elsewhere.

> ?I also support the real fix of improving the quality of every module, but that?s longer-term. :)

Having the sources on "public display" may help achieving this goal.

> 4: ?Show Source? is a link that is easily overlooked IMO, a seealso section makes me think people
> will actually see the link.

A side-bar link may be in addition to the more prominent but less
common "See also" links.  If the source navigation becomes available,
we can also add inconspicuous links to function sectoins that would
take you directly to the function source code.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10858>
_______________________________________

From report at bugs.python.org  Fri Jan  7 22:52:30 2011
From: report at bugs.python.org (Mher Movsisyan)
Date: Fri, 07 Jan 2011 21:52:30 +0000
Subject: [issue10174] multiprocessing expects sys.stdout to have a
	fileno/close method.
In-Reply-To: <1287789739.18.0.21420008091.issue10174@psf.upfronthosting.co.za>
Message-ID: <1294437150.24.0.332447296721.issue10174@psf.upfronthosting.co.za>


Mher Movsisyan <mher.movsisyan at gmail.com> added the comment:

The reported error is only reproducible in 2.6

Python 2.6.1 (r261:67515, Jun 24 2010, 21:47:49) 
[GCC 4.2.1 (Apple Inc. build 5646)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> import multiprocessing
>>> class A:pass
... 
>>> sys.stdin=A()
>>> p=multiprocessing.Pool(processes=2)
Process PoolWorker-1:
Traceback (most recent call last):
  File "/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/multiprocessing/process.py", line 223, in _bootstrap
Process PoolWorker-2:
Traceback (most recent call last):
    os.close(sys.stdin.fileno())
AttributeError: A instance has no attribute 'fileno'
>>>   File "/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/multiprocessing/process.py", line 223, in _bootstrap
    os.close(sys.stdin.fileno())
AttributeError: A instance has no attribute 'fileno'

----------
nosy: +mher

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10174>
_______________________________________

From report at bugs.python.org  Fri Jan  7 22:55:05 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 07 Jan 2011 21:55:05 +0000
Subject: [issue8844] Condition.wait() doesn't raise KeyboardInterrupt
In-Reply-To: <1275065292.27.0.238026363438.issue8844@psf.upfronthosting.co.za>
Message-ID: <1294437305.91.0.486880138734.issue8844@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Well, since #10720 exists, while do you reopen this one?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8844>
_______________________________________

From report at bugs.python.org  Fri Jan  7 23:02:55 2011
From: report at bugs.python.org (Mher Movsisyan)
Date: Fri, 07 Jan 2011 22:02:55 +0000
Subject: [issue10174] multiprocessing expects sys.stdout to have a
	fileno/close method.
In-Reply-To: <1287789739.18.0.21420008091.issue10174@psf.upfronthosting.co.za>
Message-ID: <1294437775.85.0.986423850561.issue10174@psf.upfronthosting.co.za>


Mher Movsisyan <mher.movsisyan at gmail.com> added the comment:

This bug was fixed in #5313

--- a/multiprocessing/process.py
+++ b/multiprocessing/process.py
@@ -225,7 +225,8 @@ class Process(object):
             self._children = set()
             self._counter = itertools.count(1)
             try:
-                os.close(sys.stdin.fileno())
+                sys.stdin.close()
+                sys.stdin = open(os.devnull)
             except (OSError, ValueError):
                 pass
             _current_process = self

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10174>
_______________________________________

From report at bugs.python.org  Fri Jan  7 23:25:00 2011
From: report at bugs.python.org (Daniel Black)
Date: Fri, 07 Jan 2011 22:25:00 +0000
Subject: [issue10851] further extend ssl SNI and ciphers API
In-Reply-To: <1294363252.79.0.602058607156.issue10851@psf.upfronthosting.co.za>
Message-ID: <1294439100.37.0.64749133334.issue10851@psf.upfronthosting.co.za>


Daniel Black <daniel.subs at internode.on.net> added the comment:

acknowledged. Makes sense.

----------
resolution:  -> rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10851>
_______________________________________

From report at bugs.python.org  Fri Jan  7 23:29:02 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 07 Jan 2011 22:29:02 +0000
Subject: [issue10829] PyUnicode_FromFormatV() bugs with "%" and "%%" format
	strings
In-Reply-To: <1294188403.72.0.24360709681.issue10829@psf.upfronthosting.co.za>
Message-ID: <1294439342.15.0.276922338001.issue10829@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> PyBytes_FromFormatV() has the same issue.

Oh no, it's ok, the function works as expected.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10829>
_______________________________________

From report at bugs.python.org  Fri Jan  7 23:40:42 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 07 Jan 2011 22:40:42 +0000
Subject: [issue6284] C/API PyErr_AsUnicode()
In-Reply-To: <1244999019.35.0.083174578591.issue6284@psf.upfronthosting.co.za>
Message-ID: <1294440042.57.0.210635224485.issue6284@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

+	PyErr_Fetch(&error_type, &error_value, &error_traceback);
+	
+	PyErr_Clear();

I think that the call to PyErr_Clear() is useless, PyErr_Fetch() already cleared the exception.

+	/* clear the error */
+	PyErr_Restore(error_type, error_value, error_traceback);
+	PyErr_Clear();

Why do you restore the error if you clear it directly? I think that at this position, there is no current exception. So it may be simplified as:

Py_DECREF(error_type);
Py_DECREF(error_value);
Py_DECREF(error_traceback);

I suppose here that all these 3 variables are not NULL.

+	if(! (string_io_mod= PyImport_ImportModule("io")) ) {
+		PyErr_Clear();
+		return NULL;
+	}
+	else if (! (string_io= PyObject_CallMethod(string_io_mod, "StringIO", NULL))) {
+		PyErr_Clear();
+		Py_DECREF(string_io_mod);
+		return NULL;
+	}
+	else if (! (string_io_getvalue= PyObject_GetAttrString(string_io, "getvalue"))) {
+		PyErr_Clear();
+		Py_DECREF(string_io_mod);
+		Py_DECREF(string_io);
+		return NULL;
+	}

Minor style remark: you can remove the "else" keywords here.

You should factorize the error handling at the end using "goto error;" with a error handler looking like:
------------
   ...
   goto finally;

error:
   PyErr_Clear();
   Py_CLEAR(stringio_buf);
finally:
   Py_XDECREF(string_io_mod);
   Py_XDECREF(string_io);
   Py_XDECREF(string_io_getvalue);
   return NULL;
------------
In my opinion, it's easier to maintain it, and more readable.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6284>
_______________________________________

From report at bugs.python.org  Fri Jan  7 23:45:12 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 07 Jan 2011 22:45:12 +0000
Subject: [issue6284] C/API PyErr_AsUnicode()
In-Reply-To: <1244999019.35.0.083174578591.issue6284@psf.upfronthosting.co.za>
Message-ID: <1294440312.54.0.327391350734.issue6284@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

/* Returns the exception string as a new
   PyUnicode object or NULL if the conversion failed */

NULL is not very useful to analyze the error :-/ Why don't keep errors if the conversion failed? The caller will be responsible to use the new error, or to clear it.

If PyErr_AsUnicode() raises a new error on conversion error, you should raise an error on:

+	if (!PyErr_Occurred())
+		return NULL;

On keep PyImport_ImportModule(), PyObject_CallMethod() and PyObject_GetAttrString() error.

Oh, by the way, PyErr_AsUnicode returns NULL and raise an error if PyObject_CallObject() failed (if StringIO().getvalue() failed).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6284>
_______________________________________

From report at bugs.python.org  Fri Jan  7 23:59:49 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 07 Jan 2011 22:59:49 +0000
Subject: [issue1777412] datetime.strftime dislikes years before 1900
Message-ID: <1294441189.56.0.301640685718.issue1777412@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

After r87829 (see issue10827), the insane Y2K behavior of time module functions does not extend beyond year 999.  Hopefully in Python 3.3, accept2dyear will be removed completely and datetime.strftime() will be able to support the full intersection of platform year range with that of datetime type.  Meanwhile, I propose a simple patch that lowers the 1900 limit down to 1000.  I was not able to find any evidence that there are platforms that have issues with formatting years between 1000 and 1899.

Are there any objections to committing this patch?  I will monitor the build bots if I see failures, I'll modify the test and/or add a platform-specific check to fix them.

----------
dependencies: +Functions in time module should support year < 1900 when accept2dyear = 0
stage: patch review -> commit review
Added file: http://bugs.python.org/file20307/issue1777412.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1777412>
_______________________________________

From report at bugs.python.org  Sat Jan  8 00:12:51 2011
From: report at bugs.python.org (=?utf-8?q?Andreas_St=C3=BChrk?=)
Date: Fri, 07 Jan 2011 23:12:51 +0000
Subject: [issue6284] C/API PyErr_AsUnicode()
In-Reply-To: <1244999019.35.0.083174578591.issue6284@psf.upfronthosting.co.za>
Message-ID: <1294441971.76.0.0762983225509.issue6284@psf.upfronthosting.co.za>


Andreas St?hrk <andy-python at hammerhartes.de> added the comment:

There should also be a call to `PyErr_NormalizeException()`, as `PyErr_Fetch()` can return unnormalized exceptions (see e.g. issue #10756).

----------
nosy: +Trundle

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6284>
_______________________________________

From report at bugs.python.org  Sat Jan  8 00:28:19 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Fri, 07 Jan 2011 23:28:19 +0000
Subject: [issue10854] Output DLL name in error message of ImportError when DLL
	is missing
In-Reply-To: <1294415325.09.0.315523226252.issue10854@psf.upfronthosting.co.za>
Message-ID: <1294442899.84.0.425187733071.issue10854@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Closing this as "won't fix". Python is not going to reimplement depends.exe.

----------
nosy: +loewis
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10854>
_______________________________________

From report at bugs.python.org  Sat Jan  8 00:28:39 2011
From: report at bugs.python.org (R. David Murray)
Date: Fri, 07 Jan 2011 23:28:39 +0000
Subject: [issue10686] email.Generator should use unknown-8bit encoded words
	for headers with 8 bit data
In-Reply-To: <1292176909.21.0.316774202966.issue10686@psf.upfronthosting.co.za>
Message-ID: <1294442919.97.0.565151181823.issue10686@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Committed a revised version of the patch, including doc updates, in r87840.  While I haven't documented the way to alter what encoding name is used for the unknown bytes, I did make it possible to do so (set charset.UNKNOWN8BIT to the desired string).

----------
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10686>
_______________________________________

From report at bugs.python.org  Sat Jan  8 00:40:26 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Fri, 07 Jan 2011 23:40:26 +0000
Subject: [issue10812] Add some posix functions
In-Reply-To: <1294391959.02.0.642168643566.issue10812@psf.upfronthosting.co.za>
Message-ID: <4D27A467.1020807@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> According to the spec for gethostname(), the hostname that it returns
> is null-terminated so it won't support embedded NUL bytes. Should we
> still add it anyway?

Oops, I misread the spec. No, gethostname should then not be duplicated.
Putting sethostname into the socket module might be worth considering,
though; I find the proposed split confusing.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10812>
_______________________________________

From report at bugs.python.org  Sat Jan  8 00:44:50 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Fri, 07 Jan 2011 23:44:50 +0000
Subject: [issue10812] Add some posix functions
In-Reply-To: <1294428001.98.0.478721020834.issue10812@psf.upfronthosting.co.za>
Message-ID: <4D27A51C.3040804@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> According to the spec, gethostid does not set errno - it now checks anyway.

Sorry, I misread that also. Leaving the check is fine; reverting it to
the previous code would be fine as well.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10812>
_______________________________________

From report at bugs.python.org  Sat Jan  8 00:51:56 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Fri, 07 Jan 2011 23:51:56 +0000
Subject: [issue10512] regrtest ResourceWarning - unclosed sockets and files
In-Reply-To: <1290506536.77.0.313292165719.issue10512@psf.upfronthosting.co.za>
Message-ID: <1294444316.69.0.618751710529.issue10512@psf.upfronthosting.co.za>


Nadeem Vawda <nadeem.vawda at gmail.com> added the comment:

Sorry, scratch that - I misunderstood the semantics of SocketIO.close(). I hadn't realized that the underlying socket is supposed to stay open until it itself is also explicitly closed (as well as all SocketIO objects referring to it).

I've been able to get rid of 2 of the 7 warnings in test_urllib2net with the following change:

  diff --git a/Lib/urllib/request.py b/Lib/urllib/request.py
  --- a/Lib/urllib/request.py
  +++ b/Lib/urllib/request.py
  @@ -2151,7 +2151,9 @@
               conn = self.ftp.ntransfercmd(cmd)
           self.busy = 1
           # Pass back both a suitably decorated object and a retrieval length
  -        return (addclosehook(conn[0].makefile('rb'), self.endtransfer), conn[1])
  +        fp = addclosehook(conn[0].makefile('rb'), self.endtransfer)
  +        conn[0].close()
  +        return (fp, conn[1])
       def endtransfer(self):
           if not self.busy:
               return

It seems that most of the remaining warnings are the result of FTPHandler.ftp_open() not doing anything to close the ftpwrapper objects it creates. I haven't been able to figure out exactly what the correct place to do this is, though.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10512>
_______________________________________

From report at bugs.python.org  Sat Jan  8 01:02:55 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 08 Jan 2011 00:02:55 +0000
Subject: [issue10834] Python 2.7 x86 IDLE fails to run in Windows 7
In-Reply-To: <1294224063.9.0.656095341139.issue10834@psf.upfronthosting.co.za>
Message-ID: <1294444975.28.0.204340977259.issue10834@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Changed title based on 'command line works fine'.

You might try running test suite, 'python -m test.regrtest' from Command Window in python27 directory on both this and other system. (It takes about 20 min, so minimize and do something else.) test_tcl, text_tk, and test_ttk fail even when IDLE works, but maybe something else, not normally failing, will fail on this system (and not on one where IDLE works).

----------
components: +IDLE
nosy: +terry.reedy
title: Python 2.7 x86 fails to run in Windows 7 -> Python 2.7 x86 IDLE fails to run in Windows 7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10834>
_______________________________________

From report at bugs.python.org  Sat Jan  8 01:13:20 2011
From: report at bugs.python.org (Shawn Ligocki)
Date: Sat, 08 Jan 2011 00:13:20 +0000
Subject: [issue10860] Handle empty port after port delimiter in httplib
In-Reply-To: <1294427670.55.0.855321383674.issue10860@psf.upfronthosting.co.za>
Message-ID: <1294445600.63.0.31428175932.issue10860@psf.upfronthosting.co.za>


Shawn Ligocki <sligocki at gmail.com> added the comment:

Here's a patch for 2.7 (from the hg checkout http://code.python.org/hg/branches/release2.7-maint/)

How does it look? Apparently there was already a testcase for "www.python.org:" failing!

----------
keywords: +patch
Added file: http://bugs.python.org/file20308/issue.10860.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10860>
_______________________________________

From report at bugs.python.org  Sat Jan  8 01:13:29 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 08 Jan 2011 00:13:29 +0000
Subject: [issue10838] subprocess __all__ is incomplete
In-Reply-To: <1294260769.5.0.0970426129524.issue10838@psf.upfronthosting.co.za>
Message-ID: <1294445609.66.0.938573792477.issue10838@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

My understanding is much like Toshio's: ambiguous (typically, undocumented or omitted from __all__) non-underscored names should be resolved, with the three possible outcomes listed, on a case-by-case basis.

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10838>
_______________________________________

From report at bugs.python.org  Sat Jan  8 01:17:50 2011
From: report at bugs.python.org (Nathan Herring)
Date: Sat, 08 Jan 2011 00:17:50 +0000
Subject: [issue1372770] email.Header should preserve original FWS
Message-ID: <1294445870.84.0.750651264692.issue1372770@psf.upfronthosting.co.za>


Nathan Herring <nathan.herring at technosloth.com> added the comment:

You are certainly correct about (some, perhaps many) e-mail generators using tabs when folding, which is AFAICT, much more likely an incorrect implementation of RFC 2822 rather than an intentional transformation of the user's specified Subject line. Some*, however, dutifully unfold those tabs back into the Subject line, causing all sorts of strangeness -- explosion of conversations that are logically identical, except that in one, it's all spaces, and in the others, some of the spaces have, seemingly arbitrarily, turned into tabs. 

Fixing all of the e-mail generators to Do The Right Thing wasn't what I had in mind, but making sure that mailman, a rather commonly used mail service, and its reliance on python's Header class, would no longer permute the messages made my e-mail generators that do Do The Right Thing, was one step.

I would be inclined to, were I a contributor, make it so that it would conform to RFC 2822 unfolding and preserve the FWS accordingly. I don't know if there'd be enough desire for your alternative, but if there were, I'd make it a non-default option to de-tabify Subject lines (or other headers).

As it stands, I am newly freed from any restrictions from contributing, and so I might try and see what mailman's intentions are surrounding taking updates to python before trying to propose a patch that they might never use (i.e., they may just take the version you're working on now.)

*Microsoft Entourage (which I worked on while at Microsoft) and Microsoft Outlook both behave correctly, as far as I could determine in '05, with regards to the folding/unfolding headers.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1372770>
_______________________________________

From report at bugs.python.org  Sat Jan  8 01:26:20 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 08 Jan 2011 00:26:20 +0000
Subject: [issue1777412] datetime.strftime dislikes years before 1900
Message-ID: <1294446380.65.0.102741867903.issue1777412@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Here is a patch removing the arbitrary datetime.strftime() limit on year: it adds an option "accept2dyear" to time.strftime() and datetime just sets this option to False.

----------
Added file: http://bugs.python.org/file20309/datetime_strftime_nolimit.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1777412>
_______________________________________

From report at bugs.python.org  Sat Jan  8 01:32:02 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 08 Jan 2011 00:32:02 +0000
Subject: [issue10849] Backport test/__main__
In-Reply-To: <1294354350.96.0.765120918707.issue10849@psf.upfronthosting.co.za>
Message-ID: <1294446722.66.0.383109338104.issue10849@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

The possible downside, as with any new feature, is that code using the new feature will not run on on previous micro (x.y.z) releases. In this case, one can run the tests using the new feature.

>>> from test import __main__
== CPython 3.2b2 (r32b2:87398, Dec 19 2010, 22:51:00) [MSC v.1500 32 bit (Intel)]
==   Windows-XP-5.1.2600-SP3 little-endian
==   c:\docume~1\terry\locals~1\temp\test_python_3872
[  1/351] test_gramm
...
(or via subprocess

Perhaps no one would do either.

However, the new feature currently does not work on Windows (see #10845 and my pydev post), so it definitely should not be backported until fixed and tested. Which is to say, I currently have to use -m test.regrtest even on 3.2 ;-(.

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10849>
_______________________________________

From report at bugs.python.org  Sat Jan  8 02:09:05 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 08 Jan 2011 01:09:05 +0000
Subject: [issue1777412] datetime.strftime dislikes years before 1900
In-Reply-To: <1294446380.65.0.102741867903.issue1777412@psf.upfronthosting.co.za>
Message-ID: <AANLkTinBGjiScaT7POHzh6oO3R-5LBcEkkg04oPwNf-G@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Fri, Jan 7, 2011 at 7:26 PM, STINNER Victor <report at bugs.python.org> wrote:
..
> Here is a patch removing the arbitrary datetime.strftime() limit on year: it adds an
> option "accept2dyear" to time.strftime() and datetime just sets this option to False.
>

The idea of adding an optional argument to  time.strftime() was
discussed on python-dev, but did not get much traction there:

"""
I wish we didn't have to do that -- isn't it easy enough for the app
to do the 2d -> 4d conversion itself before calling the library
function? The only exception would be when parsing a string -- but
strptime can tell whether a 2d or 4d year is requested by the format
code (%y or %Y).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1777412>
_______________________________________

From report at bugs.python.org  Sat Jan  8 02:14:24 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 08 Jan 2011 01:14:24 +0000
Subject: [issue10828] Cannot use nonascii utf8 in names of files imported from
In-Reply-To: <1294170257.81.0.980912064683.issue10828@psf.upfronthosting.co.za>
Message-ID: <1294449264.81.0.0207527679011.issue10828@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

(Ingemar: one can easily test import statements without pyqt, let alone qt ;-)

With 3.2b2 on our Win7, 64 bit machine, files with a Japanese name run but apparently cannot be imported.

a.py: print('something')
^|.py: print('other') # ^| == imitation of katakana name
c.py: import a; import ^|
something
ImportError: No module named ^|

Tried in both japanese- and then ascii-named directories.
So I am not convinced that #9425 is finished. What might I have misunderstood?

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10828>
_______________________________________

From report at bugs.python.org  Sat Jan  8 02:17:31 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 08 Jan 2011 01:17:31 +0000
Subject: [issue1372770] email.Header should preserve original FWS
Message-ID: <1294449451.5.0.608298023905.issue1372770@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/issue1372770>
_______________________________________

From report at bugs.python.org  Sat Jan  8 02:35:04 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 08 Jan 2011 01:35:04 +0000
Subject: [issue1777412] datetime.strftime dislikes years before 1900
Message-ID: <1294450504.95.0.961340579858.issue1777412@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

--
--Guido van Rossum (python.org/~guido)
"""  -- http://mail.python.org/pipermail/python-dev/2011-January/107246.html

^^^ the last lines of msg125738 cut by roundup ^^^

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1777412>
_______________________________________

From report at bugs.python.org  Sat Jan  8 02:36:53 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 08 Jan 2011 01:36:53 +0000
Subject: [issue1777412] datetime.strftime dislikes years before 1900
Message-ID: <1294450613.01.0.00636566184995.issue1777412@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

strftime_1_9999.patch: replace 1900 <= year limit by 1 <= year or 1 <= year <= 9999 (if compiled with Visual Studio). With more tests on years.

----------
Added file: http://bugs.python.org/file20310/strftime_1_9999.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1777412>
_______________________________________

From report at bugs.python.org  Sat Jan  8 02:49:06 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 08 Jan 2011 01:49:06 +0000
Subject: [issue1777412] datetime.strftime dislikes years before 1900
Message-ID: <1294451346.91.0.0188569496318.issue1777412@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

I like strftime_1_9999.patch, but it really belongs to #10827.  Please leave a note there once you commit and mention the issue in commit log.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1777412>
_______________________________________

From report at bugs.python.org  Sat Jan  8 03:01:33 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 08 Jan 2011 02:01:33 +0000
Subject: [issue1777412] datetime.strftime dislikes years before 1900
Message-ID: <1294452093.98.0.717509049499.issue1777412@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

r87845+r87846 sets time.strftime() minimum year to 1 instead of 1900. If Python is compiled with Visual Studio, it sets also the maximum year to 9999.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1777412>
_______________________________________

From report at bugs.python.org  Sat Jan  8 03:43:17 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 08 Jan 2011 02:43:17 +0000
Subject: [issue10864] time.strftime("%Y"): limitation of 4 digits on
	OpenIndiana (Solaris)
In-Reply-To: <1294454597.35.0.957818587484.issue10864@psf.upfronthosting.co.za>
Message-ID: <1294454597.35.0.957818587484.issue10864@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

The following example displays '2345' instead of '12345':

import time
t = (12345,) + (0,)*8
print(repr(time.strftime("%Y", t)))

time.strftime() should raise a ValueError if the year is bigger than 9999, as it is done with Visual Studio for year outside [1; 9999].

----------
components: Library (Lib)
messages: 125744
nosy: haypo
priority: normal
severity: normal
status: open
title: time.strftime("%Y"): limitation of 4 digits on OpenIndiana (Solaris)
versions: Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10864>
_______________________________________

From report at bugs.python.org  Sat Jan  8 04:04:33 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 08 Jan 2011 03:04:33 +0000
Subject: [issue10828] Cannot use nonascii utf8 in names of files imported from
In-Reply-To: <1294170257.81.0.980912064683.issue10828@psf.upfronthosting.co.za>
Message-ID: <1294455873.74.0.747908555535.issue10828@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> With 3.2b2 on our Win7, 64 bit machine, files with a Japanese name...

What is your ANSI code page? If it is not a japanese code page, it is the issue #3080.

On Windows, #8611 (and #9425) permit to use non-ASCII characters in the module path... but only characters encodable to your ANSI code page.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10828>
_______________________________________

From report at bugs.python.org  Sat Jan  8 04:25:41 2011
From: report at bugs.python.org (James Y Knight)
Date: Sat, 08 Jan 2011 03:25:41 +0000
Subject: [issue2650] re.escape should not escape underscore
In-Reply-To: <1208441650.53.0.945063086485.issue2650@psf.upfronthosting.co.za>
Message-ID: <1294457141.71.0.884257188717.issue2650@psf.upfronthosting.co.za>


James Y Knight <foom at users.sourceforge.net> added the comment:

I just ran into the impl of escape after being surprised that '/' was being escaped, and then was completely amazed that it wasn't just implemented as a one-line re.subn. Come on, a loop for string replacement? This is *in* the freaking re module for pete's sake!

The extra special \\000 behavior seems entirely superfluous, as well. re works just fine with nul bytes in the pattern; there's no need to special case that.

So:
return  re.subn('([^abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ01234567890])', '\\\\\\1', pattern)[0]

or, for the new proposed list of special chars:
return re.subn('([][.^$*+?{}\\|()])', '\\\\\\1', pattern)[0]


(pre-compilation of pattern left as an exercise to the reader)

----------
nosy: +foom

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2650>
_______________________________________

From report at bugs.python.org  Sat Jan  8 04:35:53 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 08 Jan 2011 03:35:53 +0000
Subject: [issue10864] time.strftime("%Y"): limitation of 4 digits on
	OpenIndiana (Solaris)
In-Reply-To: <1294454597.35.0.957818587484.issue10864@psf.upfronthosting.co.za>
Message-ID: <1294457753.81.0.686346764969.issue10864@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Oh, it's more funny with negative numbers: -1 is formatted '000/'.

Let's try r87850. I'm now waiting for the buildbot.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10864>
_______________________________________

From report at bugs.python.org  Sat Jan  8 04:39:01 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 08 Jan 2011 03:39:01 +0000
Subject: [issue1777412] datetime.strftime dislikes years before 1900
Message-ID: <1294457941.64.0.761242625024.issue1777412@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> r87845+r87846 sets time.strftime() minimum year to 1 instead of 1900.
> If Python is compiled with Visual Studio, it sets also the maximum 
> year to 9999.

r87848 removes all limits on the year field; r87850 (Issue #10864) limits year to [1; 9999] on Solaris.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1777412>
_______________________________________

From report at bugs.python.org  Sat Jan  8 05:31:10 2011
From: report at bugs.python.org (Ross Lagerwall)
Date: Sat, 08 Jan 2011 04:31:10 +0000
Subject: [issue10812] Add some posix functions
In-Reply-To: <1294058752.01.0.285856626146.issue10812@psf.upfronthosting.co.za>
Message-ID: <1294461070.21.0.335327925316.issue10812@psf.upfronthosting.co.za>


Ross Lagerwall <rosslagerwall at gmail.com> added the comment:

This patch takes out sethostname() and gethostname(). I'll open up a new issue to add sethostname() to the socket module.

----------
Added file: http://bugs.python.org/file20311/10812_v5.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10812>
_______________________________________

From report at bugs.python.org  Sat Jan  8 06:38:27 2011
From: report at bugs.python.org (Ned Deily)
Date: Sat, 08 Jan 2011 05:38:27 +0000
Subject: [issue10850] inconsistent behavior concerning
	multiprocessing.manager.BaseManager._Server
In-Reply-To: <1294360374.53.0.588595674921.issue10850@psf.upfronthosting.co.za>
Message-ID: <1294465107.68.0.293516357344.issue10850@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


----------
nosy: +asksol, jnoller

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10850>
_______________________________________

From report at bugs.python.org  Sat Jan  8 06:51:45 2011
From: report at bugs.python.org (Ned Deily)
Date: Sat, 08 Jan 2011 05:51:45 +0000
Subject: [issue10855] wave.Wave_read.close() doesn't release file
In-Reply-To: <1294417424.98.0.47429499245.issue10855@psf.upfronthosting.co.za>
Message-ID: <1294465905.09.0.864877679673.issue10855@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Thanks for the report and analysis.  Would you care to submit a patch to fix it?

----------
nosy: +ned.deily
stage:  -> unit test needed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10855>
_______________________________________

From report at bugs.python.org  Sat Jan  8 06:54:45 2011
From: report at bugs.python.org (Ned Deily)
Date: Sat, 08 Jan 2011 05:54:45 +0000
Subject: [issue10855] wave.Wave_read.close() doesn't release file
In-Reply-To: <1294417424.98.0.47429499245.issue10855@psf.upfronthosting.co.za>
Message-ID: <1294466085.48.0.0197105604656.issue10855@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

(Presumably this is also a problem for Python 3, as well).

----------
versions: +Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10855>
_______________________________________

From report at bugs.python.org  Sat Jan  8 07:04:09 2011
From: report at bugs.python.org (Ned Deily)
Date: Sat, 08 Jan 2011 06:04:09 +0000
Subject: [issue10837] Issue catching KeyboardInterrupt while reading stdin
In-Reply-To: <1294257725.97.0.863829105509.issue10837@psf.upfronthosting.co.za>
Message-ID: <1294466649.13.0.42549984966.issue10837@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


----------
nosy: +brian.curtin, tim.golden

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10837>
_______________________________________

From report at bugs.python.org  Sat Jan  8 07:17:14 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 08 Jan 2011 06:17:14 +0000
Subject: [issue1475397] time.asctime_tz, time.strftime %z %C
Message-ID: <1294467434.88.0.0739156654955.issue1475397@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


----------
resolution:  -> rejected
stage: unit test needed -> committed/rejected
status: open -> pending
superseder:  -> Add aware local time support to datetime module

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1475397>
_______________________________________

From report at bugs.python.org  Sat Jan  8 07:23:12 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 08 Jan 2011 06:23:12 +0000
Subject: [issue3080] Full unicode import system
In-Reply-To: <1213208697.49.0.984990811807.issue3080@psf.upfronthosting.co.za>
Message-ID: <1294467792.31.0.565393392221.issue3080@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

If I edit a file with IDLE, save it, and successfully run it (perhaps to test it), then when I edit a second file that imports the first, I expect the import to work. It does not always (see #10828).

Import is part of the core definition of the language. Unicode identifiers are supposedly part of Python3. Given the existence of <identifier>.py in the current directory, 'import identifier' should work. If it does not, the 3.1 message '<identifier> not found' is more truthful than the current 'no module named <identifier>', when there is one.

The doc says "identifier ::= (identifier ".")* identifier". As long as that is not true, some indication of the restriction that most people can understand would be nice. (And I suspect that a majority of Windows users, at least in the US, have no idea of what an 'ANSI code page' is.)

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3080>
_______________________________________

From report at bugs.python.org  Sat Jan  8 07:34:29 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 08 Jan 2011 06:34:29 +0000
Subject: [issue10828] Cannot use nonascii utf8 in names of files imported from
In-Reply-To: <1294170257.81.0.980912064683.issue10828@psf.upfronthosting.co.za>
Message-ID: <1294468469.52.0.900175191485.issue10828@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

ANSI code page? I have no idea how to find out and many would not even know what such a thing exists. It is an HP laptop sold in the US.  

I think bugs in core syntax should have high priority. I appreciate your work toward fixing it.

----------
versions: +Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10828>
_______________________________________

From report at bugs.python.org  Sat Jan  8 07:37:32 2011
From: report at bugs.python.org (ingemar)
Date: Sat, 08 Jan 2011 06:37:32 +0000
Subject: [issue10828] Cannot use nonascii utf8 in names of files imported from
In-Reply-To: <1294170257.81.0.980912064683.issue10828@psf.upfronthosting.co.za>
Message-ID: <1294468652.65.0.199058526643.issue10828@psf.upfronthosting.co.za>


ingemar <ingemar at sijohansson.com> added the comment:

Terry: Thanks for the hint
In a pure ascii path I created files very similar to yours with Swedish "?" instead of your katakana character.
I also got the same result.

a.py:
print ('something')

?.py:
print ('other')

c.py:
# -*- coding: utf-8 -*-
import a
import ?

I ran the files with 3.2b2:
    
c:\Python32\python.exe a.py
something

c:\Python32\python.exe ?.py
other

c:\Python32\python.exe c.py
something
Traceback (most recent call last):
  File "c.py", line 3, in <module>
    import ?
ImportError: No module name ?


Victor: How do I determine what code page my old w2k is using?.
Would that be 8859-1 or some older variant for western Europe or Sweden?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10828>
_______________________________________

From report at bugs.python.org  Sat Jan  8 07:57:22 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 08 Jan 2011 06:57:22 +0000
Subject: [issue10859] Is GeneratorContextManager public?
In-Reply-To: <1294427112.3.0.241437231702.issue10859@psf.upfronthosting.co.za>
Message-ID: <1294469842.69.0.328940921626.issue10859@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

I'd like to leave the door open to some tweaks in the GCM implementation for 3.3, so making it officially private (by adding the leading underscore) sounds good to me.

----------
keywords: +easy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10859>
_______________________________________

From report at bugs.python.org  Sat Jan  8 08:02:58 2011
From: report at bugs.python.org (ulidtko)
Date: Sat, 08 Jan 2011 07:02:58 +0000
Subject: [issue10865] chroot-ing breaks encodings.idna
In-Reply-To: <1294470178.85.0.531669703509.issue10865@psf.upfronthosting.co.za>
Message-ID: <1294470178.85.0.531669703509.issue10865@psf.upfronthosting.co.za>


New submission from ulidtko <ulidtko at gmail.com>:

Consider the following test script:

import os
import urllib.request

os.chroot("/tmp")

urllib.request.urlopen("http://localhost")


When executed with enough privileges, the script terminates with the following traceback:

Traceback (most recent call last):
  File "./test.py", line 8, in <module>
    urllib.request.urlopen("http://localhost")
  File "/usr/lib/python3.1/urllib/request.py", line 121, in urlopen
  File "/usr/lib/python3.1/urllib/request.py", line 350, in open
  File "/usr/lib/python3.1/urllib/request.py", line 368, in _open
  File "/usr/lib/python3.1/urllib/request.py", line 328, in _call_chain
  File "/usr/lib/python3.1/urllib/request.py", line 1110, in http_open
  File "/usr/lib/python3.1/urllib/request.py", line 1092, in do_open
  File "/usr/lib/python3.1/http/client.py", line 940, in request
  File "/usr/lib/python3.1/http/client.py", line 978, in _send_request
  File "/usr/lib/python3.1/http/client.py", line 936, in endheaders
  File "/usr/lib/python3.1/http/client.py", line 790, in _send_output
  File "/usr/lib/python3.1/http/client.py", line 731, in send
  File "/usr/lib/python3.1/http/client.py", line 713, in connect
  File "/usr/lib/python3.1/socket.py", line 320, in create_connection
LookupError: unknown encoding: idna

Without the os.chroot line it runs ok.


Furthermore, when importing encodings.idna explicitly and before chroot-ing, any hostname refuses to resolve at all.

Script:

import os
import urllib.request
import encodings.idna

os.chroot("/tmp")

urllib.request.urlopen("http://localhost")


now terminates with the following traceback:

Traceback (most recent call last):
  File "./test.py3", line 9, in <module>
    urllib.request.urlopen("http://localhost")
  File "/usr/lib/python3.1/urllib/request.py", line 121, in urlopen
  File "/usr/lib/python3.1/urllib/request.py", line 350, in open
  File "/usr/lib/python3.1/urllib/request.py", line 368, in _open
  File "/usr/lib/python3.1/urllib/request.py", line 328, in _call_chain
  File "/usr/lib/python3.1/urllib/request.py", line 1110, in http_open
  File "/usr/lib/python3.1/urllib/request.py", line 1095, in do_open
urllib.error.URLError: <urlopen error [Errno -2] Name or service not known>

----------
components: Library (Lib)
messages: 125756
nosy: ulidtko
priority: normal
severity: normal
status: open
title: chroot-ing breaks encodings.idna
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10865>
_______________________________________

From report at bugs.python.org  Sat Jan  8 08:03:35 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 08 Jan 2011 07:03:35 +0000
Subject: [issue10042] total_ordering stack overflow
In-Reply-To: <1286440012.74.0.624864175042.issue10042@psf.upfronthosting.co.za>
Message-ID: <1294470215.78.0.147025980908.issue10042@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Thanks for the report and patch.

Fixed.  rSee 87853.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10042>
_______________________________________

From report at bugs.python.org  Sat Jan  8 08:03:48 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 08 Jan 2011 07:03:48 +0000
Subject: [issue10042] total_ordering stack overflow
In-Reply-To: <1286440012.74.0.624864175042.issue10042@psf.upfronthosting.co.za>
Message-ID: <1294470228.23.0.368091251582.issue10042@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <rhettinger at users.sourceforge.net>:


----------
Removed message: http://bugs.python.org/msg125757

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10042>
_______________________________________

From report at bugs.python.org  Sat Jan  8 08:04:06 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 08 Jan 2011 07:04:06 +0000
Subject: [issue10042] total_ordering stack overflow
In-Reply-To: <1286440012.74.0.624864175042.issue10042@psf.upfronthosting.co.za>
Message-ID: <1294470246.48.0.216742490176.issue10042@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Thanks for the report and patch.

Fixed.  See r87853.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10042>
_______________________________________

From report at bugs.python.org  Sat Jan  8 09:08:52 2011
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 08 Jan 2011 08:08:52 +0000
Subject: [issue10865] chroot-ing breaks encodings.idna
In-Reply-To: <1294470178.85.0.531669703509.issue10865@psf.upfronthosting.co.za>
Message-ID: <1294474132.38.0.26837708115.issue10865@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

This is not a bug in Python: name resolution may not work in the chroot unless you add the libraries that are loaded on the fly by the libc.

It *may* also work if you make one name resolution (using socket.getaddressinfo for example) *before* chrooting.

To demonstrate that Python is not involved, you can reproduce the failure with the C program below.


#include <sys/types.h>
#include <sys/socket.h>
#include <netdb.h>
#include <stdio.h>
#include <unistd.h>

int main() {
        int res;
        struct addrinfo *ai;

        if ((res = chroot("/tmp")) < 0) {
                printf("chroot failed with errno %d\n", -res);
        } else if ((res = getaddrinfo("google.de", "80", NULL, &ai)) < 0) {
                printf("getaddrinfo failed with errno %d: %s\n",
                       -res, gai_strerror(res));
        }
        return 0;
}

----------
nosy: +georg.brandl
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10865>
_______________________________________

From report at bugs.python.org  Sat Jan  8 09:11:40 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Sat, 08 Jan 2011 08:11:40 +0000
Subject: [issue10860] urllib2 crashes on valid URL
In-Reply-To: <1294427670.55.0.855321383674.issue10860@psf.upfronthosting.co.za>
Message-ID: <20110108081123.GA1162@rubuntu>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

On Fri, Jan 07, 2011 at 07:14:30PM +0000, Shawn Ligocki wrote:
> 
> I think the problem is that "http://118114.cn" says it redirects to
> "http://www.118114.cn:", but it seems like urllib2 should be able to
> deal with that or at least report back a more useful error message.

I think, this is improper at the Server End to redirect it to URL
where ':' is provided and Port is missing.

Any client, which does a transparent redirection, can be expected to fail.

senthil at rubuntu:~$ curl -L http://118114.cn
curl: (6) Couldn't resolve host 'www.118114.cn:'

The Redirected URL is an Invalid Syntax and I don't think we should
fix by providing a default port at urllib2 end. What can be done is
fail with timeout or raise an Exception for an Invalid URL.

----------
title: Handle empty port after port delimiter in httplib -> urllib2 crashes on valid URL

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10860>
_______________________________________

From report at bugs.python.org  Sat Jan  8 09:16:17 2011
From: report at bugs.python.org (Ross Lagerwall)
Date: Sat, 08 Jan 2011 08:16:17 +0000
Subject: [issue10866] Add sethostname()
In-Reply-To: <1294474577.93.0.97800635081.issue10866@psf.upfronthosting.co.za>
Message-ID: <1294474577.93.0.97800635081.issue10866@psf.upfronthosting.co.za>


New submission from Ross Lagerwall <rosslagerwall at gmail.com>:

This patch adds sethostname to the socket module (since socket has gethostname()).

----------
components: Library (Lib)
files: sethostname.patch
keywords: patch
messages: 125761
nosy: giampaolo.rodola, loewis, rosslagerwall
priority: normal
severity: normal
status: open
title: Add sethostname()
versions: Python 3.3
Added file: http://bugs.python.org/file20312/sethostname.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10866>
_______________________________________

From report at bugs.python.org  Sat Jan  8 09:20:45 2011
From: report at bugs.python.org (ulidtko)
Date: Sat, 08 Jan 2011 08:20:45 +0000
Subject: [issue10865] chroot-ing breaks encodings.idna
In-Reply-To: <1294470178.85.0.531669703509.issue10865@psf.upfronthosting.co.za>
Message-ID: <1294474845.8.0.264225113587.issue10865@psf.upfronthosting.co.za>


ulidtko <ulidtko at gmail.com> added the comment:

Can I perform a name resolution before chrooting, save the result and use it later for creating an instance of http.server.HTTPServer, as a workaround?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10865>
_______________________________________

From report at bugs.python.org  Sat Jan  8 09:25:57 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Sat, 08 Jan 2011 08:25:57 +0000
Subject: [issue10860] Handle empty port after port delimiter in httplib
In-Reply-To: <1294427670.55.0.855321383674.issue10860@psf.upfronthosting.co.za>
Message-ID: <1294475157.65.0.411836272482.issue10860@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

The title got reset by my previous response. Changing it again.

I vote for closing this report as Invalid as I see that the error message which is raised is proper and meaningful.

httplib.InvalidURL: nonnumeric port: ''

----------
priority: normal -> low
resolution:  -> invalid
status: open -> pending
title: urllib2 crashes on valid URL -> Handle empty port after port delimiter in httplib

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10860>
_______________________________________

From report at bugs.python.org  Sat Jan  8 09:56:50 2011
From: report at bugs.python.org (ulidtko)
Date: Sat, 08 Jan 2011 08:56:50 +0000
Subject: [issue10865] chroot-ing breaks encodings.idna
In-Reply-To: <1294470178.85.0.531669703509.issue10865@psf.upfronthosting.co.za>
Message-ID: <1294477010.93.0.404062624753.issue10865@psf.upfronthosting.co.za>


ulidtko <ulidtko at gmail.com> added the comment:

Ok, I can do it with socket.gethostbyname().

Thanks for clarifications.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10865>
_______________________________________

From report at bugs.python.org  Sat Jan  8 09:57:25 2011
From: report at bugs.python.org (anatoly techtonik)
Date: Sat, 08 Jan 2011 08:57:25 +0000
Subject: [issue10854] Output DLL name in error message of ImportError when DLL
	is missing
In-Reply-To: <1294415325.09.0.315523226252.issue10854@psf.upfronthosting.co.za>
Message-ID: <1294477045.2.0.694831638624.issue10854@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

Martin, shouldn't there be at least majority to reach consensus on this matter, or you're self-proclaimed BSDL II? =)

At least failed .pyd module name should be present in error message.

----------
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10854>
_______________________________________

From report at bugs.python.org  Sat Jan  8 10:06:52 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 08 Jan 2011 09:06:52 +0000
Subject: [issue10813] Suppress adding decimal point for places=0 in moneyfmt()
In-Reply-To: <1294059487.44.0.656415691247.issue10813@psf.upfronthosting.co.za>
Message-ID: <1294477612.8.0.941696409319.issue10813@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

See r87856

----------
resolution:  -> accepted
status: open -> closed
type:  -> feature request
versions: +Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10813>
_______________________________________

From report at bugs.python.org  Sat Jan  8 10:17:54 2011
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 08 Jan 2011 09:17:54 +0000
Subject: [issue10863] zlib.compress() fails with string
In-Reply-To: <1294430571.2.0.193589316262.issue10863@psf.upfronthosting.co.za>
Message-ID: <1294478274.16.0.107017237624.issue10863@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

This is already fixed in dev docs, just needs backporting.

----------
nosy: +georg.brandl
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10863>
_______________________________________

From report at bugs.python.org  Sat Jan  8 10:30:10 2011
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 08 Jan 2011 09:30:10 +0000
Subject: [issue10854] Output DLL name in error message of ImportError when DLL
	is missing
In-Reply-To: <1294415325.09.0.315523226252.issue10854@psf.upfronthosting.co.za>
Message-ID: <1294479010.48.0.255051147823.issue10854@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

No idea what a BSDL is, but a developer is definitely entitled to close a bug without resorting to a "majority" decision (what is that, anyway? should we hold monthly parliament over bugs?).

You're of course free to reopen with a different request, as you did, and I also think it'd be useful to have the failed module name in the message.

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10854>
_______________________________________

From report at bugs.python.org  Sat Jan  8 10:32:09 2011
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 08 Jan 2011 09:32:09 +0000
Subject: [issue10849] Backport test/__main__
In-Reply-To: <1294354350.96.0.765120918707.issue10849@psf.upfronthosting.co.za>
Message-ID: <1294479129.26.0.564945717016.issue10849@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

> The possible downside, as with any new feature, is that code using the
> new feature will not run on on previous micro (x.y.z) releases.

That's absolutely no downside: I daresay 99% of test runs by developers are done at the branch head, not some released version.

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10849>
_______________________________________

From report at bugs.python.org  Sat Jan  8 10:34:07 2011
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 08 Jan 2011 09:34:07 +0000
Subject: [issue2650] re.escape should not escape underscore
In-Reply-To: <1208441650.53.0.945063086485.issue2650@psf.upfronthosting.co.za>
Message-ID: <1294479247.4.0.891708231584.issue2650@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

The loop looks strange to me too, not to mention inefficient compared with a regex replacement done in C.

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2650>
_______________________________________

From report at bugs.python.org  Sat Jan  8 10:37:07 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 08 Jan 2011 09:37:07 +0000
Subject: [issue10533] Need example of using __missing__
In-Reply-To: <1290704449.7.0.95801510837.issue10533@psf.upfronthosting.co.za>
Message-ID: <1294479427.85.0.824834844627.issue10533@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

See r87858.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10533>
_______________________________________

From report at bugs.python.org  Sat Jan  8 10:45:58 2011
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 08 Jan 2011 09:45:58 +0000
Subject: [issue10855] wave.Wave_read.close() doesn't release file
In-Reply-To: <1294417424.98.0.47429499245.issue10855@psf.upfronthosting.co.za>
Message-ID: <1294479958.52.0.0889688129475.issue10855@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

This is not a bug in the implementation: the file object is only closed when you passed a file name to open().

Like other APIs that allow file names or objects to be passed in, it is the caller's responsibility to close the file object if an object was passed.

However, this was not documented.  I've fixed that with r87859.

----------
nosy: +georg.brandl
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10855>
_______________________________________

From report at bugs.python.org  Sat Jan  8 10:56:00 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 08 Jan 2011 09:56:00 +0000
Subject: [issue10859] Is GeneratorContextManager public?
In-Reply-To: <1294427112.3.0.241437231702.issue10859@psf.upfronthosting.co.za>
Message-ID: <1294480560.5.0.572676411213.issue10859@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Ok, done in r87860.

----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10859>
_______________________________________

From report at bugs.python.org  Sat Jan  8 11:28:01 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 08 Jan 2011 10:28:01 +0000
Subject: [issue9717] operator module - "in place" operators documentation
In-Reply-To: <1283194174.19.0.42398116416.issue9717@psf.upfronthosting.co.za>
Message-ID: <1294482481.74.0.233201108452.issue9717@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

See r87862.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9717>
_______________________________________

From report at bugs.python.org  Sat Jan  8 11:28:58 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 08 Jan 2011 10:28:58 +0000
Subject: [issue10648] Extend peepholer to reverse loads or stores instead of
	build/unpack
In-Reply-To: <1291771551.8.0.926490370256.issue10648@psf.upfronthosting.co.za>
Message-ID: <1294482538.79.0.185258178587.issue10648@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <rhettinger at users.sourceforge.net>:


----------
resolution:  -> rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10648>
_______________________________________

From report at bugs.python.org  Sat Jan  8 12:16:30 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sat, 08 Jan 2011 11:16:30 +0000
Subject: [issue10849] Backport test/__main__
In-Reply-To: <1294354350.96.0.765120918707.issue10849@psf.upfronthosting.co.za>
Message-ID: <1294485390.47.0.675338228337.issue10849@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

I'm with Raymond here (probably not surprisingly): -1 on backporting new features into 2.7. This really is foremost about having policies and sticking to them; special cases aren't special enough to break the rules. 

Personally, I haven't arrived yet at using -m to run the test suite (I run "python Lib\test\regrtest.py", as that works nicely with shell completion), so I don't care about the feature.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10849>
_______________________________________

From report at bugs.python.org  Sat Jan  8 12:22:21 2011
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 08 Jan 2011 11:22:21 +0000
Subject: [issue10849] Backport test/__main__
In-Reply-To: <1294354350.96.0.765120918707.issue10849@psf.upfronthosting.co.za>
Message-ID: <1294485741.4.0.468886986983.issue10849@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Okay, that's reasonable enough.  Closing (or shall we wait for the majority to consent first?)

----------
resolution:  -> rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10849>
_______________________________________

From report at bugs.python.org  Sat Jan  8 12:25:27 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 08 Jan 2011 11:25:27 +0000
Subject: [issue10849] Backport test/__main__
In-Reply-To: <1294354350.96.0.765120918707.issue10849@psf.upfronthosting.co.za>
Message-ID: <1294485927.22.0.839900699682.issue10849@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

A backport would be more attractive if the Windows issue was fixed first...
(and I don't care about the "policy" here: anything which makes testing easier is good IMO, and we have routinely backported tests as mentioned by someone else)

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10849>
_______________________________________

From report at bugs.python.org  Sat Jan  8 12:29:59 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 08 Jan 2011 11:29:59 +0000
Subject: [issue2650] re.escape should not escape underscore
In-Reply-To: <1208441650.53.0.945063086485.issue2650@psf.upfronthosting.co.za>
Message-ID: <1294486199.08.0.146914048169.issue2650@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

James, could you propose a proper patch? Even better if you also give a couple of timing results, just for the record?

----------
versions: +Python 3.2 -Python 2.7, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2650>
_______________________________________

From report at bugs.python.org  Sat Jan  8 12:33:06 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 08 Jan 2011 11:33:06 +0000
Subject: [issue10174] multiprocessing expects sys.stdout to have a
	fileno/close method.
In-Reply-To: <1287789739.18.0.21420008091.issue10174@psf.upfronthosting.co.za>
Message-ID: <1294486386.49.0.830865207952.issue10174@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Ok, closing then.

----------
nosy: +pitrou
resolution:  -> duplicate
status: open -> closed
superseder:  -> multiprocessing.process using os.close(sys.stdin.fileno) instead of sys.stdin.close()

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10174>
_______________________________________

From report at bugs.python.org  Sat Jan  8 13:20:30 2011
From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=)
Date: Sat, 08 Jan 2011 12:20:30 +0000
Subject: [issue10867] python mmap objects issue msync() in destructor even if
	mapping was created with prot=mmap.PROT_READ only
In-Reply-To: <1294489230.48.0.811640987738.issue10867@psf.upfronthosting.co.za>
Message-ID: <1294489230.48.0.811640987738.issue10867@psf.upfronthosting.co.za>


New submission from ???? ????????? <socketpair at gmail.com>:

python mmap objects issue msync() in destructor even if mapping was created with  prot=mmap.PROT_READ only

----------
messages: 125780
nosy: mmarkk
priority: normal
severity: normal
status: open
title: python mmap objects issue msync() in destructor even if mapping was created with  prot=mmap.PROT_READ only

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10867>
_______________________________________

From report at bugs.python.org  Sat Jan  8 13:34:29 2011
From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=)
Date: Sat, 08 Jan 2011 12:34:29 +0000
Subject: [issue10867] python mmap objects issue msync() in destructor even if
	mapping was created with prot=mmap.PROT_READ only
In-Reply-To: <1294489230.48.0.811640987738.issue10867@psf.upfronthosting.co.za>
Message-ID: <1294490069.03.0.634212655844.issue10867@psf.upfronthosting.co.za>


???? ????????? <socketpair at gmail.com> added the comment:

Soory, this is dup of Issue2643

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10867>
_______________________________________

From report at bugs.python.org  Sat Jan  8 13:36:16 2011
From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=)
Date: Sat, 08 Jan 2011 12:36:16 +0000
Subject: [issue10867] python mmap objects issue msync() in destructor even if
	mapping was created with prot=mmap.PROT_READ only
In-Reply-To: <1294489230.48.0.811640987738.issue10867@psf.upfronthosting.co.za>
Message-ID: <1294490176.98.0.442990619534.issue10867@psf.upfronthosting.co.za>


???? ????????? <socketpair at gmail.com> added the comment:

i'm crazy today. sorry twice. this is not dup of 2643 :(

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10867>
_______________________________________

From report at bugs.python.org  Sat Jan  8 14:38:10 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 08 Jan 2011 13:38:10 +0000
Subject: [issue10834] Python 2.7 x86 IDLE fails to run in Windows 7
In-Reply-To: <1294224063.9.0.656095341139.issue10834@psf.upfronthosting.co.za>
Message-ID: <1294493890.66.0.305476844513.issue10834@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/issue10834>
_______________________________________

From report at bugs.python.org  Sat Jan  8 14:39:03 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 08 Jan 2011 13:39:03 +0000
Subject: [issue3132] implement PEP 3118 struct changes
In-Reply-To: <1213741832.59.0.0620778602246.issue3132@psf.upfronthosting.co.za>
Message-ID: <1294493943.67.0.187661562402.issue3132@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
assignee: meador.inge -> mark.dickinson
stage: needs patch -> patch review
versions: +Python 3.3 -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3132>
_______________________________________

From report at bugs.python.org  Sat Jan  8 14:55:36 2011
From: report at bugs.python.org (Skip Montanaro)
Date: Sat, 08 Jan 2011 13:55:36 +0000
Subject: [issue10864] time.strftime("%Y"): limitation of 4 digits on
	OpenIndiana (Solaris)
In-Reply-To: <1294454597.35.0.957818587484.issue10864@psf.upfronthosting.co.za>
Message-ID: <1294494936.03.0.065016207022.issue10864@psf.upfronthosting.co.za>


Skip Montanaro <skip at pobox.com> added the comment:

On my Mac it displays "12345".  I don't see that as a big problem.
It raises ValueError for a year of -1.  This is with  build py3k:87566.

If someone wants to feed a year > 9999 to time.strftime I don't see that
as a big problem.  I less sure about year < 0.

----------
nosy: +skip.montanaro

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10864>
_______________________________________

From report at bugs.python.org  Sat Jan  8 16:42:37 2011
From: report at bugs.python.org (R. David Murray)
Date: Sat, 08 Jan 2011 15:42:37 +0000
Subject: [issue1372770] email.Header should preserve original FWS
Message-ID: <1294501357.0.0.556612428524.issue1372770@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I agree that when dealing with prexisting folding it is better to preserve it.  The case I was talking about is, say, prepending re to a subject and refolding it.  It is the transformation step where I think turning fws into a single space makes sense.  But I absolutly want this to be controllable and hope that experience can inform the chosen defaults.  I also expect to be getting feedback from the mailman folks well before anything gets set in stone.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1372770>
_______________________________________

From report at bugs.python.org  Sat Jan  8 17:02:52 2011
From: report at bugs.python.org (Charles-Francois Natali)
Date: Sat, 08 Jan 2011 16:02:52 +0000
Subject: [issue10867] python mmap objects issue msync() in destructor even if
	mapping was created with prot=mmap.PROT_READ only
In-Reply-To: <1294489230.48.0.811640987738.issue10867@psf.upfronthosting.co.za>
Message-ID: <1294502572.57.0.589484247611.issue10867@psf.upfronthosting.co.za>


Charles-Francois Natali <neologix at free.fr> added the comment:

> python mmap objects issue msync() in destructor even if mapping was created with  prot=mmap.PROT_READ only

Actually, the call to msync(2) from destructor has been removed altogether in py3k. See http://bugs.python.org/issue2643.

The patch (one line) might be worth backporting, though.

----------
nosy: +neologix

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10867>
_______________________________________

From report at bugs.python.org  Sat Jan  8 17:13:24 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 08 Jan 2011 16:13:24 +0000
Subject: [issue10828] Cannot use nonascii utf8 in names of files imported from
In-Reply-To: <1294170257.81.0.980912064683.issue10828@psf.upfronthosting.co.za>
Message-ID: <1294503204.02.0.116383177589.issue10828@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> Victor: How do I determine what code page my old w2k is using?.

python.exe -c 'import locale; print("ANSI code page: {}".format(locale.getpreferredencoding()))'


> On Windows, #8611 (and #9425) permit to use non-ASCII characters 
> in the module path... but only characters encodable to your 
> ANSI code page.

If you would like to check if your path is encodable to your ANSI code page, try:

python.exe -c "import os; fn=os.fsencode('?'); print(ascii(fn))"

If fsencode() raises an error, the filename is not encodable to your ANSI code page and you have to wait until #3080 is fixed :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10828>
_______________________________________

From report at bugs.python.org  Sat Jan  8 17:16:31 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 08 Jan 2011 16:16:31 +0000
Subject: [issue10828] Cannot use nonascii utf8 in names of files imported from
In-Reply-To: <1294170257.81.0.980912064683.issue10828@psf.upfronthosting.co.za>
Message-ID: <1294503391.59.0.817653185532.issue10828@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> I think bugs in core syntax should have high priority.

It took me 7 months to implement the first part (#8611 and #9425). I plan to do the second part (#3080) in Python 3.3 (it's too late for Python 3.2, final is planned for February 5, 2011). I already have an huge patch somewhere (in a SVN branch, import_unicode), but I have to update the patch and split it into small and simple patches.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10828>
_______________________________________

From report at bugs.python.org  Sat Jan  8 17:18:13 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 08 Jan 2011 16:18:13 +0000
Subject: [issue10864] time.strftime("%Y"): limitation of 4 digits on
	OpenIndiana (Solaris)
In-Reply-To: <1294454597.35.0.957818587484.issue10864@psf.upfronthosting.co.za>
Message-ID: <1294503493.21.0.832410297013.issue10864@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> Let's try r87850. I'm now waiting for the buildbot.

The test pass on both OpenIndiana buildbots, so I close the issue.

> On my Mac it displays "12345".  I don't see that as a big problem.

Why do you say "problem"? It is the correct result :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10864>
_______________________________________

From report at bugs.python.org  Sat Jan  8 17:18:18 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 08 Jan 2011 16:18:18 +0000
Subject: [issue10864] time.strftime("%Y"): limitation of 4 digits on
	OpenIndiana (Solaris)
In-Reply-To: <1294454597.35.0.957818587484.issue10864@psf.upfronthosting.co.za>
Message-ID: <1294503498.41.0.392399371909.issue10864@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/issue10864>
_______________________________________

From report at bugs.python.org  Sat Jan  8 17:22:43 2011
From: report at bugs.python.org (Philippe Devalkeneer)
Date: Sat, 08 Jan 2011 16:22:43 +0000
Subject: [issue8033] sqlite: broken long integer handling for arguments to
	user-defined functions
In-Reply-To: <1267408991.73.0.408537758811.issue8033@psf.upfronthosting.co.za>
Message-ID: <1294503763.05.0.595504387551.issue8033@psf.upfronthosting.co.za>


Philippe Devalkeneer <phil.le.bienheureux at gmail.com> added the comment:

Here a new patch with sqlite3_int64 type, and unit test.

----------
Added file: http://bugs.python.org/file20313/broken_long_sqlite_userfunctions.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8033>
_______________________________________

From report at bugs.python.org  Sat Jan  8 17:27:47 2011
From: report at bugs.python.org (R. David Murray)
Date: Sat, 08 Jan 2011 16:27:47 +0000
Subject: [issue10867] python mmap objects issue msync() in destructor even if
	mapping was created with prot=mmap.PROT_READ only
In-Reply-To: <1294489230.48.0.811640987738.issue10867@psf.upfronthosting.co.za>
Message-ID: <1294504067.21.0.120024672695.issue10867@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Antoine didn't want to backport that patch.  Does the fix applied in issue 678250 address this?

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10867>
_______________________________________

From report at bugs.python.org  Sat Jan  8 17:38:05 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 08 Jan 2011 16:38:05 +0000
Subject: [issue10827] Functions in time module should support year < 1900 when
	accept2dyear = 0
In-Reply-To: <1294159712.85.0.42147185487.issue10827@psf.upfronthosting.co.za>
Message-ID: <1294504685.98.0.122996454583.issue10827@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

time.asctime(), time.ctime() and time.strftime() are no more not limited for the year field if accept2dyear=0. Except with Visual Studio or on Solaris: the year is limited to the range [1; 9999].

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10827>
_______________________________________

From report at bugs.python.org  Sat Jan  8 17:40:35 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 08 Jan 2011 16:40:35 +0000
Subject: [issue1777412] datetime.strftime dislikes years before 1900
Message-ID: <1294504835.91.0.921305723239.issue1777412@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

time.asctime(), time.ctime() and time.strftime() are no more not limited for the year field if accept2dyear=0. Except with Visual Studio or on Solaris: the year is limited to the range [1; 9999].

datetime.strftime() is limited to year >= 1000 (instead of year >= 1900) because it cannot set accept2dyear=0 temporary (it is no thread safe). We might fix it, but it is complex and not really needed. The correct fix is just to remove accept2dyear (and consider that accept2dyear=0), which cannot be done before Python 3.3.

Anyway, the situation is much better in Python 3.2 than Python 3.1, and I consider that it's enough. Let's close the issue.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1777412>
_______________________________________

From report at bugs.python.org  Sat Jan  8 18:02:58 2011
From: report at bugs.python.org (Skip Montanaro)
Date: Sat, 08 Jan 2011 17:02:58 +0000
Subject: [issue10864] time.strftime("%Y"): limitation of 4 digits on
	OpenIndiana (Solaris)
In-Reply-To: <1294454597.35.0.957818587484.issue10864@psf.upfronthosting.co.za>
Message-ID: <1294506178.43.0.70585352459.issue10864@psf.upfronthosting.co.za>


Skip Montanaro <skip at pobox.com> added the comment:

Skip> On my Mac it displays "12345".  I don't see that as a big problem.

haypo> Why do you say "problem"? It is the correct result :-)

I agree.  I interpreted your ticket as complaining that it should raise
a ValueError if year > 9999:

>> time.strftime() should raise a ValueError if the year is bigger
>> than 9999, as it is done with Visual Studio for year
>> outside [1; 9999].

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10864>
_______________________________________

From report at bugs.python.org  Sat Jan  8 18:26:26 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 08 Jan 2011 17:26:26 +0000
Subject: [issue10864] time.strftime("%Y"): limitation of 4 digits on
	OpenIndiana (Solaris)
In-Reply-To: <1294506178.43.0.70585352459.issue10864@psf.upfronthosting.co.za>
Message-ID: <1294507703.14757.0.camel@marge>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Le samedi 08 janvier 2011 ? 17:02 +0000, Skip Montanaro a ?crit :
> I agree.  I interpreted your ticket as complaining that it should raise
> a ValueError if year > 9999:

Only on OpenIndiana because on this specific OS, "%Y" only supoprts year
in [1; 9999]. For other values, it gives strange results :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10864>
_______________________________________

From report at bugs.python.org  Sat Jan  8 20:34:20 2011
From: report at bugs.python.org (ingemar)
Date: Sat, 08 Jan 2011 19:34:20 +0000
Subject: [issue10828] Cannot use nonascii utf8 in names of files imported from
In-Reply-To: <1294170257.81.0.980912064683.issue10828@psf.upfronthosting.co.za>
Message-ID: <1294515260.83.0.52420897335.issue10828@psf.upfronthosting.co.za>


ingemar <ingemar at sijohansson.com> added the comment:

python.exe -c "import locale; print('ANSI code page: {}'.format(locale.getpreferredencoding()))"
ANSI code page: cp1252


python.exe -c "import os; fn=os.fsencode('?'); print(ascii(fn))"
b'\xe4'
and no error raised

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10828>
_______________________________________

From report at bugs.python.org  Sat Jan  8 20:37:02 2011
From: report at bugs.python.org (Doug Hellmann)
Date: Sat, 08 Jan 2011 19:37:02 +0000
Subject: [issue7372] Regression in pstats
In-Reply-To: <1258765391.77.0.857956675588.issue7372@psf.upfronthosting.co.za>
Message-ID: <1294515422.34.0.379275150921.issue7372@psf.upfronthosting.co.za>


Doug Hellmann <doug.hellmann at gmail.com> added the comment:

I just ran into this problem with pstats under Python 2.7.  The ticket is marked as "fixed", but it looks like the change was only checked in under the py3k branch.

What's the policy on fixing stuff like this for 2.7 patch releases?

Thanks,
Doug

----------
nosy: +doughellmann

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7372>
_______________________________________

From report at bugs.python.org  Sat Jan  8 20:50:54 2011
From: report at bugs.python.org (Jose-Luis Fernandez-Barros)
Date: Sat, 08 Jan 2011 19:50:54 +0000
Subject: [issue10863] zlib.compress() fails with string
In-Reply-To: <1294430571.2.0.193589316262.issue10863@psf.upfronthosting.co.za>
Message-ID: <1294516254.79.0.993658947887.issue10863@psf.upfronthosting.co.za>


Jose-Luis Fernandez-Barros <jlfbarros at gmail.com> added the comment:

Thanks for your answer.

Error remains at development "The Python Standard Library", secction 12. Data Compression and Archiving
  http://docs.python.org/dev/py3k/library/zlib.html#module-zlib
zlib.compress(string[, level])

----------
resolution: fixed -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10863>
_______________________________________

From report at bugs.python.org  Sat Jan  8 21:12:51 2011
From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=)
Date: Sat, 08 Jan 2011 20:12:51 +0000
Subject: [issue10867] mmap.flush() issue msync() even if mapping was created
	with prot=mmap.PROT_READ only
In-Reply-To: <1294489230.48.0.811640987738.issue10867@psf.upfronthosting.co.za>
Message-ID: <1294517571.63.0.730373192828.issue10867@psf.upfronthosting.co.za>


???? ????????? <socketpair at gmail.com> added the comment:

I have changed title of the bug. This is more precisely describe the problem.

In my code, I do mmap.close(), so msync does not called.

Generally, calling msync() on read-only mapping is not needed at all. And meven more, calling msync() on memory-mapped USB-camera will lead to EIO errno

I think, that flush() should be no-op if mapping is read-only.

----------
title: python mmap objects issue msync() in destructor even if mapping was created with  prot=mmap.PROT_READ only -> mmap.flush() issue msync() even if mapping was created with  prot=mmap.PROT_READ only

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10867>
_______________________________________

From report at bugs.python.org  Sat Jan  8 21:55:32 2011
From: report at bugs.python.org (ipatrol)
Date: Sat, 08 Jan 2011 20:55:32 +0000
Subject: [issue7511] msvc9compiler.py: ValueError: [u'path']
In-Reply-To: <1260858478.84.0.495655867168.issue7511@psf.upfronthosting.co.za>
Message-ID: <1294520132.77.0.220701077232.issue7511@psf.upfronthosting.co.za>


ipatrol <ipatrol6010 at yahoo.com> added the comment:

Going through more than a few registry keys, here are some that stood out for me:

"HKEY_CURRENT_USER\Software\Microsoft\Microsoft SDKs\Windows\v6.0A" InstallationFolder

"HKEY_CURRENT_USER\Software\Microsoft\Microsoft SDKs\Windows\v6.1" InstallationFolder

"HKEY_CURRENT_USER\Software\Microsoft\VCExpress\9.0\External Tools" ToolDir1

"HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SDKs\Windows\v6.0A" InstallationFolder

"HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SDKs\Windows\v6.1" InstallationFolder

"HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VisualStudio\SxS\VC7" 9.0

"HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Microsoft SDKs\Windows" CurrentInstallFolder

"HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\VisualStudio\9.0\Setup\VC" ProductDir

"HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\VisualStudio\SxS\VC7" 9.0


Maybe they can be read to tease out the install dirs?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7511>
_______________________________________

From report at bugs.python.org  Sat Jan  8 22:04:42 2011
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 08 Jan 2011 21:04:42 +0000
Subject: [issue10863] zlib.compress() fails with string
In-Reply-To: <1294430571.2.0.193589316262.issue10863@psf.upfronthosting.co.za>
Message-ID: <1294520682.9.0.395942635509.issue10863@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Quite right, this is now fixed in r87870.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10863>
_______________________________________

From report at bugs.python.org  Sat Jan  8 22:04:48 2011
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 08 Jan 2011 21:04:48 +0000
Subject: [issue10863] zlib.compress() fails with string
In-Reply-To: <1294430571.2.0.193589316262.issue10863@psf.upfronthosting.co.za>
Message-ID: <1294520688.16.0.209395087063.issue10863@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10863>
_______________________________________

From report at bugs.python.org  Sat Jan  8 22:37:53 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 08 Jan 2011 21:37:53 +0000
Subject: [issue9844] calling nonexisting function under __INSURE__
In-Reply-To: <1284358768.31.0.932745075936.issue9844@psf.upfronthosting.co.za>
Message-ID: <1294522673.46.0.926744984772.issue9844@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

If the source will not compile with __INSURE__ defined, then perhaps no one has ever tried to do that with 3.x. That would suggest that the ifdef could be removed. In any case, the non-function call should be removed.
Is the other function called anywhere else? 

Which file contains this code, and which has the functions in 2.7 (so I can verify removal in 3.x)?

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9844>
_______________________________________

From report at bugs.python.org  Sat Jan  8 22:45:42 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 08 Jan 2011 21:45:42 +0000
Subject: [issue9904] Cosmetic issues that may warrant a fix in symtable.h/c
In-Reply-To: <1284964146.62.0.95975690396.issue9904@psf.upfronthosting.co.za>
Message-ID: <1294523142.3.0.492723781886.issue9904@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I think this needs at least two patches: one to change comments, another to remove two fields. Can you prepare something?

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9904>
_______________________________________

From report at bugs.python.org  Sat Jan  8 23:14:52 2011
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 08 Jan 2011 22:14:52 +0000
Subject: [issue9880] Python 2.7 Won't Build: SystemError: unknown opcode
In-Reply-To: <1284674532.4.0.904279806396.issue9880@psf.upfronthosting.co.za>
Message-ID: <1294524892.84.0.219595017775.issue9880@psf.upfronthosting.co.za>


Changes by Stefan Krah <stefan-usenet at bytereef.org>:


----------
nosy: +skrah

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9880>
_______________________________________

From report at bugs.python.org  Sat Jan  8 23:17:05 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 08 Jan 2011 22:17:05 +0000
Subject: [issue3821] trace module bug when using --missing
In-Reply-To: <1220976433.09.0.355914664139.issue3821@psf.upfronthosting.co.za>
Message-ID: <1294525025.83.0.493174195737.issue3821@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
versions: +Python 3.2 -Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3821>
_______________________________________

From report at bugs.python.org  Sun Jan  9 00:15:33 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 08 Jan 2011 23:15:33 +0000
Subject: [issue9264] trace.py documentation is incomplete
In-Reply-To: <1279167085.71.0.92983376648.issue9264@psf.upfronthosting.co.za>
Message-ID: <1294528533.19.0.394642217983.issue9264@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9264>
_______________________________________

From report at bugs.python.org  Sun Jan  9 00:28:25 2011
From: report at bugs.python.org (Charles-Francois Natali)
Date: Sat, 08 Jan 2011 23:28:25 +0000
Subject: [issue10867] mmap.flush() issue msync() even if mapping was created
	with prot=mmap.PROT_READ only
In-Reply-To: <1294489230.48.0.811640987738.issue10867@psf.upfronthosting.co.za>
Message-ID: <1294529305.79.0.235258601801.issue10867@psf.upfronthosting.co.za>


Charles-Francois Natali <neologix at free.fr> added the comment:

>  have changed title of the bug. This is more precisely describe the problem

Yes, its's not quite the same problem.

> I think, that flush() should be no-op if mapping is read-only.

This has already be done for py3k. See http://svn.python.org/view/python/branches/py3k/Modules/mmapmodule.c?r1=84950&r2=85678

Note that you shouldn't be calling flush in the first place...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10867>
_______________________________________

From report at bugs.python.org  Sun Jan  9 00:32:13 2011
From: report at bugs.python.org (Edoardo Spadolini)
Date: Sat, 08 Jan 2011 23:32:13 +0000
Subject: [issue10868] ABCMeta.register() should work as a decorator
In-Reply-To: <1294529533.15.0.442078735636.issue10868@psf.upfronthosting.co.za>
Message-ID: <1294529533.15.0.442078735636.issue10868@psf.upfronthosting.co.za>


New submission from Edoardo Spadolini <kerio00 at gmail.com>:

If we make ABCMeta.register() return the registered class, like atexit.register() does for the registered function, we can then use it as a decorator:

Now:

class Foo:
    ...
ABarC.register(Foo)

With this change:

@ABarC.register
class Foo:
    ...

The only problem this would cause is in code that relies on ABCMeta.register() to return None; I can't think of a reason anyone would rely on this, but...

----------
components: Library (Lib)
files: abcmeta_register_deco.diff
keywords: patch
messages: 125804
nosy: kerio
priority: normal
severity: normal
status: open
title: ABCMeta.register() should work as a decorator
type: feature request
versions: Python 3.3
Added file: http://bugs.python.org/file20314/abcmeta_register_deco.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10868>
_______________________________________

From report at bugs.python.org  Sun Jan  9 00:33:12 2011
From: report at bugs.python.org (R. David Murray)
Date: Sat, 08 Jan 2011 23:33:12 +0000
Subject: [issue10861] urllib2 sporadically falsely claims infinite redirect
In-Reply-To: <1294429318.76.0.578486353319.issue10861@psf.upfronthosting.co.za>
Message-ID: <1294529592.78.0.721226044975.issue10861@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I ran into a redirection loop when cookies were blocked from google, who should know better.  And then they had the gall to blacklist my ip for an attempted DOS attack.  So a feature request may not be out of order; but I for one would not be motivated enough to write a patch for it.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10861>
_______________________________________

From report at bugs.python.org  Sun Jan  9 00:33:16 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 08 Jan 2011 23:33:16 +0000
Subject: [issue10868] ABCMeta.register() should work as a decorator
In-Reply-To: <1294529533.15.0.442078735636.issue10868@psf.upfronthosting.co.za>
Message-ID: <1294529596.2.0.20535559411.issue10868@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Looks like a good idea to me.

----------
nosy: +benjamin.peterson, gvanrossum, pitrou
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10868>
_______________________________________

From report at bugs.python.org  Sun Jan  9 00:41:14 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 08 Jan 2011 23:41:14 +0000
Subject: [issue10868] ABCMeta.register() should work as a decorator
In-Reply-To: <1294529533.15.0.442078735636.issue10868@psf.upfronthosting.co.za>
Message-ID: <1294530074.81.0.993212688006.issue10868@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Thanks for the report and patch.  Some comments:


+        """Register a virtual subclass of an ABC. Returns the said subclass."""
Should be ?Return?, for consistency.

+        return subclass # For usage as a decorator
I?d move that to the docstring.

Can you edit the docs (remember to use the versionchanged directive) too?

----------
assignee:  -> eric.araujo
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10868>
_______________________________________

From report at bugs.python.org  Sun Jan  9 00:46:18 2011
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 08 Jan 2011 23:46:18 +0000
Subject: [issue9880] Python 2.7 Won't Build: SystemError: unknown opcode
In-Reply-To: <1284674532.4.0.904279806396.issue9880@psf.upfronthosting.co.za>
Message-ID: <1294530378.25.0.934655826303.issue9880@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

I narrowed this issue down to -ftree-vectorize, which is part of
-O3.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9880>
_______________________________________

From report at bugs.python.org  Sun Jan  9 00:52:10 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 08 Jan 2011 23:52:10 +0000
Subject: [issue10357] ** and "mapping" are poorly defined in python docs
In-Reply-To: <1289222187.72.0.886873143688.issue10357@psf.upfronthosting.co.za>
Message-ID: <1294530730.29.0.128466220805.issue10357@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Clarified what it means to be a mapping in r87871 and r87872.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10357>
_______________________________________

From report at bugs.python.org  Sun Jan  9 01:05:46 2011
From: report at bugs.python.org (Edoardo Spadolini)
Date: Sun, 09 Jan 2011 00:05:46 +0000
Subject: [issue10868] ABCMeta.register() should work as a decorator
In-Reply-To: <1294529533.15.0.442078735636.issue10868@psf.upfronthosting.co.za>
Message-ID: <1294531546.48.0.778936722109.issue10868@psf.upfronthosting.co.za>


Edoardo Spadolini <kerio00 at gmail.com> added the comment:

Ok, edited the docs too; hope I did everything right...

----------
Added file: http://bugs.python.org/file20315/abcmeta_register_deco_with_docs.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10868>
_______________________________________

From report at bugs.python.org  Sun Jan  9 01:06:08 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 09 Jan 2011 00:06:08 +0000
Subject: [issue10533] Need example of using __missing__
In-Reply-To: <1290704449.7.0.95801510837.issue10533@psf.upfronthosting.co.za>
Message-ID: <1294531568.31.0.28956473134.issue10533@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Great, thanks.

We?ll see later if more cross-links are needed.

----------
stage: needs patch -> committed/rejected

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10533>
_______________________________________

From report at bugs.python.org  Sun Jan  9 01:07:56 2011
From: report at bugs.python.org (Ned Deily)
Date: Sun, 09 Jan 2011 00:07:56 +0000
Subject: [issue5622] wrong error from curses.wrapper if curses initialization
	fails
In-Reply-To: <1238511637.05.0.307555783931.issue5622@psf.upfronthosting.co.za>
Message-ID: <1294531676.61.0.609700456006.issue5622@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

A simpler way to reproduce:
TERM= python -c 'import curses; curses.wrapper(lambda a:a.getch())'

I looked at adding an automated test case for this but it is a little tricky to make it bulletproof across all environments. Since the problem is really a one-time coding error, perhaps a permanent test case can be omitted?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5622>
_______________________________________

From report at bugs.python.org  Sun Jan  9 01:13:40 2011
From: report at bugs.python.org (David White)
Date: Sun, 09 Jan 2011 00:13:40 +0000
Subject: [issue10869] ast.increment_lineno() increments root node twice
In-Reply-To: <1294532020.29.0.848816436513.issue10869@psf.upfronthosting.co.za>
Message-ID: <1294532020.29.0.848816436513.issue10869@psf.upfronthosting.co.za>


New submission from David White <dappawit at gmail.com>:

When using ast.increment_lineno(), it visits the root node twice.  Therefore if the root node contains the lineno attribute, it is incremented twice.  (Often, the root node will not have a lineno attribute, so there is no effect.  This is why the current test case passes.)

I believe that part of the problem is that the docs for ast.walk(), which ast.increment_lineno() calls, state that it visits all child nodes of the given node.  It does not state that it also visits the given node itself.

I use 2.7, but I noticed the same issue is present in 3.1 and the py3k branch.

I have written a patch that fixes both of these issues, ast.increment_lineno and the ast.walk docs, and adds a new test case to the test suite.  I will be posting it after I submit the issue (so I have the issue number).

----------
components: Library (Lib)
messages: 125813
nosy: dpwhite2
priority: normal
severity: normal
status: open
title: ast.increment_lineno() increments root node twice
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10869>
_______________________________________

From report at bugs.python.org  Sun Jan  9 01:19:30 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 09 Jan 2011 00:19:30 +0000
Subject: [issue10868] ABCMeta.register() should work as a decorator
In-Reply-To: <1294529533.15.0.442078735636.issue10868@psf.upfronthosting.co.za>
Message-ID: <1294532370.73.0.0848040162198.issue10868@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Edited your patch to fix some nits.  If there is no opposition, I?ll commit this to py3k when 3.2 is out.

----------
Added file: http://bugs.python.org/file20316/abcmeta_register_v3.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10868>
_______________________________________

From report at bugs.python.org  Sun Jan  9 01:26:58 2011
From: report at bugs.python.org (Charles-Francois Natali)
Date: Sun, 09 Jan 2011 00:26:58 +0000
Subject: [issue9504] signal.signal/signal.alarm not working as expected
In-Reply-To: <1280910836.88.0.645209486589.issue9504@psf.upfronthosting.co.za>
Message-ID: <1294532818.19.0.599064185448.issue9504@psf.upfronthosting.co.za>


Charles-Francois Natali <neologix at free.fr> added the comment:

It's due to the way the python interpreter handles signals: when the signal is received, python runs a stub signal handler that just sets a flag indicating that the signal has been received: the actual handler is executed later, synchronously, mainly from the main evaluation loop.
The problem here is that since the main process is performing a read until EOF is reached (i.e. until the subprocess exits), the C code loops around the read(2) call without giving a chance for the handler to run.
A patch for is similar issue has been applied, see http://bugs.python.org/issue9617#

But it only fixed writes, not reads.
I think _bufferedreader_read_all and _bufferedreader_read_generic should be fixed too to call PyErr_CheckSignals().

----------
nosy: +neologix

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9504>
_______________________________________

From report at bugs.python.org  Sun Jan  9 01:30:41 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 09 Jan 2011 00:30:41 +0000
Subject: [issue10868] ABCMeta.register() should work as a decorator
In-Reply-To: <1294529533.15.0.442078735636.issue10868@psf.upfronthosting.co.za>
Message-ID: <1294533041.04.0.870237752252.issue10868@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

+1

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10868>
_______________________________________

From report at bugs.python.org  Sun Jan  9 01:56:45 2011
From: report at bugs.python.org (David White)
Date: Sun, 09 Jan 2011 00:56:45 +0000
Subject: [issue10869] ast.increment_lineno() increments root node twice
In-Reply-To: <1294532020.29.0.848816436513.issue10869@psf.upfronthosting.co.za>
Message-ID: <1294534605.67.0.573288295734.issue10869@psf.upfronthosting.co.za>


Changes by David White <dappawit at gmail.com>:


----------
keywords: +patch
Added file: http://bugs.python.org/file20317/increment_linenos_27.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10869>
_______________________________________

From report at bugs.python.org  Sun Jan  9 01:57:54 2011
From: report at bugs.python.org (David White)
Date: Sun, 09 Jan 2011 00:57:54 +0000
Subject: [issue10869] ast.increment_lineno() increments root node twice
In-Reply-To: <1294532020.29.0.848816436513.issue10869@psf.upfronthosting.co.za>
Message-ID: <1294534674.69.0.982541295161.issue10869@psf.upfronthosting.co.za>


Changes by David White <dappawit at gmail.com>:


Added file: http://bugs.python.org/file20318/increment_linenos_31.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10869>
_______________________________________

From report at bugs.python.org  Sun Jan  9 02:02:51 2011
From: report at bugs.python.org (David White)
Date: Sun, 09 Jan 2011 01:02:51 +0000
Subject: [issue10869] ast.increment_lineno() increments root node twice
In-Reply-To: <1294532020.29.0.848816436513.issue10869@psf.upfronthosting.co.za>
Message-ID: <1294534971.93.0.578803639936.issue10869@psf.upfronthosting.co.za>


Changes by David White <dappawit at gmail.com>:


----------
resolution:  -> fixed
Added file: http://bugs.python.org/file20319/increment_linenos_3k.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10869>
_______________________________________

From report at bugs.python.org  Sun Jan  9 02:08:11 2011
From: report at bugs.python.org (David White)
Date: Sun, 09 Jan 2011 01:08:11 +0000
Subject: [issue10869] ast.increment_lineno() increments root node twice
In-Reply-To: <1294532020.29.0.848816436513.issue10869@psf.upfronthosting.co.za>
Message-ID: <1294535291.29.0.413904808279.issue10869@psf.upfronthosting.co.za>


David White <dappawit at gmail.com> added the comment:

I've uploaded the patches.  Beware, this is my first attempt to contribute.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10869>
_______________________________________

From report at bugs.python.org  Sun Jan  9 02:11:19 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 09 Jan 2011 01:11:19 +0000
Subject: [issue10639] reindent.py converts newlines to platform default
In-Reply-To: <1291653413.79.0.461728889357.issue10639@psf.upfronthosting.co.za>
Message-ID: <1294535479.68.0.441730256572.issue10639@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I did a bit of testing on demo files.  The first one I tested with had mixed EOLs, in which case the newlines attribute will be a tuple and open(..., newline=r.newlines) will fail.  For reference: http://docs.python.org/dev/library/io#io.TextIOBase.newlines

What would be the best behavior in such cases?  Refuse the temptation to guess and exit?

----------
nosy: +pitrou
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10639>
_______________________________________

From report at bugs.python.org  Sun Jan  9 02:14:53 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 09 Jan 2011 01:14:53 +0000
Subject: [issue10869] ast.increment_lineno() increments root node twice
In-Reply-To: <1294532020.29.0.848816436513.issue10869@psf.upfronthosting.co.za>
Message-ID: <1294535693.98.0.105928811926.issue10869@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
keywords: +needs review
nosy: +aronacher, rhettinger
resolution: fixed -> 
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10869>
_______________________________________

From report at bugs.python.org  Sun Jan  9 02:17:02 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 09 Jan 2011 01:17:02 +0000
Subject: [issue10835] sys.executable default and altinstall
In-Reply-To: <1294231894.7.0.0581440878919.issue10835@psf.upfronthosting.co.za>
Message-ID: <1294535822.57.0.779864533796.issue10835@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/issue10835>
_______________________________________

From report at bugs.python.org  Sun Jan  9 02:21:21 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 09 Jan 2011 01:21:21 +0000
Subject: [issue9419] RUNSHARED needs LDFLAGS
In-Reply-To: <1280423222.23.0.51081739049.issue9419@psf.upfronthosting.co.za>
Message-ID: <1294536081.65.0.510214519991.issue9419@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/issue9419>
_______________________________________

From report at bugs.python.org  Sun Jan  9 02:38:27 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 09 Jan 2011 01:38:27 +0000
Subject: [issue10512] regrtest ResourceWarning - unclosed sockets and files
In-Reply-To: <1290506536.77.0.313292165719.issue10512@psf.upfronthosting.co.za>
Message-ID: <1294537107.9.0.0516161280395.issue10512@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/issue10512>
_______________________________________

From report at bugs.python.org  Sun Jan  9 02:41:53 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 09 Jan 2011 01:41:53 +0000
Subject: [issue9504] signal.signal/signal.alarm not working as expected
In-Reply-To: <1280910836.88.0.645209486589.issue9504@psf.upfronthosting.co.za>
Message-ID: <1294537313.92.0.110815089328.issue9504@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9504>
_______________________________________

From report at bugs.python.org  Sun Jan  9 03:31:29 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Sun, 09 Jan 2011 02:31:29 +0000
Subject: [issue2986] difflib.SequenceMatcher not matching long sequences
In-Reply-To: <1211920199.48.0.934398772587.issue2986@psf.upfronthosting.co.za>
Message-ID: <1294540289.58.0.0200793728391.issue2986@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/issue2986>
_______________________________________

From report at bugs.python.org  Sun Jan  9 03:40:25 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 09 Jan 2011 02:40:25 +0000
Subject: [issue10828] Cannot use nonascii utf8 in names of files imported from
In-Reply-To: <1294170257.81.0.980912064683.issue10828@psf.upfronthosting.co.za>
Message-ID: <1294540825.33.0.360294796512.issue10828@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> ANSI code page: cp1252 ...os.fsencode('?') => b'\xe4'

Hum, I ran your example with a debugger, and ok, I now remember the whole thing.

I fixed Python to support non-ASCII characters (... only non-ASCII characters encodable to the ANSI code page for Windows) in the *search path*, not in the module name.

The import machinery encodes each search path to the filesystem encoding, but it encodes the module name to UTF-8. Concatenate two byte strings encoded to different encodings doesn't work (it leads to mojibake).

To fix this problem, there are two solutions:

 a) encode the module name to the fileystem encoding
 b) manipulate paths as unicode strings; to access the filesystem: use the wide character (unicode) API of Windows and encode paths to the filesystem encoding on UNIX/BSD

It is easier to implement (a) than (b), but (a) only gives you the support of paths and module names encodable to the ANSI code page.

(b) gives you the full unicode support because it never *encodes* paths to the filesystem encoding, but it may *decodes* paths from the filesystem encoding. Encode a path raises a UnicodeEncodeError on the first character not encodable to the ANSI code page, whereas decode a path never fails (except if the user manually changed its code page to a rare ANSI code page like UTF-8).

I implemented (b) in my import_unicode SVN branch, but as I wrote, I still have some work to merge this branch into py3k, and anyway I will wait for Python 3.3.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10828>
_______________________________________

From report at bugs.python.org  Sun Jan  9 03:59:54 2011
From: report at bugs.python.org (R. David Murray)
Date: Sun, 09 Jan 2011 02:59:54 +0000
Subject: [issue5871] email.header.Header too lax with embeded newlines
In-Reply-To: <1240953937.2.0.828159818097.issue5871@psf.upfronthosting.co.za>
Message-ID: <1294541994.34.0.974608920701.issue5871@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Receiving no negative votes :), I've committed this to py3k in r87873, 3.1 in r87874, and 2.7 in r87875.

Barry, Martin, do you think this should be backported as a security fix?  I'm thinking it should be.

----------
nosy: +loewis
resolution:  -> fixed
stage: patch review -> committed/rejected
type: behavior -> security

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5871>
_______________________________________

From report at bugs.python.org  Sun Jan  9 04:16:49 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 09 Jan 2011 03:16:49 +0000
Subject: [issue10858] Make source code links less prominent
In-Reply-To: <1294423770.11.0.311474750627.issue10858@psf.upfronthosting.co.za>
Message-ID: <1294543009.44.0.97018842923.issue10858@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

I'm curious as to how the experiment is being carried out and how conclusions will be drawn.

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10858>
_______________________________________

From report at bugs.python.org  Sun Jan  9 04:22:36 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 09 Jan 2011 03:22:36 +0000
Subject: [issue2986] difflib.SequenceMatcher not matching long sequences
In-Reply-To: <1211920199.48.0.934398772587.issue2986@psf.upfronthosting.co.za>
Message-ID: <1294543356.81.0.220471404525.issue2986@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
stage: needs patch -> committed/rejected

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2986>
_______________________________________

From report at bugs.python.org  Sun Jan  9 05:47:19 2011
From: report at bugs.python.org (ingemar)
Date: Sun, 09 Jan 2011 04:47:19 +0000
Subject: [issue10828] Cannot use nonascii utf8 in names of files imported from
In-Reply-To: <1294170257.81.0.980912064683.issue10828@psf.upfronthosting.co.za>
Message-ID: <1294548439.29.0.826288460362.issue10828@psf.upfronthosting.co.za>


ingemar <ingemar at sijohansson.com> added the comment:

Thanks Victor for the explanation.

Py3 is still far better than Py2, letting me use utf-8 as much as it does.

I will be able to live with this bug being known. I can understand though, that people in some places of the world may feel more concerned.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10828>
_______________________________________

From report at bugs.python.org  Sun Jan  9 06:32:04 2011
From: report at bugs.python.org (David-Sarah Hopwood)
Date: Sun, 09 Jan 2011 05:32:04 +0000
Subject: [issue1602] windows console doesn't print utf8 (Py30a2)
In-Reply-To: <1197453390.87.0.813702844893.issue1602@psf.upfronthosting.co.za>
Message-ID: <1294551124.96.0.713012981792.issue1602@psf.upfronthosting.co.za>


David-Sarah Hopwood <david-sarah at jacaranda.org> added the comment:

It is certainly possible to write Unicode to the console successfully using WriteConsoleW. This works regardless of the console code page, including 65001. The code <a href="http://tahoe-lafs.org/trac/tahoe-lafs/browser/src/allmydata/windows/fixups.py">here</a> does so (it's for Python 2.x, but you'd be calling WriteConsoleW from C anyway).

WriteConsoleW has one bug that I know of, which is that it <a href="http://tahoe-lafs.org/trac/tahoe-lafs/ticket/1232">fails when writing more than 26608 characters at once</a>. That's easy to work around by limiting the amount of data passed in a single call.

Fonts are not Python's problem, but encoding is. It doesn't make sense to fail to output the right characters just because some users might not have selected fonts that can display those characters. This bug should be reopened.

(For completeness, it is possible to display Unicode on the console using fonts other than Lucida Console and Consolas, but it <a href="http://stackoverflow.com/questions/878972/windows-cmd-encoding-change-causes-python-crash/3259271#3259271">requires a registry hack</a>.)

----------
nosy: +davidsarah

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1602>
_______________________________________

From report at bugs.python.org  Sun Jan  9 07:52:59 2011
From: report at bugs.python.org (Glenn Linderman)
Date: Sun, 09 Jan 2011 06:52:59 +0000
Subject: [issue1602] windows console doesn't print utf8 (Py30a2)
In-Reply-To: <1197453390.87.0.813702844893.issue1602@psf.upfronthosting.co.za>
Message-ID: <1294555979.18.0.574724683586.issue1602@psf.upfronthosting.co.za>


Glenn Linderman <v+python at g.nevcal.com> added the comment:

Interesting!

I was able to tweak David-Sarah's code to work with Python 3.x, mostly doing things that 2to3 would probably do: changing  unicode() to str(), dropping u from u'...', etc.

I skipped the unmangling of command-line arguments, because it produced an error I didn't understand, about needing a buffer protocol.  But I'll attach David-Sarah's code + tweaks + a test case showing output of the Cyrillic alphabet to a console with code page 437 (at least, on my Win7-64 box, that is what it is).

Nice work, David-Sarah.  I'm quite sure this is not in a form usable inside Python 3, but it shows exactly what could be done inside Python 3 to make things work... and gives us a workaround if Python 3 is not fixed.

----------
Added file: http://bugs.python.org/file20320/unicode2.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1602>
_______________________________________

From report at bugs.python.org  Sun Jan  9 08:06:50 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 09 Jan 2011 07:06:50 +0000
Subject: [issue9904] Cosmetic issues that may warrant a fix in symtable.h/c
In-Reply-To: <1284964146.62.0.95975690396.issue9904@psf.upfronthosting.co.za>
Message-ID: <1294556810.92.0.8129285887.issue9904@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

If I recall correctly, st_nblocks and st_future are there for consistency with the corresponding compiler structures.

I believe st_future is also needed whenever a future flag affects the symtable construction (there aren't any at the moment, but a trawl through the version history in the Python 2.x symtable.c may reveal some)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9904>
_______________________________________

From report at bugs.python.org  Sun Jan  9 08:28:51 2011
From: report at bugs.python.org (David-Sarah Hopwood)
Date: Sun, 09 Jan 2011 07:28:51 +0000
Subject: [issue1602] windows console doesn't print utf8 (Py30a2)
In-Reply-To: <1197453390.87.0.813702844893.issue1602@psf.upfronthosting.co.za>
Message-ID: <1294558131.85.0.440055903585.issue1602@psf.upfronthosting.co.za>


David-Sarah Hopwood <david-sarah at jacaranda.org> added the comment:

Glenn Linderman wrote:
> I skipped the unmangling of command-line arguments, because it produced an error I didn't understand, about needing a buffer protocol.

If I understand correctly, that part isn't needed on Python 3 because issue2128 is already fixed there.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1602>
_______________________________________

From report at bugs.python.org  Sun Jan  9 08:36:55 2011
From: report at bugs.python.org (David-Sarah Hopwood)
Date: Sun, 09 Jan 2011 07:36:55 +0000
Subject: [issue2128] sys.argv is wrong for unicode strings
In-Reply-To: <1203179266.7.0.767749493824.issue2128@psf.upfronthosting.co.za>
Message-ID: <1294558615.21.0.00860554810313.issue2128@psf.upfronthosting.co.za>


David-Sarah Hopwood <david-sarah at jacaranda.org> added the comment:

The following code is being used to work around this issue for Python 2.x in Tahoe-LAFS:

    # This works around <http://bugs.python.org/issue2128>.
    GetCommandLineW = WINFUNCTYPE(LPWSTR)(("GetCommandLineW", windll.kernel32))
    CommandLineToArgvW = WINFUNCTYPE(POINTER(LPWSTR), LPCWSTR, POINTER(c_int)) \
                            (("CommandLineToArgvW", windll.shell32))

    argc = c_int(0)
    argv_unicode = CommandLineToArgvW(GetCommandLineW(), byref(argc))

    argv = [argv_unicode[i].encode('utf-8') for i in range(0, argc.value)]

    if not hasattr(sys, 'frozen'):
        # If this is an executable produced by py2exe or bbfreeze, then it will
        # have been invoked directly. Otherwise, unicode_argv[0] is the Python
        # interpreter, so skip that.
        argv = argv[1:]

        # Also skip option arguments to the Python interpreter.
        while len(argv) > 0:
            arg = argv[0]
            if not arg.startswith("-") or arg == "-":
                break
            argv = argv[1:]
            if arg == '-m':
                # sys.argv[0] should really be the absolute path of the module source,
                # but never mind
                break
            if arg == '-c':
                argv[0] = '-c'
                break

----------
nosy: +davidsarah
versions: +Python 2.5, Python 2.6, Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2128>
_______________________________________

From report at bugs.python.org  Sun Jan  9 08:39:07 2011
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 09 Jan 2011 07:39:07 +0000
Subject: [issue10869] ast.increment_lineno() increments root node twice
In-Reply-To: <1294532020.29.0.848816436513.issue10869@psf.upfronthosting.co.za>
Message-ID: <1294558747.31.0.648606542311.issue10869@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Thanks, fixed in r87876.  Will backport to other branches.

----------
nosy: +georg.brandl
resolution:  -> accepted
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10869>
_______________________________________

From report at bugs.python.org  Sun Jan  9 08:39:46 2011
From: report at bugs.python.org (David-Sarah Hopwood)
Date: Sun, 09 Jan 2011 07:39:46 +0000
Subject: [issue2128] sys.argv is wrong for unicode strings
In-Reply-To: <1203179266.7.0.767749493824.issue2128@psf.upfronthosting.co.za>
Message-ID: <1294558786.17.0.876522315598.issue2128@psf.upfronthosting.co.za>


David-Sarah Hopwood <david-sarah at jacaranda.org> added the comment:

Sorry, missed out the imports:

    from ctypes import WINFUNCTYPE, windll, POINTER, byref, c_int
    from ctypes.wintypes import LPWSTR, LPCWSTR

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2128>
_______________________________________

From report at bugs.python.org  Sun Jan  9 08:43:31 2011
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 09 Jan 2011 07:43:31 +0000
Subject: [issue9504] signal.signal/signal.alarm not working as expected
In-Reply-To: <1280910836.88.0.645209486589.issue9504@psf.upfronthosting.co.za>
Message-ID: <1294559011.42.0.031354240069.issue9504@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Antoine?

----------
assignee:  -> pitrou
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9504>
_______________________________________

From report at bugs.python.org  Sun Jan  9 08:48:03 2011
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 09 Jan 2011 07:48:03 +0000
Subject: [issue7372] Regression in pstats
In-Reply-To: <1258765391.77.0.857956675588.issue7372@psf.upfronthosting.co.za>
Message-ID: <1294559283.91.0.860673028328.issue7372@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

This change was backported to the 2.7 branch in r83533; it should therefore be in 2.7.1, but not 2.7.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7372>
_______________________________________

From report at bugs.python.org  Sun Jan  9 09:59:46 2011
From: report at bugs.python.org (Baptiste Lepilleur)
Date: Sun, 09 Jan 2011 08:59:46 +0000
Subject: [issue10870] Last line of argparse code samples can not be read on
	Windows
In-Reply-To: <1294563586.16.0.961055405371.issue10870@psf.upfronthosting.co.za>
Message-ID: <1294563586.16.0.961055405371.issue10870@psf.upfronthosting.co.za>


New submission from Baptiste Lepilleur <blep at users.sourceforge.net>:

When the code samples from the CHM documentation are displayed, if the lines are too long, a scroll bar is added at the bottom which prevents reading the last line of the code sample.

Usually this can be worked-around by making the windows larger, but some examples in the documentation of the argparse are so wide that even in full screen, the window is not wide enough.

I attached a screen capture to illustrate the issue (taken from section 14.4.3.3. nargs of Python 3.2b2). This is even worth with one-liner code sample when not browsing full screen (e.g. with the index on the side).

Environment: Windows XP SP3, resolution: 1024x768, python 3.2b2.

I don't know if it is possible, but adding a blank line at the end of code sample that are more than 80 characters wide would likely work-around the issue.

----------
assignee: docs at python
components: Documentation
files: argparse-codesample-unreadable.png
messages: 125832
nosy: blep, docs at python
priority: normal
severity: normal
status: open
title: Last line of argparse code samples can not be read on Windows
versions: Python 3.2
Added file: http://bugs.python.org/file20321/argparse-codesample-unreadable.png

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10870>
_______________________________________

From report at bugs.python.org  Sun Jan  9 10:03:12 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 09 Jan 2011 09:03:12 +0000
Subject: [issue1602] windows console doesn't print utf8 (Py30a2)
In-Reply-To: <1197453390.87.0.813702844893.issue1602@psf.upfronthosting.co.za>
Message-ID: <1294563792.48.0.258758561067.issue1602@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> It is certainly possible to write Unicode to the console 
> successfully using WriteConsoleW

Did you tried with characters not encodable to the code page and with character that cannot be rendeded by the font?

See msg120414 for my tests with WriteConsoleOutputW.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1602>
_______________________________________

From report at bugs.python.org  Sun Jan  9 10:07:40 2011
From: report at bugs.python.org (Baptiste Lepilleur)
Date: Sun, 09 Jan 2011 09:07:40 +0000
Subject: [issue10871] argparse example use "file" instead of "open"
In-Reply-To: <1294564060.95.0.807361745459.issue10871@psf.upfronthosting.co.za>
Message-ID: <1294564060.95.0.807361745459.issue10871@psf.upfronthosting.co.za>


New submission from Baptiste Lepilleur <blep at users.sourceforge.net>:

In section "14.4.3.6. type" of the argparse module, the following code sample is given:

>>> parser = argparse.ArgumentParser()
>>> parser.add_argument('foo', type=int)
>>> parser.add_argument('bar', type=file)
>>> parser.parse_args('2 temp.txt'.split())
Namespace(bar=<open file 'temp.txt', mode 'r' at 0x...>, foo=2)

The built-in "file" used for argument 'bar' no longer exists in python 3.2.

----------
assignee: docs at python
components: Documentation
messages: 125834
nosy: blep, docs at python
priority: normal
severity: normal
status: open
title: argparse example use "file" instead of "open"
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10871>
_______________________________________

From report at bugs.python.org  Sun Jan  9 10:18:56 2011
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 09 Jan 2011 09:18:56 +0000
Subject: [issue10870] Last line of argparse code samples can not be read on
	Windows
In-Reply-To: <1294563586.16.0.961055405371.issue10870@psf.upfronthosting.co.za>
Message-ID: <1294564736.82.0.249594019549.issue10870@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

I've shortened the examples in r87890.  I'll also investigate why the scrollbar isn't shown below the code.

----------
nosy: +georg.brandl
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10870>
_______________________________________

From report at bugs.python.org  Sun Jan  9 10:22:28 2011
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 09 Jan 2011 09:22:28 +0000
Subject: [issue10872] Add mode to TextIOWrapper repr
In-Reply-To: <1294564948.19.0.858903256762.issue10872@psf.upfronthosting.co.za>
Message-ID: <1294564948.19.0.858903256762.issue10872@psf.upfronthosting.co.za>


New submission from Georg Brandl <georg at python.org>:

The old file type had its mode in the repr(), which I think was useful; TextIOWrapper doesn't.  Can we add it back?

----------
assignee: pitrou
messages: 125836
nosy: georg.brandl, pitrou
priority: normal
severity: normal
status: open
title: Add mode to TextIOWrapper repr
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10872>
_______________________________________

From report at bugs.python.org  Sun Jan  9 10:31:27 2011
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 09 Jan 2011 09:31:27 +0000
Subject: [issue10871] argparse example use "file" instead of "open"
In-Reply-To: <1294564060.95.0.807361745459.issue10871@psf.upfronthosting.co.za>
Message-ID: <1294565487.78.0.278609120496.issue10871@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Thanks, this is now fixed in r87891.

----------
nosy: +georg.brandl
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10871>
_______________________________________

From report at bugs.python.org  Sun Jan  9 13:20:44 2011
From: report at bugs.python.org (Ashwin Purohit)
Date: Sun, 09 Jan 2011 12:20:44 +0000
Subject: [issue10873] String formatting example invalid
In-Reply-To: <1294575644.02.0.857949444366.issue10873@psf.upfronthosting.co.za>
Message-ID: <1294575644.02.0.857949444366.issue10873@psf.upfronthosting.co.za>


New submission from Ashwin Purohit <purohit at gmail.com>:

Your example on page http://docs.python.org/tutorial/inputoutput.html is outdated and won't work in Python 2.7:

Basic usage of the str.format() method looks like this:

>>> print 'We are the {} who say "{}!"'.format('knights', 'Ni')
We are the knights who say "Ni!"


Now, all brackets have to have a numeric or keyword argument.

----------
assignee: docs at python
components: Documentation
messages: 125838
nosy: doagie, docs at python
priority: normal
severity: normal
status: open
title: String formatting example invalid
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10873>
_______________________________________

From report at bugs.python.org  Sun Jan  9 13:26:24 2011
From: report at bugs.python.org (Pierre Quentel)
Date: Sun, 09 Jan 2011 12:26:24 +0000
Subject: [issue4953] cgi module cannot handle POST with multipart/form-data
	in	3.0
In-Reply-To: <1232010166.79.0.972664060868.issue4953@psf.upfronthosting.co.za>
Message-ID: <1294575984.07.0.700034944239.issue4953@psf.upfronthosting.co.za>


Pierre Quentel <pierre.quentel at gmail.com> added the comment:

Here is the diff file for the revised version of cgi.py

FieldStorage tests if the stream is an instance of (a subclass of) io.TextIOBase. If true, data is read from its attribute buffer ; if it hasn't one (eg for StringIO instances), an AttributeException is raised. Should we have a more specific exception ?
If false, the stream's method read() is supposed to return bytes ; an exception will be raised if it's not the case

The encoding used to decode keys and values to strings is the attribute "encoding" of the stream, or "latin-1" if this attribute doesn't exist

Besides FieldStorage, I modified the  parse() function at module level, but not parse_multipart (should it be kept at all ?)

I leave the code to set sys.stdin to binary on Windows for the moment, but it can be removed in the final version thanks to Victor's fix of issue 10841

I modified cgi_test.py and test_cgi.py (sent in a next post), all the tests pass with the revised version of cgi.py on my PC

While testing the patch I found other related things that I suppose should be changed (but need to check again - perhaps there are already tracker issues about them) :
- in http.server.CGIHTPPRequestHandler, the -u option should be removed (line 1123)
- on Windows, http.server.SimpleHTTPRequestHandler.list_directory() fails with Arabic characters (mbcs encoding fails, utf-8 works)
- in urllib.parse.unquote(), default encoding should be latin-1, not utf-8 (submitting a simple form with French accented characters raises a UnicodeEncodeError when trying to print the submitted value)

----------
Added file: http://bugs.python.org/file20322/cgi_diff_20110109.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4953>
_______________________________________

From report at bugs.python.org  Sun Jan  9 13:28:03 2011
From: report at bugs.python.org (Pierre Quentel)
Date: Sun, 09 Jan 2011 12:28:03 +0000
Subject: [issue4953] cgi module cannot handle POST with multipart/form-data
	in	3.0
In-Reply-To: <1232010166.79.0.972664060868.issue4953@psf.upfronthosting.co.za>
Message-ID: <1294576083.0.0.454569216524.issue4953@psf.upfronthosting.co.za>


Pierre Quentel <pierre.quentel at gmail.com> added the comment:

cgi tests

----------
Added file: http://bugs.python.org/file20323/cgi_tests.zip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4953>
_______________________________________

From report at bugs.python.org  Sun Jan  9 13:52:12 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 09 Jan 2011 12:52:12 +0000
Subject: [issue10833] Replace %.100s by %s in PyErr_Format(): the arbitrary
	limit of 500 bytes is outdated
In-Reply-To: <1294196554.94.0.785505480291.issue10833@psf.upfronthosting.co.za>
Message-ID: <1294577532.47.0.104678434485.issue10833@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> I am concerned about conditions that are impossible in a valid
> program.  However, if you have a buffer overflow that trashes your
> tp_name pointer so that it suddenly resolves to a binary code section,

Yes, %.100s may avoid a crash after the buffer overflow on the string formatting, but it may quickly crash on another instruction. I don't think that you should limit the error message length to protect Python against buffer overflow. A buffer overflow can corrupt everything, and we should fix the buffer overflow instead :-)

> you will need all help you can get to find the bug.

You have debuggers like gdb for that.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10833>
_______________________________________

From report at bugs.python.org  Sun Jan  9 14:52:34 2011
From: report at bugs.python.org (SilentGhost)
Date: Sun, 09 Jan 2011 13:52:34 +0000
Subject: [issue10873] String formatting example invalid
In-Reply-To: <1294575644.02.0.857949444366.issue10873@psf.upfronthosting.co.za>
Message-ID: <1294581154.4.0.521911831004.issue10873@psf.upfronthosting.co.za>


SilentGhost <ghost.adh at gmail.com> added the comment:

Works as advertised for me. Unless more information is added, it looks like an invalid issue.

----------
nosy: +SilentGhost

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10873>
_______________________________________

From report at bugs.python.org  Sun Jan  9 14:56:50 2011
From: report at bugs.python.org (Eric Smith)
Date: Sun, 09 Jan 2011 13:56:50 +0000
Subject: [issue10873] String formatting example invalid
In-Reply-To: <1294575644.02.0.857949444366.issue10873@psf.upfronthosting.co.za>
Message-ID: <1294581410.94.0.0853340779128.issue10873@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

This feature was added in 2.7 (and 3.1, I think). If the numeric indices are not specified, they take the args in order.

----------
assignee: docs at python -> eric.smith
nosy: +eric.smith
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10873>
_______________________________________

From report at bugs.python.org  Sun Jan  9 15:07:53 2011
From: report at bugs.python.org (Carsten Koch)
Date: Sun, 09 Jan 2011 14:07:53 +0000
Subject: [issue410547] os.statvfs support for Windows
Message-ID: <1294582073.74.0.0391870696767.issue410547@psf.upfronthosting.co.za>


Carsten Koch <carstenkoch at users.sourceforge.net> added the comment:

Here is what I am doing now:

...
if sys.platform == "win32":
   import win32file
else:
   import statvfs
...


def get_free_space(path = '.'):
   """
      Determine the free space in bytes for the given path.
   """
   if sys.platform == "win32":
      sizes = win32file.GetDiskFreeSpace(path)
      return sizes[0] * sizes[1] * sizes[2]
   else:
      status = os.statvfs(path)
      return status[statvfs.F_BAVAIL] * status[statvfs.F_FRSIZE]



def get_partition_size(path = '.'):
   """
      Determine the total space in bytes for the given path.
   """
   if sys.platform == "win32":
      sizes = win32file.GetDiskFreeSpace(path)
      return sizes[0] * sizes[1] * sizes[3]
   else:
      status = os.statvfs(path)
      return status[statvfs.F_BLOCKS] * status[statvfs.F_FRSIZE]

----------
versions: +Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue410547>
_______________________________________

From report at bugs.python.org  Sun Jan  9 16:11:28 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 09 Jan 2011 15:11:28 +0000
Subject: [issue10872] Add mode to TextIOWrapper repr
In-Reply-To: <1294564948.19.0.858903256762.issue10872@psf.upfronthosting.co.za>
Message-ID: <1294585888.9.0.301658128666.issue10872@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
components: +IO
nosy: +amaury.forgeotdarc, benjamin.peterson
type:  -> feature request

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10872>
_______________________________________

From report at bugs.python.org  Sun Jan  9 16:14:01 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 09 Jan 2011 15:14:01 +0000
Subject: [issue9504] signal.signal/signal.alarm not working as expected
In-Reply-To: <1280910836.88.0.645209486589.issue9504@psf.upfronthosting.co.za>
Message-ID: <1294586041.23.0.803705323781.issue9504@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Charles-Fran?ois' analysis seems to be right. Note that the actual issue here is that read() always succeeds, returning a partial result (because you're executing a command, 'find /', which outputs a lot of data). If read() were interrupted before anything could be read, it would return EINTR and the handler would get executed immediately.

Anyone wants to propose a patch + tests?

----------
versions: +Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9504>
_______________________________________

From report at bugs.python.org  Sun Jan  9 17:35:51 2011
From: report at bugs.python.org (Roger Serwy)
Date: Sun, 09 Jan 2011 16:35:51 +0000
Subject: [issue9262] IDLE: Use tabbed shell and edit windows
In-Reply-To: <1279128709.53.0.879340925848.issue9262@psf.upfronthosting.co.za>
Message-ID: <1294590951.44.0.352467964742.issue9262@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/issue9262>
_______________________________________

From report at bugs.python.org  Sun Jan  9 17:52:43 2011
From: report at bugs.python.org (=?utf-8?q?Andreas_St=C3=BChrk?=)
Date: Sun, 09 Jan 2011 16:52:43 +0000
Subject: [issue10874] test_urllib2 shouldn't use is operator for comparing
	strings
In-Reply-To: <1294591963.25.0.901803829485.issue10874@psf.upfronthosting.co.za>
Message-ID: <1294591963.25.0.901803829485.issue10874@psf.upfronthosting.co.za>


New submission from Andreas St?hrk <andy-python at hammerhartes.de>:

See the attached patch (applies to 2.7 and 3.2).

----------
components: Tests
files: test_urllib2.patch
keywords: patch
messages: 125846
nosy: Trundle, lukasz.langa
priority: normal
severity: normal
status: open
title: test_urllib2 shouldn't use is operator for comparing strings
versions: Python 2.7, Python 3.2
Added file: http://bugs.python.org/file20324/test_urllib2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10874>
_______________________________________

From report at bugs.python.org  Sun Jan  9 18:05:14 2011
From: report at bugs.python.org (anatoly techtonik)
Date: Sun, 09 Jan 2011 17:05:14 +0000
Subject: [issue8954] wininst regression: errors when building on linux
In-Reply-To: <1276093244.44.0.895217979727.issue8954@psf.upfronthosting.co.za>
Message-ID: <1294592714.22.0.811406892194.issue8954@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

Fixed Ezio comments at http://codereview.appspot.com/1774043

Eric, if I understand you correctly, the mbcs issue you're experiencing is unrelated to the patch. What else do you need?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8954>
_______________________________________

From report at bugs.python.org  Sun Jan  9 18:14:07 2011
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sun, 09 Jan 2011 17:14:07 +0000
Subject: [issue5871] email.header.Header too lax with embeded newlines
In-Reply-To: <1240953937.2.0.828159818097.issue5871@psf.upfronthosting.co.za>
Message-ID: <1294593247.3.0.473547044713.issue5871@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/issue5871>
_______________________________________

From report at bugs.python.org  Sun Jan  9 18:16:04 2011
From: report at bugs.python.org (anatoly techtonik)
Date: Sun, 09 Jan 2011 17:16:04 +0000
Subject: [issue8871] --user-access-control=auto has no effect
In-Reply-To: <1275420139.65.0.104008426141.issue8871@psf.upfronthosting.co.za>
Message-ID: <1294593364.76.0.225883267821.issue8871@psf.upfronthosting.co.za>


Changes by anatoly techtonik <techtonik at gmail.com>:


----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8871>
_______________________________________

From report at bugs.python.org  Sun Jan  9 18:16:18 2011
From: report at bugs.python.org (anatoly techtonik)
Date: Sun, 09 Jan 2011 17:16:18 +0000
Subject: [issue8871] --user-access-control=auto has no effect
In-Reply-To: <1275420139.65.0.104008426141.issue8871@psf.upfronthosting.co.za>
Message-ID: <1294593378.52.0.745998996066.issue8871@psf.upfronthosting.co.za>


Changes by anatoly techtonik <techtonik at gmail.com>:


----------
resolution: invalid -> out of date

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8871>
_______________________________________

From report at bugs.python.org  Sun Jan  9 18:40:53 2011
From: report at bugs.python.org (anatoly techtonik)
Date: Sun, 09 Jan 2011 17:40:53 +0000
Subject: [issue8954] wininst regression: errors when building on linux
In-Reply-To: <1276093244.44.0.895217979727.issue8954@psf.upfronthosting.co.za>
Message-ID: <1294594853.15.0.549576670564.issue8954@psf.upfronthosting.co.za>


Changes by anatoly techtonik <techtonik at gmail.com>:


Added file: http://bugs.python.org/file20325/suffix.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8954>
_______________________________________

From report at bugs.python.org  Sun Jan  9 18:41:01 2011
From: report at bugs.python.org (anatoly techtonik)
Date: Sun, 09 Jan 2011 17:41:01 +0000
Subject: [issue8954] wininst regression: errors when building on linux
In-Reply-To: <1276093244.44.0.895217979727.issue8954@psf.upfronthosting.co.za>
Message-ID: <1294594861.65.0.799750709442.issue8954@psf.upfronthosting.co.za>


Changes by anatoly techtonik <techtonik at gmail.com>:


Removed file: http://bugs.python.org/file17961/suffix.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8954>
_______________________________________

From report at bugs.python.org  Sun Jan  9 19:00:13 2011
From: report at bugs.python.org (SilentGhost)
Date: Sun, 09 Jan 2011 18:00:13 +0000
Subject: [issue10874] test_urllib2 shouldn't use is operator for comparing
	strings
In-Reply-To: <1294591963.25.0.901803829485.issue10874@psf.upfronthosting.co.za>
Message-ID: <1294596013.02.0.824833336165.issue10874@psf.upfronthosting.co.za>


SilentGhost <ghost.adh at gmail.com> added the comment:

Shouldn't that be:

self.assertIs(req.type == "ftp", ftp)

?

----------
nosy: +SilentGhost

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10874>
_______________________________________

From report at bugs.python.org  Sun Jan  9 19:05:44 2011
From: report at bugs.python.org (SilentGhost)
Date: Sun, 09 Jan 2011 18:05:44 +0000
Subject: [issue10874] test_urllib2 shouldn't use is operator for comparing
	strings
In-Reply-To: <1294591963.25.0.901803829485.issue10874@psf.upfronthosting.co.za>
Message-ID: <1294596344.43.0.343712250024.issue10874@psf.upfronthosting.co.za>


Changes by SilentGhost <ghost.adh at gmail.com>:


Added file: http://bugs.python.org/file20326/test_urllib2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10874>
_______________________________________

From report at bugs.python.org  Sun Jan  9 19:17:57 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 09 Jan 2011 18:17:57 +0000
Subject: [issue10874] test_urllib2 shouldn't use is operator for comparing
	strings
In-Reply-To: <1294591963.25.0.901803829485.issue10874@psf.upfronthosting.co.za>
Message-ID: <1294597077.8.0.562048304291.issue10874@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Actually, this block of tests may be outdated.  Reading the comment above the list of (URIs, is_ftp) doubles makes you see that it was testing the automatic use of FTP in some file: URIs, a very dubious behavior that is now removed or deprecated.  Senthil, I think a little cleanup is needed.

----------
assignee:  -> orsenthil
nosy: +eric.araujo, orsenthil
versions: +Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10874>
_______________________________________

From report at bugs.python.org  Sun Jan  9 19:25:35 2011
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Sun, 09 Jan 2011 18:25:35 +0000
Subject: [issue10874] test_urllib2 shouldn't use is operator for comparing
	strings
In-Reply-To: <1294591963.25.0.901803829485.issue10874@psf.upfronthosting.co.za>
Message-ID: <1294597535.54.0.283207922865.issue10874@psf.upfronthosting.co.za>


?ukasz Langa <lukasz at langa.pl> added the comment:

Committed for py3k in r87895. Yup, could have been assertIs as well. The reason for the change is that "is" failed on PyPy.

This should be backported to Python 2.7 as well.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10874>
_______________________________________

From report at bugs.python.org  Sun Jan  9 19:36:42 2011
From: report at bugs.python.org (Charles-Francois Natali)
Date: Sun, 09 Jan 2011 18:36:42 +0000
Subject: [issue9504] signal.signal/signal.alarm not working as expected
In-Reply-To: <1294586041.23.0.803705323781.issue9504@psf.upfronthosting.co.za>
Message-ID: <AANLkTikt6Dc9xw4HVWYE4ew7jSivJUMoUc14uVgroBvW@mail.gmail.com>


Charles-Francois Natali <neologix at free.fr> added the comment:

> Antoine Pitrou <pitrou at free.fr> added the comment:
>
> Charles-Fran??ois' analysis seems to be right. Note that the actual issue here is that read() always succeeds, returning a partial result (because you're executing a command, 'find /', which outputs a lot of data). If read() were interrupted before anything could be read, it would return EINTR and the handler would get executed immediately.
>
> Anyone wants to propose a patch + tests?
>

Attached is a tentative patch: it checks for pending signals inside
_bufferedreader_read_generic, fileio_readall, and rawiobase_readall.
I tested quickly on regular files and on pipes, and handlers are now
called on time. As a an obvious bonus, it's also easier to interrupt a
script doing I/O with a KeyboardInterrupt (SIGINT).
If nothing seems blatantly wrong about this patch, I will go ahead and
try to write some tests for this.

Charles

> ----------
> versions: +Python 3.2
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue9504>
> _______________________________________
>

----------
keywords: +patch
Added file: http://bugs.python.org/file20327/io_signal.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9504>
_______________________________________
-------------- next part --------------
diff -urp A/Modules/_io/bufferedio.c B/Modules/_io/bufferedio.c
--- A/Modules/_io/bufferedio.c	2010-12-21 22:26:09.000000000 +0100
+++ B/Modules/_io/bufferedio.c	2011-01-09 18:46:01.000000000 +0100
@@ -1405,6 +1405,10 @@ _bufferedreader_read_generic(buffered *s
         }
         remaining -= r;
         written += r;
+        /* check pending signals */
+        if (PyErr_CheckSignals() < 0) {
+            goto error;
+        }
     }
     assert(remaining <= self->buffer_size);
     self->pos = 0;
@@ -1442,6 +1446,10 @@ _bufferedreader_read_generic(buffered *s
         }
         if (remaining == 0)
             break;
+        /* check pending signals */
+        if (PyErr_CheckSignals() < 0) {
+            goto error;
+        }
     }
 
     return res;
diff -urp A/Modules/_io/fileio.c B/Modules/_io/fileio.c
--- A/Modules/_io/fileio.c	2010-11-26 09:52:36.000000000 +0100
+++ B/Modules/_io/fileio.c	2011-01-09 19:26:52.000000000 +0100
@@ -583,6 +583,11 @@ fileio_readall(fileio *self)
             return NULL;
         }
         total += n;
+        /* check pending signals */
+        if (PyErr_CheckSignals() < 0) {
+            Py_DECREF(result);
+            return NULL;
+        }
     }
 
     if (PyBytes_GET_SIZE(result) > total) {
diff -urp A/Modules/_io/iobase.c B/Modules/_io/iobase.c
--- A/Modules/_io/iobase.c	2010-09-14 20:53:07.000000000 +0200
+++ B/Modules/_io/iobase.c	2011-01-09 19:27:15.000000000 +0100
@@ -831,6 +831,11 @@ rawiobase_readall(PyObject *self, PyObje
             Py_DECREF(chunks);
             return NULL;
         }
+        /* check pending signals */
+        if (PyErr_CheckSignals() < 0) {
+            Py_DECREF(chunks);
+            return NULL;
+        }
     }
     result = _PyBytes_Join(_PyIO_empty_bytes, chunks);
     Py_DECREF(chunks);

From report at bugs.python.org  Sun Jan  9 20:23:58 2011
From: report at bugs.python.org (David-Sarah Hopwood)
Date: Sun, 09 Jan 2011 19:23:58 +0000
Subject: [issue1602] windows console doesn't print utf8 (Py30a2)
In-Reply-To: <1197453390.87.0.813702844893.issue1602@psf.upfronthosting.co.za>
Message-ID: <1294601038.4.0.0317333350699.issue1602@psf.upfronthosting.co.za>


David-Sarah Hopwood <david-sarah at jacaranda.org> added the comment:

haypo wrote:
> davidsarah wrote:
>> It is certainly possible to write Unicode to the console 
>> successfully using WriteConsoleW
>
> Did you tried with characters not encodable to the code page and with character that cannot be rendeded by the font?

Yes, characters not encodable to the code page do work (as confirmed by Glenn Linderman, since code page 437 does not include Cyrillic).

Characters that cannot be rendered by the font print as missing-glyph boxes, as expected. They don't cause any other problem, and they can be cut-and-pasted to other Unicode-aware applications, showing up as the original characters.

> See msg120414 for my tests with WriteConsoleOutputW

Even if it handled encoding correctly, WriteConsoleOutputW (http://msdn.microsoft.com/en-us/library/ms687404%28v=vs.85%29.aspx) would not be the right API to use in any case, because it prints to a rectangle of characters without scrolling. WriteConsoleW does scroll in the same way that printing to a console output stream normally would. (Redirection to a non-console stream can be detected and handled differently, as the code in unicode2.py does.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1602>
_______________________________________

From report at bugs.python.org  Sun Jan  9 20:44:31 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 09 Jan 2011 19:44:31 +0000
Subject: [issue10872] Add mode to TextIOWrapper repr
In-Reply-To: <1294564948.19.0.858903256762.issue10872@psf.upfronthosting.co.za>
Message-ID: <1294602271.12.0.919050471742.issue10872@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Here is a patch.

----------
keywords: +patch
Added file: http://bugs.python.org/file20328/textiorepr.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10872>
_______________________________________

From report at bugs.python.org  Sun Jan  9 20:54:16 2011
From: report at bugs.python.org (David-Sarah Hopwood)
Date: Sun, 09 Jan 2011 19:54:16 +0000
Subject: [issue410547] os.statvfs support for Windows
Message-ID: <1294602856.15.0.284617060798.issue410547@psf.upfronthosting.co.za>


David-Sarah Hopwood <david-sarah at jacaranda.org> added the comment:

Don't use win32file.GetDiskFreeSpace; the underlying Windows API only supports drives up to 2 GB (http://blogs.msdn.com/b/oldnewthing/archive/2007/11/01/5807020.aspx). Use GetFreeDiskSpaceEx, as the code I linked to does.

I'm not sure it makes sense to provide an exact clone of os.statvfs, since some of the statvfs fields don't have equivalents that are obtainable by any Windows API as far as I know. What <em>would</em> make sense is a cross-platform way to get total disk space, and the space free for root/Administrator and for the current user. This would actually be somewhat easier to use on Unix as well.

Anyway, here's some code for Windows that only uses ctypes (whichdir should be Unicode):

    from ctypes import WINFUNCTYPE, windll, POINTER, byref, c_ulonglong
    from ctypes.wintypes import BOOL, DWORD, LPCWSTR

    # <http://msdn.microsoft.com/en-us/library/aa383742%28v=VS.85%29.aspx>
    PULARGE_INTEGER = POINTER(c_ulonglong)

    # <http://msdn.microsoft.com/en-us/library/aa364937%28VS.85%29.aspx>
    GetDiskFreeSpaceExW = WINFUNCTYPE(BOOL, LPCWSTR, PULARGE_INTEGER, PULARGE_INTEGER, PULARGE_INTEGER)(
        ("GetDiskFreeSpaceExW", windll.kernel32))

    # <http://msdn.microsoft.com/en-us/library/ms679360%28v=VS.85%29.aspx>
    GetLastError = WINFUNCTYPE(DWORD)(("GetLastError", windll.kernel32))

    # (This might put up an error dialog unless
    # SetErrorMode(SEM_FAILCRITICALERRORS | SEM_NOOPENFILEERRORBOX)
    # has been called.)

    n_free_for_user = c_ulonglong(0)
    n_total         = c_ulonglong(0)
    n_free          = c_ulonglong(0)
    retval = GetDiskFreeSpaceExW(whichdir,
                                 byref(n_free_for_user),
                                 byref(n_total),
                                 byref(n_free))
    if retval == 0:
        raise OSError("Windows error %d attempting to get disk statistics for %r"
                      % (GetLastError(), whichdir))

    free_for_user = n_free_for_user.value
    total         = n_total.value
    free          = n_free.value

----------
versions: +Python 2.7, Python 3.3 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue410547>
_______________________________________

From report at bugs.python.org  Sun Jan  9 21:20:09 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 09 Jan 2011 20:20:09 +0000
Subject: [issue10875] Update Regular Expression HOWTO
In-Reply-To: <1294604409.29.0.577762819836.issue10875@psf.upfronthosting.co.za>
Message-ID: <1294604409.29.0.577762819836.issue10875@psf.upfronthosting.co.za>


New submission from Terry J. Reedy <tjreedy at udel.edu>:

0. Does 'Release 0.05' at the top have any useful current meaning?
or could it be deleted?

1. Introduction:

The history paragraph "The re module was added in Python 1.5, and provides Perl-style regular expression patterns. Earlier versions of Python came with the regex module, which provided Emacs-style patterns. The regex module was removed completely in Python 2.5." might be eliminated in 3.x, or at least the irrelevant-for-py3 reference to regex. This is a policy decision.

2. Performing matches:

"If you have Tkinter available, you may also want to look at Tools/scripts/redemo.py,"

Change 'Tkinter' to 'tkinter' and make it a module reference.
In link, change 'scripts' to 'demo' as redemo.py got moved.

"Phil Schwartz?s Kodos is also an interactive tool for developing and testing RE patterns."

Add the url '(http://kodos.sourceforge.net/)' to the text so that Windows help users can copy and paste it into a browser. (This should be a general policy.)

"Python 2.2.2 (#1, Feb 10 2003, 12:57:01)"
delete

<_sre.SRE_Match object at 80c4f68>

This is correctly updated (for late 2.x and 3.x)

"<re.MatchObject instance at 80c9650>" (7 like this)

Globally replace 're.MatchObject instance' with '_sre.SRE_Match object'

3. Footnote

"[1] Introduced in Python 2.2.2."

remove for 3.x here and wherever footnote reference is in the text.

4. "Not Using re.VERBOSE"

This section is about *using* re.VERBOSE and the benefit thereof, not about not using it. I recommend deleting 'Not' as it gives the impression that the section is a warning about not using, the opposite of the intent.

5. Code example output and doctest:

I ran doctest.testfile("C:/programs/PyDev/py32/Doc/howto/regex.rst", module_relative = False)

After the 're...' to '_sre...' substitution above, all 11 failures would be due to 'at 0x#######' address mismatches. I believe changing all 11 addresses to '0x...' (I took this from the doctest doc) would both fix the failures and remove irrelevant detail for human readers.

The other 87 examples all passed ;-!.

Is there any current doctest-related markup that should be added?

----------
assignee: docs at python
components: Documentation
messages: 125855
nosy: akuchling, docs at python, terry.reedy
priority: normal
severity: normal
stage: needs patch
status: open
title: Update Regular Expression HOWTO
versions: Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10875>
_______________________________________

From report at bugs.python.org  Sun Jan  9 21:31:32 2011
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 09 Jan 2011 20:31:32 +0000
Subject: [issue10872] Add mode to TextIOWrapper repr
In-Reply-To: <1294564948.19.0.858903256762.issue10872@psf.upfronthosting.co.za>
Message-ID: <1294605092.9.0.274482832434.issue10872@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

LGTM.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10872>
_______________________________________

From report at bugs.python.org  Sun Jan  9 21:42:28 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 09 Jan 2011 20:42:28 +0000
Subject: [issue10872] Add mode to TextIOWrapper repr
In-Reply-To: <1294564948.19.0.858903256762.issue10872@psf.upfronthosting.co.za>
Message-ID: <1294605748.21.0.621160063959.issue10872@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Committed in r87897. Left open for backport.

----------
assignee: pitrou -> 
resolution:  -> accepted
stage:  -> committed/rejected
type: feature request -> behavior
versions: +Python 2.7, Python 3.1 -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10872>
_______________________________________

From report at bugs.python.org  Sun Jan  9 21:47:59 2011
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 09 Jan 2011 20:47:59 +0000
Subject: [issue10875] Update Regular Expression HOWTO
In-Reply-To: <1294604409.29.0.577762819836.issue10875@psf.upfronthosting.co.za>
Message-ID: <1294606079.23.0.68208171949.issue10875@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Your points 1-5 all sound valid to me.  Would you like to do make a patch? I don't know what to do about the release number.  Probably doesn't hurt anyone to keep it.

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10875>
_______________________________________

From report at bugs.python.org  Sun Jan  9 21:51:11 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 09 Jan 2011 20:51:11 +0000
Subject: [issue10875] Update Regular Expression HOWTO
In-Reply-To: <1294604409.29.0.577762819836.issue10875@psf.upfronthosting.co.za>
Message-ID: <1294606271.65.0.164511298304.issue10875@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Good points overall.

The only subpoint I disagree with is this one: ?Add the url '(http://kodos.sourceforge.net/)' to the text so that Windows help users can copy and paste it into a browser. (This should be a general policy.)?  IMO, it?s the job of the Sphinx builder to add URIs in plaintext if the format does not have hyperlinks.  -1 on cluttering the source and HTML output with duplicated links.

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10875>
_______________________________________

From report at bugs.python.org  Sun Jan  9 21:52:50 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 09 Jan 2011 20:52:50 +0000
Subject: [issue10225] Fix doctest runable examples in python manual
In-Reply-To: <1288318735.45.0.959857258913.issue10225@psf.upfronthosting.co.za>
Message-ID: <1294606370.8.0.33298496606.issue10225@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

As I understand this, your patch would fix numerous errors in the docs, but has not been applied. It would be nice to get the fixes into 3.2. What sort of feedback do you want? Proofreading of text? Recheck of doctest?

Does sphinx suppress doctest comments like
     #doctest: +IGNORE_EXCEPTION_DETAIL
?

doctest.testfile("C:/programs/PyDev/py32/Doc/howto/sorting.rst", module_relative = False) fails 23 of 37 attempts, so improvement is needed ;-).

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10225>
_______________________________________

From report at bugs.python.org  Sun Jan  9 21:55:39 2011
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 09 Jan 2011 20:55:39 +0000
Subject: [issue10875] Update Regular Expression HOWTO
In-Reply-To: <1294604409.29.0.577762819836.issue10875@psf.upfronthosting.co.za>
Message-ID: <1294606539.51.0.962615321739.issue10875@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Oh right, I misread that one.  Can't Windows help users right-click and select "Copy URL"?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10875>
_______________________________________

From report at bugs.python.org  Sun Jan  9 21:56:59 2011
From: report at bugs.python.org (SilentGhost)
Date: Sun, 09 Jan 2011 20:56:59 +0000
Subject: [issue10875] Update Regular Expression HOWTO
In-Reply-To: <1294604409.29.0.577762819836.issue10875@psf.upfronthosting.co.za>
Message-ID: <1294606619.16.0.721316492897.issue10875@psf.upfronthosting.co.za>


SilentGhost <ghost.adh at gmail.com> added the comment:

Here is the patch implementing all but the url suggestion.

Doctest still has 11 failures (changing to '0x...' didn't help).

----------
keywords: +patch
nosy: +SilentGhost
Added file: http://bugs.python.org/file20329/regex.rst.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10875>
_______________________________________

From report at bugs.python.org  Sun Jan  9 21:59:29 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 09 Jan 2011 20:59:29 +0000
Subject: [issue9504] signal.signal/signal.alarm not working as expected
In-Reply-To: <AANLkTikt6Dc9xw4HVWYE4ew7jSivJUMoUc14uVgroBvW@mail.gmail.com>
Message-ID: <1294606761.3700.3.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Attached is a tentative patch: it checks for pending signals inside
> _bufferedreader_read_generic, fileio_readall, and rawiobase_readall.
> I tested quickly on regular files and on pipes, and handlers are now
> called on time. As a an obvious bonus, it's also easier to interrupt a
> script doing I/O with a KeyboardInterrupt (SIGINT).
> If nothing seems blatantly wrong about this patch, I will go ahead and
> try to write some tests for this.

A potential downside is that the bytes which have been read simply get
lost. But since a signal can happen at any moment I guess nothing can be
done to protect from it in the general case, anyway.

As for the tests, the SignalsTest class in test_io.py is a natural
recipient.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9504>
_______________________________________

From report at bugs.python.org  Sun Jan  9 22:12:15 2011
From: report at bugs.python.org (Ashwin Purohit)
Date: Sun, 09 Jan 2011 21:12:15 +0000
Subject: [issue10873] String formatting example invalid
In-Reply-To: <1294581154.4.0.521911831004.issue10873@psf.upfronthosting.co.za>
Message-ID: <AANLkTikq=0yGxqFfpFhAUQPFZySdY01XPqvFaGg6z-Gw@mail.gmail.com>


Ashwin Purohit <purohit at gmail.com> added the comment:

Yes, apologies (I was using 2.6).

On Jan 9, 2011 5:52 AM, "SilentGhost" <report at bugs.python.org> wrote:

SilentGhost <ghost.adh at gmail.com> added the comment:

Works as advertised for me. Unless more information is added, it looks like
an invalid issue.

----------
nosy: +SilentGhost

_______________________________________ Python tracker <
report at bugs.python.org> <http://bugs.python...

----------
Added file: http://bugs.python.org/file20330/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10873>
_______________________________________
-------------- next part --------------
<p>Yes, apologies (I was using 2.6).</p>
<p><blockquote type="cite">On Jan 9, 2011 5:52 AM, &quot;SilentGhost&quot; &lt;<a href="mailto:report at bugs.python.org">report at bugs.python.org</a>&gt; wrote:<br><br><br>
SilentGhost &lt;<a href="mailto:ghost.adh at gmail.com">ghost.adh at gmail.com</a>&gt; added the comment:<br>
<br>
Works as advertised for me. Unless more information is added, it looks like an invalid issue.<br>
<br>
----------<br>
nosy: +SilentGhost<br>
<p><font color="#500050">
_______________________________________
Python tracker &lt;<a href="mailto:report at bugs.python.org">report at bugs.python.org</a>&gt;
&lt;<a href="http://bugs.python.">http://bugs.python.</a>..</font></p></blockquote></p>

From report at bugs.python.org  Sun Jan  9 22:17:35 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 09 Jan 2011 21:17:35 +0000
Subject: [issue10873] String formatting example invalid
In-Reply-To: <1294575644.02.0.857949444366.issue10873@psf.upfronthosting.co.za>
Message-ID: <1294607855.6.0.751116689531.issue10873@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


Removed file: http://bugs.python.org/file20330/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10873>
_______________________________________

From report at bugs.python.org  Sun Jan  9 22:20:56 2011
From: report at bugs.python.org (SilentGhost)
Date: Sun, 09 Jan 2011 21:20:56 +0000
Subject: [issue10875] Update Regular Expression HOWTO
In-Reply-To: <1294604409.29.0.577762819836.issue10875@psf.upfronthosting.co.za>
Message-ID: <1294608056.27.0.063936928067.issue10875@psf.upfronthosting.co.za>


SilentGhost <ghost.adh at gmail.com> added the comment:

A few bits and pieces fixed compared to the previous patch.

>>> doctest.testfile("/home/mischa/pydev/Doc/howto/regex.rst", module_relative = False, optionflags=doctest.ELLIPSIS)
TestResults(failed=0, attempted=98)

----------
Added file: http://bugs.python.org/file20331/regex.rst.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10875>
_______________________________________

From report at bugs.python.org  Sun Jan  9 22:21:05 2011
From: report at bugs.python.org (SilentGhost)
Date: Sun, 09 Jan 2011 21:21:05 +0000
Subject: [issue10875] Update Regular Expression HOWTO
In-Reply-To: <1294604409.29.0.577762819836.issue10875@psf.upfronthosting.co.za>
Message-ID: <1294608065.39.0.659361973358.issue10875@psf.upfronthosting.co.za>


Changes by SilentGhost <ghost.adh at gmail.com>:


Removed file: http://bugs.python.org/file20329/regex.rst.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10875>
_______________________________________

From report at bugs.python.org  Sun Jan  9 22:35:31 2011
From: report at bugs.python.org (SilentGhost)
Date: Sun, 09 Jan 2011 21:35:31 +0000
Subject: [issue10875] Update Regular Expression HOWTO
In-Reply-To: <1294604409.29.0.577762819836.issue10875@psf.upfronthosting.co.za>
Message-ID: <1294608931.64.0.477348697842.issue10875@psf.upfronthosting.co.za>


SilentGhost <ghost.adh at gmail.com> added the comment:

It seems that the special sequences description in Matching Characters section need to be updated to incorporate information on unicode and bytes. I don't think, however, that it's a good idea just to copy that information from the Doc/library/re.rst May be the section could be shortened and linked to that RE Syntax section? there aren't any deeper links available unfortunately.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10875>
_______________________________________

From report at bugs.python.org  Sun Jan  9 23:17:47 2011
From: report at bugs.python.org (Kira Erethon)
Date: Sun, 09 Jan 2011 22:17:47 +0000
Subject: [issue10876] Zipfile crashes when zip password is 610
In-Reply-To: <1294611467.71.0.814994722037.issue10876@psf.upfronthosting.co.za>
Message-ID: <1294611467.71.0.814994722037.issue10876@psf.upfronthosting.co.za>


New submission from Kira Erethon <shinjierethon at gmail.com>:

Was playing around with Zipfile and passwords in zip files and I noticed that when the password on zipfile.setpassword(pwd) was set 610, the program crashed with the following errors

  File "/usr/lib/python2.6/zipfile.py", line 938, in extractall
    self.extract(zipinfo, path, pwd)
  File "/usr/lib/python2.6/zipfile.py", line 926, in extract
    return self._extract_member(member, path, pwd)
  File "/usr/lib/python2.6/zipfile.py", line 971, in _extract_member
    shutil.copyfileobj(source, target)
  File "/usr/lib/python2.6/shutil.py", line 28, in copyfileobj
    buf = fsrc.read(length)
  File "/usr/lib/python2.6/zipfile.py", line 612, in read
    newdata = self.dc.decompress(newdata)
zlib.error: Error -3 while decompressing: invalid distance too far back

----------
components: Extension Modules
messages: 125867
nosy: Kira.Kapoios
priority: normal
severity: normal
status: open
title: Zipfile crashes when zip password is 610
type: crash
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10876>
_______________________________________

From report at bugs.python.org  Sun Jan  9 23:17:53 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 09 Jan 2011 22:17:53 +0000
Subject: [issue10875] Update Regular Expression HOWTO
In-Reply-To: <1294604409.29.0.577762819836.issue10875@psf.upfronthosting.co.za>
Message-ID: <1294611473.04.0.752121486419.issue10875@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I agree that the .rst should not have two copies and that any windows.chm specific fixup should be in the tool. Right now, right clicking gives a context menu with one item: Properties. Clicking that brings up a dialog box with a url that can be copied. Good enough for me at the moment but not terribly obvious. A possible separate issue.

Unless A Kuchling says different, I would like to remove the version number. It implies to me that this doc is in pre-alpha condition and it is far beyond that. I see that the patch already does so.

-:file:`Tools/scripts/redemo.py`, a demonstration program included with the
+:file:`Tools/scripts/demo.py`, a demonstration program included with the

should (currently) be
+:file:`Tools/demo/redemo.py`, a demonstration program included with the

Other than that, the patch looks good. Thanks. I am still thinking about Matching Characters. Once the patch is fixed with possible addition, a 2.7 version can easily be made be deleting the 3.x-specific deletions.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10875>
_______________________________________

From report at bugs.python.org  Sun Jan  9 23:19:32 2011
From: report at bugs.python.org (Kira Erethon)
Date: Sun, 09 Jan 2011 22:19:32 +0000
Subject: [issue10876] Zipfile crashes when zip password is set to 610
In-Reply-To: <1294611467.71.0.814994722037.issue10876@psf.upfronthosting.co.za>
Message-ID: <1294611572.55.0.656612504273.issue10876@psf.upfronthosting.co.za>


Changes by Kira Erethon <shinjierethon at gmail.com>:


----------
title: Zipfile crashes when zip password is 610 -> Zipfile crashes when zip password is set to 610

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10876>
_______________________________________

From report at bugs.python.org  Sun Jan  9 23:29:06 2011
From: report at bugs.python.org (SilentGhost)
Date: Sun, 09 Jan 2011 22:29:06 +0000
Subject: [issue10875] Update Regular Expression HOWTO
In-Reply-To: <1294604409.29.0.577762819836.issue10875@psf.upfronthosting.co.za>
Message-ID: <1294612146.85.0.529573764226.issue10875@psf.upfronthosting.co.za>


SilentGhost <ghost.adh at gmail.com> added the comment:

I don't know whether it would be easy to strip down py3k version to 2.7 version.

Seeing how it's just a basic introduction, I would think that a single statement re unicode support might be sufficient. For exhaustive description of special sequences refer the docs and carry on with ascii strings.

Attached patch fixes path issue.

----------
Added file: http://bugs.python.org/file20332/regex.rst.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10875>
_______________________________________

From report at bugs.python.org  Sun Jan  9 23:29:27 2011
From: report at bugs.python.org (SilentGhost)
Date: Sun, 09 Jan 2011 22:29:27 +0000
Subject: [issue10875] Update Regular Expression HOWTO
In-Reply-To: <1294604409.29.0.577762819836.issue10875@psf.upfronthosting.co.za>
Message-ID: <1294612167.06.0.333307836586.issue10875@psf.upfronthosting.co.za>


Changes by SilentGhost <ghost.adh at gmail.com>:


Removed file: http://bugs.python.org/file20331/regex.rst.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10875>
_______________________________________

From report at bugs.python.org  Sun Jan  9 23:41:15 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 09 Jan 2011 22:41:15 +0000
Subject: [issue10116] Sporadic failures in test_urllibnet
In-Reply-To: <1287150282.16.0.127032822399.issue10116@psf.upfronthosting.co.za>
Message-ID: <1294612875.1.0.0768720069866.issue10116@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

There are still sporadic failures:

http://www.python.org/dev/buildbot/all/builders/AMD64%20Leopard%203.x/builds/684/steps/test/logs/stdio

Of course, it seems to be because of stupid urllib wrapping the socket.error inside an IOError:

Traceback (most recent call last):
  File "/Users/pythonbuildbot/buildarea/3.x.hansen-osx-x86-2/build/Lib/test/test_urllibnet.py", line 97, in test_getcode
    open_url = urllib.request.FancyURLopener().open(URL)
  File "/Users/pythonbuildbot/buildarea/3.x.hansen-osx-x86-2/build/Lib/urllib/request.py", line 1516, in open
    raise IOError('socket error', msg).with_traceback(sys.exc_info()[2])
  File "/Users/pythonbuildbot/buildarea/3.x.hansen-osx-x86-2/build/Lib/urllib/request.py", line 1512, in open
    return getattr(self, name)(url)
  File "/Users/pythonbuildbot/buildarea/3.x.hansen-osx-x86-2/build/Lib/urllib/request.py", line 1684, in open_http
    return self._open_generic_http(http.client.HTTPConnection, url, data)
  File "/Users/pythonbuildbot/buildarea/3.x.hansen-osx-x86-2/build/Lib/urllib/request.py", line 1664, in _open_generic_http
    http_conn.request("GET", selector, headers=headers)
  File "/Users/pythonbuildbot/buildarea/3.x.hansen-osx-x86-2/build/Lib/http/client.py", line 962, in request
    self._send_request(method, url, body, headers)
  File "/Users/pythonbuildbot/buildarea/3.x.hansen-osx-x86-2/build/Lib/http/client.py", line 1000, in _send_request
    self.endheaders(body)
  File "/Users/pythonbuildbot/buildarea/3.x.hansen-osx-x86-2/build/Lib/http/client.py", line 958, in endheaders
    self._send_output(message_body)
  File "/Users/pythonbuildbot/buildarea/3.x.hansen-osx-x86-2/build/Lib/http/client.py", line 803, in _send_output
    self.send(msg)
  File "/Users/pythonbuildbot/buildarea/3.x.hansen-osx-x86-2/build/Lib/http/client.py", line 741, in send
    self.connect()
  File "/Users/pythonbuildbot/buildarea/3.x.hansen-osx-x86-2/build/Lib/http/client.py", line 719, in connect
    self.timeout, self.source_address)
  File "/Users/pythonbuildbot/buildarea/3.x.hansen-osx-x86-2/build/Lib/socket.py", line 398, in create_connection
    raise err
  File "/Users/pythonbuildbot/buildarea/3.x.hansen-osx-x86-2/build/Lib/socket.py", line 389, in create_connection
    sock.connect(sa)
IOError: [Errno socket error] [Errno 60] Operation timed out

----------
resolution: fixed -> 
stage: patch review -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10116>
_______________________________________

From report at bugs.python.org  Sun Jan  9 23:42:09 2011
From: report at bugs.python.org (Eric Smith)
Date: Sun, 09 Jan 2011 22:42:09 +0000
Subject: [issue10876] Zipfile crashes when zip password is set to 610
In-Reply-To: <1294611467.71.0.814994722037.issue10876@psf.upfronthosting.co.za>
Message-ID: <1294612929.34.0.743402403064.issue10876@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

What do you mean by "is set to 610"? Can you show us the code that caused this error?

----------
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10876>
_______________________________________

From report at bugs.python.org  Mon Jan 10 00:12:23 2011
From: report at bugs.python.org (Kira Erethon)
Date: Sun, 09 Jan 2011 23:12:23 +0000
Subject: [issue10876] Zipfile crashes when zip password is set to 610
In-Reply-To: <1294611467.71.0.814994722037.issue10876@psf.upfronthosting.co.za>
Message-ID: <1294614743.32.0.806276300468.issue10876@psf.upfronthosting.co.za>


Kira Erethon <shinjierethon at gmail.com> added the comment:

Ok, I tried recreating the bug and found out that I couldn't. Originally this happened when I tried to find the password of a zip file through a dictionary attack. The code I used is this:

import zipfile

zfile=raw_input("Please input zip's file name\n")
diction=raw_input("Please input dictionary\n")
found = False
zipf = zipfile.ZipFile( zfile, 'r' )
f = open(diction, 'r')
for line in f:
    pswd = line
    pswd = pswd[:-1]
    zipf.setpassword(pswd)
    try:
        zipf.extractall()
        found = True
        break
    except RuntimeError:
        continue
zipf.close()  

First time I encountered the bug was when on my dictionary I had all the numbers from 000 to 999 and saw that it crashed at 610. Now it crashes at 844.Even when I do this 

import zipfile

zfile=raw_input("Please input zip's file name\n")
zipf = zipfile.ZipFile( zfile, 'r' )
zipf.setpassword('844')
zipf.extractall()
zipf.close()  

it crashes with the error in my first post.
If this is any help, i'm using python 2.6.6 on linux and the number changed from 610 to 844 when I opened a new terminal window.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10876>
_______________________________________

From report at bugs.python.org  Mon Jan 10 00:15:01 2011
From: report at bugs.python.org (Kira Erethon)
Date: Sun, 09 Jan 2011 23:15:01 +0000
Subject: [issue10876] Zipfile crashes when zip password is set to 610/844
In-Reply-To: <1294611467.71.0.814994722037.issue10876@psf.upfronthosting.co.za>
Message-ID: <1294614901.6.0.545005207829.issue10876@psf.upfronthosting.co.za>


Changes by Kira Erethon <shinjierethon at gmail.com>:


----------
title: Zipfile crashes when zip password is set to 610 -> Zipfile crashes when zip password is set to 610/844

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10876>
_______________________________________

From report at bugs.python.org  Mon Jan 10 00:37:10 2011
From: report at bugs.python.org (Kira Erethon)
Date: Sun, 09 Jan 2011 23:37:10 +0000
Subject: [issue10876] Zipfile crashes when zip password is set to
	610/844/numerous other numbers
In-Reply-To: <1294611467.71.0.814994722037.issue10876@psf.upfronthosting.co.za>
Message-ID: <1294616230.48.0.929553226928.issue10876@psf.upfronthosting.co.za>


Kira Erethon <shinjierethon at gmail.com> added the comment:

Update, tried this in another machine of mine, same exact code and this time it crashes at 68

----------
title: Zipfile crashes when zip password is set to 610/844 -> Zipfile crashes when zip password is set to 610/844/numerous other numbers

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10876>
_______________________________________

From report at bugs.python.org  Mon Jan 10 00:50:32 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 09 Jan 2011 23:50:32 +0000
Subject: [issue10875] Update Regular Expression HOWTO
In-Reply-To: <1294604409.29.0.577762819836.issue10875@psf.upfronthosting.co.za>
Message-ID: <1294617032.15.0.971529291218.issue10875@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Since I think I know how to do it, easily, I will try to derive the 2.7 patch.

In Matching Characters, I think
"The following predefined special sequences are available:"

should be expanded to 

"The following predefined special sequences are a subset of those available. The equivalent classes are for bytes patterns. For a complete list of sequences and expanded class definitions for Unicode string patterns, see the end of Regular Expression Syntax."
(with section reference markup).

Note to myself. /bytes/byte string/ for 2.7.

While the changes all look innocuous to me with respect to building the docs, I am curious if you have tried to rebuild the HOWTO (if you have the tool chain, which I do not).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10875>
_______________________________________

From report at bugs.python.org  Mon Jan 10 00:52:54 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 09 Jan 2011 23:52:54 +0000
Subject: [issue10877] Make Tools (and subdirs) a package (and subpackages)
In-Reply-To: <1294617174.73.0.902104851361.issue10877@psf.upfronthosting.co.za>
Message-ID: <1294617174.73.0.902104851361.issue10877@psf.upfronthosting.co.za>


New submission from Terry J. Reedy <tjreedy at udel.edu>:

Given that sys.path includes ".../python32" adding the requisite empty __init__.py to Tools/ and, for instance, demo/ would allow

>>> from Tools.demo.redemo import main; main()

to work (I tried it with Scripts instead of demo in b2). Now I have to open an editor window and hit F5 to run. (On Windows, the Command Prompt window is so wretched that it is much easier to work and explore within a Python shell.)

Can files like __init__.py be added to the repository just by adding them to a checked-out working copy?

Would there be a reason to exclude any subdirectories (that have .py files)?

Can this be done for 3.2? I see that things have already been moved around within Tools since b2.

If there is a policy against this, perhaps Tools/README could mention it. In any case, 

"This directory contains a number of Python programs that are useful"

should be edited to

"This directory contains a number of subdirectories with Python programs that are useful"

as *every* program has been put in a subdirectory, even if by itself.

----------
components: Demos and Tools
messages: 125875
nosy: terry.reedy
priority: normal
severity: normal
status: open
title: Make Tools (and subdirs) a package (and subpackages)
type: feature request
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10877>
_______________________________________

From report at bugs.python.org  Mon Jan 10 00:53:50 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 09 Jan 2011 23:53:50 +0000
Subject: [issue10877] Make Tools (and subdirs) a package (and subpackages)
In-Reply-To: <1294617174.73.0.902104851361.issue10877@psf.upfronthosting.co.za>
Message-ID: <1294617230.21.0.32543098878.issue10877@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10877>
_______________________________________

From report at bugs.python.org  Mon Jan 10 03:19:05 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 10 Jan 2011 02:19:05 +0000
Subject: [issue10877] Make Tools (and subdirs) a package (and subpackages)
In-Reply-To: <1294617174.73.0.902104851361.issue10877@psf.upfronthosting.co.za>
Message-ID: <1294625945.19.0.346894146976.issue10877@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/issue10877>
_______________________________________

From report at bugs.python.org  Mon Jan 10 03:20:42 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 10 Jan 2011 02:20:42 +0000
Subject: [issue10875] Update Regular Expression HOWTO
In-Reply-To: <1294604409.29.0.577762819836.issue10875@psf.upfronthosting.co.za>
Message-ID: <1294626042.4.0.192426886898.issue10875@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> I agree that the .rst should not have two copies and that any windows.chm specific fixup should be in the tool. Right now, right clicking gives a context menu with one item: Properties. Clicking that brings up a dialog box with a url that can be copied. Good enough for me at the moment but not terribly obvious. A possible separate issue.

I would argue that this is a bug in the CHM viewers, not Python :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10875>
_______________________________________

From report at bugs.python.org  Mon Jan 10 03:27:31 2011
From: report at bugs.python.org (Glenn Linderman)
Date: Mon, 10 Jan 2011 02:27:31 +0000
Subject: [issue1602] windows console doesn't print utf8 (Py30a2)
In-Reply-To: <1197453390.87.0.813702844893.issue1602@psf.upfronthosting.co.za>
Message-ID: <1294626451.69.0.775421210982.issue1602@psf.upfronthosting.co.za>


Glenn Linderman <v+python at g.nevcal.com> added the comment:

I would certainly be delighted if someone would reopen this issue, and figure out how to translate unicode2.py to Python internals so that Python's console I/O on Windows would support Unicode "out of the box".

Otherwise, I'll have to include the equivalent of unicode2.py in all my Python programs, because right now, I'm including instructions for the use to (1) choose Lucida or Consolas font if they can't figure out any other font that gets rid of the square boxes (2) chcp 65001 (3) set PYTHONIOENCODING=UTF-8

Having this capability inside Python (or my programs) will enable me to eliminate two-thirds of the geeky instructions for my users.  But it seems like a very appropriate capability to have within Python, especially Python 3.x with its preference and support Unicode in so many other ways.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1602>
_______________________________________

From report at bugs.python.org  Mon Jan 10 03:30:32 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 10 Jan 2011 02:30:32 +0000
Subject: =?utf-8?q?=5Bissue10628=5D_Typos_in_3=2E2_what=E2=80=99s_new?=
In-Reply-To: <1291489855.52.0.016822369266.issue10628@psf.upfronthosting.co.za>
Message-ID: <1294626632.09.0.0235838041358.issue10628@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I collected typos instead of replying to python-checkins notifications, so as not to disturb Raymond?s writing process.  Now that the file is nearly complete and 3.2rc at hand, here is my updated patch.  It mixes real typos, one Python syntax fix, very minor typos, markup tweaks, and some rephrasing where the previous text was unclear to me.  Of course, I am not a native speaker, so you?re welcome to take my proposals merely as indications of unclarity and rephrase otherwise or ignore them altogether.

If that?s more convenient, I can make one patch for certain typos and fixes, one patch for minor nitpicks, and a list of unclear wording.

----------
resolution: fixed -> 
stage:  -> patch review
status: closed -> open
Added file: http://bugs.python.org/file20333/whatsnew-3.2-typos.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10628>
_______________________________________

From report at bugs.python.org  Mon Jan 10 03:30:39 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 10 Jan 2011 02:30:39 +0000
Subject: =?utf-8?q?=5Bissue10628=5D_Typos_in_3=2E2_what=E2=80=99s_new?=
In-Reply-To: <1291489855.52.0.016822369266.issue10628@psf.upfronthosting.co.za>
Message-ID: <1294626639.56.0.639616733641.issue10628@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


Removed file: http://bugs.python.org/file19942/whatsnew-3.2-typos.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10628>
_______________________________________

From report at bugs.python.org  Mon Jan 10 04:26:53 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 10 Jan 2011 03:26:53 +0000
Subject: [issue10858] Make source code links less prominent
In-Reply-To: <1294423770.11.0.311474750627.issue10858@psf.upfronthosting.co.za>
Message-ID: <1294630013.94.0.900105904803.issue10858@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Removed the wordy and bright yellow boxes.
Replace with single source link just below the section heading.
Style modeled after that used in the Go language docs http://golang.org/pkg/container/heap/

See r87898.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10858>
_______________________________________

From report at bugs.python.org  Mon Jan 10 06:26:53 2011
From: report at bugs.python.org (Craig McQueen)
Date: Mon, 10 Jan 2011 05:26:53 +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: <1294637213.55.0.545769757806.issue9196@psf.upfronthosting.co.za>


Craig McQueen <python at craig.mcqueen.id.au> added the comment:

I'm attaching a file that I used (in Python 2.x).

It's a little rough--I manually commented and uncommented various lines to see what would change under various circumstances. But at least you should be able to see what I was doing.

----------
Added file: http://bugs.python.org/file20334/class_str_unicode_methods.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9196>
_______________________________________

From report at bugs.python.org  Mon Jan 10 06:55:38 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 10 Jan 2011 05:55:38 +0000
Subject: =?utf-8?q?=5Bissue10628=5D_Typos_in_3=2E2_what=E2=80=99s_new?=
In-Reply-To: <1291489855.52.0.016822369266.issue10628@psf.upfronthosting.co.za>
Message-ID: <1294638938.88.0.281951732885.issue10628@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Fixed in r87899.
Thanks for the patch
and attention to detail.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10628>
_______________________________________

From report at bugs.python.org  Mon Jan 10 07:40:38 2011
From: report at bugs.python.org (Teodor Georgiev)
Date: Mon, 10 Jan 2011 06:40:38 +0000
Subject: [issue10878] asyncore does not react properly on close()
In-Reply-To: <1294641638.26.0.753920382409.issue10878@psf.upfronthosting.co.za>
Message-ID: <1294641638.26.0.753920382409.issue10878@psf.upfronthosting.co.za>


New submission from Teodor Georgiev <lv_tokata at yahoo.com>:

I am trying to add a simple timer to each created socket and destroy it
once the timer expires:

class client(asyncore.dispatcher):
    def __init__(self,host):
    ...
    self.timeout = time.time() + 5

    def readable(self):
        if time.time() >= self.timeout:
            self.close()
        return True

When running that code, it raises an exception:

asyncore.loop(timeout=0.8)
  File "/usr/lib/python2.6/asyncore.py", line 211, in loop
    poll_fun(timeout)
  File "/usr/lib/python2.6/asyncore.py", line 144, in poll
    raise
  File "/usr/lib/python2.6/asyncore.py", line 141, in poll
    r, w, e = select.select(r, w, e, timeout)
select.error: (9, 'Bad file descriptor')


Although del_channel is executed properly and the socket is removed from the map, the poll function is not updated with that info and continues to keep the socket into the r,w,e.

----------
components: Library (Lib)
messages: 125882
nosy: tgeorgiev
priority: normal
severity: normal
status: open
title: asyncore does not react properly on close()
versions: Python 2.6, Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10878>
_______________________________________

From report at bugs.python.org  Mon Jan 10 08:35:26 2011
From: report at bugs.python.org (Giampaolo Rodola')
Date: Mon, 10 Jan 2011 07:35:26 +0000
Subject: [issue10878] asyncore does not react properly on close()
In-Reply-To: <1294641638.26.0.753920382409.issue10878@psf.upfronthosting.co.za>
Message-ID: <1294644926.27.0.481303927574.issue10878@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

Problem is you have to return False right after close().
There's an open issue to add a scheduler to asyncore:
http://bugs.python.org/issue1641
Closing this out as invalid.

----------
nosy: +giampaolo.rodola
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10878>
_______________________________________

From report at bugs.python.org  Mon Jan 10 09:34:50 2011
From: report at bugs.python.org (Glenn Linderman)
Date: Mon, 10 Jan 2011 08:34:50 +0000
Subject: [issue10879] cgi memory usage
In-Reply-To: <1294648490.09.0.987257947586.issue10879@psf.upfronthosting.co.za>
Message-ID: <1294648490.09.0.987257947586.issue10879@psf.upfronthosting.co.za>


New submission from Glenn Linderman <v+python at g.nevcal.com>:

In attempting to review issue 4953, I discovered a conundrum in handling of multipart/formdata.

cgi.py has claimed for some time (at least since 2.4) that it "handles" file storage for uploading large files.  I looked at the code in 2.6 that handles such, and it uses the rfc822.Message method, which parses headers from any object supporting readline().  In particular, it doesn't attempt to read message bodies, and there is code in cgi.py to perform that.

There is still code in 3.2 cgi.py to read message bodies, but... rfc822 has gone away, and been replaced with the email package.  Theoretically this is good, but the cgi FieldStorage read_multi method now parses the whole CGI input and then iteration parcels out items to FieldStorage instances.  There is a significant difference here: email reads everything into memory (if I understand it correctly).  That will never work to upload large or many files when combined with a Web server that launches CGI programs with memory limits.

I see several possible actions that could be taken:
1) Documentation.  While it is doubtful that any is using 3.x CGI, and this makes it more doubtful, the present code does not match the documentation, because while the documenteation claims to handle file uploads as files, rather than in-memory blobs, the current code does not do that.

2) If there is a method in the email package that corresponds to rfc822.Message, parsing only headers, I couldn't find it.  Perhaps it is possible to feed just headers to BytesFeedParser, and stop, and get the same sort of effect.  However, this is not the way the cgi.py presently is coded.  And if there is a better API, for parsing only headers, that is or could be exposed by email, that might be handy.

3) The 2.6 cgi.py does not claim to support nested multipart/ stuff, only one level.  I'm not sure if any present or planned web browsers use nested multipart/ stuff... I guess it would require a nested <form> tag? which is illegal HTML last I checked.  So perhaps the general logic flow of 2.6 cgi.py could be reinstated, with a technique to feed only headers to BytesFeedParser, together with reinstating the MIME body parsing in cgi.py,b and this could make a solution that works.

I discovered this, beacuase I couldn't figure out where a bunch of the methods in cgi.py were called from, particularly read_lines_to_outerboundary, and make_file.  They seemed to be called much too late in the process.  It wasn't until I looked back at 2.6 code that I could see that there was a transition from using rfc822 only for headers to using email for parsing the whole data stream, and that that was the cause of the documentation not seeming to match the code logic.  I have no idea if this problem is in 2.7, as I don't have it installed here for easy reference, and I'm personally much more interested in 3.2.

----------
components: Library (Lib)
messages: 125884
nosy: r.david.murray, v+python
priority: normal
severity: normal
status: open
title: cgi memory usage
versions: Python 3.1, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10879>
_______________________________________

From report at bugs.python.org  Mon Jan 10 09:52:19 2011
From: report at bugs.python.org (Glenn Linderman)
Date: Mon, 10 Jan 2011 08:52:19 +0000
Subject: [issue4953] cgi module cannot handle POST with multipart/form-data
	in	3.0
In-Reply-To: <1232010166.79.0.972664060868.issue4953@psf.upfronthosting.co.za>
Message-ID: <1294649539.28.0.477289044307.issue4953@psf.upfronthosting.co.za>


Glenn Linderman <v+python at g.nevcal.com> added the comment:

This looks much simpler than the previous patch.  However, I think it can be further simplified. This is my first reading of this code, however, so I might be totally missing something(s).

Pierre said:
Besides FieldStorage, I modified the  parse() function at module level, but not parse_multipart (should it be kept at all ?)

I say:
Since none of this stuff works correctly in 3.x, and since there are comments in the code about "folding" the parse* functions into FieldStorage, then I think they could be deprecated, and not fixed.  If people are still using them, by writing code to work around their deficiencies, that code would continue to work for 3.2, but then not in 3.3 when that code is removed?  That seems reasonable to me.  In this scenario, the few parse* functions that are used by FieldStorage should be copied into FieldStorage as methods (possibly private methods), and fixed there, instead of being fixed in place.  That was all the parse* functions could be deprecated, and the use of them would be unchanged for 3.2.

Since RFC 2616 says that the HTTP protocol uses ISO-8859-1 (latin-1), I think that should be required here, instead of deferring to fp.encoding, which would eliminate 3 lines.

Also, the use of FeedParser could be replaced by BytesFeedParser, thus eliminating the need to decode header lines in that loop.

And, since this patch will be applied only to Python 3.2+, the mscvrt code can be removed (you might want a personal copy with it for earlier version of Python 3.x, of course).

I wonder if the 'ascii' reference should also be 'latin-1'?

In truly reading and trying to understand this code to do a review, I notice a deficiency in _parseparam and parse_header: should I file new issues for them? (perhaps these are unimportant in practice; I haven't seen \ escapes used in HTTP headers).  RFC 2616 allows for "" which are handled in _parseparam.  And for \c inside "", which is handled in parse_header.  But: _parseparam counts " without concern for \", and parse_header allows for \\ and \" but not \f or \j or \ followed by other characters, even though they are permitted (but probably not needed for much).

In make_file, shouldn't the encoding and newline parameters be preserved when opening text files?  On the other hand, it seems like perhaps we should leverage the power of IO to do our encoding/decoding... open the file with the TextIOBase layer set to the encoding for the MIME part, but then just read binary without decoding it, write it to the .buffer of the TextIOBase, and when the end is reached, flush it, and seek(0).  Then the data can be read back from the TextIOBase layer, and it will be appropriate decoded.  Decoding errors might be deferred, but will still occur.  This technique would save two data operations: the explicit decode in the cgi code, and the implicit encode in the IO layers, so resources would be saved.  Additionally, if there is a CONTENT-LENGTH specified for non-binary data, the read_binary method should be used for it also, because it is much more efficient than readlines... less scanning of the data, and fewer outer iterations.  This goes well with the technique of leaving that data in binary until read from the file.

It seems that in addition to fixing this bug, you are also trying to limit the bytes read by FieldStorage to some maximum (CONTENT_LENGTH).  This is good, I guess.  But skip_lines() has a readline potentially as long as 32KB, that isn't limited by the maximum.  Similar in read_lines_to_outer_boundary, and read_lines_to_eof (although that may not get called in the cases that need to be limited).  If a limit is to be checked for, I think it should be a true, exact limit, not an approximate limit.

See also issue 10879.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4953>
_______________________________________

From report at bugs.python.org  Mon Jan 10 10:31:53 2011
From: report at bugs.python.org (Glenn Linderman)
Date: Mon, 10 Jan 2011 09:31:53 +0000
Subject: [issue4953] cgi module cannot handle POST with multipart/form-data
	in	3.0
In-Reply-To: <1232010166.79.0.972664060868.issue4953@psf.upfronthosting.co.za>
Message-ID: <1294651913.83.0.298873295626.issue4953@psf.upfronthosting.co.za>


Glenn Linderman <v+python at g.nevcal.com> added the comment:

Also, the required behavior of make_file changes, to need the right encoding, or binary, so that needs to be documented as a change for people porting from 2.x. It would be possible, even for files, which will be uploaded as binary, for a user to know the appropriate encoding and, if the file is to be processed rather than saved, supply that encoding for the temporary file.  So the temporary file may not want to be assumed to be binary, even though we want to write binary to it.  So similarly to the input stream, if it is TextIOBase, we want to write to the .buffer.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4953>
_______________________________________

From report at bugs.python.org  Mon Jan 10 10:44:46 2011
From: report at bugs.python.org (Giampaolo Rodola')
Date: Mon, 10 Jan 2011 09:44:46 +0000
Subject: [issue10784] os.getpriority() and os.setpriority()
In-Reply-To: <1293500810.54.0.0610321482452.issue10784@psf.upfronthosting.co.za>
Message-ID: <1294652686.25.0.259220186998.issue10784@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

Question: should Py_BEGIN/END_ALLOW_THREADS be used around getpriority() and setpriority() calls? It's still not clear to me when to use them exactly.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10784>
_______________________________________

From report at bugs.python.org  Mon Jan 10 10:45:46 2011
From: report at bugs.python.org (Glenn Linderman)
Date: Mon, 10 Jan 2011 09:45:46 +0000
Subject: [issue10879] cgi memory usage
In-Reply-To: <1294648490.09.0.987257947586.issue10879@psf.upfronthosting.co.za>
Message-ID: <1294652746.24.0.244606386518.issue10879@psf.upfronthosting.co.za>


Glenn Linderman <v+python at g.nevcal.com> added the comment:

Trying to code some of this, it would be handy if BytesFeedParser.feed would return a status, indicating if it has seen the end of the headers yet. But that would only work if it is parsing as it goes, rather than just buffering, with all the real parsing work being done at .close time.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10879>
_______________________________________

From report at bugs.python.org  Mon Jan 10 10:50:49 2011
From: report at bugs.python.org (David-Sarah Hopwood)
Date: Mon, 10 Jan 2011 09:50:49 +0000
Subject: [issue1602] windows console doesn't print utf8 (Py30a2)
In-Reply-To: <1197453390.87.0.813702844893.issue1602@psf.upfronthosting.co.za>
Message-ID: <1294653049.51.0.623165459165.issue1602@psf.upfronthosting.co.za>


David-Sarah Hopwood <david-sarah at jacaranda.org> added the comment:

I'll have a look at the Py3k I/O internals and see what I can do.
(Reopening a bug appears to need Coordinator permissions.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1602>
_______________________________________

From report at bugs.python.org  Mon Jan 10 11:05:13 2011
From: report at bugs.python.org (Tim Golden)
Date: Mon, 10 Jan 2011 10:05:13 +0000
Subject: [issue1602] windows console doesn't print utf8 (Py30a2)
In-Reply-To: <1197453390.87.0.813702844893.issue1602@psf.upfronthosting.co.za>
Message-ID: <1294653913.66.0.846497582866.issue1602@psf.upfronthosting.co.za>


Tim Golden <mail at timgolden.me.uk> added the comment:

Reopening as there seems to be some possibility of progress

----------
nosy:  -BreamoreBoy
resolution: invalid -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1602>
_______________________________________

From report at bugs.python.org  Mon Jan 10 11:07:44 2011
From: report at bugs.python.org (Tim Golden)
Date: Mon, 10 Jan 2011 10:07:44 +0000
Subject: [issue1602] windows console doesn't print utf8 (Py30a2)
In-Reply-To: <1197453390.87.0.813702844893.issue1602@psf.upfronthosting.co.za>
Message-ID: <1294654064.98.0.945341794371.issue1602@psf.upfronthosting.co.za>


Changes by Tim Golden <mail at timgolden.me.uk>:


----------
versions: +Python 3.3 -Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1602>
_______________________________________

From report at bugs.python.org  Mon Jan 10 11:09:49 2011
From: report at bugs.python.org (SilentGhost)
Date: Mon, 10 Jan 2011 10:09:49 +0000
Subject: [issue10875] Update Regular Expression HOWTO
In-Reply-To: <1294604409.29.0.577762819836.issue10875@psf.upfronthosting.co.za>
Message-ID: <1294654189.76.0.833765927726.issue10875@psf.upfronthosting.co.za>


SilentGhost <ghost.adh at gmail.com> added the comment:

> While the changes all look innocuous to me with respect to building the docs, I am curious if you have tried to rebuild the HOWTO (if you have the tool chain, which I do not).

I did rebuild the docs with 'make html'. Build was clean every time. If you meant something else please let me know.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10875>
_______________________________________

From report at bugs.python.org  Mon Jan 10 11:13:08 2011
From: report at bugs.python.org (Glenn Linderman)
Date: Mon, 10 Jan 2011 10:13:08 +0000
Subject: [issue4953] cgi module cannot handle POST with multipart/form-data
	in	3.0
In-Reply-To: <1232010166.79.0.972664060868.issue4953@psf.upfronthosting.co.za>
Message-ID: <1294654388.49.0.9307733353.issue4953@psf.upfronthosting.co.za>


Glenn Linderman <v+python at g.nevcal.com> added the comment:

I wrote:
Additionally, if there is a CONTENT-LENGTH specified for non-binary data, the read_binary method should be used for it also, because it is much more efficient than readlines... less scanning of the data, and fewer outer iterations.  This goes well with the technique of leaving that data in binary until read from the file.

I further elucidate:
Sadly, while the browser (Firefox) seems to calculate an overall CONTENT-LENGTH for the HTTP headers, it does not seem to calculate CONTENT-LENGTH for individual parts, not even file parts where it would be extremely helpful.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4953>
_______________________________________

From report at bugs.python.org  Mon Jan 10 11:23:45 2011
From: report at bugs.python.org (Glenn Linderman)
Date: Mon, 10 Jan 2011 10:23:45 +0000
Subject: [issue4953] cgi module cannot handle POST with multipart/form-data
	in	3.0
In-Reply-To: <1232010166.79.0.972664060868.issue4953@psf.upfronthosting.co.za>
Message-ID: <1294655025.18.0.132557207934.issue4953@psf.upfronthosting.co.za>


Glenn Linderman <v+python at g.nevcal.com> added the comment:

It seems the choice of whether to make_file or StringIO is based on the existence of self.length... per my previous comment, content-length doesn't seem to appear in any of the multipart/ item headers, so it is unlikely that real files will be created by this code.

Sadly that seems to be the case for 2.x also, so I wonder now if CGI has ever properly saved files, instead of buffering in memory...

I'm basing this off the use of Firefox Live HTTP headers tool.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4953>
_______________________________________

From report at bugs.python.org  Mon Jan 10 12:03:25 2011
From: report at bugs.python.org (Teodor Georgiev)
Date: Mon, 10 Jan 2011 11:03:25 +0000
Subject: [issue10878] asyncore does not react properly on close()
In-Reply-To: <1294641638.26.0.753920382409.issue10878@psf.upfronthosting.co.za>
Message-ID: <1294657405.23.0.667152627049.issue10878@psf.upfronthosting.co.za>


Teodor Georgiev <lv_tokata at yahoo.com> added the comment:

Sorry, I forgot to mention - I have already tried to return False, but there was no difference.

def readable(self):
        if time.time() >= self.timeout:
            self.close()
            return False
         else:
            return True

----------
resolution: invalid -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10878>
_______________________________________

From report at bugs.python.org  Mon Jan 10 12:21:08 2011
From: report at bugs.python.org (Giampaolo Rodola')
Date: Mon, 10 Jan 2011 11:21:08 +0000
Subject: [issue10878] asyncore does not react properly on close()
In-Reply-To: <1294641638.26.0.753920382409.issue10878@psf.upfronthosting.co.za>
Message-ID: <1294658468.39.0.603630493307.issue10878@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

What if you return False also in writable method?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10878>
_______________________________________

From report at bugs.python.org  Mon Jan 10 12:34:41 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 10 Jan 2011 11:34:41 +0000
Subject: [issue10876] Zipfile crashes when zip password is set to
	610/844/numerous other numbers
In-Reply-To: <1294611467.71.0.814994722037.issue10876@psf.upfronthosting.co.za>
Message-ID: <1294659281.26.0.767846416996.issue10876@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Well, the password-checking scheme uses a one-byte check against the zip header for consistency. 
So there is a (near) 1/256 chance of false positives, that is of bad passwords mistakenly detected as good; then the ZipFile class proceeds with unarchiving and that's where things fail (because the "decrypted" stream is really junk).

Therefore, I'd call it not a bug. If you want to crack a password, you need to trap this exception and interpret it as "bad password".

----------
nosy: +pitrou
resolution:  -> invalid
status: open -> closed
type: crash -> behavior
versions: +Python 2.7, Python 3.1, Python 3.2 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10876>
_______________________________________

From report at bugs.python.org  Mon Jan 10 12:44:37 2011
From: report at bugs.python.org (Teodor Georgiev)
Date: Mon, 10 Jan 2011 11:44:37 +0000
Subject: [issue10878] asyncore does not react properly on close()
In-Reply-To: <1294641638.26.0.753920382409.issue10878@psf.upfronthosting.co.za>
Message-ID: <1294659877.06.0.707006492266.issue10878@psf.upfronthosting.co.za>


Teodor Georgiev <lv_tokata at yahoo.com> added the comment:

Precisely, I traced down the problem by putting a simple "breakpoint"
in asyncore.py:

def poll(timeout=0.0, map=None):
    if map is None:
        map = socket_map
    if map:
        r = []; w = []; e = []
        for fd, obj in map.items():
            is_r = obj.readable()
            print "Readable??? -->" , is_r
            is_w = obj.writable()
            if is_r:
                r.append(fd)
            if is_w:
                w.append(fd)
            if is_r or is_w:
                e.append(fd)
        if [] == r == w == e:
            time.sleep(timeout)
            return

        print r,w,e
try:
            r, w, e = select.select(r, w, e, timeout)
        except select.error, err:
            if err.args[0] != EINTR:
                raise
            else:
                return



And here it comes:

[5] [5] [5]
Readable??? --> True
[5] [5] [5]
Readable??? --> True
[5] [5] [5]
Readable??? --> False
[] [5] [5]

Traceback (most recent call last):
  File "./dlms_client.py", line 136, in <module>
    asyncore.loop(timeout=0.8)
  File "/usr/lib/python2.6/asyncore.py", line 213, in loop
    poll_fun(timeout)
  File "/usr/lib/python2.6/asyncore.py", line 146, in poll
    raise
  File "/usr/lib/python2.6/asyncore.py", line 143, in poll
    r, w, e = select.select(r, w, e, timeout)
select.error: (9, 'Bad file descriptor')

So, in order this to work, on first sight all r,w,e must not point to
a socket that has been already closed. Now I am going to think for a workaround at least.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10878>
_______________________________________

From report at bugs.python.org  Mon Jan 10 12:50:07 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 10 Jan 2011 11:50:07 +0000
Subject: [issue1602] windows console doesn't print utf8 (Py30a2)
In-Reply-To: <1197453390.87.0.813702844893.issue1602@psf.upfronthosting.co.za>
Message-ID: <1294660207.03.0.604298820061.issue1602@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

The script unicode2.py uses the console STD_OUTPUT_HANDLE iff sys.stdout.fileno()==1.
But is it always the case? What about pythonw.exe? 
Also some applications may redirect fd=1: I'm sure that py.test does this http://pytest.org/capture.html#setting-capturing-methods-or-disabling-capturing and IIRC Apache also redirects file descriptors.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1602>
_______________________________________

From report at bugs.python.org  Mon Jan 10 13:33:21 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 10 Jan 2011 12:33:21 +0000
Subject: [issue1602] windows console doesn't print utf8 (Py30a2)
In-Reply-To: <1294660207.03.0.604298820061.issue1602@psf.upfronthosting.co.za>
Message-ID: <201101101333.15618.victor.stinner@haypocalc.com>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

amaury> The script unicode2.py uses the console STD_OUTPUT_HANDLE iff
amaury> sys.stdout.fileno()==1

Interesting article about the Windows console:
http://blogs.msdn.com/b/michkap/archive/2008/03/18/8306597.aspx

There is an example which has many tests to check that stdout is the windows 
console (and not a pipe or something else).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1602>
_______________________________________

From report at bugs.python.org  Mon Jan 10 14:03:51 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 10 Jan 2011 13:03:51 +0000
Subject: [issue4953] cgi module cannot handle POST with
	multipart/form-datain	3.0
In-Reply-To: <1294575984.07.0.700034944239.issue4953@psf.upfronthosting.co.za>
Message-ID: <201101101403.48304.victor.stinner@haypocalc.com>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Some comments on cgi_diff_20110109.txt, especially on FieldStorage 
constructor.

Le dimanche 09 janvier 2011 13:26:24, vous avez ?crit :
> Here is the diff file for the revised version of cgi.py

+            import msvcrt
+            msvcrt.setmode (0, os.O_BINARY) # stdin  = 0
+            msvcrt.setmode (1, os.O_BINARY) # stdout = 1
+            msvcrt.setmode (2, os.O_BINARY) # stderr = 2

Why do you change stdout and stderr mode? Is it needed? Instead of 0, you 
should use sys.stdin.fileno() with a try/except on .fileno() because stdin can 
be a StringIO object:

   >>> o=io.StringIO()    
   >>> o.fileno()
   io.UnsupportedOperation: fileno

I suppose that it's better to do nothing if sys.stdin has no .fileno() method.

More generally, I don't think that the cgi module should touch sys.stdin mode: 
it impacts the whole process, not only the cgi module. Eg. change sys.stdin 
mode in Python 3.1 will break the interperter because the Python parser in 
Pytohn 3.1 doesn't know how to handle \r\n end of line. If you need binary 
stdin, I should backport my patch for #10841 (for std*, FileIO and the 
parser).

----
def __init__(self, fp=None, headers=None, outerboundary="",
             environ=os.environ, keep_blank_values=0, strict_parsing=0,
             limit=None):
...
if 'QUERY_STRING' in environ:
   qs = environ['QUERY_STRING']
elif sys.argv[1:]:
   qs = sys.argv[1]
else:
   qs = ""
fp = BytesIO(qs.encode('ascii')) # bytes
----

With Python 3.2, you should use environ=environ.os.environb by default to 
avoid unnecessary conversion (os.environb --decode--> os.environ --encode--> 
qs). To decode sys.argv, ASCII is not the right encoding: you should use 
qs.encode(locale.getpreferredencoding(), 'surrogateescape') because Python 
decodes the environment and the command line arguments from 
locale.getpreferredencoding()+'surrogateescape', so it is the exact reverse 
operation and you get the original raw bytes.

For Python 3.1, use also qs.encode(locale.getpreferredencoding(), 
'surrogateescape') to encode the environment variable.

So for Python 3.2, it becomes something like:
----
def __init__(self, fp=None, headers=None, outerboundary="",
             environ=os.environb, keep_blank_values=0, strict_parsing=0,
             limit=None):
...
if 'QUERY_STRING' in environ:
   qs = environ[b'QUERY_STRING']
elif sys.argv[1:]:
   qs = sys.argv[1]
else:
   qs = b""
if isinstance(qs, str):
   encoding = locale.getpreferredencoding()
   qs = qs.encode(encoding, 'surrogateescape'))
fp = BytesIO(qs)
----
If you would like to support byte *and* Unicode environment (eg. 
environ=os.environ and environ=os.environb), you should do something a little 
bit more complex: see os.get_exec_path(). I can work on a patch if you would 
like to. A generic function should maybe be added to the os module, function 
with an optional environ argument (as os.get_exec_path()).

---
if fp is None:
   fp = sys.stdin
if fp is sys.stdin:
   ...
---
you should use sys.stdin.buffer if fp is None, and accept sys.stdin.buffer in 
the second test. Something like:
---
stdin = sys.stdin
if isinstance(fp,TextIOBase):
   stdin_buffer = stdin.buffer
else:
   stdin_buffer = stdin
if fp is None:
   fp = stdin_buffer
if fp is stdin or fp is stdin_buffer:
   ...
---

Don't you think that a warning would be appropriate if sys.stdin is passed 
here?
---
        # self.fp.read() must return bytes
        if isinstance(fp,TextIOBase):
            self.fp = fp.buffer
        else:
            self.fp = fp
---
Maybe a DeprecationWarning if we would like to drop support of TextIOWrapper 
later :-)

For the else case: you should maybe add a strict test on the type, eg. check 
for RawIOBase or BufferedIOBase subclass, isinstance(fp, (io.RawIOBase, 
io.BufferedIOBase)). It would avoid to check that fp.read() returns a bytes 
object (or get an ugly error later).

Set sys.stdin.buffer.encoding attribute is not a good idea. Why do you modify 
fp, instead of using a separated attribute on FieldStorage (eg. 
self.fp_encoding)?
---
        # field keys and values (except for files) are returned as strings
        # an encoding is required to decode the bytes read from self.fp
        if hasattr(fp,'encoding'):
            self.fp.encoding = fp.encoding
        else:
            self.fp.encoding = 'latin-1' # ?
---

I only read the constructor code.

----------
title: cgi module cannot handle POST with multipart/form-data in	3.0 -> cgi module cannot handle POST with multipart/form-datain	3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4953>
_______________________________________

From report at bugs.python.org  Mon Jan 10 14:07:33 2011
From: report at bugs.python.org (Etienne Robillard)
Date: Mon, 10 Jan 2011 13:07:33 +0000
Subject: [issue4953] cgi module cannot handle POST with multipart/form-data
	in	3.0
In-Reply-To: <1294655025.18.0.132557207934.issue4953@psf.upfronthosting.co.za>
Message-ID: <4D2B075A.7090608@gthcfoundation.org>


Etienne Robillard <erob at gthcfoundation.org> added the comment:

On 10/01/11 05:23 AM, Glenn Linderman wrote:
> I'm basing this off the use of Firefox Live HTTP headers tool.
>
>   

is sendfile() available on Windows ? i thought the Apache server could
use that
to upload files without having to buffer files in memory..

HTH,

-- 

Etienne Robillard

Company: Green Tea Hackers Club
Occupation: Software Developer
E-mail:     erob at gthcfoundation.org
Work phone: +1 514-962-7703
Website (Company):  https://www.gthc.org/
Website (Blog):     https://www.gthc.org/blog/
PGP public key fingerprint:    F2A9 32EA 8E7C 460F 1728  A1A7 649C 7F17 A086 DDEC

During times of universal deceit, telling the truth becomes a revolutionary act. -- George Orwell

----------
title: cgi module cannot handle POST with multipart/form-datain	3.0 -> cgi module cannot handle POST with multipart/form-data in	3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4953>
_______________________________________

From report at bugs.python.org  Mon Jan 10 14:40:57 2011
From: report at bugs.python.org (R. David Murray)
Date: Mon, 10 Jan 2011 13:40:57 +0000
Subject: [issue10879] cgi memory usage
In-Reply-To: <1294648490.09.0.987257947586.issue10879@psf.upfronthosting.co.za>
Message-ID: <1294666857.38.0.557920900944.issue10879@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

The email package does have a 'parser headers only' mode, but it doesn't do what you want, since it reads the remainder of the file and sets it as the payload of the single, un-nested Message object it returns.

Adding a flag to tell it to stop parsing instead of doing that will probably be fairly simple, but is a feature request.

However, I'm not clear on how that helps.  Doesn't FieldStorage also load everything into memory?

There's an open feature request for providing a way to use alternate backing stores for the bodies of message parts in the email package, which *would* address this issue.

----------
type:  -> feature request

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10879>
_______________________________________

From report at bugs.python.org  Mon Jan 10 14:41:07 2011
From: report at bugs.python.org (R. David Murray)
Date: Mon, 10 Jan 2011 13:41:07 +0000
Subject: [issue10879] cgi memory usage
In-Reply-To: <1294648490.09.0.987257947586.issue10879@psf.upfronthosting.co.za>
Message-ID: <1294666867.25.0.775630056663.issue10879@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
versions:  -Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10879>
_______________________________________

From report at bugs.python.org  Mon Jan 10 17:55:22 2011
From: report at bugs.python.org (Yuriy)
Date: Mon, 10 Jan 2011 16:55:22 +0000
Subject: [issue10880] do_mkvalue and 'boolean'
In-Reply-To: <1294678522.28.0.674271875959.issue10880@psf.upfronthosting.co.za>
Message-ID: <1294678522.28.0.674271875959.issue10880@psf.upfronthosting.co.za>


New submission from Yuriy <irov13 at mail.ru>:

If a value created by Py_VaBuildValue and parameter "b" is transfered - a PyLong_Type value is returned despite of the fact that it would be reasonable if PyBool_Type were returned. Are there any reasons for this?

modsupport.c Ln 214

----------
messages: 125903
nosy: IROV
priority: normal
severity: normal
status: open
title: do_mkvalue and 'boolean'
type: behavior
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10880>
_______________________________________

From report at bugs.python.org  Mon Jan 10 18:04:37 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 10 Jan 2011 17:04:37 +0000
Subject: [issue10866] Add sethostname()
In-Reply-To: <1294474577.93.0.97800635081.issue10866@psf.upfronthosting.co.za>
Message-ID: <1294679077.71.0.541792454479.issue10866@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +pitrou
stage:  -> patch review
type:  -> feature request

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10866>
_______________________________________

From report at bugs.python.org  Mon Jan 10 18:05:04 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 10 Jan 2011 17:05:04 +0000
Subject: [issue10880] do_mkvalue and 'boolean'
In-Reply-To: <1294678522.28.0.674271875959.issue10880@psf.upfronthosting.co.za>
Message-ID: <1294679104.95.0.268403770597.issue10880@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

What makes you think it should be a boolean?
in http://docs.python.org/py3k/c-api/arg.html#Py_BuildValue "b" means "byte" and is processed as a tiny integer.

Now, that's true that Py_BuildValue could have a format for boolean values.  Maybe with a "?" parameter?

----------
nosy: +amaury.forgeotdarc
type: behavior -> feature request

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10880>
_______________________________________

From report at bugs.python.org  Mon Jan 10 18:36:11 2011
From: report at bugs.python.org (Daniel Urban)
Date: Mon, 10 Jan 2011 17:36:11 +0000
Subject: [issue10868] ABCMeta.register() should work as a decorator
In-Reply-To: <1294529533.15.0.442078735636.issue10868@psf.upfronthosting.co.za>
Message-ID: <1294680971.94.0.695069513576.issue10868@psf.upfronthosting.co.za>


Daniel Urban <urban.dani+py at gmail.com> added the comment:

There is another return statement earlier in the ABCMeta.register method. The patch probably should also modify that.

----------
nosy: +durban

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10868>
_______________________________________

From report at bugs.python.org  Mon Jan 10 18:37:29 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 10 Jan 2011 17:37:29 +0000
Subject: [issue10225] Fix doctest runable examples in python manual
In-Reply-To: <1294606370.8.0.33298496606.issue10225@psf.upfronthosting.co.za>
Message-ID: <AANLkTintK_9ueQ4=632FsqO_TDCNue+qWe7oUB4xFmmJ@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Sun, Jan 9, 2011 at 3:52 PM, Terry J. Reedy <report at bugs.python.org> wrote:
> .. It would be nice to get the fixes into 3.2.

Yes, it would be nice, but I don't have a 3.2 patch (yet).  As you can
see from my last comment, I ran into a bug in the alpha version of
sphinx that I used to validate py3k docs.

> What sort of feedback do you want? Proofreading of text? Recheck of doctest?
>

All of the above.  Some of the fixes may be at the expense of
readability.   I would appreciate feedback in the instances when human
and computer reader's interests are in conflict.   Some examples are
"fixed" by excluding them from being checked.  Better ideas are
welcome.

> Does sphinx suppress doctest comments like
> ? ? #doctest: +IGNORE_EXCEPTION_DETAIL
> ?

Yes.

>
> doctest.testfile("C:/programs/PyDev/py32/Doc/howto/sorting.rst", module_relative = False)
> fails 23 of 37 attempts, so improvement is needed ;-).

You cannot run documentation examples with a plain doctest.   You have
to use sphinx-build.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10225>
_______________________________________

From report at bugs.python.org  Mon Jan 10 18:51:17 2011
From: report at bugs.python.org (Edoardo Spadolini)
Date: Mon, 10 Jan 2011 17:51:17 +0000
Subject: [issue10868] ABCMeta.register() should work as a decorator
In-Reply-To: <1294529533.15.0.442078735636.issue10868@psf.upfronthosting.co.za>
Message-ID: <1294681877.78.0.720944241322.issue10868@psf.upfronthosting.co.za>


Edoardo Spadolini <kerio00 at gmail.com> added the comment:

Whoops, corrected that - should I add some more tests for that too?

----------
nosy:  -benjamin.peterson, durban, eric.araujo, gvanrossum, pitrou, rhettinger
Added file: http://bugs.python.org/file20335/abcmeta_register_v4.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10868>
_______________________________________

From report at bugs.python.org  Mon Jan 10 18:51:53 2011
From: report at bugs.python.org (Edoardo Spadolini)
Date: Mon, 10 Jan 2011 17:51:53 +0000
Subject: [issue10868] ABCMeta.register() should work as a decorator
In-Reply-To: <1294529533.15.0.442078735636.issue10868@psf.upfronthosting.co.za>
Message-ID: <1294681913.36.0.351119561008.issue10868@psf.upfronthosting.co.za>


Changes by Edoardo Spadolini <kerio00 at gmail.com>:


----------
nosy: +benjamin.peterson, durban, eric.araujo, gvanrossum, pitrou, rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10868>
_______________________________________

From report at bugs.python.org  Mon Jan 10 18:55:29 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 10 Jan 2011 17:55:29 +0000
Subject: [issue10784] os.getpriority() and os.setpriority()
In-Reply-To: <1293500810.54.0.0610321482452.issue10784@psf.upfronthosting.co.za>
Message-ID: <1294682129.0.0.13569172697.issue10784@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

You should use begin/end allow threads when the system call might block. To get an indication, trace through the kernel code of some system; my guess is that these are typically non-blocking (i.e. return immediately) - but I might be wrong.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10784>
_______________________________________

From report at bugs.python.org  Mon Jan 10 18:57:34 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 10 Jan 2011 17:57:34 +0000
Subject: [issue10868] ABCMeta.register() should work as a decorator
In-Reply-To: <1294529533.15.0.442078735636.issue10868@psf.upfronthosting.co.za>
Message-ID: <1294682254.48.0.620229120757.issue10868@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

You should, otherwise how would you prove it?s fixed? :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10868>
_______________________________________

From report at bugs.python.org  Mon Jan 10 19:01:27 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 10 Jan 2011 18:01:27 +0000
Subject: [issue2320] Race condition in subprocess using stdin
In-Reply-To: <1205760712.39.0.906940637593.issue2320@psf.upfronthosting.co.za>
Message-ID: <1294682487.51.0.723525188699.issue2320@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I confirm that it works reliably under 3.2, while it hangs as reliably under 2.7 and 3.1. Since fixing involves a C extension that is too heavy to backport to bugfix branches, I suggest closing.

By the way: triagers, please don't set stage to "unit test needed". We don't need an unit test before a proper decision about the issue has been done, and actually we don't require reporters to write an unit test either (it's done as part of the patch, usually).

----------
nosy: +pitrou
resolution:  -> out of date
stage: unit test needed -> 
status: open -> pending
versions: +Python 3.1 -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2320>
_______________________________________

From report at bugs.python.org  Mon Jan 10 19:55:28 2011
From: report at bugs.python.org (Yuriy)
Date: Mon, 10 Jan 2011 18:55:28 +0000
Subject: [issue10880] do_mkvalue and 'boolean'
In-Reply-To: <1294678522.28.0.674271875959.issue10880@psf.upfronthosting.co.za>
Message-ID: <1294685728.25.0.884134495554.issue10880@psf.upfronthosting.co.za>


Yuriy <irov13 at mail.ru> added the comment:

Thank you, how is it possible to ask the developers to add such a flag?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10880>
_______________________________________

From report at bugs.python.org  Mon Jan 10 19:58:03 2011
From: report at bugs.python.org (Edoardo Spadolini)
Date: Mon, 10 Jan 2011 18:58:03 +0000
Subject: [issue10868] ABCMeta.register() should work as a decorator
In-Reply-To: <1294529533.15.0.442078735636.issue10868@psf.upfronthosting.co.za>
Message-ID: <1294685883.05.0.821639918123.issue10868@psf.upfronthosting.co.za>


Edoardo Spadolini <kerio00 at gmail.com> added the comment:

Fair enough :)

----------
Added file: http://bugs.python.org/file20336/abcmeta_register_v4_plus_tests.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10868>
_______________________________________

From report at bugs.python.org  Mon Jan 10 20:04:45 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 10 Jan 2011 19:04:45 +0000
Subject: [issue2568] Seconds range in time unit
In-Reply-To: <1207551193.66.0.586350051723.issue2568@psf.upfronthosting.co.za>
Message-ID: <1294686285.01.0.803262339814.issue2568@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

The C89 draft as available through a Wikipedia link, http://flash-gordon.me.uk/ansi.c.txt, specifies tm_sec range as [0, 60].  Although it looks like the range has been extended in the published version.  A discussion on comp.std.c describes the situation as follows:

"""

The "double leap second" is complete nonsense. It never existed outside the 
ANSI C standard and never will. It was introduced by the ANSI C 89 committee 
to document its problems understanding UTC issues. Someone heard that there 
are two prefered dates for leap seconds per year and this got munched up to 
the false rumour that UTC days can be up to 86402 seconds long. The 
definition of UTC, which requires that |UTC-UT1| < 0.9 s all the time, 
obviously makes double leap seconds mathematically impossible. 
"""

The latest publicly available standard that I was able to find that specifies [0, 61] range was "The Single UNIX ? Specification, Version 2" from 1997: http://pubs.opengroup.org/onlinepubs/007908799/xsh/time.h.html

Note that this range has been recognized as a mistake by Open Group:

"""
Problem:

 The valid range of seconds is no longer 0-61, a range chosen
 to accomodate the mythical double leap second.

 The correct range is 0-60 seconds.

 This has been fixed elsewhere in 1003.1-200x already.  See for
 instance <time.h>.

 Action:

 Change range to 00-60 seconds.

 Search for any other places where the range is wrongly given as 0-61
 and fix them too.
 [Ed recommendation: Accept as marked
 make the change , and add a note to the CH
 that
 The description of %S is updated so the valid range is 00-60 rather
 than 00-61.

 A search was done of the draft for other occurrences of 61 and none
 found.  ]
"""  http://www.opengroup.org/austin/docs/austin_77r1.txt

Compliance with the mistakes in old versions of various standards, does not seem like a valid goal for Python, but until a system is reported that misbehaves when tm_sec = 61 is passed to strftime, I don't see a compelling reason to change Python behavior.  On the other hand, the documentation should not refer to bogus standards, so I suggest to change 

"""
The range really is 0 to 61; according to the Posix standard this accounts for leap seconds and the (very rare) double leap seconds. The time module may produce and does accept leap seconds since it is based on the Posix standard ...
"""

to 

"""
The range really is 0 to 61; tm_sec = 60 may be necessary to represent an occasional leap second and tm_sec = 61 is supported for historical reasons.
"""

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2568>
_______________________________________

From report at bugs.python.org  Mon Jan 10 20:07:43 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 10 Jan 2011 19:07:43 +0000
Subject: [issue10880] do_mkvalue and 'boolean'
In-Reply-To: <1294678522.28.0.674271875959.issue10880@psf.upfronthosting.co.za>
Message-ID: <1294686463.62.0.758605725204.issue10880@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

This is the right place to ask... but it will be faster if someone provides a patch.

----------
keywords: +easy
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10880>
_______________________________________

From report at bugs.python.org  Mon Jan 10 20:23:42 2011
From: report at bugs.python.org (Edoardo Spadolini)
Date: Mon, 10 Jan 2011 19:23:42 +0000
Subject: [issue10868] ABCMeta.register() should work as a decorator
In-Reply-To: <1294529533.15.0.442078735636.issue10868@psf.upfronthosting.co.za>
Message-ID: <1294687422.09.0.34071815507.issue10868@psf.upfronthosting.co.za>


Changes by Edoardo Spadolini <kerio00 at gmail.com>:


Removed file: http://bugs.python.org/file20336/abcmeta_register_v4_plus_tests.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10868>
_______________________________________

From report at bugs.python.org  Mon Jan 10 20:25:13 2011
From: report at bugs.python.org (Edoardo Spadolini)
Date: Mon, 10 Jan 2011 19:25:13 +0000
Subject: [issue10868] ABCMeta.register() should work as a decorator
In-Reply-To: <1294529533.15.0.442078735636.issue10868@psf.upfronthosting.co.za>
Message-ID: <1294687513.88.0.0075851330349.issue10868@psf.upfronthosting.co.za>


Changes by Edoardo Spadolini <kerio00 at gmail.com>:


Added file: http://bugs.python.org/file20337/abcmeta_register_v4_plus_tests.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10868>
_______________________________________

From report at bugs.python.org  Mon Jan 10 20:33:54 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 10 Jan 2011 19:33:54 +0000
Subject: [issue10868] ABCMeta.register() should work as a decorator
In-Reply-To: <1294685883.05.0.821639918123.issue10868@psf.upfronthosting.co.za>
Message-ID: <4D2B5F1C.7090608@netwok.org>


?ric Araujo <merwok at netwok.org> added the comment:

-            return  # Already a subclass
+            return subclass # Already a subclass
PEP 8 advises to put two spaces before inline comments, for readability.
 (There is no need to upload a new patch, I?ll change that before commit.)

+        self.assertIsInstahce(c, (A,))
This is fixed in the newest version of your patch.  Running tests before
uploading diffs catches such errors :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10868>
_______________________________________

From report at bugs.python.org  Mon Jan 10 20:36:53 2011
From: report at bugs.python.org (Stephen Hansen)
Date: Mon, 10 Jan 2011 19:36:53 +0000
Subject: [issue10820] 3.2 Makefile changes for versioned scripts break OS X
	framework installs
In-Reply-To: <1294125537.03.0.564909640075.issue10820@psf.upfronthosting.co.za>
Message-ID: <1294688213.87.0.265907624458.issue10820@psf.upfronthosting.co.za>


Stephen Hansen <me+python at ixokai.io> added the comment:

FYI, The patch applied cleanly to branches/py3k; I then built a framework build (universal), installed it and ran the test-suite.

I had two failures, but I don't know if either is related. The first was the tk tests didn't pass, but I'm not sure if there was something special I need to do to get tk compiled universal in a framework build-- I'll look into it.

But this one perplexes me:


Wimp:build pythonbuildbot$ ./python.exe -m test.regrtest test_site
[1/1] test_site
test test_site failed -- Traceback (most recent call last):
  File "/Users/pythonbuildbot/32test/build/Lib/test/test_site.py", line 225, in test_getsitepackages
    self.assertEqual(len(dirs), 2)
AssertionError: 3 != 2

1 test failed:
    test_site
Wimp:build pythonbuildbot$ ./python.exe
Python 3.2b2+ (py3k:87899M, Jan 10 2011, 11:08:48) 
[GCC 4.0.1 (Apple Inc. build 5493)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import site
>>> site.getsitepackages()
['/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/site-packages', '/Library/Frameworks/Python.framework/Versions/3.2/lib/site-python', '/Library/Python/3.2/site-packages']

This machine fwiw never had any Python 3.x installed anywhere: in fact it was an almost pure stock 10.5 with buildbots put on it.

----------
nosy: +ixokai

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10820>
_______________________________________

From report at bugs.python.org  Mon Jan 10 20:43:00 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 10 Jan 2011 19:43:00 +0000
Subject: [issue10820] 3.2 Makefile changes for versioned scripts break OS X
	framework installs
In-Reply-To: <1294125537.03.0.564909640075.issue10820@psf.upfronthosting.co.za>
Message-ID: <1294688580.9.0.974932019787.issue10820@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Looks like an issue in test_site rather than site.py itself (which has dedicated code to add a third site directory under framework builds). The test_site failure is not enough to hold the release, IMO.

Given Ronald's absence, I think Ned could start exercising his commit rights on this one. Ned, you'll need to write a Misc/NEWS entry in the "build" section (reverse chronological order). And an appropriate commit message. I think you'll figure out the (loose) typographical conventions :-)

----------
assignee: ronaldoussoren -> ned.deily
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10820>
_______________________________________

From report at bugs.python.org  Mon Jan 10 20:52:38 2011
From: report at bugs.python.org (Ned Deily)
Date: Mon, 10 Jan 2011 19:52:38 +0000
Subject: [issue10820] 3.2 Makefile changes for versioned scripts break OS X
	framework installs
In-Reply-To: <1294125537.03.0.564909640075.issue10820@psf.upfronthosting.co.za>
Message-ID: <1294689158.44.0.0187829657238.issue10820@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Thanks for trying a build.  There are various tk test failures possible depending on what version of Tcl/Tk is or isn't installed, so I wouldn't be concerned about them.  The test_site failure is also not new. It is documented in re-opened Issue8084.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10820>
_______________________________________

From report at bugs.python.org  Mon Jan 10 20:54:07 2011
From: report at bugs.python.org (Stephen Hansen)
Date: Mon, 10 Jan 2011 19:54:07 +0000
Subject: [issue10881] test_site and macframework builds fails
In-Reply-To: <1294689247.64.0.100970558273.issue10881@psf.upfronthosting.co.za>
Message-ID: <1294689247.64.0.100970558273.issue10881@psf.upfronthosting.co.za>


New submission from Stephen Hansen <me+python at ixokai.io>:

With the latest from branches/py3k, in a framework build, I get:

Wimp:build pythonbuildbot$ ./python.exe -m test.regrtest test_site
[1/1] test_site
test test_site failed -- Traceback (most recent call last):
  File "/Users/pythonbuildbot/32test/build/Lib/test/test_site.py", line 225, in test_getsitepackages
    self.assertEqual(len(dirs), 2)
AssertionError: 3 != 2

1 test failed:
    test_site
Wimp:build pythonbuildbot$ ./python.exe
Python 3.2b2+ (py3k:87899M, Jan 10 2011, 11:08:48) 
[GCC 4.0.1 (Apple Inc. build 5493)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import site
>>> site.getsitepackages()
['/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/site-packages', '/Library/Frameworks/Python.framework/Versions/3.2/lib/site-python', '/Library/Python/3.2/site-packages']

Those three dirs look correct for me, but the test is written to find exactly two from site.getsitepackages() -- the code, however, adds an extra in the event of framework builds.

----------
assignee: ronaldoussoren
components: Macintosh, Tests
messages: 125919
nosy: ixokai, ronaldoussoren
priority: normal
severity: normal
status: open
title: test_site and macframework builds fails
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10881>
_______________________________________

From report at bugs.python.org  Mon Jan 10 20:55:05 2011
From: report at bugs.python.org (Stephen Hansen)
Date: Mon, 10 Jan 2011 19:55:05 +0000
Subject: [issue10881] test_site and macframework builds fails
In-Reply-To: <1294689247.64.0.100970558273.issue10881@psf.upfronthosting.co.za>
Message-ID: <1294689305.52.0.36074950667.issue10881@psf.upfronthosting.co.za>


Stephen Hansen <me+python at ixokai.io> added the comment:

... oops! Apparently dupe. Forgot to search first. Ignore.

----------
resolution:  -> duplicate
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10881>
_______________________________________

From report at bugs.python.org  Mon Jan 10 20:56:33 2011
From: report at bugs.python.org (Glenn Linderman)
Date: Mon, 10 Jan 2011 19:56:33 +0000
Subject: [issue4953] cgi module cannot handle POST with multipart/form-data
	in	3.0
In-Reply-To: <1232010166.79.0.972664060868.issue4953@psf.upfronthosting.co.za>
Message-ID: <1294689393.37.0.610002357844.issue4953@psf.upfronthosting.co.za>


Glenn Linderman <v+python at g.nevcal.com> added the comment:

Victor said:
Don't you think that a warning would be appropriate if sys.stdin is passed 
here?
---
        # self.fp.read() must return bytes
        if isinstance(fp,TextIOBase):
            self.fp = fp.buffer
        else:
            self.fp = fp
---
Maybe a DeprecationWarning if we would like to drop support of TextIOWrapper 
later :-)

I say:
I doubt we ever want to Deprecate the use of "plain stdin" as the default (or as an explicit) parameter for FieldStorage's fp parameter.  Most usage of FieldStorage will want to use stdin; if FieldStorage detects that stdin is TextIOBase (generally it is) and uses its buffer to get binary data, that is very convenient for the typical CGI application.  I think I agree with the rest of your comments.

Etienne said:
is sendfile() available on Windows ? i thought the Apache server could
use that to upload files without having to buffer files in memory..

I say:
I don't think it is called that, but similar functionality may be available on Windows under another name.  I don't know if Apache uses it or not.  But I have no idea how FieldStorage could interact with Apache via the CGI interface, to access such features.  I'm unaware of any APIs Apache provides for that purpose, but if there are some, let me know.  On the other hand, there are other HTTP servers besides Apache to think about. 

I'm also not sure if sendfile() or equivalent, is possible to use from within FieldStorage, because it seems in practice we don't know the size of the uploaded file without parsing it (which requires buffering it in memory to look at it).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4953>
_______________________________________

From report at bugs.python.org  Mon Jan 10 20:58:40 2011
From: report at bugs.python.org (Ross Lagerwall)
Date: Mon, 10 Jan 2011 19:58:40 +0000
Subject: [issue10822] test_getgroups failure under Solaris
In-Reply-To: <1294139319.03.0.190267830849.issue10822@psf.upfronthosting.co.za>
Message-ID: <1294689520.18.0.420419587619.issue10822@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/issue10822>
_______________________________________

From report at bugs.python.org  Mon Jan 10 20:59:35 2011
From: report at bugs.python.org (Ned Deily)
Date: Mon, 10 Jan 2011 19:59:35 +0000
Subject: [issue10820] 3.2 Makefile changes for versioned scripts break OS X
	framework installs
In-Reply-To: <1294125537.03.0.564909640075.issue10820@psf.upfronthosting.co.za>
Message-ID: <1294689575.58.0.317961847387.issue10820@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

(BTW, I was planning to see what we could do about Issue8084 before release anyway.  I'll get on it.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10820>
_______________________________________

From report at bugs.python.org  Mon Jan 10 21:02:45 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 10 Jan 2011 20:02:45 +0000
Subject: [issue10784] os.getpriority() and os.setpriority()
In-Reply-To: <1293500810.54.0.0610321482452.issue10784@psf.upfronthosting.co.za>
Message-ID: <1294689765.48.0.0600105633705.issue10784@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/issue10784>
_______________________________________

From report at bugs.python.org  Mon Jan 10 21:17:20 2011
From: report at bugs.python.org (Glenn Linderman)
Date: Mon, 10 Jan 2011 20:17:20 +0000
Subject: [issue10879] cgi memory usage
In-Reply-To: <1294648490.09.0.987257947586.issue10879@psf.upfronthosting.co.za>
Message-ID: <1294690640.72.0.944923816111.issue10879@psf.upfronthosting.co.za>


Glenn Linderman <v+python at g.nevcal.com> added the comment:

R. David said:
However, I'm not clear on how that helps.  Doesn't FieldStorage also load everything into memory?

I say:
FieldStorage in 2.x (for x <= 6, at least) copies incoming file data to a file, using limited size read/write operations.  Non-file data is buffered in memory.

In 3.x, FieldStorage doesn't work.  The code that is there, though, for multipart/ data, would call email to do all the parsing, which would happen to include file data, which always comes in as part of a multipart/ data stream.  This would prevent cgi from being used to accept large files in a limited environment.  Sadly, there is code is place that would the copy the memory buffers to files, and act like they were buffered... but process limits do not care that the memory usage is only temporary...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10879>
_______________________________________

From report at bugs.python.org  Mon Jan 10 21:27:49 2011
From: report at bugs.python.org (Ross Lagerwall)
Date: Mon, 10 Jan 2011 20:27:49 +0000
Subject: [issue10882] Add os.sendfile()
In-Reply-To: <1294691268.76.0.727179568007.issue10882@psf.upfronthosting.co.za>
Message-ID: <1294691268.76.0.727179568007.issue10882@psf.upfronthosting.co.za>


New submission from Ross Lagerwall <rosslagerwall at gmail.com>:

Attached is a patch which implements os.sendfile for unix systems (linux, freebsd, apple, solaris, dragonfly).

It takes the iov initialization code and off_t parsing from i10812.

It encapsulates all the functionality from the various sendfiles which means a fair amount of #ifdefs but the basic case works for all of them.

Tested on Linux & FreeBSD - it should work on solaris but since it needs to link with the sendfile library and I have no idea how to link the posix module with the sendfile library only on Solaris, i couldn't test it. If someone could please contribute this...

I think it might be possible to get a Windows equivalent of this - i'll leave it for someone else to do ;-)

----------
components: Extension Modules
files: sendfile.patch
keywords: patch
messages: 125924
nosy: giampaolo.rodola, loewis, pitrou, rosslagerwall
priority: normal
severity: normal
status: open
title: Add os.sendfile()
type: feature request
versions: Python 3.3
Added file: http://bugs.python.org/file20338/sendfile.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10882>
_______________________________________

From report at bugs.python.org  Mon Jan 10 21:28:40 2011
From: report at bugs.python.org (Yuriy)
Date: Mon, 10 Jan 2011 20:28:40 +0000
Subject: [issue10880] do_mkvalue and 'boolean'
In-Reply-To: <1294678522.28.0.674271875959.issue10880@psf.upfronthosting.co.za>
Message-ID: <1294691320.54.0.318088138891.issue10880@psf.upfronthosting.co.za>


Yuriy <irov13 at mail.ru> added the comment:

case 'g':
		{
			int n;
			n = va_arg(*p_va, int);

			if (n == 0)
				Py_RETURN_FALSE;
			else
				Py_RETURN_TRUE;
		}

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10880>
_______________________________________

From report at bugs.python.org  Mon Jan 10 21:30:14 2011
From: report at bugs.python.org (Pierre Quentel)
Date: Mon, 10 Jan 2011 20:30:14 +0000
Subject: [issue4953] cgi module cannot handle POST with multipart/form-data
	in	3.0
In-Reply-To: <1232010166.79.0.972664060868.issue4953@psf.upfronthosting.co.za>
Message-ID: <1294691414.72.0.504336637614.issue4953@psf.upfronthosting.co.za>


Pierre Quentel <pierre.quentel at gmail.com> added the comment:

@Glenn
"Also, the use of FeedParser could be replaced by BytesFeedParser, thus eliminating the need to decode header lines in that loop."

BytesFeedParser only uses the ascii codec ; if the header has non ASCII characters (filename in a multipart/form-data), they are replaced by ? : the original file name is lost. So for the moment I leave the text version of FeedParser

@Victor :
"you should use qs.encode(locale.getpreferredencoding(), 'surrogateescape')"
Ok, I changed the code to that

"Maybe a DeprecationWarning if we would like to drop support of TextIOWrapper later :-)"
Maybe I'm missing something here, but sys.stdin is always a TextIOWrapper instance, even if set to binary mode

"For the else case: you should maybe add a strict test on the type, eg. check for RawIOBase or BufferedIOBase subclass, isinstance(fp, (io.RawIOBase, io.BufferedIOBase)). It would avoid to check that fp.read() returns a bytes object (or get an ugly error later)."

Rejecting non-instances of RawIOBase or BufferedIOBase is too much, I think. Any class whose instances have a read() method that return bytes should be accepted, like the TestReadLine class in test_cgi.py

"Set sys.stdin.buffer.encoding attribute is not a good idea. Why do you modify fp, instead of using a separated attribute on FieldStorage (eg. self.fp_encoding)?"

I set an attribute encoding to self.fp because, for each part of a multipart/form-data, a new instance of FieldStorage is created, and this instance needs to know how to decode bytes. So, either an attribute must be set to one of the arguments of the FieldStorage constructor, and fp comes to mind, or an extra argument has to be passed to this constructor, i.e. the encoding of the original stream

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4953>
_______________________________________

From report at bugs.python.org  Mon Jan 10 21:40:16 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 10 Jan 2011 20:40:16 +0000
Subject: [issue10882] Add os.sendfile()
In-Reply-To: <1294691268.76.0.727179568007.issue10882@psf.upfronthosting.co.za>
Message-ID: <1294692016.12.0.685676791125.issue10882@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Tested on Linux & FreeBSD - it should work on solaris but since it
> needs to link with the sendfile library and I have no idea how to link 
> the posix module with the sendfile library only on Solaris, i couldn't 
> test it.

Since the posix module is linked statically inside the interpreter, it probably needs some change in the base ldflags. I'll take a look when I have some time.

----------
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10882>
_______________________________________

From report at bugs.python.org  Mon Jan 10 21:41:19 2011
From: report at bugs.python.org (Glenn Linderman)
Date: Mon, 10 Jan 2011 20:41:19 +0000
Subject: [issue4953] cgi module cannot handle POST with multipart/form-data
	in	3.0
In-Reply-To: <1232010166.79.0.972664060868.issue4953@psf.upfronthosting.co.za>
Message-ID: <1294692079.01.0.921101619537.issue4953@psf.upfronthosting.co.za>


Glenn Linderman <v+python at g.nevcal.com> added the comment:

Victor said:
"Set sys.stdin.buffer.encoding attribute is not a good idea. Why do you modify fp, instead of using a separated attribute on FieldStorage (eg. self.fp_encoding)?"

Pierre said:
I set an attribute encoding to self.fp because, for each part of a multipart/form-data, a new instance of FieldStorage is created, and this instance needs to know how to decode bytes. So, either an attribute must be set to one of the arguments of the FieldStorage constructor, and fp comes to mind, or an extra argument has to be passed to this constructor, i.e. the encoding of the original stream

I say:
Ah, now I understand why you did it that way, but:

The RFC 2616 says the CGI stream is ISO-8859-1 (or latin-1).  The _defined_ encoding of the original stream is irrelevant, in the same manner that if it is a text stream, that is irrelevant.  The stream is binary, and latin-1, or it is non-standard.  Hence, there is not any reason to need a parameter, just use latin-1. If non-standard streams are to be supported, I suppose that would require a parameter, but I see no need to support non-standard streams: it is hard enough to support standard streams without complicating things.  The encoding provided with stdin is reasonably unlikely to be latin-1: Linux defaults to UTF-8 (at least on many distributions), and Windows to CP437, and in either case is configurable by the sysadmin.  But even the sysadmin should not be expected to configure the system locale to have latin-1 as the default encoding for the system, just because one of the applications that might run is an CGI program.  So I posit that the encoding on fp is irrelevant and should be ignored, and using it as a parameter between FieldStorage instances is neither appropriate nor necessary, as the standard defines latin-1 as the encoding for the stream.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4953>
_______________________________________

From report at bugs.python.org  Mon Jan 10 22:01:35 2011
From: report at bugs.python.org (Barry A. Warsaw)
Date: Mon, 10 Jan 2011 21:01:35 +0000
Subject: [issue5871] email.header.Header too lax with embeded newlines
In-Reply-To: <1240953937.2.0.828159818097.issue5871@psf.upfronthosting.co.za>
Message-ID: <1294693295.87.0.945714514547.issue5871@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

I'm inclined not to support backporting to Python 2.6.  It seems like a fairly rare and narrow hole for security problem, because it would require a program to add the bogus header explicitly, as opposed to getting it after parsing some data.  To me, that smacks of SQL-injection or XSS type bug, where it's really the application that's the problem.

Or in other words, assuming you don't have a program that is deliberately adding such headers (and then it should be considered a feature, i.e. they know what they're doing), then you'd have to trick a header-adding program to add some unvalidated text.

I dunno, it doesn't seem like a serious enough threat to backport.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5871>
_______________________________________

From report at bugs.python.org  Mon Jan 10 22:11:51 2011
From: report at bugs.python.org (R. David Murray)
Date: Mon, 10 Jan 2011 21:11:51 +0000
Subject: [issue4953] cgi module cannot handle POST with multipart/form-data
	in	3.0
In-Reply-To: <1232010166.79.0.972664060868.issue4953@psf.upfronthosting.co.za>
Message-ID: <1294693911.99.0.780001523465.issue4953@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I don't have time to review the patch or even respond in detail to the comments right now, but I do want to respond about BytesFeedParser.  It is true that there is currently no interface to get the raw-bytes version of the header back out of the Message object, even though it still has it when constructed via BytesFeedParser.  This is an API oversight that needs to be rectified.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4953>
_______________________________________

From report at bugs.python.org  Mon Jan 10 22:13:55 2011
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 10 Jan 2011 21:13:55 +0000
Subject: [issue4953] cgi module cannot handle POST with multipart/form-data
	in	3.0
In-Reply-To: <1232010166.79.0.972664060868.issue4953@psf.upfronthosting.co.za>
Message-ID: <1294694035.35.0.907381077453.issue4953@psf.upfronthosting.co.za>


Changes by Guido van Rossum <guido at python.org>:


----------
nosy:  -gvanrossum

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4953>
_______________________________________

From report at bugs.python.org  Mon Jan 10 22:29:00 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 10 Jan 2011 21:29:00 +0000
Subject: [issue4953] cgi module cannot handle POST with multipart/form-data
	in	3.0
In-Reply-To: <1232010166.79.0.972664060868.issue4953@psf.upfronthosting.co.za>
Message-ID: <1294694940.22.0.320017538896.issue4953@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> I set an attribute encoding to self.fp because, for each part 
> of a multipart/form-data, a new instance of FieldStorage is created,
> and this instance needs to know how to decode bytes.

Set fp.encoding may raise an error (eg. for a read-only object, or an object implemented in C). You should add a new argument to the constructor.

> Maybe I'm missing something here, but sys.stdin is always
> a TextIOWrapper instance, even if set to binary mode

I mean: you should pass sys.stdin.buffer instead of sys.stdin.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4953>
_______________________________________

From report at bugs.python.org  Mon Jan 10 22:32:36 2011
From: report at bugs.python.org (R. David Murray)
Date: Mon, 10 Jan 2011 21:32:36 +0000
Subject: [issue5871] email.header.Header too lax with embeded newlines
In-Reply-To: <1240953937.2.0.828159818097.issue5871@psf.upfronthosting.co.za>
Message-ID: <1294695156.48.0.277466261683.issue5871@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Well, imagine a web form that has a 'subject' text entry field, and the application does Message['Subject'] = subject_from_form as it builds a Message to hand off to smtp.sendmail.  If the application didn't sanitize the subject for newlines (and as a programmer I doubt I would have thought of doing that), then we can have header injection.  So, yes, it is analogous to an sql injection attack.

Since we don't have a report of an exploit, I'm fine with not backporting it.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5871>
_______________________________________

From report at bugs.python.org  Mon Jan 10 22:37:12 2011
From: report at bugs.python.org (R. David Murray)
Date: Mon, 10 Jan 2011 21:37:12 +0000
Subject: [issue5871] email.header.Header too lax with embeded newlines
In-Reply-To: <1240953937.2.0.828159818097.issue5871@psf.upfronthosting.co.za>
Message-ID: <1294695432.65.0.473101293578.issue5871@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Ah, I should clarify.  A sensible web application should be dealing with any multiline input it allows by turning it into a newline-less single line before using it as a subject, so the probability that there are exploitable applications out there is, I think, sufficiently low that a backport isn't needed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5871>
_______________________________________

From report at bugs.python.org  Mon Jan 10 22:48:46 2011
From: report at bugs.python.org (Charles-Francois Natali)
Date: Mon, 10 Jan 2011 21:48:46 +0000
Subject: [issue10394] subprocess Popen deadlock
In-Reply-To: <1289570708.02.0.0744739807294.issue10394@psf.upfronthosting.co.za>
Message-ID: <1294696126.5.0.0433647356239.issue10394@psf.upfronthosting.co.za>


Charles-Francois Natali <neologix at free.fr> added the comment:

It's now fixed in py3k, FD_CLOEXEC is set atomically (using pipe2 if available, otherwise it still has the GIL protection). See http://svn.python.org/view?view=rev&revision=87207

----------
nosy: +neologix, pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10394>
_______________________________________

From report at bugs.python.org  Mon Jan 10 22:49:17 2011
From: report at bugs.python.org (Stephen Hansen)
Date: Mon, 10 Jan 2011 21:49:17 +0000
Subject: [issue10881] test_site and macframework builds fails
In-Reply-To: <1294689247.64.0.100970558273.issue10881@psf.upfronthosting.co.za>
Message-ID: <1294696157.41.0.602786292357.issue10881@psf.upfronthosting.co.za>


Changes by Stephen Hansen <me+python at ixokai.io>:


----------
superseder:  -> pep-0370 on osx duplicates existing functionality

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10881>
_______________________________________

From report at bugs.python.org  Mon Jan 10 22:56:07 2011
From: report at bugs.python.org (Pierre Quentel)
Date: Mon, 10 Jan 2011 21:56:07 +0000
Subject: [issue4953] cgi module cannot handle POST with multipart/form-data
	in	3.0
In-Reply-To: <1232010166.79.0.972664060868.issue4953@psf.upfronthosting.co.za>
Message-ID: <1294696567.45.0.198907232103.issue4953@psf.upfronthosting.co.za>


Pierre Quentel <pierre.quentel at gmail.com> added the comment:

@Glenn
" The _defined_ encoding of the original stream is irrelevant, in the same manner that if it is a text stream, that is irrelevant.  The stream is binary, and latin-1, or it is non-standard"

I wish it could be as simple, but I'm afraid it's not. On my PC, sys.stdin.encoding is cp-1252. I tested a multipart/form-data with an INPUT field, and I entered the euro character, which is encoded  \x80 in cp-1252

If I use the encoding defined for sys.stdin (cp-1252) to decode the bytes received on sys.stdin.buffer, I get the correct value in the cgi script ; if I set the encoding to latin-1 in FieldStorage, since \x80 maps to undefined in latin-1, I get a UnicodeEncodeError if I try to print the value ("character maps to <undefined>")

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4953>
_______________________________________

From report at bugs.python.org  Mon Jan 10 23:03:20 2011
From: report at bugs.python.org (Gregory P. Smith)
Date: Mon, 10 Jan 2011 22:03:20 +0000
Subject: [issue2320] Race condition in subprocess using stdin
In-Reply-To: <1205760712.39.0.906940637593.issue2320@psf.upfronthosting.co.za>
Message-ID: <1294697000.68.0.367429254805.issue2320@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

btw, I will be backporting all recent subprocess changes to http://code.google.com/p/python-subprocess32/

there have been a lot of changes recently, i was waiting for that to settle down before bring it up to current.  3.2rc1 sounds like a good time.

----------
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2320>
_______________________________________

From report at bugs.python.org  Mon Jan 10 23:08:37 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 10 Jan 2011 22:08:37 +0000
Subject: [issue8084] pep-0370 on osx duplicates existing functionality
In-Reply-To: <1267964951.32.0.7992829434.issue8084@psf.upfronthosting.co.za>
Message-ID: <1294697317.97.0.0993347818103.issue8084@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/issue8084>
_______________________________________

From report at bugs.python.org  Mon Jan 10 23:12:14 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 10 Jan 2011 22:12:14 +0000
Subject: [issue10394] subprocess Popen deadlock
In-Reply-To: <1289570708.02.0.0744739807294.issue10394@psf.upfronthosting.co.za>
Message-ID: <1294697534.68.0.748656135439.issue10394@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Ok, so let's close the issue. The fix can't reasonably be backported since it involves a whole new C extension and a rather large chunk of new code.

----------
nosy: +gregory.p.smith
resolution:  -> out of date
status: open -> closed
versions:  -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10394>
_______________________________________

From report at bugs.python.org  Mon Jan 10 23:15:09 2011
From: report at bugs.python.org (David-Sarah Hopwood)
Date: Mon, 10 Jan 2011 22:15:09 +0000
Subject: [issue1602] windows console doesn't print utf8 (Py30a2)
In-Reply-To: <1197453390.87.0.813702844893.issue1602@psf.upfronthosting.co.za>
Message-ID: <1294697709.54.0.22564631861.issue1602@psf.upfronthosting.co.za>


David-Sarah Hopwood <david-sarah at jacaranda.org> added the comment:

> The script unicode2.py uses the console STD_OUTPUT_HANDLE iff sys.stdout.fileno()==1.

You may have missed "if not_a_console(hStdout): real_stdout = False".
not_a_console uses GetFileType and GetConsoleMode to check whether that handle is directed to something other than a console.

> But is it always the case?

The technique used here for detecting a console is almost the same as the code for IsConsoleRedirected at http://blogs.msdn.com/b/michkap/archive/2010/05/07/10008232.aspx , or in WriteLineRight at http://blogs.msdn.com/b/michkap/archive/2010/04/07/9989346.aspx (I got it from that blog, can't remember exactly which page).

[This code will give a false positive in the strange corner case that stdout/stderr is redirected to a console *input* handle. It might be better to use GetConsoleScreenBufferInfo instead of GetConsoleMode, as suggested by http://stackoverflow.com/questions/3648711/detect-nul-file-descriptor-isatty-is-bogus/3650507#3650507 .]

> What about pythonw.exe?

I just tested that, using pythonw run from cmd.exe with stdout redirected to a file; it works as intended. It also works (for both console and non-console cases) when the handles are inherited from a parent process.

Incidentally, what's the earliest supported Windows version for Py3k? I see that http://www.python.org/download/windows/ mentions Windows ME. I can fairly easily make it fall back to never using WriteConsoleW on Windows ME, if that's necessary.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1602>
_______________________________________

From report at bugs.python.org  Mon Jan 10 23:16:04 2011
From: report at bugs.python.org (Ned Deily)
Date: Mon, 10 Jan 2011 22:16:04 +0000
Subject: [issue10820] 3.2 Makefile changes for versioned scripts break OS X
	framework installs
In-Reply-To: <1294125537.03.0.564909640075.issue10820@psf.upfronthosting.co.za>
Message-ID: <1294697764.82.0.00664175821948.issue10820@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Fixed in r87908.

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10820>
_______________________________________

From report at bugs.python.org  Mon Jan 10 23:18:39 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 10 Jan 2011 22:18:39 +0000
Subject: [issue1697943] msgfmt cannot cope with BOM
Message-ID: <1294697919.5.0.787147009984.issue1697943@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Extract of the Unicode standard: "Use of a BOM is neither required nor recommended for UTF-8, but may be encountered in contexts where UTF-8 data is converted from other encoding forms that use a BOM or where the BOM is used as a UTF-8 signature".

See also the following section explaing issues with UTF-8 BOM:
http://en.wikipedia.org/wiki/Byte_order_mark#UTF-8

I agree that Python should handle (UTF-8) BOM to read a CSV file (#7185), because the file format is common on Windows.

But msgfmt is an UNIX tool: I would expect that Python behaves like the original msgfmt tool, fail with a fatal error on the BOM "invisible character". How do you explain to a user msgfmt fails but not msgfmt.py?

About the patch: *ignore* the BOM is not a good idea. The BOM announces the encoding (eg. UTF-8): if a Content-Type header announces another encoding, you should raise an error.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1697943>
_______________________________________

From report at bugs.python.org  Mon Jan 10 23:19:50 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 10 Jan 2011 22:19:50 +0000
Subject: [issue1697943] msgfmt cannot cope with BOM
Message-ID: <1294697990.91.0.228497799817.issue1697943@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

See also issue #7651: "Python3: guess text file charset using the BOM".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1697943>
_______________________________________

From report at bugs.python.org  Mon Jan 10 23:22:59 2011
From: report at bugs.python.org (David-Sarah Hopwood)
Date: Mon, 10 Jan 2011 22:22:59 +0000
Subject: [issue1602] windows console doesn't print utf8 (Py30a2)
In-Reply-To: <1197453390.87.0.813702844893.issue1602@psf.upfronthosting.co.za>
Message-ID: <1294698179.99.0.135706672365.issue1602@psf.upfronthosting.co.za>


David-Sarah Hopwood <david-sarah at jacaranda.org> added the comment:

Note: Michael Kaplan's code checks whether GetConsoleMode failed due to ERROR_INVALID_HANDLE. My code intentionally doesn't do that, because it is correct and conservative to fall back to the non-console behaviour when there is *any* error from GetConsoleMode. (It could also fail due to not having the GENERIC_READ right on the handle, for example.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1602>
_______________________________________

From report at bugs.python.org  Mon Jan 10 23:25:16 2011
From: report at bugs.python.org (Reid Madsen)
Date: Mon, 10 Jan 2011 22:25:16 +0000
Subject: [issue9742] Python 2.7: math module fails to build on Solaris 9
In-Reply-To: <1283438135.42.0.361314007633.issue9742@psf.upfronthosting.co.za>
Message-ID: <1294698316.77.0.0898635590542.issue9742@psf.upfronthosting.co.za>


Reid Madsen <reid.madsen at tektronix.com> added the comment:

Python support,

This issue with not being able to build on Solaris 9 is easily fixed.  I have attached a patch with the fix for Python 2.7.

When linking with libpython-2.7.a, the linker will only extract modules that satisfy dependencies emanating from python.o.  There may be objects in the archive that are not needed to satisfy any of these dependencies and those WILL NOT be included in the executable.

The GNU linker supports two options that can be use to force the linker to include ALL objects in the archive.  Thus if you change the python link line from:


 $(BUILDPYTHON):  Modules/python.o $(LIBRARY) $(LDLIBRARY)
     $(LINKCC) $(LDFLAGS) $(LINKFORSHARED) -o $@ \
         Modules/python.o \
         $(BLDLIBRARY) $(LIBS) $(MODLIBS) $(SYSLIBS) $(LDLAST)

to:

 $(BUILDPYTHON): Modules/python.o $(LIBRARY) $(LDLIBRARY)
     $(LINKCC) $(LDFLAGS) $(LINKFORSHARED) -o $@ \
         Modules/python.o \
         -Wl,--whole-archive $(BLDLIBRARY) -Wl,--no-whole-archive \
         $(LIBS) $(MODLIBS) $(SYSLIBS) $(LDLAST)

Then the problem is resolved.

For compiler toolchains that do not support the --whole-library option, you can change the link to link with the individual .o files and not use the archive library at all.

Let me know if I can be of any more help.

Reid Madsen

----------
keywords: +patch
nosy: +srmadsen
Added file: http://bugs.python.org/file20339/Python-2.7.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9742>
_______________________________________

From report at bugs.python.org  Mon Jan 10 23:32:44 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 10 Jan 2011 22:32:44 +0000
Subject: [issue10883] urllib: socket is not closed explicitly
In-Reply-To: <1294698764.05.0.403920474459.issue10883@psf.upfronthosting.co.za>
Message-ID: <1294698764.05.0.403920474459.issue10883@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

test_urllibnet.py and test_urllibnet2.py emit ResourceWarning:
==============
$ ./python Lib/test/test_urllibnet.py 
testURLread (__main__.URLTimeoutTest) ... ok
test_bad_address (__main__.urlopenNetworkTests) ... ok
test_basic (__main__.urlopenNetworkTests) ... ok
test_fileno (__main__.urlopenNetworkTests) ... ok
test_getcode (__main__.urlopenNetworkTests) ... /home/haypo/prog/GIT/py3k/Lib/socket.py:333: ResourceWarning: unclosed <socket.socket object, fd=3, family=2, type=1, proto=6>
  self._sock = None
ok
test_geturl (__main__.urlopenNetworkTests) ... ok
test_info (__main__.urlopenNetworkTests) ... ok
test_readlines (__main__.urlopenNetworkTests) ... ok
test_basic (__main__.urlretrieveNetworkTests) ... /home/haypo/prog/GIT/py3k/Lib/socket.py:333: ResourceWarning: unclosed <socket.socket object, fd=3, family=2, type=2049, proto=6>
  self._sock = None
ok
test_data_header (__main__.urlretrieveNetworkTests) ... /home/haypo/prog/GIT/py3k/Lib/socket.py:333: ResourceWarning: unclosed <socket.socket object, fd=3, family=2, type=2049, proto=6>
  self._sock = None
ok
test_header (__main__.urlretrieveNetworkTests) ... /home/haypo/prog/GIT/py3k/Lib/socket.py:333: ResourceWarning: unclosed <socket.socket object, fd=3, family=2, type=2049, proto=6>
  self._sock = None
ok
test_specified_path (__main__.urlretrieveNetworkTests) ... /home/haypo/prog/GIT/py3k/Lib/socket.py:333: ResourceWarning: unclosed <socket.socket object, fd=3, family=2, type=2049, proto=6>
  self._sock = None
ok

----------------------------------------------------------------------
Ran 12 tests in 17.473s
==============

It looks like these warning are real bugs: the socket is not closed explicitly by urllib.

Nadeem Vawda suggests a first fix:

  diff --git a/Lib/urllib/request.py b/Lib/urllib/request.py
  --- a/Lib/urllib/request.py
  +++ b/Lib/urllib/request.py
  @@ -2151,7 +2151,9 @@
               conn = self.ftp.ntransfercmd(cmd)
           self.busy = 1
           # Pass back both a suitably decorated object and a retrieval length
  -        return (addclosehook(conn[0].makefile('rb'), self.endtransfer), conn[1])
  +        fp = addclosehook(conn[0].makefile('rb'), self.endtransfer)
  +        conn[0].close()
  +        return (fp, conn[1])
       def endtransfer(self):
           if not self.busy:
               return

----------
components: Library (Lib)
messages: 125944
nosy: haypo, nvawda, orsenthil
priority: normal
severity: normal
status: open
title: urllib: socket is not closed explicitly
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/issue10883>
_______________________________________

From report at bugs.python.org  Mon Jan 10 23:33:22 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 10 Jan 2011 22:33:22 +0000
Subject: [issue10512] regrtest ResourceWarning - unclosed sockets and files
In-Reply-To: <1290506536.77.0.313292165719.issue10512@psf.upfronthosting.co.za>
Message-ID: <1294698802.54.0.753470732489.issue10512@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

I opened a separated issue for test_urllib and test_urllib2net: #10883.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10512>
_______________________________________

From report at bugs.python.org  Mon Jan 10 23:46:20 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 10 Jan 2011 22:46:20 +0000
Subject: [issue10875] Update Regular Expression HOWTO
In-Reply-To: <1294604409.29.0.577762819836.issue10875@psf.upfronthosting.co.za>
Message-ID: <1294699580.69.0.0480001739558.issue10875@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I applied patch to 3.2, 3.1 in r87904, r87905. Thanks.
I had to re-edit for 2.7: r87909.

I made a separate small patch for my suggested addition to Matching Characters. Could someone check that it is correct, given that re.rst contains the target directive (or whatever it is called):
.. _re-syntax:

----------
assignee: docs at python -> terry.reedy
stage: needs patch -> commit review
Added file: http://bugs.python.org/file20340/zregex2.rst.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10875>
_______________________________________

From report at bugs.python.org  Mon Jan 10 23:47:10 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 10 Jan 2011 22:47:10 +0000
Subject: [issue1602] windows console doesn't print utf8 (Py30a2)
In-Reply-To: <1197453390.87.0.813702844893.issue1602@psf.upfronthosting.co.za>
Message-ID: <1294699630.31.0.80037247252.issue1602@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Even if python.exe starts normally, py.test for example uses os.dup2() to redirect the file descriptors 1 and 2 to temporary files. sys.stdout.fileno() is still 1, the STD_OUTPUT_HANDLE did not change, but normal print() now goes to a file; but the proposed script won't detect this and will write to the console...
Somehow we should extract the file handle from the file descriptor, with a call to _get_osfhandle() for example.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1602>
_______________________________________

From report at bugs.python.org  Mon Jan 10 23:51:57 2011
From: report at bugs.python.org (David-Sarah Hopwood)
Date: Mon, 10 Jan 2011 22:51:57 +0000
Subject: [issue5924] When setting complete PYTHONPATH on Python 3.x,
	paths in the PYTHONPATH are ignored
In-Reply-To: <1241463970.43.0.829234478071.issue5924@psf.upfronthosting.co.za>
Message-ID: <1294699917.83.0.937435919955.issue5924@psf.upfronthosting.co.za>


David-Sarah Hopwood <david-sarah at jacaranda.org> added the comment:

Looking at http://svn.python.org/view/python/branches/py3k/PC/getpathp.c?r1=73322&r2=73321&pathrev=73322 , wouldn't it be better to add a Py_WGETENV function? There are likely to be other cases where that would be the correct thing to use.

----------
nosy: +davidsarah

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5924>
_______________________________________

From report at bugs.python.org  Mon Jan 10 23:57:21 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 10 Jan 2011 22:57:21 +0000
Subject: [issue2568] Seconds range in time unit
In-Reply-To: <1207551193.66.0.586350051723.issue2568@psf.upfronthosting.co.za>
Message-ID: <1294700241.09.0.407938675697.issue2568@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Committed in revision 87910.

----------
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2568>
_______________________________________

From report at bugs.python.org  Tue Jan 11 00:01:06 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 10 Jan 2011 23:01:06 +0000
Subject: [issue10875] Update Regular Expression HOWTO
In-Reply-To: <1294604409.29.0.577762819836.issue10875@psf.upfronthosting.co.za>
Message-ID: <1294700466.14.0.679438659325.issue10875@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Looks good, builds without warnings.

Note that you can use :ref:`re-syntax` and Sphinx will substitute the heading for you.  The :role:`some special text <real-target>` form is used when you want to control the text of the link.

(That thing is called an hyperlink target: http://docutils.sourceforge.net/docs/user/rst/quickref.html#hyperlink-targets)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10875>
_______________________________________

From report at bugs.python.org  Tue Jan 11 00:01:33 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 10 Jan 2011 23:01:33 +0000
Subject: [issue9566] Compilation warnings under x64 Windows
In-Reply-To: <1281484786.91.0.306555541292.issue9566@psf.upfronthosting.co.za>
Message-ID: <1294700493.38.0.813651278588.issue9566@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> [readinst) should return a negative value on error, whereas it 
> returns the string length which is always positive

Fixed by r87911.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9566>
_______________________________________

From report at bugs.python.org  Tue Jan 11 00:04:47 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 10 Jan 2011 23:04:47 +0000
Subject: =?utf-8?q?=5Bissue10628=5D_Typos_in_3=2E2_what=E2=80=99s_new?=
In-Reply-To: <1291489855.52.0.016822369266.issue10628@psf.upfronthosting.co.za>
Message-ID: <1294700687.72.0.386494182732.issue10628@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


Removed file: http://bugs.python.org/file20333/whatsnew-3.2-typos.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10628>
_______________________________________

From report at bugs.python.org  Tue Jan 11 00:07:27 2011
From: report at bugs.python.org (Glenn Linderman)
Date: Mon, 10 Jan 2011 23:07:27 +0000
Subject: [issue4953] cgi module cannot handle POST with multipart/form-data
	in	3.0
In-Reply-To: <1232010166.79.0.972664060868.issue4953@psf.upfronthosting.co.za>
Message-ID: <1294700847.11.0.053526051363.issue4953@psf.upfronthosting.co.za>


Glenn Linderman <v+python at g.nevcal.com> added the comment:

Victor said:
I mean: you should pass sys.stdin.buffer instead of sys.stdin.

I say:
That would be possible, but it is hard to leave it at default, in that case, because sys.stdin will, by default, not be a binary stream.  It is a convenience for FieldStorage to have a useful default for its input, since RFC 3875 declares that the message body is obtained from "standard input".

Pierre said:
I wish it could be as simple, but I'm afraid it's not. On my PC, sys.stdin.encoding is cp-1252. I tested a multipart/form-data with an INPUT field, and I entered the euro character, which is encoded  \x80 in cp-1252

If I use the encoding defined for sys.stdin (cp-1252) to decode the bytes received on sys.stdin.buffer, I get the correct value in the cgi script ; if I set the encoding to latin-1 in FieldStorage, since \x80 maps to undefined in latin-1, I get a UnicodeEncodeError if I try to print the value ("character maps to <undefined>")

I say:
Interesting. I'm curious what your system (probably Windows since you mention cp-) and browser, and HTTP server is, that you used for that test.  Is it possible to capture the data stream for that test?  Describe how, and at what stage the data stream was captured, if you can capture it.  Most interesting would be on the interface between browser and HTTP server.

RFC 3875 states (section 4.1.3) what the default encodings should be, but I see that the first possibility is "system defined".  On the other hand, it seems to imply that it should be a system definition specifically defined for particular media types, not just a general system definition such as might be used as a default encoding for file handles... after all, most Web communication crosses system boundaries.  So lacking a system defined definition for text/ types, it then indicates that the default for text/ types is Latin-1.

I wonder what result you get with the same browser, at the web page http://rishida.net/tools/conversion/ by entering the euro symbol into the Characters entry field, and choosing convert.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4953>
_______________________________________

From report at bugs.python.org  Tue Jan 11 00:18:02 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 10 Jan 2011 23:18:02 +0000
Subject: =?utf-8?q?=5Bissue10628=5D_Typos_in_3=2E2_what=E2=80=99s_new?=
In-Reply-To: <1291489855.52.0.016822369266.issue10628@psf.upfronthosting.co.za>
Message-ID: <1294701482.16.0.144519687664.issue10628@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Remaining fixes and nitpicks, in separate patches to avoid missing fixes when cherry-picking nits.

----------
Added file: http://bugs.python.org/file20341/whatsnew-3.2-typos.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10628>
_______________________________________

From report at bugs.python.org  Tue Jan 11 00:18:22 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 10 Jan 2011 23:18:22 +0000
Subject: =?utf-8?q?=5Bissue10628=5D_Typos_in_3=2E2_what=E2=80=99s_new?=
In-Reply-To: <1291489855.52.0.016822369266.issue10628@psf.upfronthosting.co.za>
Message-ID: <1294701502.75.0.670576624292.issue10628@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


Added file: http://bugs.python.org/file20342/whatsnew-3.2-nitpicks.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10628>
_______________________________________

From report at bugs.python.org  Tue Jan 11 00:19:19 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 10 Jan 2011 23:19:19 +0000
Subject: [issue10875] Update Regular Expression HOWTO
In-Reply-To: <1294604409.29.0.577762819836.issue10875@psf.upfronthosting.co.za>
Message-ID: <1294701559.8.0.286674673514.issue10875@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Thanks. r87911,r87912

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10875>
_______________________________________

From report at bugs.python.org  Tue Jan 11 00:35:23 2011
From: report at bugs.python.org (AdamN)
Date: Mon, 10 Jan 2011 23:35:23 +0000
Subject: [issue5434] datetime.monthdelta
In-Reply-To: <1236402290.49.0.02662803662.issue5434@psf.upfronthosting.co.za>
Message-ID: <1294702523.31.0.759444792288.issue5434@psf.upfronthosting.co.za>


AdamN <adam at varud.com> added the comment:

For future reference, python-dateutil seems like the maintained way to deal with "human" dates outside of the stdlib.

http://pypi.python.org/pypi/python-dateutil

----------
nosy: +adamnelson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5434>
_______________________________________

From report at bugs.python.org  Tue Jan 11 00:38:44 2011
From: report at bugs.python.org (David-Sarah Hopwood)
Date: Mon, 10 Jan 2011 23:38:44 +0000
Subject: [issue1602] windows console doesn't print utf8 (Py30a2)
In-Reply-To: <1197453390.87.0.813702844893.issue1602@psf.upfronthosting.co.za>
Message-ID: <1294702724.47.0.982623019962.issue1602@psf.upfronthosting.co.za>


David-Sarah Hopwood <david-sarah at jacaranda.org> added the comment:

"... os.dup2() ..."

Good point, thanks.

It would work to change os.dup2 so that if its second argument is 0, 1, or 2, it calls _get_osfhandle to get the Windows handle for that fd, and then reruns the console-detection logic. That would even allow Unicode output to work after redirection to a different console.

Programs that directly called the CRT dup2 or SetStdHandle would bypass this. Can we consider such programs to be broken? Methinks a documentation patch for os.dup2 would be sufficient, something like:

"When fd1 refers to the standard input, output, or error handles (0, 1 and 2 respectively), this function also ensures that state associated with Python's initial sys.{stdin,stdout,stderr} streams is correctly updated if needed. It should therefore be used in preference to calling the C library's dup2, or similar APIs such as SetStdHandle on Windows."

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1602>
_______________________________________

From report at bugs.python.org  Tue Jan 11 00:45:03 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 10 Jan 2011 23:45:03 +0000
Subject: [issue5979] strptime() gives inconsistent exceptions
In-Reply-To: <1241896450.71.0.860512052019.issue5979@psf.upfronthosting.co.za>
Message-ID: <1294703103.97.0.530884378792.issue5979@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


----------
stage: unit test needed -> needs patch
versions: +Python 3.3 -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5979>
_______________________________________

From report at bugs.python.org  Tue Jan 11 00:52:34 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 10 Jan 2011 23:52:34 +0000
Subject: [issue1667546] Time zone-capable variant of time.localtime
Message-ID: <1294703554.37.0.591715430343.issue1667546@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

I am going to close this as superseded by #9527.  In order to properly implement #9527 in datetime.py, some kind of tm_gmtoff support will need to be added to the time module, but I don't want this to become a feature that is exclusively available from the time module.

----------
resolution:  -> duplicate
stage: patch review -> committed/rejected
status: open -> pending
superseder:  -> Add aware local time support to datetime module

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1667546>
_______________________________________

From report at bugs.python.org  Tue Jan 11 00:56:23 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 10 Jan 2011 23:56:23 +0000
Subject: [issue8915] Use locale.nl_langinfo in _strptime
In-Reply-To: <1275795309.62.0.41465361185.issue8915@psf.upfronthosting.co.za>
Message-ID: <1294703783.21.0.0551280242427.issue8915@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

I would also like to consider using OS strptime on platforms with a decent implementation.

----------
stage:  -> needs patch
type:  -> feature request
versions: +Python 3.3 -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8915>
_______________________________________

From report at bugs.python.org  Tue Jan 11 00:57:35 2011
From: report at bugs.python.org (Dave Malcolm)
Date: Mon, 10 Jan 2011 23:57:35 +0000
Subject: [issue9263] Try to print repr() when an C-level assert fails (in the
	garbage collector, beyond?)
In-Reply-To: <1279151450.93.0.973335817084.issue9263@psf.upfronthosting.co.za>
Message-ID: <1294703855.14.0.313697273871.issue9263@psf.upfronthosting.co.za>


Dave Malcolm <dmalcolm at redhat.com> added the comment:

Attaching updated version of the patch.

I've added a selftest which (in a sacrificial subprocess) abuses ctypes to break an ob_refcnt, and then triggers a garbage collection.

I also changed the printing to stderr to directly use fprintf and fflush to ensure that data leaves the process before abort kills it (not sure if this is a cross-platform or unicode no-no, though).

----------
Added file: http://bugs.python.org/file20343/py3k-objdump-on-gcmodule-assertions-2011-01-10-001.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9263>
_______________________________________

From report at bugs.python.org  Tue Jan 11 01:00:01 2011
From: report at bugs.python.org (Dave Malcolm)
Date: Tue, 11 Jan 2011 00:00:01 +0000
Subject: [issue9263] Try to print repr() when an C-level assert fails (in the
	garbage collector, beyond?)
In-Reply-To: <1279151450.93.0.973335817084.issue9263@psf.upfronthosting.co.za>
Message-ID: <1294704001.06.0.472691073959.issue9263@psf.upfronthosting.co.za>


Dave Malcolm <dmalcolm at redhat.com> added the comment:

As above, but I added an extra call to fflush in case the call to _PyObject_Dump leads to a segfault.

----------
Added file: http://bugs.python.org/file20344/py3k-objdump-on-gcmodule-assertions-2011-01-10-002.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9263>
_______________________________________

From report at bugs.python.org  Tue Jan 11 01:05:41 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 11 Jan 2011 00:05:41 +0000
Subject: [issue1109963] bdist_wininst ignores build_lib from build command
Message-ID: <1294704341.55.0.282451874322.issue1109963@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/issue1109963>
_______________________________________

From report at bugs.python.org  Tue Jan 11 01:07:04 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 11 Jan 2011 00:07:04 +0000
Subject: [issue9611] FileIO not 64-bit safe under Windows
In-Reply-To: <1281893142.91.0.972520708976.issue9611@psf.upfronthosting.co.za>
Message-ID: <1294704424.47.0.392190110051.issue9611@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

r87917 removes (useless and dangerous) conversion to size_t.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9611>
_______________________________________

From report at bugs.python.org  Tue Jan 11 01:07:13 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 11 Jan 2011 00:07:13 +0000
Subject: [issue9566] Compilation warnings under x64 Windows
In-Reply-To: <1281484786.91.0.306555541292.issue9566@psf.upfronthosting.co.za>
Message-ID: <1294704433.92.0.0882251231641.issue9566@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Removed file: http://bugs.python.org/file20263/pyexpat.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9566>
_______________________________________

From report at bugs.python.org  Tue Jan 11 01:08:20 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 11 Jan 2011 00:08:20 +0000
Subject: [issue10875] Update Regular Expression HOWTO
In-Reply-To: <1294604409.29.0.577762819836.issue10875@psf.upfronthosting.co.za>
Message-ID: <1294704500.04.0.65307076913.issue10875@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

and r87918 for 2.7, with bytes -> byte string

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10875>
_______________________________________

From report at bugs.python.org  Tue Jan 11 01:08:25 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 11 Jan 2011 00:08:25 +0000
Subject: [issue9566] Compilation warnings under x64 Windows
In-Reply-To: <1281484786.91.0.306555541292.issue9566@psf.upfronthosting.co.za>
Message-ID: <1294704505.48.0.837759248633.issue9566@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

socketmodule_int.patch: Fix similar to the fix for #9611: clamp length to INT_MAX on Windows for recv(), recvfrom(), send() and sendto().

----------
Added file: http://bugs.python.org/file20345/socketmodule_int.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9566>
_______________________________________

From report at bugs.python.org  Tue Jan 11 01:11:31 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 11 Jan 2011 00:11:31 +0000
Subject: [issue7739] time.strftime may hung while trying to open
	/etc/localtime but does not release GIL
In-Reply-To: <1263893036.59.0.158350465414.issue7739@psf.upfronthosting.co.za>
Message-ID: <1294704691.2.0.798107392171.issue7739@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

-1 on releasing the GIL around strftime().  Until we have an implementation that can support multiple locales and multiple timezones, people will work around this limitation by messing up with the TZ environment variable or global locale settings.

----------
assignee: belopolsky -> 
stage:  -> patch review
type:  -> performance
versions: +Python 3.3 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7739>
_______________________________________

From report at bugs.python.org  Tue Jan 11 01:17:51 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Tue, 11 Jan 2011 00:17:51 +0000
Subject: [issue10848] Move test.regrtest from getopt to argparse
In-Reply-To: <1294362079.02.0.757131754481.issue10848@psf.upfronthosting.co.za>
Message-ID: <AANLkTinEEsL_B7nnwr_v3on+MY-YYNv82vgExyZnKzJP@mail.gmail.com>


Sandro Tosi <sandro.tosi at gmail.com> added the comment:

> R. David Murray <rdmurray at bitdance.com> added the comment:
>
> Note that based on my experience with the conversion of compileall to argparse,it is important to have good tests. ?Of course, regrtest itself has no tests...

Indeed that's quite funny :) anyhow, any suggestions on how to
properly test it while porting it to argparse? f.e, I can think to get
all the examples in the devguide and make sure they work, but since
I'm new to python development I might miss something really important,
hence the commends from more experienced devs would be really
important for me :)

Cheers,
Sandro

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10848>
_______________________________________

From report at bugs.python.org  Tue Jan 11 01:18:20 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 11 Jan 2011 00:18:20 +0000
Subject: [issue8957] strptime('%c', ..) fails to parse output of strftime('%c',
	..) in non-English locale
In-Reply-To: <1276115080.37.0.388300880324.issue8957@psf.upfronthosting.co.za>
Message-ID: <1294705100.98.0.873824264438.issue8957@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Adding #8915 as a dependency because deducing D_T_FMT locale setting from strftime output seems impossible:

>>> locale.nl_langinfo(locale.D_T_FMT)
'%a %b %e %H:%M:%S %Y'

----------
dependencies: +Use locale.nl_langinfo in _strptime
versions: +Python 3.3 -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8957>
_______________________________________

From report at bugs.python.org  Tue Jan 11 01:19:37 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Tue, 11 Jan 2011 00:19:37 +0000
Subject: [issue10512] regrtest ResourceWarning - unclosed sockets and files
In-Reply-To: <1290506536.77.0.313292165719.issue10512@psf.upfronthosting.co.za>
Message-ID: <1294705177.81.0.375873518402.issue10512@psf.upfronthosting.co.za>


Nadeem Vawda <nadeem.vawda at gmail.com> added the comment:

Good idea; they look like more work to fix than the warnings so far. Aside from those two, it looks like test_cgi is all that's left. Just to clarify, did you manage to reproduce the test_cgi warning?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10512>
_______________________________________

From report at bugs.python.org  Tue Jan 11 01:24:35 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 11 Jan 2011 00:24:35 +0000
Subject: [issue8957] strptime('%c', ..) fails to parse output of strftime('%c',
	..) in non-English locale
In-Reply-To: <1276115080.37.0.388300880324.issue8957@psf.upfronthosting.co.za>
Message-ID: <1294705475.98.0.143757532159.issue8957@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Victor,

You may be interested because your native language is implicated. :-)

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8957>
_______________________________________

From report at bugs.python.org  Tue Jan 11 01:48:43 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 11 Jan 2011 00:48:43 +0000
Subject: [issue9566] Compilation warnings under x64 Windows
In-Reply-To: <1281484786.91.0.306555541292.issue9566@psf.upfronthosting.co.za>
Message-ID: <1294706923.01.0.477412408219.issue9566@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

ssl_sock_fd_int.patch: add SOCKET_T_AS_INT(fd) macro to cast a socket descriptor (SOCKET_T) to int. I choosed a macro just to not have to repeat a comment twice :-)

It looks like it is a safe to cast SOCKET_T to int. My comment:

/* On Windows, SOCKET_T is an offset in per-process handle table.
   The per-process limit on kernel handles is 2^24. Kernel Objects:
   http://msdn.microsoft.com/en-us/library/ms724485%28VS.85%29.aspx
*/

----------
Added file: http://bugs.python.org/file20346/ssl_sock_fd_int.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9566>
_______________________________________

From report at bugs.python.org  Tue Jan 11 01:51:38 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 11 Jan 2011 00:51:38 +0000
Subject: [issue9566] Compilation warnings under x64 Windows
In-Reply-To: <1281484786.91.0.306555541292.issue9566@psf.upfronthosting.co.za>
Message-ID: <1294707098.95.0.822591672286.issue9566@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> On Windows, SOCKET_T is an offset in per-process handle table.
> The per-process limit on kernel handles is 2^24. Kernel Objects:

Reference: http://www.mail-archive.com/openssl-dev at openssl.org/msg23781.html

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9566>
_______________________________________

From report at bugs.python.org  Tue Jan 11 01:53:59 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 11 Jan 2011 00:53:59 +0000
Subject: [issue9566] Compilation warnings under x64 Windows
In-Reply-To: <1281484786.91.0.306555541292.issue9566@psf.upfronthosting.co.za>
Message-ID: <1294707239.12.0.420245679873.issue9566@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

ssl_write.patch: always clamp SSL_Write() size to INT_MAX. This patch fixes also an overflow if Py_ssize_t is 32 bits (if the size is bigger than INT_MAX).

----------
Added file: http://bugs.python.org/file20347/ssl_write.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9566>
_______________________________________

From report at bugs.python.org  Tue Jan 11 01:55:50 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 11 Jan 2011 00:55:50 +0000
Subject: [issue9566] Compilation warnings under x64 Windows
In-Reply-To: <1281484786.91.0.306555541292.issue9566@psf.upfronthosting.co.za>
Message-ID: <1294707350.74.0.0223150857676.issue9566@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

hash.patch: continue my fix on md5, sha1, sha256, sha512.

----------
Added file: http://bugs.python.org/file20348/hash.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9566>
_______________________________________

From report at bugs.python.org  Tue Jan 11 02:03:43 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 11 Jan 2011 01:03:43 +0000
Subject: [issue9566] Compilation warnings under x64 Windows
In-Reply-To: <1281484786.91.0.306555541292.issue9566@psf.upfronthosting.co.za>
Message-ID: <1294707823.8.0.254355890779.issue9566@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

_sre.patch: store sre_match() result in Py_ssize_t instead of int.

----------
Added file: http://bugs.python.org/file20349/_sre.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9566>
_______________________________________

From report at bugs.python.org  Tue Jan 11 02:13:43 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 11 Jan 2011 01:13:43 +0000
Subject: [issue9566] Compilation warnings under x64 Windows
In-Reply-To: <1281484786.91.0.306555541292.issue9566@psf.upfronthosting.co.za>
Message-ID: <1294708423.05.0.406559786751.issue9566@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

... and issue9566.patch: various fixes. Interesting parts:

---
-    id = PyLong_FromLong((Py_uintptr_t) self);
+    id = PyLong_FromVoidPtr(self);
---

---
 LOCAL(PyObject*)
-expat_parse(XMLParserObject* self, char* data, int data_len, int final)
+expat_parse(XMLParserObject* self, char* data, Py_ssize_t data_len, int final)
 {
     int ok;
 
-    ok = EXPAT(Parse)(self->parser, data, data_len, final);
+    if (data_len > INT_MAX) {
+        PyErr_SetString(PyExc_OverflowError, "length doesn't fit in an int");
+        return NULL;
+    }
+
+    ok = EXPAT(Parse)(self->parser, data, (int)data_len, final);
---

---
-        long hash = PyObject_Hash(arg);
+        Py_hash_t hash = PyObject_Hash(arg);
---

----------
Added file: http://bugs.python.org/file20350/issue9566.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9566>
_______________________________________

From report at bugs.python.org  Tue Jan 11 02:24:10 2011
From: report at bugs.python.org (R. David Murray)
Date: Tue, 11 Jan 2011 01:24:10 +0000
Subject: [issue10848] Move test.regrtest from getopt to argparse
In-Reply-To: <1294353259.48.0.852026284896.issue10848@psf.upfronthosting.co.za>
Message-ID: <1294709050.22.0.0522222691463.issue10848@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Testing regrtest is distinctly non-trivial, since options have interactions (some of the somewhat unobvious).  Ideally we'd refactor the code so that we could point it at a test test-directory so we could write some automated tests for it :)  But if you are going that far you might as well rewrite it.

This is, I suspect, why nobody has yet done this conversion.

My best suggestion if you really want to go ahead is to go through each option individually, with and without command line arguments, and test how it currently behaves and make good notes.  Anything that doesn't make sense, ask on (#)python-dev.  And then...build a matrix and test each option in combination with each other option, again keeping notes.  Which is something that has probably never been done, and will doubtless reveal some interesting bugs.  You might be able to automate some tests using doctest and subprocess.

I'm not sure about that easy tag.  This could easily be more than a one day project.  I suspect you will find your fingers itching to refactor more than just the argument parsing code.  You should probably resist that urge insofar as possible :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10848>
_______________________________________

From report at bugs.python.org  Tue Jan 11 02:24:48 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 11 Jan 2011 01:24:48 +0000
Subject: [issue1726687] Bug found in datetime for Epoch time = -1
Message-ID: <1294709088.2.0.66219495692.issue1726687@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Committed in revision 87919.  If bots are happy about the unit test, this should be backported to 3.1 and 2.7.

----------
resolution:  -> fixed
stage: unit test needed -> committed/rejected

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1726687>
_______________________________________

From report at bugs.python.org  Tue Jan 11 02:25:27 2011
From: report at bugs.python.org (Francis Cullen)
Date: Tue, 11 Jan 2011 01:25:27 +0000
Subject: [issue6792] Distutils-based installer does not detect 64bit versions
	of Python
In-Reply-To: <1251449540.11.0.0670330819334.issue6792@psf.upfronthosting.co.za>
Message-ID: <1294709127.43.0.465272491935.issue6792@psf.upfronthosting.co.za>


Francis Cullen <menekali at gmail.com> added the comment:

There are many updated installers, for many libs for those of us using 64bit windows 7.

http://www.lfd.uci.edu/~gohlke/pythonlibs/

----------
nosy: +menekali at gmail.com

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6792>
_______________________________________

From report at bugs.python.org  Tue Jan 11 02:25:48 2011
From: report at bugs.python.org (R. David Murray)
Date: Tue, 11 Jan 2011 01:25:48 +0000
Subject: [issue10848] Move test.regrtest from getopt to argparse
In-Reply-To: <1294353259.48.0.852026284896.issue10848@psf.upfronthosting.co.za>
Message-ID: <1294709148.05.0.203556332203.issue10848@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Note that it is also possible that after doing a review of the functionality, there might be consensus to drop one or more options, which would be a good thing overall, IMO.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10848>
_______________________________________

From report at bugs.python.org  Tue Jan 11 02:51:27 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 11 Jan 2011 01:51:27 +0000
Subject: [issue2267] datetime.datetime operator methods are not
	subclass-friendly
In-Reply-To: <1205176194.96.0.747568659994.issue2267@psf.upfronthosting.co.za>
Message-ID: <1294710687.0.0.881074740056.issue2267@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Note that before r82065, python prototype, now available as Lib/datetime.py had binary operations implemented to return subclass instances.  Here is annotated pre-r82065 code:


 39876 gvanrossum     def __add__(self, other):
 39876 gvanrossum         if isinstance(other, timedelta):
 39928 gvanrossum             return self.__class__(self.__days + other.__days,
 39876 gvanrossum                                   self.__seconds + other.__seconds,
 39876 gvanrossum                                   self.__microseconds + other.__microseconds)
 40207    tim_one         return NotImplemented
 39876 gvanrossum

----------
versions: +Python 3.3 -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2267>
_______________________________________

From report at bugs.python.org  Tue Jan 11 02:57:40 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 11 Jan 2011 01:57:40 +0000
Subject: [issue9034] datetime module should use int32_t for date/time
	components
In-Reply-To: <1276998258.21.0.743259532258.issue9034@psf.upfronthosting.co.za>
Message-ID: <1294711060.48.0.378165382467.issue9034@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


----------
versions: +Python 3.3 -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9034>
_______________________________________

From report at bugs.python.org  Tue Jan 11 03:04:01 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 11 Jan 2011 02:04:01 +0000
Subject: [issue9004] datetime.utctimetuple() should not set tm_isdst flag to 0
In-Reply-To: <1276659404.06.0.425467293989.issue9004@psf.upfronthosting.co.za>
Message-ID: <1294711441.6.0.0543119567223.issue9004@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


----------
versions: +Python 3.3 -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9004>
_______________________________________

From report at bugs.python.org  Tue Jan 11 03:14:26 2011
From: report at bugs.python.org (Ned Deily)
Date: Tue, 11 Jan 2011 02:14:26 +0000
Subject: [issue10844] OS X installer: update copyright dates in app bundles
In-Reply-To: <1294307725.56.0.795948655729.issue10844@psf.upfronthosting.co.za>
Message-ID: <1294712066.0.0.02562842542.issue10844@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Also backported by Georg to 3.1 (r87885) and 2.7 (r87886)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10844>
_______________________________________

From report at bugs.python.org  Tue Jan 11 03:18:26 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 11 Jan 2011 02:18:26 +0000
Subject: [issue7229] Manual entry for time.daylight can be misleading
In-Reply-To: <1256723052.19.0.148648938954.issue7229@psf.upfronthosting.co.za>
Message-ID: <1294712306.84.0.489073706162.issue7229@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

I am going to reject this.  None of the proposed changes seem to be better than the current documentation. The time.daylight variable has the same meaning as eponymous C variable defined in time.h header.  The latter is described in widely available and well known C and POSIX standards. Users that find Python manual description confusing or incomplete can easily find clarifications or details in other sources.

----------
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7229>
_______________________________________

From report at bugs.python.org  Tue Jan 11 05:56:27 2011
From: report at bugs.python.org (Michael Mulich)
Date: Tue, 11 Jan 2011 04:56:27 +0000
Subject: [issue10884] pkgutil EggInfoDistribution requirements for .egg-info
	metadata
In-Reply-To: <1294721787.13.0.963133670506.issue10884@psf.upfronthosting.co.za>
Message-ID: <1294721787.13.0.963133670506.issue10884@psf.upfronthosting.co.za>


New submission from Michael Mulich <michael.mulich at gmail.com>:

Found an issue where the metadata initialization of .egg-info dirs (an EggInfoDistribution object) overrides the 'path' variable, which makes it impossible to find a distributions requirements.

I've fixed the issue at https://bitbucket.org/pumazi/distutils2-fixes/changeset/f3b5eb2aac2c (changeset also attached).

----------
assignee: tarek
components: Distutils2
files: distutils2-fixes-f3b5eb2aac2c.diff
keywords: patch
messages: 125982
nosy: eric.araujo, pumazi, tarek
priority: normal
severity: normal
status: open
title: pkgutil EggInfoDistribution requirements for .egg-info metadata
type: behavior
versions: Python 2.5, Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file20351/distutils2-fixes-f3b5eb2aac2c.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10884>
_______________________________________

From report at bugs.python.org  Tue Jan 11 06:55:17 2011
From: report at bugs.python.org (Ross Lagerwall)
Date: Tue, 11 Jan 2011 05:55:17 +0000
Subject: [issue10882] Add os.sendfile()
In-Reply-To: <1294691268.76.0.727179568007.issue10882@psf.upfronthosting.co.za>
Message-ID: <1294725317.47.0.918702389402.issue10882@psf.upfronthosting.co.za>


Ross Lagerwall <rosslagerwall at gmail.com> added the comment:

Ok, I figured it out to link with sendfile on solaris. Here is the updated patch.

----------
Added file: http://bugs.python.org/file20352/sendfile_v2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10882>
_______________________________________

From report at bugs.python.org  Tue Jan 11 07:52:51 2011
From: report at bugs.python.org (Ross Lagerwall)
Date: Tue, 11 Jan 2011 06:52:51 +0000
Subject: [issue10822] test_getgroups failure under Solaris
In-Reply-To: <1294139319.03.0.190267830849.issue10822@psf.upfronthosting.co.za>
Message-ID: <1294728771.24.0.920696685905.issue10822@psf.upfronthosting.co.za>


Ross Lagerwall <rosslagerwall at gmail.com> added the comment:

It seems to work fine on OpenIndiana (running normally or as root).

According to the posix specification, "It is implementation-defined whether getgroups() also returns the effective group ID in the grouplist array."

But, id -G prints all group IDs. Perhaps, it failed because 0 was the effective gid & it was included by "id -G" but wasn't being returned by posix.getgroups().

This fix changes the test to compare the output from "id -G" with the union of getgroups() & getegid().

----------
keywords: +patch
Added file: http://bugs.python.org/file20353/10822.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10822>
_______________________________________

From report at bugs.python.org  Tue Jan 11 09:05:58 2011
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 11 Jan 2011 08:05:58 +0000
Subject: [issue10877] Make Tools (and subdirs) a package (and subpackages)
In-Reply-To: <1294617174.73.0.902104851361.issue10877@psf.upfronthosting.co.za>
Message-ID: <1294733158.12.0.408042717685.issue10877@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

I don't think this is a good idea.  For one thing, it only works in a checkout or source tarball, something that most users aren't going to work with.

If we now publish that they can do "import Tools.demo.redemo" and so on, confusion will be great among those whose installation doesn't include Tools.  In effect, you've added a new (and huge!) standard library package, and that's not something we do lightly or just before rc :)

Also, Tools is mostly interesting for developers only.  I'd rather put the things useful for users into the standard library at some point.

----------
resolution:  -> rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10877>
_______________________________________

From report at bugs.python.org  Tue Jan 11 09:22:21 2011
From: report at bugs.python.org (Christoph Gohlke)
Date: Tue, 11 Jan 2011 08:22:21 +0000
Subject: [issue6792] Distutils-based installer does not detect 64bit versions
	of Python
In-Reply-To: <1251449540.11.0.0670330819334.issue6792@psf.upfronthosting.co.za>
Message-ID: <1294734141.47.0.971318139886.issue6792@psf.upfronthosting.co.za>


Changes by Christoph Gohlke <cgohlke at uci.edu>:


----------
nosy: +cgohlke

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6792>
_______________________________________

From report at bugs.python.org  Tue Jan 11 09:37:23 2011
From: report at bugs.python.org (Tomas Kubes)
Date: Tue, 11 Jan 2011 08:37:23 +0000
Subject: [issue7229] Manual entry for time.daylight can be misleading
In-Reply-To: <1256723052.19.0.148648938954.issue7229@psf.upfronthosting.co.za>
Message-ID: <1294735043.99.0.987263775581.issue7229@psf.upfronthosting.co.za>


Tomas Kubes <mr_napik at centrum.cz> added the comment:

I am sorry, but as an original initiator of the the issue I find the argumentation of Alexander Belopolsky vastly ridiculous. Are you really seriously convinced that an average person responsible for Python application development and maintenance would be aware of a necessity to look for an ANSI C documentation to find a description and definitions of time functions?

You sound like Marie Antoinette who replied to peasants complaining the they do not have any bread to eat that they should eat brioches instead. Maybe in the context of the ?royal programmers family? documentation to ANSI C is wildly known and even memorized, but I do insist that Python documentation should be accessible and understandable even to ordinary peasants of the computer kingdom.

And I keep my case that the current description might trick programmers to think that it holds information whether the summer time currently applies rather than just plain information about current time zone being able to use summer time.

Regards
Tomas

----------
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7229>
_______________________________________

From report at bugs.python.org  Tue Jan 11 10:09:00 2011
From: report at bugs.python.org (Ross Lagerwall)
Date: Tue, 11 Jan 2011 09:09:00 +0000
Subject: [issue4112] Subprocess: Popen'ed children hang due to open pipes
In-Reply-To: <1223894179.31.0.303015562598.issue4112@psf.upfronthosting.co.za>
Message-ID: <1294736940.02.0.609924891893.issue4112@psf.upfronthosting.co.za>


Ross Lagerwall <rosslagerwall at gmail.com> added the comment:

This issue has been fixed on 3.2.

----------
nosy: +rosslagerwall
versions:  -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4112>
_______________________________________

From report at bugs.python.org  Tue Jan 11 10:32:34 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 11 Jan 2011 09:32:34 +0000
Subject: [issue10556] test_zipimport_support mucks up with modules
In-Reply-To: <1290900068.1.0.744896012432.issue10556@psf.upfronthosting.co.za>
Message-ID: <1294738354.76.0.922856673206.issue10556@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Even more special: put a test_doctest in first and the attempt to clean up sys.modules in test_zipimport_support leaves things alone so the _ssl module doesn't break (test_doctest just leaves sys.modules alone and doesn't even try to remove all the modules it implicitly imports).

I'm actually tempted to remove test.support.modules_setup() and modules_cleanup() and delete the calls from the affected tests. Trying to clear out implicitly imported modules is going to create far more problems than it resolves.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10556>
_______________________________________

From report at bugs.python.org  Tue Jan 11 10:55:47 2011
From: report at bugs.python.org (anatoly techtonik)
Date: Tue, 11 Jan 2011 09:55:47 +0000
Subject: [issue7229] Manual entry for time.daylight can be misleading
In-Reply-To: <1256723052.19.0.148648938954.issue7229@psf.upfronthosting.co.za>
Message-ID: <1294739747.17.0.9995254198.issue7229@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

Classic user developer impedance mismatch. =)

I agree that Python should guard its users against crazy standards that creep into standard lib, because nobody had time to think about pythonic API.

I propose the following change:

http://docs.python.org/library/time.html#time.altzone
-  UTC offset of the local DST timezone if one is defined. Only use this if daylight is nonzero.
+  UTC offset of the current timezone with Daylight Savings Time (DST) correction. To check if DST is currently active, use `time.localtime(t).tm_isdst`

http://docs.python.org/library/time.html#time.daylight
-  Nonzero if a DST timezone is defined.
+  Flag indicating that current timezone has Daylight Savings Time (DST) offset. To check if DST is currently active, use `time.localtime(t).tm_isdst`

http://docs.python.org/library/time.html#time.timezone
-  UTC offset of the local (non-DST) timezone
+  UTC offset of the current timezone. It doesn't include Daylight Savings Time (DST) correction. See `time.altzone` for that.


BTW, isn't the following check redundant?
    if time.localtime(t).tm_isdst and time.daylight:

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7229>
_______________________________________

From report at bugs.python.org  Tue Jan 11 11:06:30 2011
From: report at bugs.python.org (anatoly techtonik)
Date: Tue, 11 Jan 2011 10:06:30 +0000
Subject: [issue1667546] Time zone-capable variant of time.localtime
Message-ID: <1294740390.79.0.768157681082.issue1667546@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

IIUC #9527 is about datetime and this request is about time.localtime, i.e. about making the API more intuitive for users. I don't think this issue should be closed.

----------
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1667546>
_______________________________________

From report at bugs.python.org  Tue Jan 11 11:06:37 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 11 Jan 2011 10:06:37 +0000
Subject: [issue10556] test_zipimport_support mucks up with modules
In-Reply-To: <1290900068.1.0.744896012432.issue10556@psf.upfronthosting.co.za>
Message-ID: <1294740397.57.0.0133233877332.issue10556@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Fixed for 3.2 in r87925. (I simply dropped the attempt to restore sys.modules to its original state from test_zipimport_support)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10556>
_______________________________________

From report at bugs.python.org  Tue Jan 11 11:07:02 2011
From: report at bugs.python.org (Glenn Linderman)
Date: Tue, 11 Jan 2011 10:07:02 +0000
Subject: [issue4953] cgi module cannot handle POST with multipart/form-data
	in	3.0
In-Reply-To: <1232010166.79.0.972664060868.issue4953@psf.upfronthosting.co.za>
Message-ID: <1294740422.1.0.519032092748.issue4953@psf.upfronthosting.co.za>


Glenn Linderman <v+python at g.nevcal.com> added the comment:

I said:
I wonder what result you get with the same browser, at the web page http://rishida.net/tools/conversion/ by entering the euro symbol into the Characters entry field, and choosing convert.

But I couldn't wait, so I ran a test with ? in one of my input boxes, using Firefox, a FORM as:
<form enctype="multipart/form-data" method="post" action="...

and below is the Live Headers report.  I note several things that seem relevant to this issue.

1) The character encoding isn't specified anywhere.  In fact, the only content-type specification is the multipart/form-data in the environment.

2) Except for the Euro, everything in the data stream is ASCII (but could be ISO-8859-1, or latin-1).  

3) Looking separately at the byte stream read by my experimental version of cgi.py which prints the bytes as they are read, I see that the encoding of the Euro is UTF-8:  '\xe2\x82\xac'

4) Because of 1), it is clear that default encoding types must be applied, and it is clear that Firefox provides UTF-8.

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101203 Firefox/3.6.13
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 115
Connection: keep-alive
Content-Type: multipart/form-data; boundary=---------------------------1650566221634
Content-Length: 527
-----------------------------1650566221634
Content-Disposition: form-data; name="type"

summary
-----------------------------1650566221634
Content-Disposition: form-data; name="submit"

Search
-----------------------------1650566221634
Content-Disposition: form-data; name="pre"

?
-----------------------------1650566221634
Content-Disposition: form-data; name="part"


-----------------------------1650566221634
Content-Disposition: form-data; name="key"


-----------------------------1650566221634--

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4953>
_______________________________________

From report at bugs.python.org  Tue Jan 11 11:28:29 2011
From: report at bugs.python.org (Glenn Linderman)
Date: Tue, 11 Jan 2011 10:28:29 +0000
Subject: [issue4953] cgi module cannot handle POST with multipart/form-data
	in	3.0
In-Reply-To: <1232010166.79.0.972664060868.issue4953@psf.upfronthosting.co.za>
Message-ID: <1294741709.02.0.913998475192.issue4953@psf.upfronthosting.co.za>


Glenn Linderman <v+python at g.nevcal.com> added the comment:

R. David:

Pierre said:
BytesFeedParser only uses the ascii codec ; if the header has non ASCII characters (filename in a multipart/form-data), they are replaced by ? : the original file name is lost. So for the moment I leave the text version of FeedParser

I say:
Does this mean BytesFeedParser, to be useful for cgi.py, needs to accept an input parameter encoding, defaulting to ASCII for the email case?  Should that be a new issue?  Or should cgi.py, since it can't use email to do all its work (no support for file storage, no support for encoding) simply not try, and use its own code for header decoding also?  The only cost would be support for Encoded-Word -- but it is not clear that HTTP uses them?  Can anyone give an example of such?  Read the next message here for an example of filename containing non-ASCII.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4953>
_______________________________________

From report at bugs.python.org  Tue Jan 11 11:40:19 2011
From: report at bugs.python.org (Glenn Linderman)
Date: Tue, 11 Jan 2011 10:40:19 +0000
Subject: [issue4953] cgi module cannot handle POST with multipart/form-data
	in	3.0
In-Reply-To: <1232010166.79.0.972664060868.issue4953@psf.upfronthosting.co.za>
Message-ID: <1294742419.34.0.576130561606.issue4953@psf.upfronthosting.co.za>


Glenn Linderman <v+python at g.nevcal.com> added the comment:

In my previous message I quoted Pierre rightly cautioning about headers containing non-ASCII... and that BytesFeedParser doesn't, so using it to parse headers may be questionable.

So I decided to try one... I show the Live HTTP headers below, from a simple upload form.  What is not so simple is the filename of the file to be uploaded... it contains a couple non-ASCII characters... in fact, one of them is non-latin-1 also: "fo??.html".  It rather seems that Firefox provides the filename in UTF-8, although Live HTTP headers seems to have displayed it using Latin-1 on the screen!  But in saving it to a file, it didn't write a BOM, and the byte sequence for the filename is definitely UTF-8, and pasted here to be viewed correctly.

So my question: where does Firefox get its authority to encode the filename using UTF-8 ???

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101203 Firefox/3.6.13
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 115
Connection: keep-alive
Referer: http://rkivs.com.gl:8032/row/test.html
Content-Type: multipart/form-data; boundary=---------------------------207991835220448
Content-Length: 304
-----------------------------207991835220448
Content-Disposition: form-data; name="submit"

upload
-----------------------------207991835220448
Content-Disposition: form-data; name="pre"; filename="fo??.html"
Content-Type: text/html

aoheutns

-----------------------------207991835220448--

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4953>
_______________________________________

From report at bugs.python.org  Tue Jan 11 11:47:25 2011
From: report at bugs.python.org (Ross Lagerwall)
Date: Tue, 11 Jan 2011 10:47:25 +0000
Subject: [issue10885] multiprocessing docs
In-Reply-To: <1294742845.68.0.53995604469.issue10885@psf.upfronthosting.co.za>
Message-ID: <1294742845.68.0.53995604469.issue10885@psf.upfronthosting.co.za>


New submission from Ross Lagerwall <rosslagerwall at gmail.com>:

I think there is a small docs bug: it says that multiprocessing.Semaphore is "a bounded semaphore". Shouldn't it says that it is just "a semaphore".

Attached is a patch to fix this.

----------
components: Library (Lib)
files: docupdate.patch
keywords: patch
messages: 125995
nosy: georg.brandl, rosslagerwall
priority: normal
severity: normal
status: open
title: multiprocessing docs
versions: Python 2.7, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file20354/docupdate.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10885>
_______________________________________

From report at bugs.python.org  Tue Jan 11 12:16:59 2011
From: report at bugs.python.org (Torsten Landschoff)
Date: Tue, 11 Jan 2011 11:16:59 +0000
Subject: [issue10886] Unhelpful backtrace for multiprocessing.Queue
In-Reply-To: <1294744619.25.0.366060169853.issue10886@psf.upfronthosting.co.za>
Message-ID: <1294744619.25.0.366060169853.issue10886@psf.upfronthosting.co.za>


New submission from Torsten Landschoff <t.landschoff at gmx.net>:

When trying to send an object via a Queue that can't be pickled, one gets a quite unhelpful traceback:

Traceback (most recent call last):
  File "/usr/lib/python2.6/multiprocessing/queues.py", line 242, in _feed
    send(obj)
PicklingError: Can't pickle <type 'module'>: attribute lookup __builtin__.module failed

I have no idea where I am sending this. It would be helpful to get the call trace to the call to Queue.put.

My workaround was to create a Queue via this function MyQueue:

def MyQueue():
    import cPickle
    def myput(obj, *args, **kwargs):
        cPickle.dumps(obj)
        return orig_put(obj, *args, **kwargs)

    q = Queue()
    orig_put, q.put = q.put, myput
    return q

That way I get the pickle exception in the caller to put and was able to find out the offending code.

----------
components: Library (Lib)
messages: 125996
nosy: torsten
priority: normal
severity: normal
status: open
title: Unhelpful backtrace for multiprocessing.Queue
type: feature request
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10886>
_______________________________________

From report at bugs.python.org  Tue Jan 11 12:26:10 2011
From: report at bugs.python.org (Tomas Kubes)
Date: Tue, 11 Jan 2011 11:26:10 +0000
Subject: [issue7229] Manual entry for time.daylight can be misleading
In-Reply-To: <1256723052.19.0.148648938954.issue7229@psf.upfronthosting.co.za>
Message-ID: <1294745170.59.0.81351156853.issue7229@psf.upfronthosting.co.za>


Tomas Kubes <mr_napik at centrum.cz> added the comment:

Hello,

I find this version very clear.

Thanks
Tomas

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7229>
_______________________________________

From report at bugs.python.org  Tue Jan 11 12:34:41 2011
From: report at bugs.python.org (anatoly techtonik)
Date: Tue, 11 Jan 2011 11:34:41 +0000
Subject: [issue10887] Add link to development ML
In-Reply-To: <1294745681.16.0.799239354624.issue10887@psf.upfronthosting.co.za>
Message-ID: <1294745681.16.0.799239354624.issue10887@psf.upfronthosting.co.za>


New submission from anatoly techtonik <techtonik at gmail.com>:

Tarek, can you add link to http://groups.google.com/group/the-fellowship-of-the-packaging to distutils dev pages at https://bitbucket.org/tarek/distutils2/wiki/Home ?

----------
assignee: tarek
components: Distutils2
messages: 125998
nosy: eric.araujo, tarek, techtonik
priority: normal
severity: normal
status: open
title: Add link to development ML

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10887>
_______________________________________

From report at bugs.python.org  Tue Jan 11 12:39:50 2011
From: report at bugs.python.org (Giampaolo Rodola')
Date: Tue, 11 Jan 2011 11:39:50 +0000
Subject: [issue10882] Add os.sendfile()
In-Reply-To: <1294691268.76.0.727179568007.issue10882@psf.upfronthosting.co.za>
Message-ID: <1294745990.88.0.206244876499.issue10882@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

Thanks for writing this.
Follows my comments.

I would focus on trying to provide a unique interface across all platforms. Being sendfile() not a standard POSIX I think we should not worry about providing a strict one-to-one interface.

"headers" and "trailers" arguments should be available everywhere as they are crucial in different protocols such as HTTP.
On Linux this is possible by using the TCP_CORK option.
"man sendfile" on Linux provides some information. Also you might find useful to see how medusa did this (/medusa-20010416/sendfile/sendfilemodule.c):
http://www.nightmare.com/medusa/

The "offset" parameter should be available everywhere, Linux included (in your patch you dropped Linux support).
Also, I think it should be optional since when it's NULL, sendfile() implicitly assumes the current offset (file's tell() return value).
This is true on Linux, at least. Not sure about other platforms but my best guess is that it should not be mandatory.

It turns out the only peculiar argument is "flags", available only on *BSD.
I'm not sure what's best to do here. Maybe it makes sense to provide it across all platforms, defaulting to 0 and raise ValueError when specified on systems != *BSD.
In summary, the function might look like this:

sendfile(out, in, count, offset=None, headers=None, trailers=None, flags=0)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10882>
_______________________________________

From report at bugs.python.org  Tue Jan 11 12:50:29 2011
From: report at bugs.python.org (Giampaolo Rodola')
Date: Tue, 11 Jan 2011 11:50:29 +0000
Subject: [issue10882] Add os.sendfile()
In-Reply-To: <1294691268.76.0.727179568007.issue10882@psf.upfronthosting.co.za>
Message-ID: <1294746629.49.0.61903154262.issue10882@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

> Also, I think it should be optional since when it's NULL, sendfile() 
> implicitly assumes the current offset (file's tell() return value).
> This is true on Linux, at least. Not sure about other platforms but my 
> best guess is that it should not be mandatory.

I'm not so sure about this anymore. Please ignore this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10882>
_______________________________________

From report at bugs.python.org  Tue Jan 11 13:12:54 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 11 Jan 2011 12:12:54 +0000
Subject: [issue10884] pkgutil EggInfoDistribution requirements for .egg-info
	metadata
In-Reply-To: <1294721787.13.0.963133670506.issue10884@psf.upfronthosting.co.za>
Message-ID: <1294747974.6.0.505040700127.issue10884@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Thanks Michael for the report and fix.   Would you add a test for that fix?

Minor note: I follow docstrings good practices in my commit messages, making sure that the first line makes sense on its own (it?s used in short logs) and wrapping my lines under 80 characters, for the usual reasons.

----------
versions: +3rd party -Python 2.5, Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10884>
_______________________________________

From report at bugs.python.org  Tue Jan 11 13:28:21 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 11 Jan 2011 12:28:21 +0000
Subject: [issue10848] Move test.regrtest from getopt to argparse
In-Reply-To: <1294353259.48.0.852026284896.issue10848@psf.upfronthosting.co.za>
Message-ID: <1294748901.69.0.257885402459.issue10848@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
keywords:  -easy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10848>
_______________________________________

From report at bugs.python.org  Tue Jan 11 13:34:26 2011
From: report at bugs.python.org (Ross Lagerwall)
Date: Tue, 11 Jan 2011 12:34:26 +0000
Subject: [issue10882] Add os.sendfile()
In-Reply-To: <1294691268.76.0.727179568007.issue10882@psf.upfronthosting.co.za>
Message-ID: <1294749266.49.0.872286980076.issue10882@psf.upfronthosting.co.za>


Ross Lagerwall <rosslagerwall at gmail.com> added the comment:

Just to be clear:

There are 3 different interfaces.
The basic one with the offset included & no headers/trailers is supported by all the platforms, including Linux.
The one with offset as None is only supported by Linux.
The one with headers/trailers/flags is supported by FreeBSD & OS X.

So it does provide a unique interface across all platforms while still providing the ability to access the native functionality.

Preferably, I'd like to see a thin wrapper like this remain and then have a sendfile() method added to the socket object which takes a file-like object (not a file descriptor) and optional headers/trailers. This method can then figure out how best to do it depending on the platform. (i.e. using TCP_CORK if necessary, etc). It could even be made to work with file-like objects that cannot be mmap()ed.

Why not put it straight in socket anyway? Well, some of the implementations allow sendfile() to have a normal fd as the output. Putting it in socket then would't make sense.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10882>
_______________________________________

From report at bugs.python.org  Tue Jan 11 13:41:10 2011
From: report at bugs.python.org (Edoardo Spadolini)
Date: Tue, 11 Jan 2011 12:41:10 +0000
Subject: [issue10868] ABCMeta.register() should work as a decorator
In-Reply-To: <1294529533.15.0.442078735636.issue10868@psf.upfronthosting.co.za>
Message-ID: <1294749670.51.0.969414646912.issue10868@psf.upfronthosting.co.za>


Edoardo Spadolini <kerio00 at gmail.com> added the comment:

Yeah, I should've waited for the test to finish, but come on, "it was just a small change" :(

Now I know why you should always test everything at least, sorry about that :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10868>
_______________________________________

From report at bugs.python.org  Tue Jan 11 14:13:01 2011
From: report at bugs.python.org (dobbelaj)
Date: Tue, 11 Jan 2011 13:13:01 +0000
Subject: [issue10888] os.stat(filepath).st_mode gives wrong 'executable
	permission' result
In-Reply-To: <1294751581.52.0.421644635374.issue10888@psf.upfronthosting.co.za>
Message-ID: <1294751581.52.0.421644635374.issue10888@psf.upfronthosting.co.za>


New submission from dobbelaj <jeroen.dobbelaere at gmail.com>:

The 'os.stat' method on windows seems to be hardcoded to check the file name extension when computing the 'executable permission flag' (st_mode).

(See Modules/posixmodule.c:  win32_stat and win32_wstat)

Currently, it checks for : 
 '.bat', '.cmd', '.exe', '.com'

As dynamic libraries also must be executable on window, t should also check for : 
 '.dll'

It would be even better if the actual 'read and execute' permission is returned.

----------
components: Windows
messages: 126004
nosy: jeroen.dobbelaere
priority: normal
severity: normal
status: open
title: os.stat(filepath).st_mode gives wrong 'executable permission' result
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10888>
_______________________________________

From report at bugs.python.org  Tue Jan 11 14:33:55 2011
From: report at bugs.python.org (Ulrich Seidl)
Date: Tue, 11 Jan 2011 13:33:55 +0000
Subject: [issue9692] UnicodeDecodeError in ElementTree.tostring()
In-Reply-To: <1282833776.05.0.825088232802.issue9692@psf.upfronthosting.co.za>
Message-ID: <1294752835.17.0.0612595600447.issue9692@psf.upfronthosting.co.za>


Ulrich Seidl <Ulrich.Seidl at muneda.com> added the comment:

I would suggest adding an additional except branch to (at least) the following functions of ElementTree.py:
* _encode,
* _escape_attrib, and
* _escape_cdata 

The except branch could look like:

except (UnicodeDecodeError):
    return text.decode( encoding ).encode( encoding, "xmlcharrefreplace")

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9692>
_______________________________________

From report at bugs.python.org  Tue Jan 11 15:04:00 2011
From: report at bugs.python.org (Timothy Farrell)
Date: Tue, 11 Jan 2011 14:04:00 +0000
Subject: [issue4953] cgi module cannot handle POST with multipart/form-data
	in	3.0
In-Reply-To: <1232010166.79.0.972664060868.issue4953@psf.upfronthosting.co.za>
Message-ID: <1294754640.01.0.383609504564.issue4953@psf.upfronthosting.co.za>


Changes by Timothy Farrell <tfarrell at owassobible.org>:


----------
nosy:  -tercero12

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4953>
_______________________________________

From report at bugs.python.org  Tue Jan 11 15:18:02 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 11 Jan 2011 14:18:02 +0000
Subject: [issue1667546] Time zone-capable variant of time.localtime
In-Reply-To: <1294740390.79.0.768157681082.issue1667546@psf.upfronthosting.co.za>
Message-ID: <AANLkTimMWNqqovHOmDaPrGp6ctq=rKAGZ1xNk7P97uL4@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Tue, Jan 11, 2011 at 5:06 AM, anatoly techtonik
<report at bugs.python.org> wrote:
..
> IIUC #9527 is about datetime and this request is about time.localtime,

This is correct, but did you notice what I wrote in my last message?

"""
In order to properly implement #9527 in datetime.py, some kind of
tm_gmtoff support will need to be added to the time module, but I
don't want this to become a feature that is exclusively available from
the time module.
"""

I am not rejecting this request, I am trying to consolidate two
closely related issues.  Can you explain why you believe this
functionality should be provided exclusively through the time module
and not be available in datetime?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1667546>
_______________________________________

From report at bugs.python.org  Tue Jan 11 15:44:54 2011
From: report at bugs.python.org (Giampaolo Rodola')
Date: Tue, 11 Jan 2011 14:44:54 +0000
Subject: [issue10882] Add os.sendfile()
In-Reply-To: <1294691268.76.0.727179568007.issue10882@psf.upfronthosting.co.za>
Message-ID: <1294757094.51.0.556517419282.issue10882@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

I agree then, although I'm not sure there are other functions in the os module (or anywhere else) having a variable number of args depending on the platform.
I wanted to try your patch but it does not apply cleanly (python 3.2, revision 87930).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10882>
_______________________________________

From report at bugs.python.org  Tue Jan 11 15:47:34 2011
From: report at bugs.python.org (Giampaolo Rodola')
Date: Tue, 11 Jan 2011 14:47:34 +0000
Subject: [issue10882] Add os.sendfile()
In-Reply-To: <1294691268.76.0.727179568007.issue10882@psf.upfronthosting.co.za>
Message-ID: <1294757254.74.0.737993601367.issue10882@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

I agree then, although I'm not sure having a function with a variable number of args depending on the platform is acceptable.
I wanted to try your patch but it does not apply cleanly (python 3.2, revision 87930).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10882>
_______________________________________

From report at bugs.python.org  Tue Jan 11 15:47:46 2011
From: report at bugs.python.org (Giampaolo Rodola')
Date: Tue, 11 Jan 2011 14:47:46 +0000
Subject: [issue10882] Add os.sendfile()
In-Reply-To: <1294691268.76.0.727179568007.issue10882@psf.upfronthosting.co.za>
Message-ID: <1294757266.4.0.712801103826.issue10882@psf.upfronthosting.co.za>


Changes by Giampaolo Rodola' <g.rodola at gmail.com>:


----------
Removed message: http://bugs.python.org/msg126007

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10882>
_______________________________________

From report at bugs.python.org  Tue Jan 11 15:47:46 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 11 Jan 2011 14:47:46 +0000
Subject: [issue10556] test_zipimport_support mucks up with modules
In-Reply-To: <1290900068.1.0.744896012432.issue10556@psf.upfronthosting.co.za>
Message-ID: <1294757266.61.0.246278428236.issue10556@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

2.7 and 3.1 don't appear to exhibit the fault, so closing this one.

----------
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10556>
_______________________________________

From report at bugs.python.org  Tue Jan 11 15:52:57 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 11 Jan 2011 14:52:57 +0000
Subject: [issue7229] Manual entry for time.daylight can be misleading
In-Reply-To: <1294739747.17.0.9995254198.issue7229@psf.upfronthosting.co.za>
Message-ID: <AANLkTi=Zn6tkHZLeyFVnGsd3HpEwNW-Mz=hQtVGxb8cP@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Tue, Jan 11, 2011 at 4:55 AM, anatoly techtonik
<report at bugs.python.org> wrote:
..
> I propose the following change:
..
> http://docs.python.org/library/time.html#time.daylight
> - ?Nonzero if a DST timezone is defined.
> + .. To check if DST is currently active, use `time.localtime(t).tm_isdst`

This is simply wrong. Your time.localtime(t).tm_isdst expression will
return the DST flag for the POSIX time value t, not for the current
time.  This could be fixed by replacing your proposed expression with
time.localtime().tm_isdst, but why do you think someone  reading about
time.daylight actually wants to "check if DST is currently active"?

What can be improved, though, is the documentation of time.tzset().
The current version fails to mention that  time.tzset() resets the
values of tzname, timezone, altzone and daylight.  This would be the
proper place to document the meaning of all three variables in greater
detail.  Individual entries can then refer to it with say "See
time.tzset() for details."

Here is how POSIX tzset() is defined:

"""
The tzset() function sets the external variable tzname as follows:

tzname[0] = "std";
tzname[1] = "dst";

where std and dst are as described in the XBD specification,
Environment Variables .

The tzset() function also sets the external variable daylight to 0 if
Daylight Savings Time conversions should never be applied for the time
zone in use; otherwise non-zero. The external variable timezone is set
to the difference, in seconds, between Coordinated Universal Time
(UTC) and local standard time.
"""  http://pubs.opengroup.org/onlinepubs/007908799/xsh/tzset.html

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7229>
_______________________________________

From report at bugs.python.org  Tue Jan 11 16:16:45 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 11 Jan 2011 15:16:45 +0000
Subject: [issue9051] Improve pickle format for aware datetime instances
In-Reply-To: <1277151308.95.0.331220838487.issue9051@psf.upfronthosting.co.za>
Message-ID: <1294759005.26.0.850087126885.issue9051@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


----------
versions: +Python 3.3 -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9051>
_______________________________________

From report at bugs.python.org  Tue Jan 11 16:36:04 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 11 Jan 2011 15:36:04 +0000
Subject: [issue9118] help() on a property descriptor launches interactive help
In-Reply-To: <1277836369.81.0.859952586368.issue9118@psf.upfronthosting.co.za>
Message-ID: <1294760164.21.0.324360833087.issue9118@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Backported to 3.1 (r87934) and 2.7 (r87935).

----------
resolution: accepted -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9118>
_______________________________________

From report at bugs.python.org  Tue Jan 11 16:36:56 2011
From: report at bugs.python.org (david)
Date: Tue, 11 Jan 2011 15:36:56 +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: <1294760216.38.0.0377281828892.issue10441@psf.upfronthosting.co.za>


david <db.pub.mail at gmail.com> added the comment:

Thank you @loewis. However, I don't see where set_default_verify_path - is defined in the patch you have provided.

It would also be nice to do something like this:
import ssl
...
ssl._FORCE_VERIFICATION = True

and even better would be to determine the CA path as @pitrou was suggesting and incorporate this into the ssl module somehow.

----------
nosy: +db

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10441>
_______________________________________

From report at bugs.python.org  Tue Jan 11 16:43:20 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 11 Jan 2011 15:43:20 +0000
Subject: [issue1100942] Add datetime.time.strptime and datetime.date.strptime
Message-ID: <1294760600.4.0.615887474704.issue1100942@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

New patch needed to address the issue of time.strftime() accepting %Y when year is 1900 and other similar oddities.  See msg107402 above.  Also a patch for datetime.py is needed.

----------
stage: patch review -> needs patch
versions: +Python 3.3 -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1100942>
_______________________________________

From report at bugs.python.org  Tue Jan 11 16:48:38 2011
From: report at bugs.python.org (Giampaolo Rodola')
Date: Tue, 11 Jan 2011 15:48:38 +0000
Subject: [issue4112] Subprocess: Popen'ed children hang due to open pipes
In-Reply-To: <1223894179.31.0.303015562598.issue4112@psf.upfronthosting.co.za>
Message-ID: <1294760918.89.0.810606824447.issue4112@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/issue4112>
_______________________________________

From report at bugs.python.org  Tue Jan 11 16:48:57 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 11 Jan 2011 15:48:57 +0000
Subject: [issue5109] array.array constructor very slow when passed an array
	object.
In-Reply-To: <1233318806.98.0.166527784762.issue5109@psf.upfronthosting.co.za>
Message-ID: <1294760937.76.0.00908223942207.issue5109@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Georg,

Is it too late to commit this for 3.2?

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5109>
_______________________________________

From report at bugs.python.org  Tue Jan 11 16:52:55 2011
From: report at bugs.python.org (Ross Lagerwall)
Date: Tue, 11 Jan 2011 15:52:55 +0000
Subject: [issue10882] Add os.sendfile()
In-Reply-To: <1294691268.76.0.727179568007.issue10882@psf.upfronthosting.co.za>
Message-ID: <1294761175.82.0.659665118309.issue10882@psf.upfronthosting.co.za>


Ross Lagerwall <rosslagerwall at gmail.com> added the comment:

I've just tried it against r87935 and it applies cleanly.

Perhaps you didn't apply the patch correctly (it requires "-p1" since it was a Mercurial diff), try:
   patch -p1 < sendfile_v2.patch

With regards to the different arguments, I don't know if that's acceptable or not or if there is a better way. Since you can have mmap.mmap() with differing args between Windows & Unix, maybe it is acceptable. And, Python exposes differing functionality via the posix module since the available functions differs widely between platforms.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10882>
_______________________________________

From report at bugs.python.org  Tue Jan 11 16:54:50 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 11 Jan 2011 15:54:50 +0000
Subject: [issue9860] Building python outside of source directory fails
In-Reply-To: <1284559695.71.0.359508650396.issue9860@psf.upfronthosting.co.za>
Message-ID: <1294761290.89.0.744774361528.issue9860@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Here is a related bug:

$ make patchcheck
./python.exe ../py3k-commit/Tools/scripts/patchcheck.py
Getting the list of files that have been added/changed ... need a checkout to get modified files
[49399 refs]
make: *** [patchcheck] Error 1

----------
versions: +Python 3.3 -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9860>
_______________________________________

From report at bugs.python.org  Tue Jan 11 16:59:29 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 11 Jan 2011 15:59:29 +0000
Subject: [issue10889] Fix range slicing and indexing to handle lengths >
	sys.maxsize
In-Reply-To: <1294761569.28.0.225841776524.issue10889@psf.upfronthosting.co.za>
Message-ID: <1294761569.28.0.225841776524.issue10889@psf.upfronthosting.co.za>


New submission from Nick Coghlan <ncoghlan at gmail.com>:

Enhancement to range to correctly handle indexing and slicing when len(x) raises OverflowError.

Note that this enables correct calculation of the length of such ranges via:

        def _range_len(x):
            try:
                length = len(x)
            except OverflowError:
                step = x[1] - x[0]
                length = 1 + ((x[-1] - x[0]) // step)
            return length

----------
assignee: ncoghlan
messages: 126017
nosy: ncoghlan
priority: normal
severity: normal
status: open
title: Fix range slicing and indexing to handle lengths > sys.maxsize

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10889>
_______________________________________

From report at bugs.python.org  Tue Jan 11 17:05:54 2011
From: report at bugs.python.org (Brian Curtin)
Date: Tue, 11 Jan 2011 16:05:54 +0000
Subject: [issue10888] os.stat(filepath).st_mode gives wrong 'executable
	permission' result
In-Reply-To: <1294751581.52.0.421644635374.issue10888@psf.upfronthosting.co.za>
Message-ID: <1294761954.45.0.478746512926.issue10888@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

The "Read & Execute" permission listed on a file's property window doesn't really mean anything. Executables only need read permissions [0] to actually be executed.

Additionally, in terms of _stat, Windows does its check by extension [1] but they don't specify what extensions they look for.

Adding ".dll" checking would be the most we could do here.



[0] http://technet.microsoft.com/en-us/library/bb727008.aspx
[1] See "st_mode" halfway down the page, http://msdn.microsoft.com/en-us/library/14h5k7ff(v=VS.90).aspx

----------
components: +Extension Modules
keywords: +easy
nosy: +brian.curtin
stage:  -> needs patch
versions: +Python 3.1, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10888>
_______________________________________

From report at bugs.python.org  Tue Jan 11 17:20:21 2011
From: report at bugs.python.org (Tomas Kubes)
Date: Tue, 11 Jan 2011 16:20:21 +0000
Subject: [issue7229] Manual entry for time.daylight can be misleading
In-Reply-To: <1256723052.19.0.148648938954.issue7229@psf.upfronthosting.co.za>
Message-ID: <1294762821.02.0.411400646391.issue7229@psf.upfronthosting.co.za>


Tomas Kubes <mr_napik at centrum.cz> added the comment:

>>why do you think someone  reading about
time.daylight actually wants to "check if DST is currently active"?

If you are not familiar with the cryptic names of POSIX but live in normal world, time.daylight sounds like a quite probable place where to check if the daylight savings are active. That's why I think the help text should explicitely note it has other meaning.

You should try to think like a person that does not have any background knowledge of underlying libraries but just looks through the time library trying to solve the question - how can I check if my machine uses daylight savings now.

Regards
Tomas

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7229>
_______________________________________

From report at bugs.python.org  Tue Jan 11 17:22:28 2011
From: report at bugs.python.org (Brian Curtin)
Date: Tue, 11 Jan 2011 16:22:28 +0000
Subject: [issue7229] Manual entry for time.daylight can be misleading
In-Reply-To: <1256723052.19.0.148648938954.issue7229@psf.upfronthosting.co.za>
Message-ID: <1294762948.69.0.757733053736.issue7229@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
nosy:  -brian.curtin

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7229>
_______________________________________

From report at bugs.python.org  Tue Jan 11 17:26:31 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 11 Jan 2011 16:26:31 +0000
Subject: [issue9305] Don't use east/west of UTC in date/time documentation
In-Reply-To: <1279556505.28.0.814004588201.issue9305@psf.upfronthosting.co.za>
Message-ID: <1294763191.61.0.184014624161.issue9305@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

I've noticed that the time module docstring handles this issue rather nicely:

>>> help('time')
...
    timezone -- difference in seconds between UTC and local standard time
    altzone -- difference in  seconds between UTC and local DST time

We can use similar language for utcoffset(): "difference between local time and UTC expressed as a timedelta".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9305>
_______________________________________

From report at bugs.python.org  Tue Jan 11 17:39:50 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 11 Jan 2011 16:39:50 +0000
Subject: [issue7229] Manual entry for time.daylight can be misleading
In-Reply-To: <1294762821.02.0.411400646391.issue7229@psf.upfronthosting.co.za>
Message-ID: <AANLkTimmA=ozOns4BbBsmaT7KOu+Bh3_f5D3vy87yAHT@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Tue, Jan 11, 2011 at 11:20 AM, Tomas Kubes <report at bugs.python.org> wrote:
..
> You should try to think like a person that does not have any background knowledge of underlying libraries but
> just looks through the time library trying to solve the question - how can I check if my machine uses daylight
> savings now.

I think you are confusing the purposes of a reference manual with that
of a tutorial or an FAQ collection.

I will keep this issue open, however, in case someone will come up
with a patch that does not introduce factual mistakes.   As I
suggested, the place to present details about tzname, timezone,
altzone and daylight variables is the section on time.tzset().  It is
currently devoted to a rather useless discussion of the TZ environment
variable syntax.  Instead, it should describe these variables and list
the functions whose behavior depends on the value of TZ
(time.localtime(), time.ctime(), time.mktime() and time.strftime()).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7229>
_______________________________________

From report at bugs.python.org  Tue Jan 11 17:56:39 2011
From: report at bugs.python.org (Ross Lagerwall)
Date: Tue, 11 Jan 2011 16:56:39 +0000
Subject: [issue10885] multiprocessing docs
In-Reply-To: <1294742845.68.0.53995604469.issue10885@psf.upfronthosting.co.za>
Message-ID: <1294764999.64.0.502587194498.issue10885@psf.upfronthosting.co.za>


Changes by Ross Lagerwall <rosslagerwall at gmail.com>:


----------
assignee:  -> docs at python
components: +Documentation
nosy: +docs at python

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10885>
_______________________________________

From report at bugs.python.org  Tue Jan 11 17:57:11 2011
From: report at bugs.python.org (Tomas Kubes)
Date: Tue, 11 Jan 2011 16:57:11 +0000
Subject: [issue7229] Manual entry for time.daylight can be misleading
In-Reply-To: <1256723052.19.0.148648938954.issue7229@psf.upfronthosting.co.za>
Message-ID: <1294765031.26.0.216259312364.issue7229@psf.upfronthosting.co.za>


Tomas Kubes <mr_napik at centrum.cz> added the comment:

> I think you are confusing the purposes of a reference manual with that
of a tutorial or an FAQ collection.

There is a fine line between them. Even though reference manual should not be a substitute for a tutorial, I still believe it should try to clarify potential confusions - after all it is the less experienced users who will most likely spend their time with it looking for something.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7229>
_______________________________________

From report at bugs.python.org  Tue Jan 11 18:14:39 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 11 Jan 2011 17:14:39 +0000
Subject: [issue10889] Fix range slicing and indexing to handle lengths >
	sys.maxsize
In-Reply-To: <1294761569.28.0.225841776524.issue10889@psf.upfronthosting.co.za>
Message-ID: <1294766079.67.0.475070368388.issue10889@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Having started work on this, the code changes are probably too significant to consider adding it to 3.2 at this late stage.

Writing my own slice interpretation support which avoids the ssize_t limit is an interesting exercise :)

----------
versions: +Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10889>
_______________________________________

From report at bugs.python.org  Tue Jan 11 18:28:15 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 11 Jan 2011 17:28:15 +0000
Subject: [issue10875] Update Regular Expression HOWTO
In-Reply-To: <1294604409.29.0.577762819836.issue10875@psf.upfronthosting.co.za>
Message-ID: <1294766895.38.0.49029861427.issue10875@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
Removed message: http://bugs.python.org/msg125954

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10875>
_______________________________________

From report at bugs.python.org  Tue Jan 11 18:46:30 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 11 Jan 2011 17:46:30 +0000
Subject: [issue10875] Update Regular Expression HOWTO
In-Reply-To: <1294604409.29.0.577762819836.issue10875@psf.upfronthosting.co.za>
Message-ID: <1294767990.76.0.851522702608.issue10875@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Correction: r87912 and r87913 for 3.x

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10875>
_______________________________________

From report at bugs.python.org  Tue Jan 11 19:13:01 2011
From: report at bugs.python.org (Jeroen Dobbelaere)
Date: Tue, 11 Jan 2011 18:13:01 +0000
Subject: [issue10888] os.stat(filepath).st_mode gives wrong 'executable
	permission' result
In-Reply-To: <1294751581.52.0.421644635374.issue10888@psf.upfronthosting.co.za>
Message-ID: <1294769581.88.0.0818988977974.issue10888@psf.upfronthosting.co.za>


Jeroen Dobbelaere <jeroen.dobbelaere at gmail.com> added the comment:

Some more background:
The actual issue was initially detected when observing that the 'tarfile' package produced a tar containing different permissions, depending on the script being executed by 'cygwin python' or 'native python'.

When using native python to do the 'untar', I did not observe any issue (as it seems to automatically add 'read and execute' for all files).
But, when I used 'cygwin tar', the .dll did not get its 'read and execute' permission (as it was not specified in the tar file), which then resulted in program that crashed (with a very unhelpful message). Allowing 'read and execute' manually resolved the crash.

So, although this permission should not mean anything, it does seem to have some influence :(

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10888>
_______________________________________

From report at bugs.python.org  Tue Jan 11 19:14:06 2011
From: report at bugs.python.org (rurpy the second)
Date: Tue, 11 Jan 2011 18:14:06 +0000
Subject: [issue1397474] timeit execution enviroment
Message-ID: <1294769646.21.0.3653114015.issue1397474@psf.upfronthosting.co.za>


rurpy the second <rurpy at yahoo.com> added the comment:

I find the changes suggested by T Reedy and refined in the 
patch by E Bendersky an improvement.  However, I found the 
following things confused me when reading it:

"...constructor creates a function..."
the constructor creates a Timeit instance, not a function.  
There is a method on that instance that is the function but 
the way it is phrased in like describing the autos coming off
a Ford production line as "steering wheels".  As written, the 
statement creates an immediate WTF reaction in my mind.

"...that executes the *setup* statement..."
Use of term "statement" here is confusing as that term already
has a well defined meaning in Python docs.  One can't syntactically
use a statement as a function argument.  Only by suspending this
confusion and reading further does one discover that "statement"
here means a string containing text of some python code or a 
callable object.  

Use of "statement" (singular) also directly conflicts with following 
information that states multiple statements are ok.  

Since the synopsis line already refers to "snippets", I think 
continuing to use that is better (having no preexisting conflicting
meanings) than "statement".

"...default to ``'pass'`..." 
The call summary immediately above makes clear what the default
parameter values are.  While fine to repeat it in text, it is not
high priority information so should be moved to later in the
description.

"...or newlines as long as they don???t contain  multi-line string literals..."
What is a multi-line string literal?  The Language Reference -> 
Lexical Analysis -> String Literals section says nothing about 
"multi-line literals".  
Is it "a\nb"?  Or """a
b"""?  Both?
'"a\nb"' actually works.  '"""a
b"""' doesn't of course but it is it is also clearly not valid
python string syntax so I'm not sure that 'multi-line strings need 
even be mentioned.  If it is mentioned then it should be made clear 
that multi-line string literals are not allowed not because timeit
doesn't like them, but because python syntax allows no way to 
embed them in another string.
.
"...pre-defined user objects..."
What does "pre-defined" mean?  Builtin?  Imported from stdlib?
I would use a more explicit description here.

I also think a short explanation of *why* one needs to import 
program objects in 'setup' makes it a little easier and quicker 
to understand what one is doing with the import, particularly if
one is using timeit somewhere other than __main__..  Thus I 
suggest expanding that section slightly.

Here is my attempt to adjust taking the above observations into 
account.  (Sorry, can't supply a patch since I have slow internet
connection and don't have source.  Text below is just my hand edit
of the "+" lines in Eli's patch.)

  Class for timing execution speed of small code snippets.
  A Timeit instance will contain a function (see :meth:`Timer.timeit`)
  that executes a snippet of "setup" code once and then times some 
  number of executions of "stmt" code .  The code snippets, given as
  arguments *setup* and *stmt* when creating the instance, may be 
  either strings or callable objects.

  If a string, it may contain a python expression, statement, or
  multiple statements separated by ";" or newlines.  Whitespace 
  adhering to the usual Python indentation rules must follow any
  newlines.

  If a callable object, (often a function), the object is called 
  with no arguments.  Note that the timing overhead is a little 
  larger in this case because of the extra function calls required.

  The *setup* and *stmt* parameters default to ``'pass'``.
  The *timer* parameter defaults to a platform-dependent 
  timer function (see the module doc string).

  When the *setup* and *stmt* are run, they are run in a 
  different namespace than that of the code that calls timeit(). 
  To give *stmt* (whether it is a callable name or code string) 
  access to  objects defined in the code that calls timeit, 
  *setup* can import any needed objects.  For example, if your
  code defines function testfunc(), *setup* can contain, 
  ``from __main__ import testfunc``, and code in   *stmt* can
  then call testfunc.

  To measure the execution time of *stmt*, use the :meth:`Timer.timeit()` method. 
  The :meth:`Timer.repeat()` method is a convenience to call :meth:`Timer.timeit()` 
  multiple times and return a list of results.

  Changed in version 2.6: The stmt and setup parameters can now
  also take objects.

Notes:
----
Added the line "Whitespace adhering..." because when using backslash-n
in strings it is easy to forget about any needed indentation.  Sentence
could be deleted if deemed too obvious.  There may also be a better 
way to phrase it; currently it might imply that some whitespace
is always neccessary if not enough attention paid to the "usual
indentation rules" phrase.

----
In msg116330 - Eli Bendersky (eli.bendersky) wrote:

> 1) My tests show that passing the callable instead of the string
> 'test()' actually takes longer to run.

Should the documentation promise that?
I take your word that it also takes longer than running the function's
code directly (outside a function) 
     
The original "Changed in version 2.6" section said

| Note that the timing overhead is a little larger in this case 
| [callable objects] because of the extra function calls.

Here, "the other case" is presumably the plain code but could 
also be a string function call (e.g. "test()") so I suppose it
is still vacuously true in that case.  Accordingly I reused the
statement above in in my suggested changes.  Perhaps all three 
cases (string code, string function call, callable object) 
should be distinguished further and compared re overhead?

----------
nosy: +rurpy2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1397474>
_______________________________________

From report at bugs.python.org  Tue Jan 11 19:19:44 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 11 Jan 2011 18:19:44 +0000
Subject: [issue10889] Fix range slicing and indexing to handle lengths >
	sys.maxsize
In-Reply-To: <1294761569.28.0.225841776524.issue10889@psf.upfronthosting.co.za>
Message-ID: <1294769984.28.0.683615170929.issue10889@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Attached patch moves range indexing and slicing over to PyLong and updates the tests accordingly.

Georg, I think this really makes the large range story far more usable - if you're OK with it, I would like to check it in this week so it lands in 3.2.

----------
assignee: ncoghlan -> georg.brandl
keywords: +patch
nosy: +georg.brandl
versions: +Python 3.2 -Python 3.3
Added file: http://bugs.python.org/file20355/issue10889_range_subscripts.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10889>
_______________________________________

From report at bugs.python.org  Tue Jan 11 19:25:24 2011
From: report at bugs.python.org (Brian Curtin)
Date: Tue, 11 Jan 2011 18:25:24 +0000
Subject: [issue10888] os.stat(filepath).st_mode gives wrong 'executable
	permission' result
In-Reply-To: <1294751581.52.0.421644635374.issue10888@psf.upfronthosting.co.za>
Message-ID: <1294770324.01.0.10520219211.issue10888@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

> The actual issue was initially detected when observing that the
> 'tarfile' package produced a tar containing different permissions,
> depending on the script being executed by 'cygwin python' or 'native python'.

I would expect that. Each of those work in their own world when it comes to file permissions, and there really isn't a 1-to-1 match when it comes to working in both environments.


On native Windows, "Read & Execute" has no real affect on applications, as it appears to be a synthetic permission probably constructed for that property window. I just looked at a number of definitely not executable files on my computer (e.g., text files), and they are all listed as "Read & Execute". Even by right clicking and adding a new file with a garbage name, no extension, and no contents, it's still "Read & Execute" enabled.

Additionally, there is no programmatic way to set that "Read & Execute" flag that you see in the property window.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10888>
_______________________________________

From report at bugs.python.org  Tue Jan 11 19:34:54 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 11 Jan 2011 18:34:54 +0000
Subject: [issue10889] Fix range slicing and indexing to handle lengths >
	sys.maxsize
In-Reply-To: <1294761569.28.0.225841776524.issue10889@psf.upfronthosting.co.za>
Message-ID: <1294770894.48.0.348668661624.issue10889@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Oh, and to explain my negative comment from earlier: that was my reaction when I realised I also needed to write PyLong versions of _PyEval_SliceIndex and PySlice_GetIndicesEx to make range slicing with large integers work properly.

As it turned out, the end result wasn't as scary as I initially feared (while compute_slice_indices is quite long, most of that is just the verbosity of PyLong arithmetic).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10889>
_______________________________________

From report at bugs.python.org  Tue Jan 11 19:42:30 2011
From: report at bugs.python.org (yeswanth)
Date: Tue, 11 Jan 2011 18:42:30 +0000
Subject: [issue2650] re.escape should not escape underscore
In-Reply-To: <1208441650.53.0.945063086485.issue2650@psf.upfronthosting.co.za>
Message-ID: <1294771350.71.0.487882979415.issue2650@psf.upfronthosting.co.za>


Changes by yeswanth <swamiyeswanth at yahoo.com>:


----------
nosy: +swamiyeswanth

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2650>
_______________________________________

From report at bugs.python.org  Tue Jan 11 19:44:11 2011
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 11 Jan 2011 18:44:11 +0000
Subject: [issue10889] Fix range slicing and indexing to handle lengths >
	sys.maxsize
In-Reply-To: <1294761569.28.0.225841776524.issue10889@psf.upfronthosting.co.za>
Message-ID: <1294771451.89.0.138275829039.issue10889@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

It's a moderate chunk of code, but lots of new tests... I'd say go for it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10889>
_______________________________________

From report at bugs.python.org  Tue Jan 11 19:46:58 2011
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 11 Jan 2011 18:46:58 +0000
Subject: [issue5109] array.array constructor very slow when passed an array
	object.
In-Reply-To: <1233318806.98.0.166527784762.issue5109@psf.upfronthosting.co.za>
Message-ID: <1294771618.67.0.608795022422.issue5109@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Should be fine to apply.  I trust all the different code paths for different types are tested?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5109>
_______________________________________

From report at bugs.python.org  Tue Jan 11 19:56:54 2011
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 11 Jan 2011 18:56:54 +0000
Subject: [issue7229] Manual entry for time.daylight can be misleading
In-Reply-To: <1256723052.19.0.148648938954.issue7229@psf.upfronthosting.co.za>
Message-ID: <1294772214.87.0.0663546786939.issue7229@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

It seems to me that the quoted function from bzr

def local_time_offset(t=None):
    """Return offset of local zone from GMT, either at present or at time t."""
    # python2.3 localtime() can't take None
    if t is None:
        t = time.time()

    if time.localtime(t).tm_isdst and time.daylight:
        return -time.altzone
    else:
        return -time.timezone

would be very helpful to add to the `time` module docs as an example.  I have to agree with the OP that the current state of the docs is not as clear as it could be.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7229>
_______________________________________

From report at bugs.python.org  Tue Jan 11 20:42:09 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 11 Jan 2011 19:42:09 +0000
Subject: [issue7229] Manual entry for time.daylight can be misleading
In-Reply-To: <1294772214.87.0.0663546786939.issue7229@psf.upfronthosting.co.za>
Message-ID: <AANLkTinFTkwCLOyn9f6rE2-wKr-iSJ-Pdk1Rd7yKTxmw@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Tue, Jan 11, 2011 at 1:56 PM, Georg Brandl <report at bugs.python.org> wrote:
..
> It seems to me that the quoted function from bzr ...
> would be very helpful to add to the `time` module docs as an example.

The problem with this function is the same as with the doc patches
that have been proposed so far.  It is subtly wrong.  See issue
#1647654.  Specifically, see the link to a bug in Hg mentioned in
msg122166.

>?I have to agree with the OP that the current state of the docs is not as clear as it could be.

In some ways the state of the docs is reflective of the state of the
code.  C/POSIX API on which time module design is based is not very
well suited to the age of smart phones and distributed VC systems.
The whole idea that there is a static "system timezone" is absurd when
a "system" is in your pocket or in the cloud.

I agree that the docs can be improved, but I don't see patches that
would constitute an improvement.  I've explained what I would see as
an improvement in my prior comments.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7229>
_______________________________________

From report at bugs.python.org  Tue Jan 11 21:51:58 2011
From: report at bugs.python.org (Sergey Shepelev)
Date: Tue, 11 Jan 2011 20:51:58 +0000
Subject: [issue10880] do_mkvalue and 'boolean'
In-Reply-To: <1294678522.28.0.674271875959.issue10880@psf.upfronthosting.co.za>
Message-ID: <1294779118.18.0.80550361061.issue10880@psf.upfronthosting.co.za>


Sergey Shepelev <temotor at gmail.com> added the comment:

Here's patch against 2.6


--- a/Python/modsupport.c	Tue Aug 24 18:19:58 2010 +0200
+++ b/Python/modsupport.c	Tue Jan 11 23:50:40 2011 +0300
@@ -459,6 +459,16 @@
             return v;
         }
 
+        case '?':
+        {
+            int n;
+            n = va_arg(*p_va, int);
+            if (n == 0)
+                Py_RETURN_FALSE;
+            else
+                Py_RETURN_TRUE;
+        }
+
         case ':':
         case ',':
         case ' ':

----------
nosy: +temoto

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10880>
_______________________________________

From report at bugs.python.org  Tue Jan 11 22:04:02 2011
From: report at bugs.python.org (Pierre Quentel)
Date: Tue, 11 Jan 2011 21:04:02 +0000
Subject: [issue4953] cgi module cannot handle POST with multipart/form-data
	in	3.0
In-Reply-To: <1232010166.79.0.972664060868.issue4953@psf.upfronthosting.co.za>
Message-ID: <1294779842.81.0.280746462868.issue4953@psf.upfronthosting.co.za>


Pierre Quentel <pierre.quentel at gmail.com> added the comment:

@Glenn
"I'm curious what your system (probably Windows since you mention cp-) and browser, and HTTP server is, that you used for that test.  Is it possible to capture the data stream for that test?  Describe how, and at what stage the data stream was captured, if you can capture it.  Most interesting would be on the interface between browser and HTTP server."

I tested it on Windows XP Family Edition 2020, Service Pack 3, with Python 3.2b2
Browsers : Mozilla Firefox 3.6.13 and Internet Explorer 7.0
Servers : Apache 2.2, and the built-in server started by :

import http.server
http.server.test(HandlerClass=http.server.CGIHTTPRequestHandler)

I print the bytes received in the multipart/form-data part by "print(odelim+line)" at the end of method  read_lines_to_outerboundary() of FieldStorage. The bytes sent when I enter the string 
    "a"+"n tilde" + the euro sign 
are : b'a\xf1\x80' - that is, the cp-1252 encoding of the string

Since it works the same with 2 browsers and 2 web servers, I'm almost sure it's not dependant on the configuration - but if others can tests on different configurations I'd like to know the result

Basically, this behaviour is not surprising : if sys.stdin.encoding is set to a certain value, it's natural that the bytes sent on the binary layer are encoded with this encoding, not with latin-1

I attach the diff file for an updated version of cgi.py :
- new argument stream_encoding instead of setting an attribute "encoding" to fp
- use locale.getpreferredencoding() to decode the query string

----------
Added file: http://bugs.python.org/file20356/cgi_diff_20110111.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4953>
_______________________________________

From report at bugs.python.org  Tue Jan 11 22:15:00 2011
From: report at bugs.python.org (anatoly techtonik)
Date: Tue, 11 Jan 2011 21:15:00 +0000
Subject: [issue7229] Manual entry for time.daylight can be misleading
In-Reply-To: <AANLkTi=Zn6tkHZLeyFVnGsd3HpEwNW-Mz=hQtVGxb8cP@mail.gmail.com>
Message-ID: <AANLkTi=t2548FPZQQTYbyyxWGJdoeB4EmYR9Esu=tuea@mail.gmail.com>


anatoly techtonik <techtonik at gmail.com> added the comment:

On Tue, Jan 11, 2011 at 4:52 PM, Alexander Belopolsky
<report at bugs.python.org> wrote:
> ..
>> http://docs.python.org/library/time.html#time.daylight
>> - ?Nonzero if a DST timezone is defined.
>> + .. To check if DST is currently active, use `time.localtime(t).tm_isdst`
>
> This is simply wrong. Your time.localtime(t).tm_isdst expression will
> return the DST flag for the POSIX time value t, not for the current
> time. ?This could be fixed by replacing your proposed expression with
> time.localtime().tm_isdst, but why do you think someone ?reading about
> time.daylight actually wants to "check if DST is currently active"?

Sorry, I've just copy/pasted this snippet and haven't noticed t argument.

As for your question, I think that someone reading about time.daylight
is reading about it to know how it can be used, and if you're quoting,
please quote without removing words inside the quote, or else I won't
be able to give you the answers that will be appropriate in your
context.

> What can be improved, though, is the documentation of time.tzset().
> The current version fails to mention that ?time.tzset() resets the
> values of tzname, timezone, altzone and daylight. ?This would be the
> proper place to document the meaning of all three variables in greater
> detail. ?Individual entries can then refer to it with say "See
> time.tzset() for details."

How about making it in iterations and keep the steps as small as
possible, i.e. split the big problem into munchable chunks? First we
can accept the version of doc from my previous comment and then open a
new RFE for further work. Considering how much time this issue took
already, I see this approach as the only viable one.

> Here is how POSIX tzset() is defined:
> ...

I am sorry Alexander, but I can't really follow up on this issue. It
is interesting, but unfortunately right now I can only dedicate my
time to things that take don't more than 15 minutes of my attention,
and there are about 50 out of 700 of these in my inbox right now. We
need to split these datetime problems into smaller ones somehow. They
are really too complex for users.

To summarize: What is wrong with my previous proposal if we remove t
from params?

P.S. Looks like we need a PEP for this. =)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7229>
_______________________________________

From report at bugs.python.org  Tue Jan 11 22:22:24 2011
From: report at bugs.python.org (anatoly techtonik)
Date: Tue, 11 Jan 2011 21:22:24 +0000
Subject: [issue7229] Manual entry for time.daylight can be misleading
In-Reply-To: <AANLkTinFTkwCLOyn9f6rE2-wKr-iSJ-Pdk1Rd7yKTxmw@mail.gmail.com>
Message-ID: <AANLkTi=g0pCiWqmeCuDOUFhf+pAg_0OMuKaQn+G82XOc@mail.gmail.com>


anatoly techtonik <techtonik at gmail.com> added the comment:

On Tue, Jan 11, 2011 at 9:42 PM, Alexander Belopolsky
<report at bugs.python.org> wrote:
>
>>?I have to agree with the OP that the current state of the docs is not as clear as it could be.
>
> In some ways the state of the docs is reflective of the state of the
> code. ?C/POSIX API on which time module design is based is not very
> well suited to the age of smart phones and distributed VC systems.
> The whole idea that there is a static "system timezone" is absurd when
> a "system" is in your pocket or in the cloud.
>
> I agree that the docs can be improved, but I don't see patches that
> would constitute an improvement. ?I've explained what I would see as
> an improvement in my prior comments.

Absurd need to be eliminated, but every time I touch datetime issues I
am confused by the complexity of additional information and
incompatibility of low-level C API with user needs. We need datetime
FAQ for a reference and a collection of user stories to see what it
possible (with examples/recipes) and what is impossible (with
proposals/PEP) in current state. If I was in charge - I'd mark all
datetime issues as release blockers for Py3k, so that all who wanted
Py3k released ASAP dedicate their time to this problem.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7229>
_______________________________________

From report at bugs.python.org  Tue Jan 11 22:27:26 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 11 Jan 2011 21:27:26 +0000
Subject: [issue7229] Manual entry for time.daylight can be misleading
In-Reply-To: <AANLkTi=t2548FPZQQTYbyyxWGJdoeB4EmYR9Esu=tuea@mail.gmail.com>
Message-ID: <AANLkTikYbXX+pm=PRZBRJZkb02kh-2oqvPpFnR2aXF5F@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Tue, Jan 11, 2011 at 4:15 PM, anatoly techtonik
<report at bugs.python.org> wrote:
..
> To summarize: What is wrong with my previous proposal if we remove t
> from params?

Not much is wrong with it.   If it would come in a form of a patch and
without typos or mark-up mistakes, I or another committer would
probably apply it as an incremental improvement.   However, given that
additional effort is needed to apply your suggestion, I would rather
wait until a better solution is available.  Specifically, I don like
the duplication of time.localtime().tm_isdst recipe in daylight and
altzone.  Also, these variables should really be grouped together in
the docs.   I would like this to be done before a committer spends
time proofreading, fixing reST markup and committing the change.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7229>
_______________________________________

From report at bugs.python.org  Tue Jan 11 23:05:15 2011
From: report at bugs.python.org (Giampaolo Rodola')
Date: Tue, 11 Jan 2011 22:05:15 +0000
Subject: [issue10882] Add os.sendfile()
In-Reply-To: <1294691268.76.0.727179568007.issue10882@psf.upfronthosting.co.za>
Message-ID: <1294783515.96.0.698021544025.issue10882@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

The patch as-is did not work on Linux. 
I had to add entries in pyconfig.h.in and configure files in order to make os.sendfile available.
Patch is in attachment.

----------
Added file: http://bugs.python.org/file20357/sendfile_v2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10882>
_______________________________________

From report at bugs.python.org  Tue Jan 11 23:07:55 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 11 Jan 2011 22:07:55 +0000
Subject: [issue5109] array.array constructor very slow when passed an array
	object.
In-Reply-To: <1233318806.98.0.166527784762.issue5109@psf.upfronthosting.co.za>
Message-ID: <1294783675.48.0.324104075106.issue5109@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Committed in revision 87942.

@Georg: Yes, I ran coverage and all branches are covered.

@Meador: I don't think the old len calculation could handle the case of array object in initial.  In any case, I don't find the new code much more complicated than the old one.  To the contrary, a chain of simple if-else looks cleaner than the original 2-line boolean expression.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5109>
_______________________________________

From report at bugs.python.org  Tue Jan 11 23:17:26 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 11 Jan 2011 22:17:26 +0000
Subject: [issue5109] array.array constructor very slow when passed an array
	object.
In-Reply-To: <1233318806.98.0.166527784762.issue5109@psf.upfronthosting.co.za>
Message-ID: <1294784246.09.0.659352498729.issue5109@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Committed to 2.7 in revision 87944.

----------
stage: commit review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5109>
_______________________________________

From report at bugs.python.org  Tue Jan 11 23:36:57 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 11 Jan 2011 22:36:57 +0000
Subject: [issue5109] array.array constructor very slow when passed an array
	object.
In-Reply-To: <1233318806.98.0.166527784762.issue5109@psf.upfronthosting.co.za>
Message-ID: <1294785417.98.0.300650316748.issue5109@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Reverted backport in r87945.

----------
versions:  -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5109>
_______________________________________

From report at bugs.python.org  Tue Jan 11 23:40:47 2011
From: report at bugs.python.org (Roumen Petrov)
Date: Tue, 11 Jan 2011 22:40:47 +0000
Subject: [issue8957] strptime('%c', ..) fails to parse output of strftime('%c',
	..) in non-English locale
In-Reply-To: <1276115080.37.0.388300880324.issue8957@psf.upfronthosting.co.za>
Message-ID: <1294785647.91.0.386826152215.issue8957@psf.upfronthosting.co.za>


Roumen Petrov <bugtrack at roumenpetrov.info> added the comment:

time.strptime(s, '%c' ) ?

----------
nosy: +rpetrov

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8957>
_______________________________________

From report at bugs.python.org  Tue Jan 11 23:45:51 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 11 Jan 2011 22:45:51 +0000
Subject: [issue8957] strptime('%c', ..) fails to parse output of strftime('%c',
	..) in non-English locale
In-Reply-To: <1276115080.37.0.388300880324.issue8957@psf.upfronthosting.co.za>
Message-ID: <1294785951.37.0.869611209634.issue8957@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

> time.strptime(s, '%c' ) ?

Oh my.  It certainly took a long time to recognize a silly mistake!

Thanks.

----------
dependencies:  -Use locale.nl_langinfo in _strptime
resolution:  -> invalid

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8957>
_______________________________________

From report at bugs.python.org  Tue Jan 11 23:51:53 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Tue, 11 Jan 2011 22:51:53 +0000
Subject: [issue5924] When setting complete PYTHONPATH on Python 3.x,
	paths in the PYTHONPATH are ignored
In-Reply-To: <1241463970.43.0.829234478071.issue5924@psf.upfronthosting.co.za>
Message-ID: <1294786313.99.0.358440022338.issue5924@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Unless you think the code is actually incorrect as it stands, it's certainly worse to change it (in whatever respect) than to leave it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5924>
_______________________________________

From report at bugs.python.org  Wed Jan 12 00:00:27 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 11 Jan 2011 23:00:27 +0000
Subject: [issue8957] strptime('%c', ..) fails to parse output of strftime('%c',
	..) in non-English locale
In-Reply-To: <1276115080.37.0.388300880324.issue8957@psf.upfronthosting.co.za>
Message-ID: <1294786827.02.0.604337853856.issue8957@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8957>
_______________________________________

From report at bugs.python.org  Wed Jan 12 00:01:16 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Tue, 11 Jan 2011 23:01:16 +0000
Subject: [issue10888] os.stat(filepath).st_mode gives wrong 'executable
	permission' result
In-Reply-To: <1294751581.52.0.421644635374.issue10888@psf.upfronthosting.co.za>
Message-ID: <1294786876.07.0.835910309996.issue10888@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Brian: "On native Windows, "Read & Execute" has no real affect on applications". Why do you say that? The FILE_EXECUTE permission certainly has a meaning on Windows, see

http://msdn.microsoft.com/en-us/library/gg258116(v=vs.85).aspx

I agree that FILE_EXECUTE is, in principle, mostly the equivalent of the x bit on POSIX. Unfortunately, it's also confusing, since most files have that permission.

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10888>
_______________________________________

From report at bugs.python.org  Wed Jan 12 00:03:29 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Tue, 11 Jan 2011 23:03:29 +0000
Subject: [issue10441] some stdlib modules need to be updated to handle
	SSL	certificate validation
In-Reply-To: <1294760216.38.0.0377281828892.issue10441@psf.upfronthosting.co.za>
Message-ID: <4D2CE1BC.5090405@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> Thank you @loewis. However, I don't see where 
> set_default_verify_path - is defined in the patch you have provided.

It's not defined in the patch, as it is already committed to Python.

----------
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 Jan 12 00:06:51 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Tue, 11 Jan 2011 23:06:51 +0000
Subject: [issue10882] Add os.sendfile()
In-Reply-To: <1294745990.88.0.206244876499.issue10882@psf.upfronthosting.co.za>
Message-ID: <4D2CE288.3070306@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> I would focus on trying to provide a unique interface across all
> platforms. Being sendfile() not a standard POSIX I think we should
> not worry about providing a strict one-to-one interface.

We absolutely need to expose sendfile as-is. If we want to provide
some unifying layer, we must not call it sendfile.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10882>
_______________________________________

From report at bugs.python.org  Wed Jan 12 00:10:11 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 11 Jan 2011 23:10:11 +0000
Subject: [issue10225] Fix doctest runable examples in python manual
In-Reply-To: <1288318735.45.0.959857258913.issue10225@psf.upfronthosting.co.za>
Message-ID: <1294787411.16.0.552389169733.issue10225@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Doctest runs on .rst files, which are plain text files, finds and reports errors, and reports no errors when the errors are fixed. See #10875 where is was very helpful. So your last comment puzzles me.

In any case, your patch is too big to digest at once. I extracted the part for howto/sorting.rst and tried to apply to 3.2, but the file has changed too much (at least for TortoiseSVN). So I pasted the '... 's (and adjusted spacing) where needed, and did the two other changes you had. This left just two failures -- for the 2.7 code using 'cmp=xxx' args. With '# doctest: +SKIP' added twice, doctest passes. Patch commited for 3.2 as r87946.

> instances when human and computer reader's interests are in conflict.
What is one (or more) that you were thinking of?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10225>
_______________________________________

From report at bugs.python.org  Wed Jan 12 00:17:09 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 11 Jan 2011 23:17:09 +0000
Subject: [issue10225] Fix doctest runable examples in python manual
In-Reply-To: <1294787411.16.0.552389169733.issue10225@psf.upfronthosting.co.za>
Message-ID: <AANLkTikiQZGX-NC6wb=cgOrThZYa9efN3=PQ8Pnbw+DQ@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Tue, Jan 11, 2011 at 6:10 PM, Terry J. Reedy <report at bugs.python.org> wrote:
..
> Doctest runs on .rst files, which are plain text files, finds and reports errors, and reports no errors when the errors are fixed.
> See #10875 where is was very helpful. So your last comment puzzles me.
>

Sphinx doctest runner supports doctest fixtures that plain doctest
does not.  Some of the examples in the docs rely on these.

See http://sphinx.pocoo.org/ext/doctest.html .

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10225>
_______________________________________

From report at bugs.python.org  Wed Jan 12 00:48:39 2011
From: report at bugs.python.org (Brian Curtin)
Date: Tue, 11 Jan 2011 23:48:39 +0000
Subject: [issue10888] os.stat(filepath).st_mode gives wrong 'executable
	permission' result
In-Reply-To: <1294751581.52.0.421644635374.issue10888@psf.upfronthosting.co.za>
Message-ID: <1294789719.13.0.372836889022.issue10888@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

I meant that it doesn't have any effect because it's apparently always set from what I could see, which was poor wording. The TechNet article also made a similar claim. If it is ever not set, then the file clearly can't be executed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10888>
_______________________________________

From report at bugs.python.org  Wed Jan 12 00:50:05 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 11 Jan 2011 23:50:05 +0000
Subject: [issue7057] tkinter doc: more 3.x updates
In-Reply-To: <1254697168.63.0.205098696566.issue7057@psf.upfronthosting.co.za>
Message-ID: <1294789805.46.0.848504751362.issue7057@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> I used 'manN'
FYI, there is a :file:`man{n}` construct where braces mark up replaceable text, like the var element in HTML.

----------
nosy: +docs at python, eric.araujo -georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7057>
_______________________________________

From report at bugs.python.org  Wed Jan 12 00:53:28 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 11 Jan 2011 23:53:28 +0000
Subject: [issue3693] Obscure array.array error message
In-Reply-To: <1219801896.33.0.491668230509.issue3693@psf.upfronthosting.co.za>
Message-ID: <1294790008.27.0.877683341526.issue3693@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
components: +Extension Modules -Library (Lib)
nosy: +alexandre.vassalotti, georg.brandl
stage: unit test needed -> needs patch
versions: +Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3693>
_______________________________________

From report at bugs.python.org  Wed Jan 12 01:04:12 2011
From: report at bugs.python.org (Roumen Petrov)
Date: Wed, 12 Jan 2011 00:04:12 +0000
Subject: [issue9419] RUNSHARED needs LDFLAGS
In-Reply-To: <1280423222.23.0.51081739049.issue9419@psf.upfronthosting.co.za>
Message-ID: <1294790652.96.0.036892300877.issue9419@psf.upfronthosting.co.za>


Roumen Petrov <bugtrack at roumenpetrov.info> added the comment:

Yes Peter, build outside source tree fail for,  fail for me and pass for python developers :). So no idea how to convince them to fix this issue.

Next is from my sources for python 2.7

Index: Lib/distutils/tests/test_build_ext.py
===================================================================
--- Lib/distutils/tests/test_build_ext.py       (revision 87946)
+++ Lib/distutils/tests/test_build_ext.py       (working copy)
@@ -91,6 +91,9 @@
             sys.stdout = StringIO()
         try:
             cmd.ensure_finalized()
+            #Broken after issue 7712(r78136) : add a temp_cwd context manager to test_support ...
+            #Without current working dir: "...cannot find -lpython27"
+            cmd.library_dirs.insert(0, test_support.SAVEDCWD)
             cmd.run()
         finally:
             sys.stdout = old_stdout
@@ -284,6 +287,12 @@
         # returns wrong result with --inplace
         other_tmp_dir = os.path.realpath(self.mkdtemp())
         old_wd = os.getcwd()
+        print >> sys.stderr, "...TRACE test_build_ext.py:test_get_outputs old_wd=%s" %(old_wd)
+        #Without current working dir: "...cannot find -lpython27"
+        #NOTE: After issue #7712(r78136) test cannot use old_wd !
+        #cmd.library_dirs.insert(0, old_wd)
+        cmd.library_dirs.insert(0, test_support.SAVEDCWD)
+        #?#cmd.library_dirs.insert(0, old_wd)
         os.chdir(other_tmp_dir)
         try:
             cmd.inplace = 1
=================================

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9419>
_______________________________________

From report at bugs.python.org  Wed Jan 12 01:08:43 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 12 Jan 2011 00:08:43 +0000
Subject: [issue8957] strptime('%c', ..) fails to parse output of strftime('%c',
	..) in non-English locale
In-Reply-To: <1276115080.37.0.388300880324.issue8957@psf.upfronthosting.co.za>
Message-ID: <1294790923.92.0.18684035199.issue8957@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

My tests were wrong but the problem does exist.  I am attaching a script that tests strptime(.., '%c') for all locales installed on my system (an unmodified  US Mac OS X 10.6.6).  

The only failing locale that I recognize is Hebrew (he_IL).  Eli, what do you think about this?

 
$ ./python.exe cfmt.py 
am_ET [??? ??? 11 18:56:18 2011] %A %B %d %H:%M:%S %Y != %a %b %e %H:%M:%S %Y
et_EE [T, 11. jaan  2011. 18:56:18] %a, %d. %B %Y. %H:%M:%S != %a, %d. %b %Y. %T
he_IL [EST 18:56:18 2011 ??? 11 ?'] %Z %H:%M:%S %Y %B %d %a != %Z %H:%M:%S %Y %b %d %a

----------
dependencies: +Use locale.nl_langinfo in _strptime
nosy: +eli.bendersky
resolution: invalid -> 
status: closed -> open
Added file: http://bugs.python.org/file20358/cfmt.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8957>
_______________________________________

From report at bugs.python.org  Wed Jan 12 01:09:29 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 12 Jan 2011 00:09:29 +0000
Subject: [issue8957] strptime(.., '%c') fails to parse output of strftime('%c',
	..) in some locales
In-Reply-To: <1276115080.37.0.388300880324.issue8957@psf.upfronthosting.co.za>
Message-ID: <1294790969.71.0.332543825838.issue8957@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


----------
title: strptime('%c', ..) fails to parse output of strftime('%c', ..) in non-English locale -> strptime(.., '%c') fails to parse output of strftime('%c', ..) in some locales

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8957>
_______________________________________

From report at bugs.python.org  Wed Jan 12 01:12:19 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 12 Jan 2011 00:12:19 +0000
Subject: [issue10885] multiprocessing docs
In-Reply-To: <1294742845.68.0.53995604469.issue10885@psf.upfronthosting.co.za>
Message-ID: <1294791139.77.0.793914185892.issue10885@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +asksol, jnoller

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10885>
_______________________________________

From report at bugs.python.org  Wed Jan 12 01:21:00 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 12 Jan 2011 00:21:00 +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: <1294791660.22.0.74447943151.issue4395@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +docs at python -georg.brandl
stage:  -> needs patch
type:  -> behavior
versions: +Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4395>
_______________________________________

From report at bugs.python.org  Wed Jan 12 01:23:31 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 12 Jan 2011 00:23:31 +0000
Subject: [issue10799] Improve webbrowser.open doc (and, someday, behavior?)
In-Reply-To: <1293767251.94.0.704365544958.issue10799@psf.upfronthosting.co.za>
Message-ID: <1294791811.71.0.632386139594.issue10799@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> I thought of adding 'http://' if not present but that would disable opening files in a file browser.

I think that?s a Windows-specific behavior, not a promise of the *web*browser module.

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10799>
_______________________________________

From report at bugs.python.org  Wed Jan 12 01:26:43 2011
From: report at bugs.python.org (Roumen Petrov)
Date: Wed, 12 Jan 2011 00:26:43 +0000
Subject: [issue8957] strptime(.., '%c') fails to parse output of strftime('%c',
	..) in some locales
In-Reply-To: <1276115080.37.0.388300880324.issue8957@psf.upfronthosting.co.za>
Message-ID: <1294792003.64.0.335181029397.issue8957@psf.upfronthosting.co.za>


Roumen Petrov <bugtrack at roumenpetrov.info> added the comment:

- %T is equal for %H:%M:%S
- locales with %A and %B are broken on this platform as %c is "Appropriate date and time representation (%c) with abbreviations"

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8957>
_______________________________________

From report at bugs.python.org  Wed Jan 12 01:28:31 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 12 Jan 2011 00:28:31 +0000
Subject: [issue9419] RUNSHARED needs LDFLAGS
In-Reply-To: <1280423222.23.0.51081739049.issue9419@psf.upfronthosting.co.za>
Message-ID: <1294792111.62.0.808960618769.issue9419@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

> build outside source tree fail for me and pass for python
> developers :). So no idea how to convince them to fix this issue.

I am collecting out of tree build failures in issue 9860.  One issue that is easily reproducible is triggered when there are object files in the tree from another build, but it looks like you see something else.

As for convincing developers to fix a bug, the best approach is to propose a patch! :-)

----------
nosy: +belopolsky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9419>
_______________________________________

From report at bugs.python.org  Wed Jan 12 01:34:44 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 12 Jan 2011 00:34:44 +0000
Subject: [issue8957] strptime(.., '%c') fails to parse output of strftime('%c',
	..) in some locales
In-Reply-To: <1294792003.64.0.335181029397.issue8957@psf.upfronthosting.co.za>
Message-ID: <AANLkTikadQe0RQe_VwM1vsCp4qnK59G8QHM9sQK7GpU_@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Tue, Jan 11, 2011 at 7:26 PM, Roumen Petrov <report at bugs.python.org> wrote:
..
> - locales with %A and %B are broken on this platform as %c is "Appropriate date and time representation (%c) with abbreviations"

According to what standard? POSIX defines it as

%c Replaced by the locale's appropriate date and time representation.

http://pubs.opengroup.org/onlinepubs/009695399/functions/strftime.html

and the manual page on my system agrees:

 %c    is replaced by national representation of time and date.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8957>
_______________________________________

From report at bugs.python.org  Wed Jan 12 01:36:23 2011
From: report at bugs.python.org (Glenn Linderman)
Date: Wed, 12 Jan 2011 00:36:23 +0000
Subject: [issue4953] cgi module cannot handle POST with multipart/form-data
	in	3.0
In-Reply-To: <1232010166.79.0.972664060868.issue4953@psf.upfronthosting.co.za>
Message-ID: <1294792583.58.0.261559920547.issue4953@psf.upfronthosting.co.za>


Glenn Linderman <v+python at g.nevcal.com> added the comment:

Pierre said:
Since it works the same with 2 browsers and 2 web servers, I'm almost sure it's not dependant on the configuration - but if others can tests on different configurations I'd like to know the result

So I showed in my just previous messages (after the one you are responding to) my output from Live HTTP Headers, where it seems that Firefox is using UTF-8 transmission, both for header values (filename) and data values (euro character).  Without specifying Content-Type (for the data) or doing RFC 2047 encoding as would be expected from reading the various standard documents (RFC 2045, W3 HTML 4.01, RFC 2388).  I wonder now if Live HTTP Headers is reporting the logical data, prior to encoding for transmission.  But I was getting UTF-8 data inside my CGI script... 

So now I tweaked the server to save the bytes it transfers its rfile to the cgi process (had already tweaked that to be binary instead of having encodings), and it is clearly UTF-8 at that point also.  Looks just like the Live HTTP headers.  Now that I have data-capture on the server side, I can run the same tests with other browsers... so I ran it with Opera 11, IE 8, Chrome 8, and the only differences were the specific value of the boundaries... all the data was in UTF-8, both filename, and form data value.

I can't now find a setting for Firefox to allow the user to control the encoding it sends to the server, but I can't rule out that I once might have, and set it to UTF-8.  But I'm quite certain I don't know enough about the other browsers to adjust their settings.  I don't have Apache installed on this box, so I cannot test to see if it changes something.

Is there a newer standard these browsers are following, that permits UTF-8?  Or even requires it?

Why is Pierre seeing cp-1252, and I'm seeing UTF-8?  I'm running Windows 6.1 (Build 7600), 64-bit, the so-called Windows 7 Professional edition.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4953>
_______________________________________

From report at bugs.python.org  Wed Jan 12 01:36:46 2011
From: report at bugs.python.org (Roumen Petrov)
Date: Wed, 12 Jan 2011 00:36:46 +0000
Subject: [issue9419] RUNSHARED needs LDFLAGS
In-Reply-To: <1280423222.23.0.51081739049.issue9419@psf.upfronthosting.co.za>
Message-ID: <1294792606.85.0.624039865473.issue9419@psf.upfronthosting.co.za>


Roumen Petrov <bugtrack at roumenpetrov.info> added the comment:

Alexander, I already answer to you case.
About the patch it is part of issue3871 ;)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9419>
_______________________________________

From report at bugs.python.org  Wed Jan 12 01:54:13 2011
From: report at bugs.python.org (Etienne Robillard)
Date: Wed, 12 Jan 2011 00:54:13 +0000
Subject: [issue4953] cgi module cannot handle POST with multipart/form-data
	in	3.0
In-Reply-To: <1294792583.58.0.261559920547.issue4953@psf.upfronthosting.co.za>
Message-ID: <4D2CFE70.5090008@gthcfoundation.org>


Etienne Robillard <erob at gthcfoundation.org> added the comment:

On 11/01/11 07:36 PM, Glenn Linderman wrote:
> Is there a newer standard these browsers are following, that permits UTF-8?  Or even requires it?
>
> Why is Pierre seeing cp-1252, and I'm seeing UTF-8?  I'm running Windows 6.1 (Build 7600), 64-bit, the so-called Windows 7 Professional edition.
>
> ----------
>
>   

May be your browser have differents assumptions on what charset is valid
for encoding multipart
form data... For instance, all modern browsers allow customizing
charsets based on the user's locale.

Lastly this behavior is well-defined in RFC 2616, as the
"Accept-Charset" HTTP header:

   "The Accept-Charset request-header field can be used to indicate what
   character sets are acceptable for the response. This field allows
   clients capable of understanding more comprehensive or special-
   purpose character sets to signal that capability to a server which is
   capable of representing documents in those character sets."

just my 2 cents while watching a boring hockey game... :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4953>
_______________________________________

From report at bugs.python.org  Wed Jan 12 02:02:08 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 12 Jan 2011 01:02:08 +0000
Subject: [issue10225] Fix doctest runable examples in python manual
In-Reply-To: <1288318735.45.0.959857258913.issue10225@psf.upfronthosting.co.za>
Message-ID: <1294794128.41.0.424767788036.issue10225@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Terry, I'm unhappy with the changes to the sorting how-to.  IMO, it was a not a net win (transforming code that already ran fine in something doctest would swallow).  The code snippets now have the visual clutter of the ">>>" and "..." PS1 and PS2 prompts and they can no longer be readily cut and pasted into the interpreter so that people can experiment with them.

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10225>
_______________________________________

From report at bugs.python.org  Wed Jan 12 02:44:34 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 12 Jan 2011 01:44:34 +0000
Subject: [issue7662] time.utcoffset()
In-Reply-To: <1263057341.16.0.947515103763.issue7662@psf.upfronthosting.co.za>
Message-ID: <1294796674.55.0.0392033123661.issue7662@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

I am going to close this as superseded by #9527.  All these issues, current, #9527, and #1647654 are really about Python's lack of access to the system timezone information and #9527 seem to be the most appropriate solution.

My specific concern about proposed time.utcoffset() is that you normally need UTC offset together with current time, but localtime() call followed by utcoffset() may lead to a race condition.

----------
resolution:  -> rejected
status: open -> pending
superseder:  -> Add aware local time support to datetime module

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7662>
_______________________________________

From report at bugs.python.org  Wed Jan 12 02:59:52 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 12 Jan 2011 01:59:52 +0000
Subject: [issue5516] equality not symmetric for subclasses of datetime.date
	and datetime.datetime
In-Reply-To: <1237423886.27.0.985547007127.issue5516@psf.upfronthosting.co.za>
Message-ID: <1294797592.0.0.429342913491.issue5516@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


----------
keywords:  -patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5516>
_______________________________________

From report at bugs.python.org  Wed Jan 12 03:07:14 2011
From: report at bugs.python.org (Glenn Linderman)
Date: Wed, 12 Jan 2011 02:07:14 +0000
Subject: [issue4953] cgi module cannot handle POST with multipart/form-data
	in	3.0
In-Reply-To: <1232010166.79.0.972664060868.issue4953@psf.upfronthosting.co.za>
Message-ID: <1294798034.23.0.645802705375.issue4953@psf.upfronthosting.co.za>


Glenn Linderman <v+python at g.nevcal.com> added the comment:

Aha!

Found a page <http://htmlpurifier.org/docs/enduser-utf8.html#whyutf8-support> which links to another page <http://web.archive.org/web/20060427015200/ppewww.ph.gla.ac.uk/~flavell/charset/form-i18n.html> that explains the behavior.

The synopsis is that browsers (all modern browsers) return form data
Form data is generally returned in the same character encoding as the Form page itself was sent to the client.

I suspect this explains the differences between what Pierre and I are reporting.  I suspect (but would appreciate confirmation from Pierre), that his web pages use 
<meta http-equiv="Content-Type" content="text/html; charset=CP-1252" />
or else do not use such a meta tag, and his server is configured (or defaults) to send HTTP headers:
Content-Type: text/html; charset=CP-1252

Whereas, I do know that all my web pages are coded in UTF-8, have no meta tags, and my CGI scripts are sending 
Content-Type: text/html; charset=UTF-8
for all served form pages... and thus getting back UTF-8 also, per the above explanation.

What does this mean for Python support for http.server and cgi?
Well, http.server, by default, sends Content-Type without charset, except for directory listings, where it supplies charset= the result of sys.getfilesystemcoding().  So it is up to META tags to define the coding, or for the browser to guess.  That's probably OK: for a single machine environment, it is likely that the data files are coded in the default file system encoding, and it is likely the browser will guess that.  But it quickly breaks when going to a multiple machine or internet environment with different default encodings on different machines.  So if using http.server in such an environment, it is necessary to inform the client of the page encoding using META tags, or generating the Content-Type: HTTP header in the CGI script (which latter is what I'm doing for the forms and data of interest).

What does it mean for cgi.py's FieldStorage?

Well, use of the default encoding can work in the single machine environment... so I guess there are would be worse things that doing so, as Pierre has been doing.  But clearly, that isn't the complete solution.  The new parameter he proposes to FieldStorage can be used, if the application can properly determine the likeliest encoding for the form data, before calling it.

On a single machine system, that could be the default, as mentioned above.  On a single application web server, it could be some constant encoding used for all pages (like I use UTF-8 for all my pages).  For a multiple application web server, as long as each application uses a consistent encoding, that application could properly guess the encoding to pass to FieldStorage.  Or, if the application wishes to allow multiple encodings, as long as it can keep track of them, and use the right ones at the right time, it is welcome to.

How does this affect email?  Not at all, directly.

How does this affect cgi.py's use of email?
It means that cgi.py cannot use BytesFeedParser, in spite of what the standards say, so Pierre's approach of predecoding the headers is the correct one, since email doesn't offer an encoding parameter.  Since email doesn't support disk storage for file uploads, but buffers everything in memory, it means that cgi.py can only pass headers to FeedParser, so has to detect end-of-headers itself, since email provides no feedback to indicate that end-of-headers was reached, and that means that cgi.py must parse the MIME parts itself, so it can put the large parts on disk. It means that the email package provides extremely little value to cgi.py, and since web browsers and multipart/form-data use simple subsets of the full power of RFC822 headers, email could be replaced with the use of its existing parse_header function, but that should be deprecated.  A copy could be moved inside FieldStorage class and fixed a bit.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4953>
_______________________________________

From report at bugs.python.org  Wed Jan 12 03:14:48 2011
From: report at bugs.python.org (Glenn Linderman)
Date: Wed, 12 Jan 2011 02:14:48 +0000
Subject: [issue4953] cgi module cannot handle POST with multipart/form-data
	in	3.0
In-Reply-To: <1232010166.79.0.972664060868.issue4953@psf.upfronthosting.co.za>
Message-ID: <1294798488.17.0.55897884621.issue4953@psf.upfronthosting.co.za>


Glenn Linderman <v+python at g.nevcal.com> added the comment:

I notice the version on this issue is Python 3.3, but it affects 3.2 and 3.1 as well.  While I would like to see it fixed for 3.2, perhaps it is too late for that, with rc1 coming up this weekend?

Could at least the non-deprecated parse functions be deprecated in 3.2, so that they could be removed in 3.3?  Or should we continue to support them?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4953>
_______________________________________

From report at bugs.python.org  Wed Jan 12 04:03:57 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 12 Jan 2011 03:03:57 +0000
Subject: [issue10225] Fix doctest runable examples in python manual
In-Reply-To: <1288318735.45.0.959857258913.issue10225@psf.upfronthosting.co.za>
Message-ID: <1294801437.06.0.921332361387.issue10225@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

There are two reasons I forward ported the changes.

1. Without running doctest on doc examples, they sometimes have errors either originally, after patches to the doc, or after patches to Python. On other issues, I found 4 errors in the json doc (probably original; my fixes were augmented and committed by GB, I believe), and several in the re howto (due to non-update after re changes). There have been other error reports on the tracker and I presume more (other than missing '...') shown in AB's patch. (I just started with the first file changed in the patch.) So I thought it pretty well settled that getting doc examples correct (and test-ready) is be a good idea.

2. Examples with output always start with '>>> ' to differentiate input from output. I thought it pretty standard that continuation lines start with '... '. This is true of all applicable examples in re howto, module chapters for difflib, json, bisect, and 4 of 5 applicable examples in the Built-in Types chapter. Other chapters for binhex, itertools, and tkinter have no multiline interactive examples, so provide no precedent either way.

What is the alternative? The current sorting howto is not consistent:

For some examples, '... ' is just deleted:
>>> student_tuples = [
    ('john', 'A', 15),
    ('jane', 'B', 12),
    ('dave', 'B', 10),
]

For others, '... ' is replaced with '    ':
>>> class Student:
        def __init__(self, name, grade, age):
            self.name = name
            self.grade = grade
            self.age = age

The cmp_to_key function def is a special case: there is no output in the same box with the def and so (normally) should not have prompts. The only reason I followed AB's patch here and added them is because the definition is used in the next box. If the next example were changed for 3.2 to use the new-in-3.2  functools.cmp_to_key(), then the def would not be needed.  (I already planned to suggest thisOr the followup example could just be marked SKIP. With either change, I would remove the prompts added to this function, which are the ones I presume bother you the most.


Summary: according to my current (and subject-to-update ;-) understanding of precedent and policy, the changes other than for cmp_to_key seem correct. The rationale for cmp_to_key changes could easily be negated, in which case they should be reverted.

I will put my thoughts on cut-and-paste in a separate message.

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10225>
_______________________________________

From report at bugs.python.org  Wed Jan 12 04:19:36 2011
From: report at bugs.python.org (david)
Date: Wed, 12 Jan 2011 03:19:36 +0000
Subject: [issue10441] some stdlib modules need to be updated to handle SSL
	certificate validation
In-Reply-To: <4D2CE1BC.5090405@v.loewis.de>
Message-ID: <AANLkTi=5=uB=mOTk96j2wL_fUZCwnvxwP4-TugtVCr09@mail.gmail.com>


david <db.pub.mail at gmail.com> added the comment:

and what does it do ?

----------
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 Jan 12 04:21:57 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 12 Jan 2011 03:21:57 +0000
Subject: [issue10889] Fix range slicing and indexing to handle lengths >
	sys.maxsize
In-Reply-To: <1294761569.28.0.225841776524.issue10889@psf.upfronthosting.co.za>
Message-ID: <1294802517.93.0.998885218377.issue10889@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Committed as r87948.

I added a few large_range tests to those in the patch. I checked that IndexError is raised when appropriate, as well as a specific test for the combination of a large range with a large negative step.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10889>
_______________________________________

From report at bugs.python.org  Wed Jan 12 04:22:45 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 12 Jan 2011 03:22:45 +0000
Subject: [issue10889] Fix range slicing and indexing to handle lengths >
	sys.maxsize
In-Reply-To: <1294761569.28.0.225841776524.issue10889@psf.upfronthosting.co.za>
Message-ID: <1294802565.11.0.51419781997.issue10889@psf.upfronthosting.co.za>


Changes by Nick Coghlan <ncoghlan at gmail.com>:


----------
resolution:  -> accepted
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10889>
_______________________________________

From report at bugs.python.org  Wed Jan 12 04:44:04 2011
From: report at bugs.python.org (James)
Date: Wed, 12 Jan 2011 03:44:04 +0000
Subject: [issue10890] IDLE Freezing
In-Reply-To: <1294803844.35.0.517588470253.issue10890@psf.upfronthosting.co.za>
Message-ID: <1294803844.35.0.517588470253.issue10890@psf.upfronthosting.co.za>


New submission from James <jamgood96 at gmail.com>:

Recently installed Python 2.7.1 on my MacBook running OS X 10.6.6 and have not been able to use IDLE without it freezing. When I force quit it doesn't show that it's not responding. I can run scripts fine, but if I were to try to copy-paste, or save via command-S, it will lock up completely.

----------
assignee: ronaldoussoren
components: Macintosh
messages: 126070
nosy: jamgood96, ronaldoussoren
priority: normal
severity: normal
status: open
title: IDLE Freezing
type: crash
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10890>
_______________________________________

From report at bugs.python.org  Wed Jan 12 05:08:41 2011
From: report at bugs.python.org (Ned Deily)
Date: Wed, 12 Jan 2011 04:08:41 +0000
Subject: [issue10890] IDLE Freezing
In-Reply-To: <1294803844.35.0.517588470253.issue10890@psf.upfronthosting.co.za>
Message-ID: <1294805321.61.0.909172017829.issue10890@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Unfortunately, there are some major stability problems with IDLEs that are linked with the Apple-supplied Tcl/Tk 8.5 in OS X 10.6. (See, for instance, Issue9763 and Issue10537.) That includes the current python.org 2.7.1 64-bit installer.  The simplest workaround at the moment is to use the other, 32-bit-only 2.7.1 installer for OS X available here:  http://www.python.org/download/releases/2.7.1/

It uses the Apple Tcl/Tk 8.4 or ActiveTcl 8.4, if present, neither of which exhibits these kinds of problems.

----------
nosy: +ned.deily
resolution:  -> duplicate
stage:  -> committed/rejected
status: open -> closed
superseder:  -> OS X IDLE 2.7 from 64-bit installer hangs when you paste something.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10890>
_______________________________________

From report at bugs.python.org  Wed Jan 12 05:13:06 2011
From: report at bugs.python.org (Ross Lagerwall)
Date: Wed, 12 Jan 2011 04:13:06 +0000
Subject: [issue10882] Add os.sendfile()
In-Reply-To: <1294691268.76.0.727179568007.issue10882@psf.upfronthosting.co.za>
Message-ID: <1294805586.77.0.183975785223.issue10882@psf.upfronthosting.co.za>


Ross Lagerwall <rosslagerwall at gmail.com> added the comment:

Oh sorry, that was because it changed configure.in so "autoreconf" needs to be run to regenerate configure & pyconfig.h.in.

I thought that patches weren't meant to include the regenerated files. Especially since differences in the versions between autoconf 2.65 & 2.67 can produce hundreds of differences in "configure" making the patch large and obfuscating the actual changes.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10882>
_______________________________________

From report at bugs.python.org  Wed Jan 12 05:21:55 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 12 Jan 2011 04:21:55 +0000
Subject: [issue10225] Fix doctest runable examples in python manual
In-Reply-To: <1288318735.45.0.959857258913.issue10225@psf.upfronthosting.co.za>
Message-ID: <1294806115.86.0.11897022638.issue10225@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

You're welcome to discuss this with me on IRC at some point.  For now, the important thing is that I put a good deal of time and effort working on the sorting howto and I like it as it stands (your notions of precedent or consistency not withstanding).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10225>
_______________________________________

From report at bugs.python.org  Wed Jan 12 05:32:04 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 12 Jan 2011 04:32:04 +0000
Subject: [issue10225] Fix doctest runable examples in python manual
In-Reply-To: <1294801437.06.0.921332361387.issue10225@psf.upfronthosting.co.za>
Message-ID: <AANLkTikZo+B4oKs+0GitogNB-nYbKHJEPzZ8gGy-CShQ@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Tue, Jan 11, 2011 at 10:03 PM, Terry J. Reedy <report at bugs.python.org> wrote:
..
> What is the alternative?

I am attaching an alternative patch for sorting howto. You can run the
doctests in it as follows:

$ python2.7 tools/sphinx-build.py -b doctest -d build/doctrees .
build/doctest howto/sorting.rst
...

Doctest summary
===============
   34 tests
    0 failures in tests
    0 failures in setup code
build succeeded.

Unfortunately, Sphinx does not support Ramond's preferred style, but
my patch comes close.

----------
Added file: http://bugs.python.org/file20359/sorting-howto.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10225>
_______________________________________
-------------- next part --------------
Index: howto/sorting.rst
===================================================================
--- howto/sorting.rst	(revision 87942)
+++ howto/sorting.rst	(working copy)
@@ -58,30 +58,44 @@
 A common pattern is to sort complex objects using some of the object's indices
 as keys. For example:
 
-    >>> student_tuples = [
+.. testcode::
+
+    student_tuples = [
         ('john', 'A', 15),
         ('jane', 'B', 12),
         ('dave', 'B', 10),
     ]
-    >>> sorted(student_tuples, key=lambda student: student[2])   # sort by age
+
+Sort by age:
+
+.. doctest::
+
+    >>> sorted(student_tuples, key=lambda student: student[2])
     [('dave', 'B', 10), ('jane', 'B', 12), ('john', 'A', 15)]
 
 The same technique works for objects with named attributes. For example:
 
-    >>> class Student:
-            def __init__(self, name, grade, age):
-                self.name = name
-                self.grade = grade
-                self.age = age
-            def __repr__(self):
-                return repr((self.name, self.grade, self.age))
+.. testcode::
 
-    >>> student_objects = [
+    class Student:
+        def __init__(self, name, grade, age):
+            self.name = name
+            self.grade = grade
+            self.age = age
+        def __repr__(self):
+            return repr((self.name, self.grade, self.age))
+
+    student_objects = [
         Student('john', 'A', 15),
         Student('jane', 'B', 12),
         Student('dave', 'B', 10),
     ]
-    >>> sorted(student_objects, key=lambda student: student.age)   # sort by age
+
+Sort by age:
+
+.. doctest::
+
+    >>> sorted(student_objects, key=lambda student: student.age)
     [('dave', 'B', 10), ('jane', 'B', 12), ('john', 'A', 15)]
 
 Operator Module Functions
@@ -210,22 +224,34 @@
 return a negative value for less-than, return zero if they are equal, or return
 a positive value for greater-than. For example, we can do:
 
-    >>> def numeric_compare(x, y):
-            return x - y
+.. testcode::
+
+    def numeric_compare(x, y):
+        return x - y
+
+.. doctest::
+
     >>> sorted([5, 2, 4, 1, 3], cmp=numeric_compare)
     [1, 2, 3, 4, 5]
 
 Or you can reverse the order of comparison with:
 
-    >>> def reverse_numeric(x, y):
-            return y - x
+.. testcode::
+
+    def reverse_numeric(x, y):
+        return y - x
+
+.. doctest::
+
     >>> sorted([5, 2, 4, 1, 3], cmp=reverse_numeric)
     [5, 4, 3, 2, 1]
 
 When porting code from Python 2.x to 3.x, the situation can arise when you have
 the user supplying a comparison function and you need to convert that to a key
-function. The following wrapper makes that easy to do::
+function. The following wrapper makes that easy to do:
 
+.. testcode::
+
     def cmp_to_key(mycmp):
         'Convert a cmp= function into a key= function'
         class K(object):

From report at bugs.python.org  Wed Jan 12 05:36:43 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 12 Jan 2011 04:36:43 +0000
Subject: [issue10225] Fix doctest runable examples in python manual
In-Reply-To: <1288318735.45.0.959857258913.issue10225@psf.upfronthosting.co.za>
Message-ID: <1294807003.59.0.664734130472.issue10225@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <rhettinger at users.sourceforge.net>:


----------
assignee: belopolsky -> rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10225>
_______________________________________

From report at bugs.python.org  Wed Jan 12 06:12:42 2011
From: report at bugs.python.org (David-Sarah Hopwood)
Date: Wed, 12 Jan 2011 05:12:42 +0000
Subject: [issue1602] windows console doesn't print utf8 (Py30a2)
In-Reply-To: <1197453390.87.0.813702844893.issue1602@psf.upfronthosting.co.za>
Message-ID: <1294809162.21.0.840976880754.issue1602@psf.upfronthosting.co.za>


Changes by David-Sarah Hopwood <david-sarah at jacaranda.org>:


----------
nosy: +BreamoreBoy
versions: +Python 3.1, Python 3.2 -Python 3.3
Added file: http://bugs.python.org/file20360/doc-patch.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1602>
_______________________________________

From report at bugs.python.org  Wed Jan 12 06:18:42 2011
From: report at bugs.python.org (David-Sarah Hopwood)
Date: Wed, 12 Jan 2011 05:18:42 +0000
Subject: [issue1602] windows console doesn't print utf8 (Py30a2)
In-Reply-To: <1197453390.87.0.813702844893.issue1602@psf.upfronthosting.co.za>
Message-ID: <1294809522.59.0.621791930632.issue1602@psf.upfronthosting.co.za>


Changes by David-Sarah Hopwood <david-sarah at jacaranda.org>:


----------
nosy: +BreamoreBoy
versions: +Python 3.1, Python 3.2 -Python 3.3
Added file: http://bugs.python.org/file20361/doc-patch.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1602>
_______________________________________

From report at bugs.python.org  Wed Jan 12 06:25:44 2011
From: report at bugs.python.org (David-Sarah Hopwood)
Date: Wed, 12 Jan 2011 05:25:44 +0000
Subject: [issue1602] windows console doesn't print utf8 (Py30a2)
In-Reply-To: <1197453390.87.0.813702844893.issue1602@psf.upfronthosting.co.za>
Message-ID: <1294809944.28.0.962114411919.issue1602@psf.upfronthosting.co.za>


Changes by David-Sarah Hopwood <david-sarah at jacaranda.org>:


Added file: http://bugs.python.org/file20362/doc-patch.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1602>
_______________________________________

From report at bugs.python.org  Wed Jan 12 06:32:09 2011
From: report at bugs.python.org (David-Sarah Hopwood)
Date: Wed, 12 Jan 2011 05:32:09 +0000
Subject: [issue1602] windows console doesn't print or input Unicode
In-Reply-To: <1197453390.87.0.813702844893.issue1602@psf.upfronthosting.co.za>
Message-ID: <1294810329.29.0.426203043309.issue1602@psf.upfronthosting.co.za>


Changes by David-Sarah Hopwood <david-sarah at jacaranda.org>:


----------
title: windows console doesn't print utf8 (Py30a2) -> windows console doesn't print or input Unicode
Added file: http://bugs.python.org/file20363/doc-patch.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1602>
_______________________________________

From report at bugs.python.org  Wed Jan 12 07:07:58 2011
From: report at bugs.python.org (Glenn Linderman)
Date: Wed, 12 Jan 2011 06:07:58 +0000
Subject: [issue4953] cgi module cannot handle POST with multipart/form-data
	in	3.0
In-Reply-To: <1232010166.79.0.972664060868.issue4953@psf.upfronthosting.co.za>
Message-ID: <1294812478.77.0.270255268119.issue4953@psf.upfronthosting.co.za>


Glenn Linderman <v+python at g.nevcal.com> added the comment:

Pierre,
I applied your patch to my local copy of cgi.py for my installation of 3.2, and have been testing.  Lots of things work great!

My earlier comment regarding make_file seems to be relevant.  Files that are not binary should have an encoding.  Likely you removed the encoding because it was a hard-coded UTF-8 and that didn't work for you, with your default encoding of cp-1252.  However, now that I am passing in UTF-8 via the stream-encoding parameter, because that is what matches my form-data, I get an error that cp-1252 (apparently also my default encoding, except for console stuff which is 437) cannot encode \u0163.  So I think the encoding parameter should be added back in, but the value used should be the stream_encoding parameter.  You might also turn around the test on self.filename:

        import tempfile
        if self.filename:
            return tempfile.TemporaryFile("wb+")
        else:
            return tempfile.TemporaryFile("w+",
                                          encoding=self.stream_encoding,
                                          newline="\n")

One of my tests used a large textarea and a short file.  I was surprised to see that the file was not stored as a file, but the textarea was.  I guess that is due to the code in read_single that checks length rather than filename to decide whether it should be stored in a file from the get-go.  It seems that this behaviour, while probably more efficient than actually creating a file, might be surprising to folks overriding make_file so that they could directly store the data in the final destination file, instead of copying it later.  The documented semantics for make_file do not state that it is only called if there is more than 1000 bytes of data, or that the form_data item headers contain a CONTENT-LENGTH header (which never seems to happen).  Indeed, I found a comment on StackOverflow where someone had been surprised that small files did not have make_file called on them.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4953>
_______________________________________

From report at bugs.python.org  Wed Jan 12 08:39:28 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Wed, 12 Jan 2011 07:39:28 +0000
Subject: [issue10882] Add os.sendfile()
In-Reply-To: <1294805586.77.0.183975785223.issue10882@psf.upfronthosting.co.za>
Message-ID: <4D2D5AAA.4080207@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> I thought that patches weren't meant to include the regenerated files. 

Correct. Not including them is perfectly fine.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10882>
_______________________________________

From report at bugs.python.org  Wed Jan 12 08:53:56 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 12 Jan 2011 07:53:56 +0000
Subject: [issue10889] Fix range slicing and indexing to handle lengths >
	sys.maxsize
In-Reply-To: <1294761569.28.0.225841776524.issue10889@psf.upfronthosting.co.za>
Message-ID: <1294818836.71.0.0525604893911.issue10889@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/issue10889>
_______________________________________

From report at bugs.python.org  Wed Jan 12 10:20:44 2011
From: report at bugs.python.org (Charles-Francois Natali)
Date: Wed, 12 Jan 2011 09:20:44 +0000
Subject: [issue3006] subprocess.Popen causes socket to remain open after close
In-Reply-To: <1212094958.77.0.0391223554576.issue3006@psf.upfronthosting.co.za>
Message-ID: <1294824044.66.0.503798537803.issue3006@psf.upfronthosting.co.za>


Charles-Francois Natali <neologix at free.fr> added the comment:

> I cannot figure out why the closesocket's graceful
shutdown is waiting for the Popen command to complete.

It doesn't. Your main process closes its socket. You could see it with a netstat/lsof (don't know under Windows).
The problem is that when you call subprocess.Popen(), there's a fork behind, and the child process receives a copy of the FD. That's why your socket is not deallocated until the subprocess completes (and closes the FD on exit).

> This problem does not show up with the equivalent os.popen command.

That's because os.popen() is implemented as subprocess.Popen with close_fds=True, so the socket is closed before execve is called. IMHO, setting close_fds=True by default is the Right Thing to do (and I think it's now done by default in py3k to avoid races between concurrent popen calls, in addition to setting pipe's FD as FD_CLOEXEC).

----------
nosy: +neologix

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3006>
_______________________________________

From report at bugs.python.org  Wed Jan 12 10:35:25 2011
From: report at bugs.python.org (Lennart Regebro)
Date: Wed, 12 Jan 2011 09:35:25 +0000
Subject: [issue9124] Mailbox module demonstrates infeasibly slow performance
In-Reply-To: <1277900903.38.0.556015912714.issue9124@psf.upfronthosting.co.za>
Message-ID: <1294824925.08.0.279249120729.issue9124@psf.upfronthosting.co.za>


Lennart Regebro <regebro at gmail.com> added the comment:

I can confirm on Ubuntu and with other example mailboxes. Looping through the messages and printing the subjects takes around 200-300 times longer under Python 3 than under Python 2.

----------
nosy: +lregebro

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9124>
_______________________________________

From report at bugs.python.org  Wed Jan 12 10:37:27 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 12 Jan 2011 09:37:27 +0000
Subject: [issue9124] Mailbox module demonstrates infeasibly slow performance
In-Reply-To: <1277900903.38.0.556015912714.issue9124@psf.upfronthosting.co.za>
Message-ID: <1294825047.66.0.448874713343.issue9124@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <rhettinger at users.sourceforge.net>:


----------
priority: normal -> high

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9124>
_______________________________________

From report at bugs.python.org  Wed Jan 12 10:40:07 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 12 Jan 2011 09:40:07 +0000
Subject: [issue9124] Mailbox module demonstrates infeasibly slow performance
In-Reply-To: <1277900903.38.0.556015912714.issue9124@psf.upfronthosting.co.za>
Message-ID: <1294825207.55.0.724200840602.issue9124@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Can you confirm using the Py3.2 head?
Am curious if Antoine's optimizations helped here.

----------
nosy: +pitrou, rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9124>
_______________________________________

From report at bugs.python.org  Wed Jan 12 10:54:36 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 12 Jan 2011 09:54:36 +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: <1294826076.87.0.544705079202.issue10441@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

We tend to spend some time on documentation: http://docs.python.org/dev/library/ssl#ssl.SSLContext.set_default_verify_paths

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10441>
_______________________________________

From report at bugs.python.org  Wed Jan 12 11:07:10 2011
From: report at bugs.python.org (david)
Date: Wed, 12 Jan 2011 10:07:10 +0000
Subject: [issue10441] some stdlib modules need to be updated to handle SSL
	certificate validation
In-Reply-To: <1294826076.87.0.544705079202.issue10441@psf.upfronthosting.co.za>
Message-ID: <AANLkTikEd8+hstL2U8Bn8RUGy=C8cBAJ7yu0qg91KUo6@mail.gmail.com>


david <db.pub.mail at gmail.com> added the comment:

Cool yeah. The documentation is good I asked the question because I
wasn't sure if it was in a pending patch elsewhere in the bug tracker
or was accepted. I guess I should have googled for it.

Thank you.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10441>
_______________________________________

From report at bugs.python.org  Wed Jan 12 11:21:17 2011
From: report at bugs.python.org (Lennart Regebro)
Date: Wed, 12 Jan 2011 10:21:17 +0000
Subject: [issue9124] Mailbox module demonstrates infeasibly slow performance
In-Reply-To: <1277900903.38.0.556015912714.issue9124@psf.upfronthosting.co.za>
Message-ID: <1294827677.31.0.120180599873.issue9124@psf.upfronthosting.co.za>


Lennart Regebro <regebro at gmail.com> added the comment:

3.2 sees a small improvement when running the Steve test:

Python 2.6.6: 0.0291s

Python 3.1.2: 31.1s

Python 3.2b2+: 28.8s

This is Ubuntu 10.04 on ext3, with all Pythons compiled from source, with no configure attributes except a prefix.

I wonder if the differences between different unix systems can have to do with what the default system encoding is? Mine is UTF-8.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9124>
_______________________________________

From report at bugs.python.org  Wed Jan 12 11:29:48 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 12 Jan 2011 10:29:48 +0000
Subject: [issue10891] Tweak sorting howto to eliminate redundancy
In-Reply-To: <1294828188.31.0.578827978132.issue10891@psf.upfronthosting.co.za>
Message-ID: <1294828188.31.0.578827978132.issue10891@psf.upfronthosting.co.za>


New submission from ?ric Araujo <merwok at netwok.org>:

When reading over the sorting howto, I noticed redundancy of the form ?the list.sort() method of a list?.  Raymond, if you approve the attached patch, please assign back to me.  There were no warnings during doc build and no link was broken.

Note that :meth:`list.sort` (or :meth:`~list.sort`) does not trigger a link to the doc of the method, since sort is not marked up with a method directive but listed in a table alongside other list and bytearray methods (http://docs.python.org/dev/library/stdtypes#typesseq-mutable).  This table is preceded by index-generating markup, but it does not create a target for :meth:`list.sort`; that?s a separate issue.  Until it?s solved, the sorting howto could turn the first occurrence of ?list? into a link to the right section, using :ref:`typesseq-mutable <list>`, or continue to live without a link to list or list.sort.

----------
assignee: rhettinger
components: Documentation
files: minor-sorting-changes.diff
keywords: patch
messages: 126083
nosy: docs at python, eric.araujo, rhettinger
priority: normal
severity: normal
stage: commit review
status: open
title: Tweak sorting howto to eliminate redundancy
versions: Python 2.7, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file20364/minor-sorting-changes.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10891>
_______________________________________

From report at bugs.python.org  Wed Jan 12 11:54:59 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 12 Jan 2011 10:54:59 +0000
Subject: [issue8957] strptime(.., '%c') fails to parse output of strftime('%c',
	..) in some locales
In-Reply-To: <1276115080.37.0.388300880324.issue8957@psf.upfronthosting.co.za>
Message-ID: <1294829699.13.0.893913339412.issue8957@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

On Linux, cfmt.py fails on fr_FR locale (the only valid locale in the list of tested locales):
---
fr_FR [mer. 12 janv. 2011 11:30:35 CET] %a %d %B %Y %H:%M:%S %Z != %a %d %b %Y %T %Z
---

The problem is the month format: locale.nl_langinfo(locale.D_T_FMT) returns '%a %d %b %Y %T %Z', but _strptime (LocaleTime().LC_date_time) uses '%a %d %B %Y %H:%M:%S %Z' => '%b' vs '%B'.

_strptime.LocalTime.__calc_date_time() uses strftime('%c') and then parse the output to get the complete format. But it uses strftime('%c') with the march month, and in french, march is formatted 'mars' for both month formats (%b *and* %B).

_strptime.LocalTime.__calc_date_time() should detect that the month has the same format with %b and %B, and try other timestamps (other months).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8957>
_______________________________________

From report at bugs.python.org  Wed Jan 12 12:56:06 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 12 Jan 2011 11:56:06 +0000
Subject: [issue9124] Mailbox module should use binary I/O, not text I/O
In-Reply-To: <1277900903.38.0.556015912714.issue9124@psf.upfronthosting.co.za>
Message-ID: <1294833366.65.0.708878668651.issue9124@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

The aforementioned python-dev thread (available at http://mail.python.org/pipermail/python-dev/2010-June/101186.html ) explains things quite well.
The mailbox module needs to be modified to use binary I/O, both for functionality and for speed. Right now, I don't know how the mailbox module can be useful in py3k (you'd quickly run into unicode errors as soon as you try to read an email with another charset, I think).

----------
stage: unit test needed -> needs patch
title: Mailbox module demonstrates infeasibly slow performance -> Mailbox module should use binary I/O, not text I/O
type: performance -> behavior
versions: +Python 3.2, Python 3.3 -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9124>
_______________________________________

From report at bugs.python.org  Wed Jan 12 13:09:16 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 12 Jan 2011 12:09:16 +0000
Subject: [issue10892] segfault with "del X.__abstractmethods__"
In-Reply-To: <1294834156.26.0.13558320611.issue10892@psf.upfronthosting.co.za>
Message-ID: <1294834156.26.0.13558320611.issue10892@psf.upfronthosting.co.za>


New submission from Amaury Forgeot d'Arc <amauryfa at gmail.com>:

A short crasher::
    class X(object): pass
    del X.__abstractmethods__

All versions since 2.6 are affected.
The fix is probably simple: the setter function type_set_abstractmethods() in typeobject.c should check for a NULL value.

----------
keywords: easy
messages: 126086
nosy: amaury.forgeotdarc
priority: critical
severity: normal
status: open
title: segfault with "del X.__abstractmethods__"
type: crash
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10892>
_______________________________________

From report at bugs.python.org  Wed Jan 12 13:35:49 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 12 Jan 2011 12:35:49 +0000
Subject: [issue10892] segfault with "del X.__abstractmethods__"
In-Reply-To: <1294834156.26.0.13558320611.issue10892@psf.upfronthosting.co.za>
Message-ID: <1294835749.24.0.556811006145.issue10892@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I think a crash does not qualify as security issue, hence removing 2.6.

----------
nosy: +eric.araujo
versions:  -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10892>
_______________________________________

From report at bugs.python.org  Wed Jan 12 13:37:48 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 12 Jan 2011 12:37:48 +0000
Subject: [issue775321] plistlib error handling
Message-ID: <1294835868.33.0.304731256695.issue775321@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I think this was closed prematurely.  I would like a core dev to assess this issue and reject or validate it.

----------
nosy: +eric.araujo -BreamoreBoy
resolution: wont fix -> 
stage: patch review -> 
status: closed -> open
versions: +Python 3.3 -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue775321>
_______________________________________

From report at bugs.python.org  Wed Jan 12 13:38:29 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 12 Jan 2011 12:38:29 +0000
Subject: [issue775321] plistlib error handling
Message-ID: <1294835909.7.0.381322825341.issue775321@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +georg.brandl, mher, ned.deily, ronaldoussoren

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue775321>
_______________________________________

From report at bugs.python.org  Wed Jan 12 13:39:23 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 12 Jan 2011 12:39:23 +0000
Subject: [issue985064] plistlib crashes too easily on bad files
Message-ID: <1294835963.01.0.56843513229.issue985064@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

See also reopened dependency #775321.

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue985064>
_______________________________________

From report at bugs.python.org  Wed Jan 12 13:59:56 2011
From: report at bugs.python.org (Ram Rachum)
Date: Wed, 12 Jan 2011 12:59:56 +0000
Subject: [issue10893] The docs mark staticmethod as a function
In-Reply-To: <1294837196.34.0.0437845342766.issue10893@psf.upfronthosting.co.za>
Message-ID: <1294837196.34.0.0437845342766.issue10893@psf.upfronthosting.co.za>


New submission from Ram Rachum <cool-rr at cool-rr.com>:

The Python documentation uses :func:`staticmethod` to describe staticmethod, while staticmethod is a type.

I want to link to the Python documentation from my project's documentation using Intersphinx, and I wouldn't want to mislead my users by marking static method as a function.

----------
assignee: docs at python
components: Documentation
messages: 126090
nosy: cool-RR, docs at python
priority: normal
severity: normal
status: open
title: The docs mark staticmethod as a function
type: behavior
versions: Python 2.5, Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10893>
_______________________________________

From report at bugs.python.org  Wed Jan 12 14:08:36 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 12 Jan 2011 13:08:36 +0000
Subject: [issue9880] Python 2.7 Won't Build: SystemError: unknown opcode
In-Reply-To: <1284674532.4.0.904279806396.issue9880@psf.upfronthosting.co.za>
Message-ID: <1294837716.55.0.23707415042.issue9880@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

With gcc-4.6 -O1, Python 3.2 works correctly. With gcc-4.6 -O1 -ftree-vectorize, the assertion "assert (new_line - last_line < 255);" fails in PyCode_Optimize().

I think that the problem is in the following loop:
-------------------------------------
#define NOP    9
#define HAVE_ARGUMENT  90  /* Opcodes from here have an argument: */
#define HAS_ARG(op) ((op) >= HAVE_ARGUMENT)
#define CODESIZE(op)  (HAS_ARG(op) ? 3 : 1)

unsigned char *codestr = NULL;
Py_ssize_t codelen;
int *addrmap = NULL;

/* Fixup linenotab */
for (i=0, nops=0 ; i<codelen ; i += CODESIZE(codestr[i])) {
    addrmap[i] = i - nops;
    if (codestr[i] == NOP)
        nops++;
}
-------------------------------------

gcc-4.6 -O1:
-------------------------------------
0x0000000000480991 <+5041>:  mov    %eax,%edx
0x0000000000480993 <+5043>:  sub    %esi,%edx
0x0000000000480995 <+5045>:  mov    %edx,(%r12,%rax,4)
0x0000000000480999 <+5049>:  movzbl 0x0(%rbp,%rax,1),%edx
0x000000000048099e <+5054>:  cmp    $0x9,%dl
0x00000000004809a1 <+5057>:  jne    0x4809a8 <PyCode_Optimize+5064>
0x00000000004809a3 <+5059>:  add    $0x1,%esi
0x00000000004809a6 <+5062>:  jmp    0x4809b2 <PyCode_Optimize+5074>
0x00000000004809a8 <+5064>:  mov    $0x3,%ecx
0x00000000004809ad <+5069>:  cmp    $0x59,%dl
0x00000000004809b0 <+5072>:  ja     0x4809b7 <PyCode_Optimize+5079>
0x00000000004809b2 <+5074>:  mov    $0x1,%ecx
0x00000000004809b7 <+5079>:  add    %rcx,%rax
0x00000000004809ba <+5082>:  cmp    %rax,%rdi
0x00000000004809bd <+5085>:  jg     0x480991 <PyCode_Optimize+5041>
-------------------------------------

gcc-4.6 -O1 -ftree-vectorize
-------------------------------------
0x0000000000480991 <+5041>:  mov    %eax,%ecx
0x0000000000480993 <+5043>:  sub    %edx,%ecx
0x0000000000480995 <+5045>:  mov    %ecx,(%r12,%rax,4)
0x0000000000480999 <+5049>:  movzbl 0x0(%rbp,%rax,1),%ecx
0x000000000048099e <+5054>:  lea    0x1(%rdx),%esi
0x00000000004809a1 <+5057>:  cmp    $0x9,%cl
0x00000000004809a4 <+5060>:  cmovne %edx,%esi
0x00000000004809a7 <+5063>:  cmove  %esi,%edx
0x00000000004809aa <+5066>:  setne  %cl
0x00000000004809ad <+5069>:  movzbl %cl,%ecx
0x00000000004809b0 <+5072>:  lea    0x1(%rax,%rcx,2),%rax
0x00000000004809b5 <+5077>:  cmp    %rax,%rdi
0x00000000004809b8 <+5080>:  jg     0x480991 <PyCode_Optimize+5041>
-------------------------------------

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9880>
_______________________________________

From report at bugs.python.org  Wed Jan 12 14:11:50 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 12 Jan 2011 13:11:50 +0000
Subject: [issue9880] Python 2.7 Won't Build: SystemError: unknown opcode
In-Reply-To: <1284674532.4.0.904279806396.issue9880@psf.upfronthosting.co.za>
Message-ID: <1294837910.05.0.218849901132.issue9880@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

More info about the loop:
----
Py_ssize_t i;
int nops;
----

My setup:
 * Intel(R) Pentium(R) 4 CPU 3.00GHz
 * Debian Sid
 * gcc (Debian 20110106-1) 4.6.0 20110106 (experimental) [trunk revision 168538]

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9880>
_______________________________________

From report at bugs.python.org  Wed Jan 12 14:16:27 2011
From: report at bugs.python.org (Charles-Francois Natali)
Date: Wed, 12 Jan 2011 13:16:27 +0000
Subject: [issue1488934] file.write + closed pipe = no error
Message-ID: <1294838187.12.0.385212839178.issue1488934@psf.upfronthosting.co.za>


Charles-Francois Natali <neologix at free.fr> added the comment:

This is normal behaviour: stdout is normally line buffered (_IOLBF) only if connected to a tty.
When it's not connected to a tty, it's full buffered (_IOFBF). This is done on purpose for performance reason. To convince yourself, run 

$ cat test.py
for i in range(1, 1000000):
    print('hello world')

$ time python test.py > /tmp/foo

With buffering off (-u option), the same commande takes almost 10 times longer.

If the application wants to be sure to receive a SIGPIPE when the pipe's end is closed, it should just flush stdout explicitely (sys.stdout.flush()).

Suggesting to close.

----------
nosy: +neologix, pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1488934>
_______________________________________

From report at bugs.python.org  Wed Jan 12 14:17:17 2011
From: report at bugs.python.org (SilentGhost)
Date: Wed, 12 Jan 2011 13:17:17 +0000
Subject: [issue10894] Making stdlib APIs private
In-Reply-To: <1294838236.87.0.84648349826.issue10894@psf.upfronthosting.co.za>
Message-ID: <1294838236.87.0.84648349826.issue10894@psf.upfronthosting.co.za>


New submission from SilentGhost <ghost.adh at gmail.com>:

Following suggestion in the Developers Guide (http://docs.python.org/devguide/#index-5) and the rules proposed by Michael Foord (http://mail.python.org/pipermail/python-dev/2010-November/105476.html):
------------
> If a module or package defines __all__ that authoritatively defines the 
public interface. Modules with __all__ SHOULD still respect the naming 
conventions (leading underscore for private members) to avoid confusing 
users. Modules SHOULD NOT export private members in __all__.

> Names imported into a module a never considered part of its public API 
unless documented to be so or included in __all__.

> Methods / functions / classes and module attributes whose names begin 
with a leading underscore are private.

> If a class name begins with a leading underscore none of its members are 
public, whether or not they begin with a leading underscore.

> If a module name in a package begins with a leading underscore none of 
its members are public, whether or not they begin with a leading underscore.

> If a module or package doesn't define __all__ then all names that don't 
start with a leading underscore are public.

> All public members MUST be documented. Public functions, methods and 
classes SHOULD have docstrings. Private members may have docstrings.

> Where in the standard library this means that a module exports stuff 
that isn't helpful or shouldn't be part of the public API we need to 
migrate to private names and follow our deprecation process for the 
public names.
------------

The following deprecation method is adopted:

from warnings import warn as _warn

def no_underscore(<parameters>):
    _warn("The module.no_underscore() function is deprecated",
         DeprecationWarning, 2)
    return _no_underscore(<parameters>)

Note: this is a meta-issue. It should only depend on all individual issues fixing APIs. It's currently dependant only on resolved issue10371.

As I don't think it's reasonable to create an issue per stdlib module, I'm going to group a few modules in issue. However, when submitting patches, please create a patch per module to minimize disturbance. The files to check: Lib/module.py, Lib/test/test_module.py, Doc/library/module.rst

----------
components: Library (Lib)
messages: 126094
nosy: SilentGhost, brett.cannon
priority: normal
severity: normal
status: open
title: Making stdlib APIs private
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10894>
_______________________________________

From report at bugs.python.org  Wed Jan 12 14:21:03 2011
From: report at bugs.python.org (SilentGhost)
Date: Wed, 12 Jan 2011 13:21:03 +0000
Subject: [issue10895] Private stdlib API: getopt, getpass, glob, gzip,
	genericpath, gettext
In-Reply-To: <1294838463.37.0.519255760117.issue10895@psf.upfronthosting.co.za>
Message-ID: <1294838463.37.0.519255760117.issue10895@psf.upfronthosting.co.za>


New submission from SilentGhost <ghost.adh at gmail.com>:

Module generic path is in order (added here only for completeness).

Attached patch is for getopt.

----------
components: Library (Lib)
files: getopt_api.diff
keywords: patch
messages: 126095
nosy: SilentGhost
priority: normal
severity: normal
status: open
title: Private stdlib API: getopt, getpass, glob, gzip, genericpath, gettext
versions: Python 3.3
Added file: http://bugs.python.org/file20365/getopt_api.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10895>
_______________________________________

From report at bugs.python.org  Wed Jan 12 14:22:10 2011
From: report at bugs.python.org (SilentGhost)
Date: Wed, 12 Jan 2011 13:22:10 +0000
Subject: [issue10894] Making stdlib APIs private
In-Reply-To: <1294838236.87.0.84648349826.issue10894@psf.upfronthosting.co.za>
Message-ID: <1294838530.91.0.406574943774.issue10894@psf.upfronthosting.co.za>


SilentGhost <ghost.adh at gmail.com> added the comment:

Depends on issue10895

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10894>
_______________________________________

From report at bugs.python.org  Wed Jan 12 14:32:09 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 12 Jan 2011 13:32:09 +0000
Subject: [issue9880] Python 2.7 Won't Build: SystemError: unknown opcode
In-Reply-To: <1294837716.55.0.23707415042.issue9880@psf.upfronthosting.co.za>
Message-ID: <1294839123.3718.15.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

[...]
> 
> gcc-4.6 -O1 -ftree-vectorize
> -------------------------------------
> 0x0000000000480991 <+5041>:  mov    %eax,%ecx
> 0x0000000000480993 <+5043>:  sub    %edx,%ecx
> 0x0000000000480995 <+5045>:  mov    %ecx,(%r12,%rax,4)
> 0x0000000000480999 <+5049>:  movzbl 0x0(%rbp,%rax,1),%ecx
> 0x000000000048099e <+5054>:  lea    0x1(%rdx),%esi
> 0x00000000004809a1 <+5057>:  cmp    $0x9,%cl
> 0x00000000004809a4 <+5060>:  cmovne %edx,%esi
> 0x00000000004809a7 <+5063>:  cmove  %esi,%edx
> 0x00000000004809aa <+5066>:  setne  %cl
> 0x00000000004809ad <+5069>:  movzbl %cl,%ecx
> 0x00000000004809b0 <+5072>:  lea    0x1(%rax,%rcx,2),%rax
> 0x00000000004809b5 <+5077>:  cmp    %rax,%rdi
> 0x00000000004809b8 <+5080>:  jg     0x480991 <PyCode_Optimize+5041>
> -------------------------------------

Looks like code generation is borked.
(it lacks a compare to 0x59 or 0x5a (90), and "setne" wouldn't be the
right instruction anyway)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9880>
_______________________________________

From report at bugs.python.org  Wed Jan 12 14:38:23 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 12 Jan 2011 13:38:23 +0000
Subject: [issue9880] Python 2.7 Won't Build: SystemError: unknown opcode
In-Reply-To: <1284674532.4.0.904279806396.issue9880@psf.upfronthosting.co.za>
Message-ID: <1294839503.06.0.707815269511.issue9880@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> Looks like code generation is borked.

I sent an email to the mailing list:
http://gcc.gnu.org/ml/gcc-help/2011-01/msg00136.html

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9880>
_______________________________________

From report at bugs.python.org  Wed Jan 12 15:13:48 2011
From: report at bugs.python.org (SilentGhost)
Date: Wed, 12 Jan 2011 14:13:48 +0000
Subject: [issue10895] Private stdlib API: getopt, getpass, glob, gzip,
	genericpath, gettext
In-Reply-To: <1294838463.37.0.519255760117.issue10895@psf.upfronthosting.co.za>
Message-ID: <1294841628.42.0.0144257661509.issue10895@psf.upfronthosting.co.za>


SilentGhost <ghost.adh at gmail.com> added the comment:

Attached patch is for glob.

While I haven't touched it, I find it strange that Doc/library/glob.rst draws special attention to the actual source code of the glob module. Since, in my view, it's pertaining to the public API, I would consider deleting that "See also" note.

----------
Added file: http://bugs.python.org/file20366/glob_api.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10895>
_______________________________________

From report at bugs.python.org  Wed Jan 12 15:33:27 2011
From: report at bugs.python.org (SilentGhost)
Date: Wed, 12 Jan 2011 14:33:27 +0000
Subject: [issue10895] Private stdlib API: getopt, getpass, glob, gzip,
	genericpath, gettext
In-Reply-To: <1294838463.37.0.519255760117.issue10895@psf.upfronthosting.co.za>
Message-ID: <1294842807.73.0.257548149829.issue10895@psf.upfronthosting.co.za>


SilentGhost <ghost.adh at gmail.com> added the comment:

Attached patch is for getpass.

Additionally, I let myself remove superfluous import.

----------
Added file: http://bugs.python.org/file20367/getpass_api.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10895>
_______________________________________

From report at bugs.python.org  Wed Jan 12 15:44:49 2011
From: report at bugs.python.org (Vladimir Rutsky)
Date: Wed, 12 Jan 2011 14:44:49 +0000
Subject: [issue10896] trace module compares directories as strings
	(--ignore-dir)
In-Reply-To: <1294843489.43.0.983792093108.issue10896@psf.upfronthosting.co.za>
Message-ID: <1294843489.43.0.983792093108.issue10896@psf.upfronthosting.co.za>


New submission from Vladimir Rutsky <rutsky.vladimir at gmail.com>:

This is code from recent trace.py (http://svn.python.org/view/python/branches/release27-maint/Lib/trace.py?view=markup):

trace.py:169:
        # Ignore a file when it contains one of the ignorable paths
        for d in self._dirs:
            # The '+ os.sep' is to ensure that d is a parent directory,
            # as compared to cases like:
            #  d = "/usr/local"
            #  filename = "/usr/local.py"
            # or
            #  d = "/usr/local.py"
            #  filename = "/usr/local.py"
            if filename.startswith(d + os.sep):
                self._ignore[modulename] = 1
                return 1

Directories comparison like "filename.startswith(d + os.sep)" works incorrect on case-insensitive filesystems (such as NTFS on Windows).

This leads to confusing results on Windows:
  python trace.py --ignore-dir='$prefix' -t test.py
or
  python trace.py --ignore-dir C:\Python26\Lib -t test.py
shows all calls from standard library, but this one doesn't:
  python trace.py --ignore-dir=c:\python26\lib -t test.py

See attached test files and log for details.

----------
components: Library (Lib)
files: test.py
messages: 126101
nosy: vrutsky
priority: normal
severity: normal
status: open
title: trace module compares directories as strings (--ignore-dir)
versions: Python 2.7
Added file: http://bugs.python.org/file20368/test.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10896>
_______________________________________

From report at bugs.python.org  Wed Jan 12 15:45:21 2011
From: report at bugs.python.org (Vladimir Rutsky)
Date: Wed, 12 Jan 2011 14:45:21 +0000
Subject: [issue10896] trace module compares directories as strings
	(--ignore-dir)
In-Reply-To: <1294843489.43.0.983792093108.issue10896@psf.upfronthosting.co.za>
Message-ID: <1294843521.86.0.453731343706.issue10896@psf.upfronthosting.co.za>


Changes by Vladimir Rutsky <rutsky.vladimir at gmail.com>:


Added file: http://bugs.python.org/file20369/test.cmd

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10896>
_______________________________________

From report at bugs.python.org  Wed Jan 12 15:45:39 2011
From: report at bugs.python.org (Vladimir Rutsky)
Date: Wed, 12 Jan 2011 14:45:39 +0000
Subject: [issue10896] trace module compares directories as strings
	(--ignore-dir)
In-Reply-To: <1294843489.43.0.983792093108.issue10896@psf.upfronthosting.co.za>
Message-ID: <1294843539.18.0.441662681769.issue10896@psf.upfronthosting.co.za>


Changes by Vladimir Rutsky <rutsky.vladimir at gmail.com>:


Added file: http://bugs.python.org/file20370/test.out

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10896>
_______________________________________

From report at bugs.python.org  Wed Jan 12 15:58:27 2011
From: report at bugs.python.org (SilentGhost)
Date: Wed, 12 Jan 2011 14:58:27 +0000
Subject: [issue10893] The docs mark staticmethod as a function
In-Reply-To: <1294837196.34.0.0437845342766.issue10893@psf.upfronthosting.co.za>
Message-ID: <1294844307.79.0.300465389265.issue10893@psf.upfronthosting.co.za>


SilentGhost <ghost.adh at gmail.com> added the comment:

So, is int, str, bool and enumerate. And many others. The preface on functions page (http://docs.python.org/dev/library/functions.html) says: 

"The Python interpreter has a number of functions and types built into it that are always available."

I would think it's clear enough.

----------
nosy: +SilentGhost

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10893>
_______________________________________

From report at bugs.python.org  Wed Jan 12 16:09:04 2011
From: report at bugs.python.org (SilentGhost)
Date: Wed, 12 Jan 2011 15:09:04 +0000
Subject: [issue10895] Private stdlib API: getopt, getpass, glob, gzip,
	genericpath, gettext
In-Reply-To: <1294838463.37.0.519255760117.issue10895@psf.upfronthosting.co.za>
Message-ID: <1294844944.36.0.880782264924.issue10895@psf.upfronthosting.co.za>


SilentGhost <ghost.adh at gmail.com> added the comment:

Attached patch is for gzip.

Additionally, I had to fix import and removed two unused (?) functions. Let me know if that's inappropriate. I wasn't sure what to do about constants (all caps vars) so I left them as they were.

----------
Added file: http://bugs.python.org/file20371/gzip_api.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10895>
_______________________________________

From report at bugs.python.org  Wed Jan 12 16:14:25 2011
From: report at bugs.python.org (SilentGhost)
Date: Wed, 12 Jan 2011 15:14:25 +0000
Subject: [issue10895] Private stdlib API: getopt, getpass, glob, gzip,
	genericpath, gettext
In-Reply-To: <1294838463.37.0.519255760117.issue10895@psf.upfronthosting.co.za>
Message-ID: <1294845265.4.0.627970155705.issue10895@psf.upfronthosting.co.za>


Changes by SilentGhost <ghost.adh at gmail.com>:


Removed file: http://bugs.python.org/file20367/getpass_api.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10895>
_______________________________________

From report at bugs.python.org  Wed Jan 12 16:14:45 2011
From: report at bugs.python.org (SilentGhost)
Date: Wed, 12 Jan 2011 15:14:45 +0000
Subject: [issue10895] Private stdlib API: getopt, getpass, glob, gzip,
	genericpath, gettext
In-Reply-To: <1294838463.37.0.519255760117.issue10895@psf.upfronthosting.co.za>
Message-ID: <1294845285.96.0.4834143072.issue10895@psf.upfronthosting.co.za>


Changes by SilentGhost <ghost.adh at gmail.com>:


Added file: http://bugs.python.org/file20372/getpass_api.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10895>
_______________________________________

From report at bugs.python.org  Wed Jan 12 16:16:19 2011
From: report at bugs.python.org (Lorenz Huedepohl)
Date: Wed, 12 Jan 2011 15:16:19 +0000
Subject: [issue10897] UNIX mmap unnecessarily dup() file descriptor
In-Reply-To: <1294845379.76.0.427887707002.issue10897@psf.upfronthosting.co.za>
Message-ID: <1294845379.76.0.427887707002.issue10897@psf.upfronthosting.co.za>


New submission from Lorenz Huedepohl <lorenz at mpa-garching.mpg.de>:

The UNIX mmap version in

  Modules/mmapmodule.c 

makes a call to dup() to duplicate the file descriptor that is passed for creating the memory-mapped region.

This way, I frequently hit the limit for the number of open file handles while creating mmap.mmap() instances, despite closing all my opened files after creating a mapping for them.

My application is scientific data (read: "large data" :-) analysis for which mmap() is very well suited together with numpy/scipy - however, the large number of files causes me to hit the resource limit on open file handles)

I propose to remove this dup(), which was apparently introduced in the process of fixing issue #728515, concerning incorrect behavior of the mmap.resize() method on UNIX, as it was feared the user could have closed the file handle already.

I think it should be the responsibility of the user not to close the file in question or either - if it needs to be closed - not to call the resize method later.

I should stress that a call to mmap(2) does not require an open file handle during the time of the mapping but that a duplicate of the file handle was only kept to allow .size() and .resize() to work. See the POSIX Programmer's Manual:

  The mmap() function shall add an extra reference to the file
  associated with the file descriptor fildes which is not removed
  by a subsequent close() on that file descriptor. This reference
  shall be removed when there are no more mappings to the file.

It would be great if this little nicety would translate better to Python!

Regards,
   Lorenz

----------
components: Library (Lib)
files: no_dup.patch
keywords: patch
messages: 126104
nosy: lorenz
priority: normal
severity: normal
status: open
title: UNIX mmap unnecessarily dup() file descriptor
type: resource usage
versions: Python 2.5, Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file20373/no_dup.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10897>
_______________________________________

From report at bugs.python.org  Wed Jan 12 16:32:07 2011
From: report at bugs.python.org (Mher Movsisyan)
Date: Wed, 12 Jan 2011 15:32:07 +0000
Subject: [issue775321] plistlib error handling
Message-ID: <1294846327.32.0.396748079845.issue775321@psf.upfronthosting.co.za>


Mher Movsisyan <mher.movsisyan at gmail.com> added the comment:

I don't see compelling reasons to wrap ExpatError in ValueError. ExpatError contains extra diagnostic information such as line and column numbers.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue775321>
_______________________________________

From report at bugs.python.org  Wed Jan 12 16:32:09 2011
From: report at bugs.python.org (Peter Creath)
Date: Wed, 12 Jan 2011 15:32:09 +0000
Subject: [issue10855] wave.Wave_read.close() doesn't release file
In-Reply-To: <1294417424.98.0.47429499245.issue10855@psf.upfronthosting.co.za>
Message-ID: <1294846329.52.0.817384849698.issue10855@psf.upfronthosting.co.za>


Peter Creath <pjcreath+python at gmail.com> added the comment:

Thank you for clarifying the documentation.  However, I don't think that fully resolves the issue.

I'm not complaining about a failure to close the file.  As you observe, it doesn't need to (and shouldn't) close a file object, but it should release the reference.

The code already tries to release the reference ("self._file = None").  It just fails to release it correctly, missing the other reference to the file object (self._data_chunk).  That's the bug.

Your clarification of the documentation is appreciated nonetheless.

I've attached a patch as Ned requested.  The same patch can currently be applied to release27-maint, release31-maint, and py3k.  (The line numbers and surrounding context are identical.)

----------
keywords: +patch
resolution: fixed -> 
status: closed -> open
versions: +Python 2.5, Python 2.6, Python 3.1
Added file: http://bugs.python.org/file20374/issue10855.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10855>
_______________________________________

From report at bugs.python.org  Wed Jan 12 16:33:42 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 12 Jan 2011 15:33:42 +0000
Subject: [issue10225] Fix doctest runable examples in python manual
In-Reply-To: <1288318735.45.0.959857258913.issue10225@psf.upfronthosting.co.za>
Message-ID: <1294846422.29.0.831272331294.issue10225@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

I have updated Sphinx and rerun py3k doctests.  It looks like the newest Sphinx does not check examples unless the file has a .. testsetup::  directive somewhere.  This is nice because it focuses on the files that are clearly intended to be doctest-checked.  Of course, there are many perfectly good code examples that are now skipped, but this can be addressed in the next step.

I am attaching a patch that makes the following command succeed in py3k Doc directory:

$ sphinx-build --version
Sphinx v1.1pre
..
$ sphinx-build -b doctest -d build/doctrees . build/doctest
..
Doctest summary
===============
  581 tests
    0 failures ..

Most of the changes in issue10225-py3k.diff are non-controvercial with the exception of code fixes in collections and difflib.

In collections, I removed trailing whitespace from generated namedtuple code and in difflib I changed get_close_matches() return value from map object to a list.   I would appreciate comments on these two changes.

----------
Added file: http://bugs.python.org/file20375/issue10225-py3k.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10225>
_______________________________________

From report at bugs.python.org  Wed Jan 12 16:34:25 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 12 Jan 2011 15:34:25 +0000
Subject: [issue10892] segfault with "del X.__abstractmethods__"
In-Reply-To: <1294834156.26.0.13558320611.issue10892@psf.upfronthosting.co.za>
Message-ID: <1294846465.12.0.516690893781.issue10892@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

r87954

----------
nosy: +benjamin.peterson
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10892>
_______________________________________

From report at bugs.python.org  Wed Jan 12 16:38:35 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 12 Jan 2011 15:38:35 +0000
Subject: [issue10225] Fix doctest runable examples in python manual
In-Reply-To: <1288318735.45.0.959857258913.issue10225@psf.upfronthosting.co.za>
Message-ID: <1294846715.93.0.0439072435915.issue10225@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


Added file: http://bugs.python.org/file20376/issue10225-py3k.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10225>
_______________________________________

From report at bugs.python.org  Wed Jan 12 16:38:42 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 12 Jan 2011 15:38:42 +0000
Subject: [issue10225] Fix doctest runable examples in python manual
In-Reply-To: <1288318735.45.0.959857258913.issue10225@psf.upfronthosting.co.za>
Message-ID: <1294846722.51.0.61781256328.issue10225@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


Removed file: http://bugs.python.org/file20375/issue10225-py3k.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10225>
_______________________________________

From report at bugs.python.org  Wed Jan 12 17:10:16 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 12 Jan 2011 16:10:16 +0000
Subject: [issue1488934] file.write + closed pipe = no error
Message-ID: <1294848616.57.0.709576998995.issue1488934@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Agreed with Charles-Fran?ois, this is normal behaviour since the bytes written on stdout are buffered (up to a certain size). If calling flush() doesn't solve the issue, please reopen the issue.

----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1488934>
_______________________________________

From report at bugs.python.org  Wed Jan 12 17:21:34 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 12 Jan 2011 16:21:34 +0000
Subject: [issue9941] Unify trace and profile interfaces
In-Reply-To: <1285347468.19.0.483467963743.issue9941@psf.upfronthosting.co.za>
Message-ID: <1294849294.61.0.786391664289.issue9941@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


----------
versions: +Python 3.3 -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9941>
_______________________________________

From report at bugs.python.org  Wed Jan 12 17:27:24 2011
From: report at bugs.python.org (Vladimir Rutsky)
Date: Wed, 12 Jan 2011 16:27:24 +0000
Subject: [issue10896] trace module compares directories as strings
	(--ignore-dir)
In-Reply-To: <1294843489.43.0.983792093108.issue10896@psf.upfronthosting.co.za>
Message-ID: <1294849644.6.0.993120212353.issue10896@psf.upfronthosting.co.za>


Vladimir Rutsky <rutsky.vladimir at gmail.com> added the comment:

Workaround for people on Windows who don't wan't to modify trace.py:
to get clean trace of only your project calls add to ignore list python path with mix of character cases. For me worked out this string:
  python -m trace --ignore-dir=c:\python26\lib;C:\python26\lib;C:\Python26\Lib -t main.py

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10896>
_______________________________________

From report at bugs.python.org  Wed Jan 12 17:42:56 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 12 Jan 2011 16:42:56 +0000
Subject: [issue10225] Fix doctest runable examples in python manual
In-Reply-To: <1288318735.45.0.959857258913.issue10225@psf.upfronthosting.co.za>
Message-ID: <1294850576.65.0.83039259773.issue10225@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Committed the simple fixes in r87957.  Updated the patch to include only the remaining changes.

----------
Added file: http://bugs.python.org/file20377/issue10225-py3k.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10225>
_______________________________________

From report at bugs.python.org  Wed Jan 12 17:43:07 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 12 Jan 2011 16:43:07 +0000
Subject: [issue10225] Fix doctest runable examples in python manual
In-Reply-To: <1288318735.45.0.959857258913.issue10225@psf.upfronthosting.co.za>
Message-ID: <1294850587.9.0.322680642334.issue10225@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


Removed file: http://bugs.python.org/file20376/issue10225-py3k.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10225>
_______________________________________

From report at bugs.python.org  Wed Jan 12 18:03:22 2011
From: report at bugs.python.org (SilentGhost)
Date: Wed, 12 Jan 2011 17:03:22 +0000
Subject: [issue10896] trace module compares directories as strings
	(--ignore-dir)
In-Reply-To: <1294843489.43.0.983792093108.issue10896@psf.upfronthosting.co.za>
Message-ID: <1294851802.36.0.911337158683.issue10896@psf.upfronthosting.co.za>


SilentGhost <ghost.adh at gmail.com> added the comment:

It's due to the os.path.normpath not normalizing case. Here is the patch.

Also affects 3.x

----------
keywords: +patch
nosy: +SilentGhost
versions: +Python 3.1, Python 3.2
Added file: http://bugs.python.org/file20378/trace.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10896>
_______________________________________

From report at bugs.python.org  Wed Jan 12 18:17:51 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 12 Jan 2011 17:17:51 +0000
Subject: [issue766910] fix one or two bugs in trace.py
In-Reply-To: <1291451642.88.0.784916842776.issue766910@psf.upfronthosting.co.za>
Message-ID: <AANLkTinScCOxqRPTGG5_eR3NqkQh-=i=Q_4YsPcCOR89@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Sat, Dec 4, 2010 at 3:34 AM, Eli Bendersky <report at bugs.python.org> wrote:
>..
> However, while experimenting, I think I ran into much larger problems. Either that or I've forgotten
> how to use the module :-)

I am afraid it is the latter. :-)  The file specified in --file option
should be a pickle, not a coverage file from the previous run.

$ ./python.exe -m trace -s -f counts.pickle -c trace_target.py
K is 380
Skipping counts file 'counts.pickle': [Errno 2] No such file or
directory: 'counts.pickle'
lines   cov%   module   (path)
    1   100%   trace   (/Users/sasha/Work/python-svn/py3k-commit/Lib/trace.py)
    9   100%   trace_target   (trace_target.py)
    6   100%   traced_module   (traced_module.py)

$ ./python.exe -m pickletools counts.pickle
    0: (    MARK
    1: }        EMPTY_DICT
    2: q        BINPUT     0
    4: (        MARK
    5: (            MARK
    6: X                BINUNICODE 'trace_target.py'
...

However, there is a problem here, I think:

$ ./python.exe -m trace -s -f counts.pickle -c trace_target.py
K is 380
lines   cov%   module   (path)
    1   100%   trace   (/Users/sasha/Work/python-svn/py3k-commit/Lib/trace.py)
    9   100%   trace_target   (trace_target.py)
    6   100%   traced_module   (traced_module.py)
$ ./python.exe -m trace -s -f counts.pickle -c trace_target.py
K is 380
lines   cov%   module   (path)
    1   100%   trace   (/Users/sasha/Work/python-svn/py3k-commit/Lib/trace.py)
    9   100%   trace_target   (trace_target.py)
    6   100%   traced_module   (traced_module.py)

The counts should grow in repeated runs.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue766910>
_______________________________________

From report at bugs.python.org  Wed Jan 12 18:23:01 2011
From: report at bugs.python.org (SilentGhost)
Date: Wed, 12 Jan 2011 17:23:01 +0000
Subject: [issue10896] trace module compares directories as strings
	(--ignore-dir)
In-Reply-To: <1294843489.43.0.983792093108.issue10896@psf.upfronthosting.co.za>
Message-ID: <1294852981.21.0.947341639743.issue10896@psf.upfronthosting.co.za>


Changes by SilentGhost <ghost.adh at gmail.com>:


----------
nosy: +belopolsky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10896>
_______________________________________

From report at bugs.python.org  Wed Jan 12 18:25:11 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 12 Jan 2011 17:25:11 +0000
Subject: [issue10894] Making stdlib APIs private
In-Reply-To: <1294838236.87.0.84648349826.issue10894@psf.upfronthosting.co.za>
Message-ID: <1294853111.81.0.157134255668.issue10894@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <benjamin at python.org>:


----------
dependencies: +Private stdlib API: getopt, getpass, glob, gzip, genericpath, gettext

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10894>
_______________________________________

From report at bugs.python.org  Wed Jan 12 18:25:29 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 12 Jan 2011 17:25:29 +0000
Subject: [issue10896] trace module compares directories as strings
	(--ignore-dir)
In-Reply-To: <1294843489.43.0.983792093108.issue10896@psf.upfronthosting.co.za>
Message-ID: <1294853129.03.0.367885148817.issue10896@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
stage:  -> patch review
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10896>
_______________________________________

From report at bugs.python.org  Wed Jan 12 18:31:20 2011
From: report at bugs.python.org (SilentGhost)
Date: Wed, 12 Jan 2011 17:31:20 +0000
Subject: [issue10895] Private stdlib API: getopt, getpass, glob, gzip,
	genericpath, gettext
In-Reply-To: <1294838463.37.0.519255760117.issue10895@psf.upfronthosting.co.za>
Message-ID: <1294853480.32.0.106605016419.issue10895@psf.upfronthosting.co.za>


SilentGhost <ghost.adh at gmail.com> added the comment:

Attached patch is fro gettext

None of the public members of the module has any docstrings. I'm not sure that simple copying from Doc/library/gettext.rst would be satisfactory. But if it is, please let me know.

----------
Added file: http://bugs.python.org/file20379/gettext_api.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10895>
_______________________________________

From report at bugs.python.org  Wed Jan 12 18:33:50 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 12 Jan 2011 17:33:50 +0000
Subject: [issue10897] UNIX mmap unnecessarily dup() file descriptor
In-Reply-To: <1294845379.76.0.427887707002.issue10897@psf.upfronthosting.co.za>
Message-ID: <1294853630.43.0.291240778538.issue10897@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Thanks for the report and patch.  Can you refresh it against the py3k branch?  Bugs are fixed there and then backported to 3.1 and 2.7.  If possible, please include a test in your patch.

----------
nosy: +eric.araujo, facundobatista, georg.brandl, josiahcarlson, pitrou
stage:  -> patch review
versions:  -Python 2.5, Python 2.6, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10897>
_______________________________________

From report at bugs.python.org  Wed Jan 12 18:35:13 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 12 Jan 2011 17:35:13 +0000
Subject: [issue10894] Making stdlib APIs private
In-Reply-To: <1294838236.87.0.84648349826.issue10894@psf.upfronthosting.co.za>
Message-ID: <1294853713.27.0.867782650018.issue10894@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/issue10894>
_______________________________________

From report at bugs.python.org  Wed Jan 12 18:36:06 2011
From: report at bugs.python.org (Erik Demaine)
Date: Wed, 12 Jan 2011 17:36:06 +0000
Subject: [issue1488934] file.write + closed pipe = no error
Message-ID: <1294853766.03.0.52427696718.issue1488934@psf.upfronthosting.co.za>


Erik Demaine <edemaine at mit.edu> added the comment:

msg28537 shows a version with flush, and says that it fails.  I haven't tested since 2006, though, so I can retry, in particular to see whether the patch suggested in the original post has been applied now.

----------
resolution: invalid -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1488934>
_______________________________________

From report at bugs.python.org  Wed Jan 12 18:37:04 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 12 Jan 2011 17:37:04 +0000
Subject: [issue10895] Private stdlib API: getopt, getpass, glob, gzip,
	genericpath, gettext
In-Reply-To: <1294838463.37.0.519255760117.issue10895@psf.upfronthosting.co.za>
Message-ID: <1294853824.91.0.445458537615.issue10895@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +brett.cannon, eric.araujo, rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10895>
_______________________________________

From report at bugs.python.org  Wed Jan 12 18:42:59 2011
From: report at bugs.python.org (R. David Murray)
Date: Wed, 12 Jan 2011 17:42:59 +0000
Subject: [issue4953] cgi module cannot handle POST with multipart/form-data
	in	3.0
In-Reply-To: <1232010166.79.0.972664060868.issue4953@psf.upfronthosting.co.za>
Message-ID: <1294854179.7.0.397225502276.issue4953@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Yes, the immanence of RC1 makes it really doubtful that this can be fixed in 3.2.  Whether or not it can be fixed in 3.2.1 will depend on the nature of the fix.  If it changes behavior such that currently working uses of FieldStorage (that don't deal with binary files) break, then the fix can't be backported.  Likewise if the API changes, the change can't be backported.

Doing the deprecation sounds like a good idea.  Would you be willing to propose a patch with tests?  I'm pretty busy this week and I doubt I can do anything myself about it before the weekend.

If this cannot be fixed in a way that is backward compatible (and even if it can), in 3.3 we also have the option of adding features to the email package to better support the use cases in HTTP if that makes sense.  Certainly the external file support is something that email needs for itself, so it would be nice to add that in 3.3.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4953>
_______________________________________

From report at bugs.python.org  Wed Jan 12 18:58:21 2011
From: report at bugs.python.org (SilentGhost)
Date: Wed, 12 Jan 2011 17:58:21 +0000
Subject: [issue10897] UNIX mmap unnecessarily dup() file descriptor
In-Reply-To: <1294845379.76.0.427887707002.issue10897@psf.upfronthosting.co.za>
Message-ID: <1294855101.64.0.840193271133.issue10897@psf.upfronthosting.co.za>


Changes by SilentGhost <ghost.adh at gmail.com>:


----------
nosy: +SilentGhost

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10897>
_______________________________________

From report at bugs.python.org  Wed Jan 12 19:10:02 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 12 Jan 2011 18:10:02 +0000
Subject: [issue1488934] file.write + closed pipe = no error
Message-ID: <1294855802.85.0.715005305665.issue1488934@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> msg28537 shows a version with flush, and says that it fails

I cannot reproduce. Either with Python 2.5.2 (!), 2.7 or 3.2, on a remote Debian system. Even using "kill -9" on the local ssh process does shut down the remote Python process.
If I comment out the flush() call, it is clearly reproduceable. I would suggest you did something wrong when testing the flush() version.

----------
resolution:  -> invalid
stage: unit test needed -> 
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1488934>
_______________________________________

From report at bugs.python.org  Wed Jan 12 19:30:25 2011
From: report at bugs.python.org (Erik Demaine)
Date: Wed, 12 Jan 2011 18:30:25 +0000
Subject: [issue1488934] file.write + closed pipe = no error
Message-ID: <1294857025.23.0.984562774502.issue1488934@psf.upfronthosting.co.za>


Erik Demaine <edemaine at mit.edu> added the comment:

I just tested on Python 2.5.2, 2.6.2, and 3.0.1, and I could not reproduce the error (using the code in msg28537).  It would seem that file.flush is catching the problem, even though file.write is ignoring the error, but I can't see any changes since 1.5.2 that would have changed this behavior of file.flush.  So I'm not sure what happened, but at least it seems to no longer be a bug.  Closing.

----------
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1488934>
_______________________________________

From report at bugs.python.org  Wed Jan 12 19:32:29 2011
From: report at bugs.python.org (Alan Hourihane)
Date: Wed, 12 Jan 2011 18:32:29 +0000
Subject: [issue10898] posixmodule.c redefines FSTAT
In-Reply-To: <1294857148.96.0.548396285489.issue10898@psf.upfronthosting.co.za>
Message-ID: <1294857148.96.0.548396285489.issue10898@psf.upfronthosting.co.za>


New submission from Alan Hourihane <alanh at fairlite.co.uk>:

Python 2.7.1 redefines FSTAT, but the problem is my libc already defines FSTAT in sys/ioctl.h.

I've worked around this by prefixing the FSTAT define with PYTHON. It should probably be done with STAT too.

--- Modules/posixmodule.c.old	2011-01-12 01:46:45.000000000 +0000
+++ Modules/posixmodule.c	2011-01-12 01:47:05.000000000 +0000
@@ -344,11 +344,11 @@
 #undef STAT
 #if defined(MS_WIN64) || defined(MS_WINDOWS)
 #       define STAT win32_stat
-#       define FSTAT win32_fstat
+#       define PYTHON_FSTAT win32_fstat
 #       define STRUCT_STAT struct win32_stat
 #else
 #       define STAT stat
-#       define FSTAT fstat
+#       define PYTHON_FSTAT fstat
 #       define STRUCT_STAT struct stat
 #endif
 
@@ -6641,7 +6641,7 @@
     if (!_PyVerify_fd(fd))
         return posix_error();
     Py_BEGIN_ALLOW_THREADS
-    res = FSTAT(fd, &st);
+    res = PYTHON_FSTAT(fd, &st);
     Py_END_ALLOW_THREADS
     if (res != 0) {
 #ifdef MS_WINDOWS

----------
messages: 126120
nosy: alanh
priority: normal
severity: normal
status: open
title: posixmodule.c redefines FSTAT
type: compile error

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10898>
_______________________________________

From report at bugs.python.org  Wed Jan 12 19:38:20 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 12 Jan 2011 18:38:20 +0000
Subject: [issue9880] GCC 4.6 bug with -ftree-vectorize
In-Reply-To: <1284674532.4.0.904279806396.issue9880@psf.upfronthosting.co.za>
Message-ID: <1294857500.59.0.271670393824.issue9880@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

I reported the bug to GCC:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47271

----------
title: Python 2.7 Won't Build: SystemError: unknown opcode -> GCC 4.6 bug with -ftree-vectorize

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9880>
_______________________________________

From report at bugs.python.org  Wed Jan 12 19:38:44 2011
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 12 Jan 2011 18:38:44 +0000
Subject: [issue10894] Making stdlib APIs private
In-Reply-To: <1294838236.87.0.84648349826.issue10894@psf.upfronthosting.co.za>
Message-ID: <1294857524.94.0.311213957592.issue10894@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

I will be writing a proper task item for this (there's a reason it's a todo item =), but I will read this before writing it so feel free to leave any thoughts or ideas for the future task.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10894>
_______________________________________

From report at bugs.python.org  Wed Jan 12 19:44:46 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 12 Jan 2011 18:44:46 +0000
Subject: [issue10895] Private stdlib API: getopt, getpass, glob, gzip,
	genericpath, gettext
In-Reply-To: <1294838463.37.0.519255760117.issue10895@psf.upfronthosting.co.za>
Message-ID: <1294857886.38.0.389865238537.issue10895@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

-0

It is questionable whether this should be done at all.  Either it is irrelevant or it will break someone's code.

----------
priority: normal -> low

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10895>
_______________________________________

From report at bugs.python.org  Wed Jan 12 19:47:53 2011
From: report at bugs.python.org (SilentGhost)
Date: Wed, 12 Jan 2011 18:47:53 +0000
Subject: [issue10894] Making stdlib APIs private
In-Reply-To: <1294838236.87.0.84648349826.issue10894@psf.upfronthosting.co.za>
Message-ID: <1294858073.4.0.739950884751.issue10894@psf.upfronthosting.co.za>


Changes by SilentGhost <ghost.adh at gmail.com>:


----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10894>
_______________________________________

From report at bugs.python.org  Wed Jan 12 19:50:05 2011
From: report at bugs.python.org (Glenn Linderman)
Date: Wed, 12 Jan 2011 18:50:05 +0000
Subject: [issue4953] cgi module cannot handle POST with multipart/form-data
	in	3.0
In-Reply-To: <1232010166.79.0.972664060868.issue4953@psf.upfronthosting.co.za>
Message-ID: <1294858205.48.0.997751298252.issue4953@psf.upfronthosting.co.za>


Glenn Linderman <v+python at g.nevcal.com> added the comment:

I'd be willing to propose such a patch and tests, but I haven't a clue how, other than starting by reading the contributor document... I was putting off learning the process until hg conversion, not wanting to learn an old process for a few months :(  And I've never written an official Python test, or learned how to use the test modules, etc.  So that's a pretty steep curve for the 2 days remaining.

Due to the way that browsers actually work, vs. how the standards are written, it seems necessary to add the optional  stream_encoding parameter.  The limit parameter Pierre is proposing is also a good check against improperly formed inputs.  So there are new, optional parameters to the FieldStorage constructor.

Without these fixes, though, cgi.py continues to be totally useless for file uploads, so not releasing this in 3.2 makes 3.2 continue to be useless as a basis for web applications.  I have no idea if there is a timeframe for 3.3, nor what it is.  I'm not sure if, or how many, web frameworks use cgi.py vs. replacing the functionality.  Seems at least some replace it, so they may not suffer in porting to 3.x (except internally, grappling with the same issues).

Happily, Pierre's latest patch needs only one more fix, per my (non-Python-standard) testing.  Between his testing in one environment using default code pages, and mine using UTF-8, the bases seem to be pretty well covered for testing... certainly more than the previous default tests.  I think you contributed some tests, I haven't tried them, but it seems Pierre has, as he has a patch for that also (which I haven't tried).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4953>
_______________________________________

From report at bugs.python.org  Wed Jan 12 19:58:18 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 12 Jan 2011 18:58:18 +0000
Subject: [issue10822] test_getgroups failure under Solaris
In-Reply-To: <1294139319.03.0.190267830849.issue10822@psf.upfronthosting.co.za>
Message-ID: <1294858698.54.0.257570286548.issue10822@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Thanks for the patch! Committed in r87958 (3.2), r87959 (3.1) and r87961 (2.7).

----------
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10822>
_______________________________________

From report at bugs.python.org  Wed Jan 12 19:58:34 2011
From: report at bugs.python.org (SilentGhost)
Date: Wed, 12 Jan 2011 18:58:34 +0000
Subject: [issue10897] UNIX mmap unnecessarily dup() file descriptor
In-Reply-To: <1294845379.76.0.427887707002.issue10897@psf.upfronthosting.co.za>
Message-ID: <1294858714.78.0.804231333069.issue10897@psf.upfronthosting.co.za>


SilentGhost <ghost.adh at gmail.com> added the comment:

version of the lorenz's patch agains py3k branch.

----------
Added file: http://bugs.python.org/file20380/mmap.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10897>
_______________________________________

From report at bugs.python.org  Wed Jan 12 20:09:48 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 12 Jan 2011 19:09:48 +0000
Subject: [issue10897] UNIX mmap unnecessarily dup() file descriptor
In-Reply-To: <1294845379.76.0.427887707002.issue10897@psf.upfronthosting.co.za>
Message-ID: <1294859388.67.0.120682010094.issue10897@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

The problem is that it's a change in semantics. So it definitely can't be backported to the bugfix branches, nor committed into 3.2 which is in feature freeze now.

The question is which behaviour is the most expected by users of the module. I'd say that dup()ing definitely isn't intuitive, and it isn't documented; on the other hand, at least one of the examples seems to assume the original file descriptor is untouched when close()ing the mmap object:

with open("hello.txt", "r+b") as f:
    # memory-map the file, size 0 means whole file
    map = mmap.mmap(f.fileno(), 0)
    # read content via standard file methods
    print(map.readline())  # prints b"Hello Python!\n"
    # read content via slice notation
    print(map[:5])  # prints b"Hello"
    # update content using slice notation;
    # note that new content must have same size
    map[6:] = b" world!\n"
    # ... and read again using standard file methods
    map.seek(0)
    print(map.readline())  # prints b"Hello  world!\n"
    # close the map
    map.close()

----------
versions: +Python 3.3 -Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10897>
_______________________________________

From report at bugs.python.org  Wed Jan 12 20:13:19 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 12 Jan 2011 19:13:19 +0000
Subject: [issue10893] The docs mark staticmethod as a function
In-Reply-To: <1294837196.34.0.0437845342766.issue10893@psf.upfronthosting.co.za>
Message-ID: <1294859599.83.0.135485755659.issue10893@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <rhettinger at users.sourceforge.net>:


----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10893>
_______________________________________

From report at bugs.python.org  Wed Jan 12 20:23:09 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 12 Jan 2011 19:23:09 +0000
Subject: [issue10894] Making stdlib APIs private
In-Reply-To: <1294838236.87.0.84648349826.issue10894@psf.upfronthosting.co.za>
Message-ID: <1294860189.03.0.337196855239.issue10894@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

My take on this:
- adding underscores to locally-defined private functions is good. +1
- -0.5 on "from warnings import warn as _warn"; it's useless complication, users should be able to realize warn() is a public API of the warnings module, not whichever else module using it

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10894>
_______________________________________

From report at bugs.python.org  Wed Jan 12 20:24:49 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 12 Jan 2011 19:24:49 +0000
Subject: [issue10894] Making stdlib APIs private
In-Reply-To: <1294838236.87.0.84648349826.issue10894@psf.upfronthosting.co.za>
Message-ID: <1294860289.46.0.0817215464417.issue10894@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Oh, by the way, it can be good to check that the APIs are not used too widely. Example for such a query:
http://www.google.com/codesearch?q=lang%3Apython%20do_longs&hl=fr
(in this case, it's clear that only copies of the stdlib reference that function)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10894>
_______________________________________

From report at bugs.python.org  Wed Jan 12 20:24:51 2011
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 12 Jan 2011 19:24:51 +0000
Subject: [issue10855] wave.Wave_read.close() doesn't release file
In-Reply-To: <1294417424.98.0.47429499245.issue10855@psf.upfronthosting.co.za>
Message-ID: <1294860291.07.0.100839065214.issue10855@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

I don't really see the bug here.  Either you openened the file object, then you have to close it.  Or wave.py opened it, then it will close it, no matter if it still has a reference or not.

Of course we could set _data_chunk to None, but I'm unsure what behavior change you would expect from that.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10855>
_______________________________________

From report at bugs.python.org  Wed Jan 12 20:30:38 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 12 Jan 2011 19:30:38 +0000
Subject: [issue10855] wave.Wave_read.close() doesn't release file
In-Reply-To: <1294417424.98.0.47429499245.issue10855@psf.upfronthosting.co.za>
Message-ID: <1294860638.29.0.953346789217.issue10855@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Agreed with Georg. No OS resource is leaking if the file is explicitly closed (since it releases the underlying file descriptor). That the Python "file object" is still attached somewhere is of secondary importance.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10855>
_______________________________________

From report at bugs.python.org  Wed Jan 12 20:36:43 2011
From: report at bugs.python.org (SilentGhost)
Date: Wed, 12 Jan 2011 19:36:43 +0000
Subject: [issue10874] test_urllib2 shouldn't use is operator for comparing
	strings
In-Reply-To: <1294591963.25.0.901803829485.issue10874@psf.upfronthosting.co.za>
Message-ID: <1294861003.82.0.654838088516.issue10874@psf.upfronthosting.co.za>


SilentGhost <ghost.adh at gmail.com> added the comment:

Committed for 2.7 in r87964, for 3.1 in r87965.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10874>
_______________________________________

From report at bugs.python.org  Wed Jan 12 21:16:59 2011
From: report at bugs.python.org (Peter Creath)
Date: Wed, 12 Jan 2011 20:16:59 +0000
Subject: [issue10855] wave.Wave_read.close() doesn't release file
In-Reply-To: <1294417424.98.0.47429499245.issue10855@psf.upfronthosting.co.za>
Message-ID: <1294863419.9.0.754318276391.issue10855@psf.upfronthosting.co.za>


Peter Creath <pjcreath+python at gmail.com> added the comment:

A point of clarification on the original report: Georg is completely right when he points out that this is only an issue when passing in a file object.  If passed a filename, wave.py both opens and closes the file explicitly, and the dangling reference isn't important, as Antoine observes.

However, a retained reference in the file-object case is still a leak.

Georg writes: "Of course we could set _data_chunk to None, but I'm unsure what behavior change you would expect from that."

It allows garbage collection to close the file object if there are no more references to it.  It seems reasonable for a client of wave.py to assume that close() will release all references to the object, and indeed the code seems to support that assumption -- it sets _file to None.

If releasing references were truly of no importance, then I would argue that the line setting _file to None should be removed.  It serves no purpose after wave.py has explicitly closed the file (if it opened it) other than to release a reference to the file object.

Therefore, I suggest that _data_chunk should also be set to None in order to release the reference completely, thereby allowing the file object to be garbage collected.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10855>
_______________________________________

From report at bugs.python.org  Wed Jan 12 21:22:13 2011
From: report at bugs.python.org (Lorenz Huedepohl)
Date: Wed, 12 Jan 2011 20:22:13 +0000
Subject: [issue10897] UNIX mmap unnecessarily dup() file descriptor
In-Reply-To: <1294845379.76.0.427887707002.issue10897@psf.upfronthosting.co.za>
Message-ID: <1294863733.71.0.0379947152939.issue10897@psf.upfronthosting.co.za>


Lorenz Huedepohl <lorenz at mpa-garching.mpg.de> added the comment:

Thanks SilentGhost, you were much faster than me :)

I agree with Antoine, that the dup() is unexpected: It cost me some time to figure out where these additonal file descriptors originated from. One of the powers of mmap() is, that you do not need one, so it would really be great if this feature could be saved into the python abstraction.

As for the example: I think this could be cured by removing the close(m_obj->fd); statement, again shifing the responsibility for that to the creator of the intial file handle - see my attached patch.
(This time against the py3k patch)

BTW: It is a great experience for a python user to see just how fast you guys react to an issue here! Thanks!

----------
Added file: http://bugs.python.org/file20381/no_dup_no_close.py3k.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10897>
_______________________________________

From report at bugs.python.org  Wed Jan 12 21:38:59 2011
From: report at bugs.python.org (Charles-Francois Natali)
Date: Wed, 12 Jan 2011 20:38:59 +0000
Subject: [issue8771] Socket freezing under load issue on Mac.
In-Reply-To: <1274312247.36.0.878213869408.issue8771@psf.upfronthosting.co.za>
Message-ID: <1294864739.25.0.589102259946.issue8771@psf.upfronthosting.co.za>


Charles-Francois Natali <neologix at free.fr> added the comment:

As explained by Jean-Paul, it's due to the fact that the closed TCP sockets spend some time in TIME-WAIT state before being deallocated.
On Linux, this issue can be more or less worked-around using sysctl (net.ipv4.tcp_tw_{reuse,recycle}). There might be something similar on OS-X.
It's definitely an OS-level tuning issue.
Suggesting to close.

----------
nosy: +neologix

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8771>
_______________________________________

From report at bugs.python.org  Wed Jan 12 21:43:52 2011
From: report at bugs.python.org (Alice Bevan-McGregor)
Date: Wed, 12 Jan 2011 20:43:52 +0000
Subject: [issue8771] Socket freezing under load issue on Mac.
In-Reply-To: <1274312247.36.0.878213869408.issue8771@psf.upfronthosting.co.za>
Message-ID: <1294865032.69.0.495967538675.issue8771@psf.upfronthosting.co.za>


Alice Bevan-McGregor <alice at gothcandy.com> added the comment:

Agreed; I'm now certain it's a local tuning issue.  My first attempt to alter the file descriptor limits for local testing resulted in catastrophic system failure, though, so I have no clue as to the correct method to alter the TIME_WAIT time.

I will continue to investigate, thank you for the lead.

----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8771>
_______________________________________

From report at bugs.python.org  Wed Jan 12 22:05:05 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 12 Jan 2011 21:05:05 +0000
Subject: [issue10855] wave.Wave_read.close() doesn't release file
In-Reply-To: <1294417424.98.0.47429499245.issue10855@psf.upfronthosting.co.za>
Message-ID: <1294866305.99.0.882142664623.issue10855@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> It allows garbage collection to close the file object if there are no 
> more references to it.

This is a very bad policy to begin with. Garbage collection can be delayed for a number of reasons:
- someone might be running your program on a Python implementation which doesn't use reference counting (such as Jython or PyPy)
- an exception, together with its traceback object, might capture the value of some local variables and keep them alive (that is, reachable from the GC's point of view)
- a reference cycle might delay proper resource cleanup until the cyclic garbage collector kicks in

So the good thing to do is to close your file explicitly. Luckily, Python 2.6 and upwards makes it easier by using the "with" statement.

IMO this issue should be closed.

----------
resolution:  -> rejected
stage: unit test needed -> 
status: open -> pending
versions:  -Python 2.5, Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10855>
_______________________________________

From report at bugs.python.org  Wed Jan 12 22:09:54 2011
From: report at bugs.python.org (yeswanth)
Date: Wed, 12 Jan 2011 21:09:54 +0000
Subject: [issue2650] re.escape should not escape underscore
In-Reply-To: <1208441650.53.0.945063086485.issue2650@psf.upfronthosting.co.za>
Message-ID: <1294866594.24.0.989868075126.issue2650@psf.upfronthosting.co.za>


yeswanth <swamiyeswanth at yahoo.com> added the comment:

As James said I have written the patch using only regular expressions . This is going to be my first patch . I need help writing the test for it

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2650>
_______________________________________

From report at bugs.python.org  Wed Jan 12 22:14:12 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 12 Jan 2011 21:14:12 +0000
Subject: [issue9124] Mailbox module should use binary I/O, not text I/O
In-Reply-To: <1277900903.38.0.556015912714.issue9124@psf.upfronthosting.co.za>
Message-ID: <1294866852.09.0.609718105547.issue9124@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

RDM, you were suggested for this by Thomas Wouters (who wrote much of the existing code).  Are you up for it?

----------
assignee:  -> r.david.murray
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9124>
_______________________________________

From report at bugs.python.org  Wed Jan 12 22:16:02 2011
From: report at bugs.python.org (Pierre Quentel)
Date: Wed, 12 Jan 2011 21:16:02 +0000
Subject: [issue4953] cgi module cannot handle POST with multipart/form-data
	in	3.0
In-Reply-To: <1232010166.79.0.972664060868.issue4953@psf.upfronthosting.co.za>
Message-ID: <1294866962.11.0.803094391738.issue4953@psf.upfronthosting.co.za>


Pierre Quentel <pierre.quentel at gmail.com> added the comment:

Many thoughts and tests after...

Glenn, the both of us were wrong : the encoding to use in FieldStorage is neither latin-1, nor sys.stdin.encoding : I tested form fields with characters whose utf-8 encoding has bytes that map to undefined in cp1252, the calls to the decode() method with sys.stdin.encoding failed

The encoding used by the browser is defined in the Content-Type meta tag, or the content-type header ; if not, the default seems to vary for different browsers. So it's definitely better to define it

The argument stream_encoding used in FieldStorage *must* be this encoding ; in this version, it is set to utf-8 by default

But this raises another problem, when the CGI script has to print the data received. The built-in print() function encodes the string with sys.stdout.encoding, and this will fail if the string can't be encoded with it. It is the case on my PC, where sys.stdout.encoding is cp1252 : it can't handle Arabic or Chinese characters

The solution I have tried is to pass another argument, charset, to the FieldStorage contructor, defaulting to utf-8. It must be the same as the charset defined in the CGI script in the Content-Type header

FieldStorage uses this argument to override the built-in print() function :
- flush the text layer of sys.stdin, in case calls to print() have been made before calling FieldStorage
- get the binary layer of stdout : out = sys.stdout.detach()
- define a function _print this way:
	def _print(*strings):
		for item in strings:
			out.write(str(item).encode(charset))
		out.write(b'\r\n')
- override print() :
    import builtins
    builtins.print = _print

The function print() in the CGI script now sends the strings encoded with "charset" to the binary layer of sys.stdout. All the tests I made with Arabic or Chinese input fileds, or file names, succed when using this patch ; so do test_cgi and cgi_test (slightly modified)

----------
Added file: http://bugs.python.org/file20382/cgi_diff_20110112.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4953>
_______________________________________

From report at bugs.python.org  Wed Jan 12 22:21:06 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 12 Jan 2011 21:21:06 +0000
Subject: [issue2650] re.escape should not escape underscore
In-Reply-To: <1208441650.53.0.945063086485.issue2650@psf.upfronthosting.co.za>
Message-ID: <1294867266.69.0.991625392143.issue2650@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> As James said I have written the patch using only regular expressions . 
> This is going to be my first patch . I need help writing the test for it

You will find the current tests in Lib/test/test_re.py.
To execute them, run:
$ ./python -m test.regrtest -v test_re

In this case, there are probably already some tests for re.escape. So you have to check that they are sufficient, and that your patch doesn't make them fail.

----------
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2650>
_______________________________________

From report at bugs.python.org  Wed Jan 12 22:31:48 2011
From: report at bugs.python.org (Matt Chaput)
Date: Wed, 12 Jan 2011 21:31:48 +0000
Subject: [issue1172711] long long support for array module
Message-ID: <1294867908.74.0.488731565287.issue1172711@psf.upfronthosting.co.za>


Matt Chaput <matt at sidefx.com> added the comment:

This is an important feature to me. Now I get to redo a bunch of code to have two completely different code paths to do the same thing because nobody could be bothered to keep array up-to-date.

----------
nosy: +mattchaput

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1172711>
_______________________________________

From report at bugs.python.org  Wed Jan 12 22:50:05 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 12 Jan 2011 21:50:05 +0000
Subject: [issue10899] No function type annotations in the standard library
In-Reply-To: <1294869005.61.0.164570460851.issue10899@psf.upfronthosting.co.za>
Message-ID: <1294869005.61.0.164570460851.issue10899@psf.upfronthosting.co.za>


New submission from Raymond Hettinger <rhettinger at users.sourceforge.net>:

The discussion for PEP 3107 said the use and interpretation of function type annotations was being left open for third-party developers to use as they see fit (some may use strings, other ABCs, others concrete types, or tuples of types or some other structure).   

Accordingly, we're not used them in the standard library because that would trump third-party uses.

The exception is in the file Lib/_pyio.py which has a number of function annotations.  I think those annotations should be replaced with comments.  As it stands, they're untested, undocumented, and at odds with our idea to let the rest of the world decide how and when to use function type annotations.

Guido, I think you pronounced on this a long time ago.  Unfortunately, the PEP stops just short of saying "don't use this in the standard library" and the email threads are too voluminous to re-read.

So, I wanted to ask, what do you think now?  My vote is keep the stdlib out of the function type annotation business.

------------------
Excerpts from the PEP:
"""The only way that annotations take on meaning is when they are interpreted by third-party libraries. These annotation consumers can do anything they want with a function's annotations. For example, one library might use string-based annotations to provide improved help messages, like so ..."""

"""this PEP makes no attempt to introduce any kind of standard semantics, even for the built-in types. This work will be left to third-party libraries."""

"""Though discussed early on ([5], [6]), including special objects in the stdlib for annotating generator functions and higher-order functions was ultimately rejected as being more appropriate for third-party libraries; including them in the standard library raised too many thorny issues."""

"""Despite considerable discussion about a standard type parameterisation syntax, it was decided that this should also be left to third-party libraries. """

""" Despite yet more discussion, it was decided not to standardize a mechanism for annotation interoperability. Standardizing interoperability conventions at this point would be premature. We would rather let these conventions develop organically, based on real-world usage and necessity, than try to force all users into some contrived scheme. """

----------
assignee: gvanrossum
messages: 126143
nosy: collinwinter, gvanrossum, rhettinger
priority: normal
severity: normal
status: open
title: No function type annotations in the standard library
versions: Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10899>
_______________________________________

From report at bugs.python.org  Wed Jan 12 22:52:21 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 12 Jan 2011 21:52:21 +0000
Subject: [issue9124] Mailbox module should use binary I/O, not text I/O
In-Reply-To: <1277900903.38.0.556015912714.issue9124@psf.upfronthosting.co.za>
Message-ID: <1294869141.3.0.517774370047.issue9124@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

With the module being so slow as to be unusable, this can be considered a bugfix, so it is okay if the fix goes into 3.2.1.

----------
versions:  -Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9124>
_______________________________________

From report at bugs.python.org  Wed Jan 12 23:03:00 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 12 Jan 2011 22:03:00 +0000
Subject: [issue8771] Socket freezing under load issue on Mac.
In-Reply-To: <1274312247.36.0.878213869408.issue8771@psf.upfronthosting.co.za>
Message-ID: <1294869780.74.0.667288950228.issue8771@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/issue8771>
_______________________________________

From report at bugs.python.org  Wed Jan 12 23:19:51 2011
From: report at bugs.python.org (Peter Kleiweg)
Date: Wed, 12 Jan 2011 22:19:51 +0000
Subject: [issue4953] cgi module cannot handle POST with multipart/form-data
	in	3.0
In-Reply-To: <1232010166.79.0.972664060868.issue4953@psf.upfronthosting.co.za>
Message-ID: <1294870791.73.0.225221383625.issue4953@psf.upfronthosting.co.za>


Peter Kleiweg <pkleiweg at xs4all.nl> added the comment:

Pierre Quentel wrote:
- get the binary layer of stdout : out = sys.stdout.detach()

You can't do that! That makes sys.stdout unavaible to the program that is importing the cgi module.

Cgi should access and process sys.stdin only, as binary by means of sys.stdin.detach()

The cgi module is used to handle form data and uploaded files. But the resulting page is usually written by the main program or another module, using sys.stdout

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4953>
_______________________________________

From report at bugs.python.org  Wed Jan 12 23:24:04 2011
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 12 Jan 2011 22:24:04 +0000
Subject: [issue9880] GCC 4.6 bug with -ftree-vectorize
In-Reply-To: <1284674532.4.0.904279806396.issue9880@psf.upfronthosting.co.za>
Message-ID: <1294871044.13.0.261258660375.issue9880@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Do we have to keep this open?

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9880>
_______________________________________

From report at bugs.python.org  Wed Jan 12 23:26:05 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 12 Jan 2011 22:26:05 +0000
Subject: [issue9880] GCC 4.6 bug with -ftree-vectorize
In-Reply-To: <1284674532.4.0.904279806396.issue9880@psf.upfronthosting.co.za>
Message-ID: <1294871165.52.0.808833022681.issue9880@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> Do we have to keep this open?

Nope, let's close it.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9880>
_______________________________________

From report at bugs.python.org  Wed Jan 12 23:43:33 2011
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 12 Jan 2011 22:43:33 +0000
Subject: [issue10899] No function type annotations in the standard library
In-Reply-To: <1294869005.61.0.164570460851.issue10899@psf.upfronthosting.co.za>
Message-ID: <1294872213.62.0.948760819024.issue10899@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

On the one hand, I think that any framework that sets a convention for the meaning of annotations needs to cope with the possibility of other code using a different convention.  So in that sense this could be deemed a test case for the robustness of such a framework. :-)

On the other hand, having this precedent might give passers-by and perhaps future stdlib developers the idea that a convention has been adopted by the stdlib -- and its presence might impede the future selection of a better convention for the stdlib (or perhaps for all of Python).

So, given that they aren't used, and that they don't even seem to be set consistently, I think it's (marginally) better if they are removed and replaced by comments.

FWIW, I've long wished that the stdlib (and perhaps even PEP 8) would adopt a *comment-based* convention for indicating the types of arguments.  The Google Python style guide has a useful standard convention for this purpose:

http://google-styleguide.googlecode.com/svn/trunk/pyguide.html?showone=Comments#Comments

----------
assignee: gvanrossum -> rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10899>
_______________________________________

From report at bugs.python.org  Wed Jan 12 23:49:52 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 12 Jan 2011 22:49:52 +0000
Subject: [issue10899] No function type annotations in the standard library
In-Reply-To: <1294869005.61.0.164570460851.issue10899@psf.upfronthosting.co.za>
Message-ID: <1294872592.62.0.253466227156.issue10899@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> On the other hand, having this precedent might give passers-by and 
> perhaps future stdlib developers the idea that a convention has been 
> adopted by the stdlib

Could we simply state in PEP 8 that annotations have no official meaning and that anyone (including stdlib developers) can use it for whatever purpose they see fit?

> FWIW, I've long wished that the stdlib (and perhaps even PEP 8) would 
> adopt a *comment-based* convention for indicating the types of arguments.

You mean docstring-based?

----------
assignee: rhettinger -> 
components: +IO, Library (Lib)
nosy: +pitrou
versions: +Python 3.3 -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10899>
_______________________________________

From report at bugs.python.org  Wed Jan 12 23:52:12 2011
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 12 Jan 2011 22:52:12 +0000
Subject: [issue10899] No function type annotations in the standard library
In-Reply-To: <1294872592.62.0.253466227156.issue10899@psf.upfronthosting.co.za>
Message-ID: <AANLkTi=K+X5hnq+QxhAuEeYR0=i4QFAV+1Md1Dz6ju=b@mail.gmail.com>


Guido van Rossum <guido at python.org> added the comment:

On Wed, Jan 12, 2011 at 2:49 PM, Antoine Pitrou <report at bugs.python.org> wrote:
> Could we simply state in PEP 8 that annotations have no official meaning and that anyone (including stdlib developers) can use it for whatever purpose they see fit?

No, that is less strong than what I said. I agree with Raymond that
they should be kept out of the stdlib until we've come up with a
convention.

>> FWIW, I've long wished that the stdlib (and perhaps even PEP 8) would
>> adopt a *comment-based* convention for indicating the types of arguments.
>
> You mean docstring-based?

Sorry, yes.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10899>
_______________________________________

From report at bugs.python.org  Thu Jan 13 00:40:29 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 12 Jan 2011 23:40:29 +0000
Subject: [issue10899] No function type annotations in the standard library
In-Reply-To: <1294869005.61.0.164570460851.issue10899@psf.upfronthosting.co.za>
Message-ID: <1294875629.76.0.121010874277.issue10899@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Thanks for the quick reply.
Checked-in.  See r87977 and r87978.

----------
resolution:  -> fixed
status: open -> closed
versions: +Python 3.1 -Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10899>
_______________________________________

From report at bugs.python.org  Thu Jan 13 01:11:07 2011
From: report at bugs.python.org (Glenn Linderman)
Date: Thu, 13 Jan 2011 00:11:07 +0000
Subject: [issue4953] cgi module cannot handle POST with multipart/form-data
	in	3.0
In-Reply-To: <1232010166.79.0.972664060868.issue4953@psf.upfronthosting.co.za>
Message-ID: <1294877467.71.0.802431556227.issue4953@psf.upfronthosting.co.za>


Glenn Linderman <v+python at g.nevcal.com> added the comment:

Pierre said:
The encoding used by the browser is defined in the Content-Type meta tag, or the content-type header ; if not, the default seems to vary for different browsers. So it's definitely better to define it

The argument stream_encoding used in FieldStorage *must* be this encoding

I say:
I agree it is better to define it.  I think you just said the same thing that the page I linked to said, I might not have conveyed that correctly in my paraphrasing.  I assume you are talking about the charset of the Content-Type of the form page itself, as served to the browser, as the browser, sadly, doesn't send that charset back with the form data.

Pierre says:
But this raises another problem, when the CGI script has to print the data received. The built-in print() function encodes the string with sys.stdout.encoding, and this will fail if the string can't be encoded with it. It is the case on my PC, where sys.stdout.encoding is cp1252 : it can't handle Arabic or Chinese characters

I say:
I don't think there is any need to override print, especially not builtins.print.  It is still true that the HTTP data stream is and should be treated as a binary stream.  So the script author is responsible for creating such a binary stream.

The FieldStorage class does not use the print method, so it seems inappropriate to add a parameter to its constructor to create a print method that it doesn't use.

For the convenience of CGI script authors, it would be nice if CGI provided access to the output stream in a useful way... and I agree that because the generation of an output page comes complete with its own encoding, that the output stream encoding parameter should be separate from the stream_encoding parameter required for FieldStorage.

A separate, new function or class for doing that seems appropriate, possibly included in cgi.py, but not in FieldStorage.  Message 125100 in this issue describes a class IOMix that I wrote and use for such; codifying it by including it in cgi.py would be fine by me... I've been using it quite successfully for some months now.

The last line of Message 125100 may be true, perhaps a few more methods should be added.  However, print is not one of them.  I think you'll be pleasantly surprised to discover (as I was, after writing that line) that the builtins.print converts its parameters to str, and writes to stdout, assuming that stdout will do the appropriate encoding.  The class IOMix will, in fact, do that appropriate encoding (given an appropriate parameter to its initialization.  Perhaps for CGI, a convenience function could be added to IOMix to include the last two code lines after IOMix in the prior message:

        @staticmethod
        def setup( encoding="UTF-8"):
            sys.stdout = IOMix( sys.stdout, encoding )
            sys.stderr = IOMix( sys.stderr, encoding )

Note that IOMix allows the users choice of output stream encoding, applies it to both stdout and stderr, which both need it, and also allows the user to generate binary directly (if sending back a file, for example), as both bytes and str are accepted.

print can be used with a file= parameter in 3.x which your implementation doesn't permit, and which could be used to write to other files by a CGI script, so I really, really don't think we want to override builtins.print without the file= parameter, and specifically tying it to stdout.

My message 126075 still needs to be included in your next patch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4953>
_______________________________________

From report at bugs.python.org  Thu Jan 13 01:13:45 2011
From: report at bugs.python.org (R. David Murray)
Date: Thu, 13 Jan 2011 00:13:45 +0000
Subject: [issue9124] Mailbox module should use binary I/O, not text I/O
In-Reply-To: <1277900903.38.0.556015912714.issue9124@psf.upfronthosting.co.za>
Message-ID: <1294877625.23.0.159415781765.issue9124@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I've been intending to take a look at this issue at some point, but am not sure when I'd get to it.

I took a quick look. It does seems to me that it is true that for data-validity purposes the message files need to be opened in binary and fed to the email package in binary.  But this is so that the message will get decoded using the correct character sets, not to avoid the decoding.  In Python3 it makes no sense to manipulate the subjects as binary strings, so the example of "looping through the messages and printing the subjects" is still going to require decoding.

There may still be ways to make it more efficient for common use cases, but that will require more detailed analysis.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9124>
_______________________________________

From report at bugs.python.org  Thu Jan 13 01:46:31 2011
From: report at bugs.python.org (SilentGhost)
Date: Thu, 13 Jan 2011 00:46:31 +0000
Subject: [issue2650] re.escape should not escape underscore
In-Reply-To: <1208441650.53.0.945063086485.issue2650@psf.upfronthosting.co.za>
Message-ID: <1294879591.43.0.931432369395.issue2650@psf.upfronthosting.co.za>


Changes by SilentGhost <ghost.adh at gmail.com>:


----------
nosy: +SilentGhost

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2650>
_______________________________________

From report at bugs.python.org  Thu Jan 13 02:31:32 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 13 Jan 2011 01:31:32 +0000
Subject: [issue766910] fix one or two bugs in trace.py
In-Reply-To: <AANLkTinScCOxqRPTGG5_eR3NqkQh-=i=Q_4YsPcCOR89@mail.gmail.com>
Message-ID: <AANLkTikQicoqE3UzjCSgxcGb-BXLbXqyGT1XYmv9W53m@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Wed, Jan 12, 2011 at 12:17 PM, Alexander Belopolsky
<report at bugs.python.org> wrote:
..
> The counts should grow in repeated runs.

I did not pay attention: the numbers in summary are numbers of lines,
not execution counts.  The execution counts in .cover file grow as
expected.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue766910>
_______________________________________

From report at bugs.python.org  Thu Jan 13 02:38:46 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 13 Jan 2011 01:38:46 +0000
Subject: [issue766910] fix one or two bugs in trace.py
In-Reply-To: <1291451642.88.0.784916842776.issue766910@psf.upfronthosting.co.za>
Message-ID: <AANLkTina6b5X63y2WQZoa+2u0ta=OW33UVYyeuFpHmBB@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Sat, Dec 4, 2010 at 3:34 AM, Eli Bendersky <report at bugs.python.org> wrote:
..
> I reviewed the patch and ported the changes to the newest sources

Eli,

I don't think you ever posted an updated patch.  Do you still have it?

This may be a good starting issue for you as a committer.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue766910>
_______________________________________

From report at bugs.python.org  Thu Jan 13 03:04:42 2011
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 13 Jan 2011 02:04:42 +0000
Subject: [issue10899] No function type annotations in the standard library
In-Reply-To: <1294869005.61.0.164570460851.issue10899@psf.upfronthosting.co.za>
Message-ID: <1294884282.09.0.317573649137.issue10899@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

You missed importlib/abc.py which uses the annotations to document the types of method arguments (and their return values), e.g., what Guido said he might use the annotations for.

----------
nosy: +brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10899>
_______________________________________

From report at bugs.python.org  Thu Jan 13 03:35:54 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 13 Jan 2011 02:35:54 +0000
Subject: [issue10899] No function type annotations in the standard library
In-Reply-To: <1294869005.61.0.164570460851.issue10899@psf.upfronthosting.co.za>
Message-ID: <1294886154.45.0.606388839545.issue10899@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Thanks.  Fixed in r89870.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10899>
_______________________________________

From report at bugs.python.org  Thu Jan 13 03:36:30 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 13 Jan 2011 02:36:30 +0000
Subject: [issue10899] No function type annotations in the standard library
In-Reply-To: <1294869005.61.0.164570460851.issue10899@psf.upfronthosting.co.za>
Message-ID: <1294886190.74.0.203857545496.issue10899@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <rhettinger at users.sourceforge.net>:


----------
Removed message: http://bugs.python.org/msg126157

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10899>
_______________________________________

From report at bugs.python.org  Thu Jan 13 03:36:49 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 13 Jan 2011 02:36:49 +0000
Subject: [issue10899] No function type annotations in the standard library
In-Reply-To: <1294869005.61.0.164570460851.issue10899@psf.upfronthosting.co.za>
Message-ID: <1294886209.04.0.939816137492.issue10899@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Thanks.  Fixed in r87890.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10899>
_______________________________________

From report at bugs.python.org  Thu Jan 13 03:37:07 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 13 Jan 2011 02:37:07 +0000
Subject: [issue10899] No function type annotations in the standard library
In-Reply-To: <1294869005.61.0.164570460851.issue10899@psf.upfronthosting.co.za>
Message-ID: <1294886227.95.0.871994903594.issue10899@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <rhettinger at users.sourceforge.net>:


----------
Removed message: http://bugs.python.org/msg126158

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10899>
_______________________________________

From report at bugs.python.org  Thu Jan 13 03:37:34 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 13 Jan 2011 02:37:34 +0000
Subject: [issue10899] No function type annotations in the standard library
In-Reply-To: <1294869005.61.0.164570460851.issue10899@psf.upfronthosting.co.za>
Message-ID: <1294886254.88.0.81152004312.issue10899@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Thanks.  Fixed in 87980.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10899>
_______________________________________

From report at bugs.python.org  Thu Jan 13 09:39:48 2011
From: report at bugs.python.org (Pierre Quentel)
Date: Thu, 13 Jan 2011 08:39:48 +0000
Subject: [issue4953] cgi module cannot handle POST with multipart/form-data
	in	3.0
In-Reply-To: <1232010166.79.0.972664060868.issue4953@psf.upfronthosting.co.za>
Message-ID: <1294907988.33.0.499176830343.issue4953@psf.upfronthosting.co.za>


Pierre Quentel <pierre.quentel at gmail.com> added the comment:

I knew the builtins hack was terrible, thanks for the replies...

I changed cgi.py with Glenn's IOMix class, and included the changes in make_file(). The patch is attached to this message

Is it really too late to include it in 3.2 ? Missing a working cgi module is really a problem for a wider 3.x adoption

----------
Added file: http://bugs.python.org/file20383/cgi_20110113.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4953>
_______________________________________

From report at bugs.python.org  Thu Jan 13 09:40:18 2011
From: report at bugs.python.org (Pierre Quentel)
Date: Thu, 13 Jan 2011 08:40:18 +0000
Subject: [issue4953] cgi module cannot handle POST with multipart/form-data
	in	3.0
In-Reply-To: <1232010166.79.0.972664060868.issue4953@psf.upfronthosting.co.za>
Message-ID: <1294908018.8.0.189485986797.issue4953@psf.upfronthosting.co.za>


Pierre Quentel <pierre.quentel at gmail.com> added the comment:

diff for the updated version of test_cgi.py, compatible with cgi.py

----------
Added file: http://bugs.python.org/file20384/test_cgi_20111013.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4953>
_______________________________________

From report at bugs.python.org  Thu Jan 13 09:41:21 2011
From: report at bugs.python.org (Pierre Quentel)
Date: Thu, 13 Jan 2011 08:41:21 +0000
Subject: [issue4953] cgi module cannot handle POST with multipart/form-data
	in	3.0
In-Reply-To: <1232010166.79.0.972664060868.issue4953@psf.upfronthosting.co.za>
Message-ID: <1294908081.76.0.201586661131.issue4953@psf.upfronthosting.co.za>


Pierre Quentel <pierre.quentel at gmail.com> added the comment:

zip file with the updated cgi_test.py and associated files

----------
Added file: http://bugs.python.org/file20385/cgi_tests.zip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4953>
_______________________________________

From report at bugs.python.org  Thu Jan 13 10:28:15 2011
From: report at bugs.python.org (Ross Lagerwall)
Date: Thu, 13 Jan 2011 09:28:15 +0000
Subject: [issue7322] Socket timeout can cause file-like readline() method to
	lose data
In-Reply-To: <1258218993.08.0.764402701678.issue7322@psf.upfronthosting.co.za>
Message-ID: <1294910895.44.0.332284024794.issue7322@psf.upfronthosting.co.za>


Ross Lagerwall <rosslagerwall at gmail.com> added the comment:

How about this?

Instead of just losing the data that's been read so far in readline(), this patch adds the data as a new field to the exception that is thrown - this way the semantics remain exactly the same but the data is not discarded when a timeout occurs, it is still accessible via the exception.

----------
Added file: http://bugs.python.org/file20386/issue7322_new.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7322>
_______________________________________

From report at bugs.python.org  Thu Jan 13 10:43:07 2011
From: report at bugs.python.org (Glenn Linderman)
Date: Thu, 13 Jan 2011 09:43:07 +0000
Subject: [issue4953] cgi module cannot handle POST with multipart/form-data
	in	3.0
In-Reply-To: <1232010166.79.0.972664060868.issue4953@psf.upfronthosting.co.za>
Message-ID: <1294911787.42.0.686216574287.issue4953@psf.upfronthosting.co.za>


Glenn Linderman <v+python at g.nevcal.com> added the comment:

Pierre,
Looking better.
I see you've retained the charset parameter, but do not pass it through to nested calls of FieldStorage.  This is good, because it wouldn't work if you did.  However, purists might still complain that FieldStorage should only ever use and affect stdin... however, since I'm a pragmatist, I'll note that the default charset value is None, which means it does nothing to stdout or stderr by default, and be content with that.

I've run a couple basic tests and it works, and the other things the code hasn't changed since your last iteration, but I'll test them again after I get some sleep.

I'll try setting the Version here back to 3.2 -- it is a bug in 3.2 -- and see if some committer will take pity on web developers that use CGI, and are hoping to be able to use Python 3.2 someday.

----------
versions: +Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4953>
_______________________________________

From report at bugs.python.org  Thu Jan 13 10:47:20 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 13 Jan 2011 09:47:20 +0000
Subject: [issue4953] cgi module cannot handle POST with multipart/form-data in
	3.x
In-Reply-To: <1294911787.42.0.686216574287.issue4953@psf.upfronthosting.co.za>
Message-ID: <4D2ECA1F.7030508@netwok.org>


?ric Araujo <merwok at netwok.org> added the comment:

Small tip: To ease review, I recommend you work from a checkout of the
Subversion py3k branch, using svn add if you have new files and then
producing one svn diff of the whole checkout.  It?s easier than looking
at multiple files, even more so if they?re hidden in a zip.  We
programmers like text :)

You can also remove outdated patches from this page to make it clearer.

----------
title: cgi module cannot handle POST with multipart/form-data in	3.0 -> cgi module cannot handle POST with multipart/form-data in 3.x

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4953>
_______________________________________

From report at bugs.python.org  Thu Jan 13 12:53:38 2011
From: report at bugs.python.org (Charles-Francois Natali)
Date: Thu, 13 Jan 2011 11:53:38 +0000
Subject: [issue10577] (Fancy) URL opener stuck when trying to open redirected
	url
In-Reply-To: <1291039199.23.0.655972335921.issue10577@psf.upfronthosting.co.za>
Message-ID: <1294919618.62.0.210230096621.issue10577@psf.upfronthosting.co.za>


Charles-Francois Natali <neologix at free.fr> added the comment:

It's a dupe of http://bugs.python.org/issue8035.

By the way, it works with 2.7 because urllib used HTTP 1.0 by default, and in py3k it now uses HTTP 1.1.
And from what I understood (by I'm by no means an http expert), in http 1.0 the server was required to close the connection following a 302, and this requirement was lifted in http 1.1.

----------
nosy: +neologix

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10577>
_______________________________________

From report at bugs.python.org  Thu Jan 13 14:18:43 2011
From: report at bugs.python.org (Pierre Quentel)
Date: Thu, 13 Jan 2011 13:18:43 +0000
Subject: [issue4953] cgi module cannot handle POST with multipart/form-data in
	3.x
In-Reply-To: <1232010166.79.0.972664060868.issue4953@psf.upfronthosting.co.za>
Message-ID: <1294924723.54.0.618403744129.issue4953@psf.upfronthosting.co.za>


Changes by Pierre Quentel <pierre.quentel at gmail.com>:


Removed file: http://bugs.python.org/file20229/cgi_diff.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4953>
_______________________________________

From report at bugs.python.org  Thu Jan 13 14:18:50 2011
From: report at bugs.python.org (Pierre Quentel)
Date: Thu, 13 Jan 2011 13:18:50 +0000
Subject: [issue4953] cgi module cannot handle POST with multipart/form-data in
	3.x
In-Reply-To: <1232010166.79.0.972664060868.issue4953@psf.upfronthosting.co.za>
Message-ID: <1294924730.51.0.761219797757.issue4953@psf.upfronthosting.co.za>


Changes by Pierre Quentel <pierre.quentel at gmail.com>:


Removed file: http://bugs.python.org/file20235/cgi_diff.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4953>
_______________________________________

From report at bugs.python.org  Thu Jan 13 14:18:58 2011
From: report at bugs.python.org (Pierre Quentel)
Date: Thu, 13 Jan 2011 13:18:58 +0000
Subject: [issue4953] cgi module cannot handle POST with multipart/form-data in
	3.x
In-Reply-To: <1232010166.79.0.972664060868.issue4953@psf.upfronthosting.co.za>
Message-ID: <1294924738.31.0.875416604134.issue4953@psf.upfronthosting.co.za>


Changes by Pierre Quentel <pierre.quentel at gmail.com>:


Removed file: http://bugs.python.org/file20322/cgi_diff_20110109.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4953>
_______________________________________

From report at bugs.python.org  Thu Jan 13 14:19:12 2011
From: report at bugs.python.org (Pierre Quentel)
Date: Thu, 13 Jan 2011 13:19:12 +0000
Subject: [issue4953] cgi module cannot handle POST with multipart/form-data in
	3.x
In-Reply-To: <1232010166.79.0.972664060868.issue4953@psf.upfronthosting.co.za>
Message-ID: <1294924752.79.0.178802010826.issue4953@psf.upfronthosting.co.za>


Changes by Pierre Quentel <pierre.quentel at gmail.com>:


Removed file: http://bugs.python.org/file20323/cgi_tests.zip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4953>
_______________________________________

From report at bugs.python.org  Thu Jan 13 14:19:19 2011
From: report at bugs.python.org (Pierre Quentel)
Date: Thu, 13 Jan 2011 13:19:19 +0000
Subject: [issue4953] cgi module cannot handle POST with multipart/form-data in
	3.x
In-Reply-To: <1232010166.79.0.972664060868.issue4953@psf.upfronthosting.co.za>
Message-ID: <1294924759.61.0.00224562964609.issue4953@psf.upfronthosting.co.za>


Changes by Pierre Quentel <pierre.quentel at gmail.com>:


Removed file: http://bugs.python.org/file20356/cgi_diff_20110111.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4953>
_______________________________________

From report at bugs.python.org  Thu Jan 13 14:19:26 2011
From: report at bugs.python.org (Pierre Quentel)
Date: Thu, 13 Jan 2011 13:19:26 +0000
Subject: [issue4953] cgi module cannot handle POST with multipart/form-data in
	3.x
In-Reply-To: <1232010166.79.0.972664060868.issue4953@psf.upfronthosting.co.za>
Message-ID: <1294924766.29.0.586498644351.issue4953@psf.upfronthosting.co.za>


Changes by Pierre Quentel <pierre.quentel at gmail.com>:


Removed file: http://bugs.python.org/file20382/cgi_diff_20110112.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4953>
_______________________________________

From report at bugs.python.org  Thu Jan 13 14:19:31 2011
From: report at bugs.python.org (Pierre Quentel)
Date: Thu, 13 Jan 2011 13:19:31 +0000
Subject: [issue4953] cgi module cannot handle POST with multipart/form-data in
	3.x
In-Reply-To: <1232010166.79.0.972664060868.issue4953@psf.upfronthosting.co.za>
Message-ID: <1294924771.69.0.125850223575.issue4953@psf.upfronthosting.co.za>


Changes by Pierre Quentel <pierre.quentel at gmail.com>:


Removed file: http://bugs.python.org/file20383/cgi_20110113.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4953>
_______________________________________

From report at bugs.python.org  Thu Jan 13 14:19:39 2011
From: report at bugs.python.org (Pierre Quentel)
Date: Thu, 13 Jan 2011 13:19:39 +0000
Subject: [issue4953] cgi module cannot handle POST with multipart/form-data in
	3.x
In-Reply-To: <1232010166.79.0.972664060868.issue4953@psf.upfronthosting.co.za>
Message-ID: <1294924779.6.0.130599556739.issue4953@psf.upfronthosting.co.za>


Changes by Pierre Quentel <pierre.quentel at gmail.com>:


Removed file: http://bugs.python.org/file20384/test_cgi_20111013.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4953>
_______________________________________

From report at bugs.python.org  Thu Jan 13 14:19:46 2011
From: report at bugs.python.org (Pierre Quentel)
Date: Thu, 13 Jan 2011 13:19:46 +0000
Subject: [issue4953] cgi module cannot handle POST with multipart/form-data in
	3.x
In-Reply-To: <1232010166.79.0.972664060868.issue4953@psf.upfronthosting.co.za>
Message-ID: <1294924786.74.0.471871902088.issue4953@psf.upfronthosting.co.za>


Changes by Pierre Quentel <pierre.quentel at gmail.com>:


Removed file: http://bugs.python.org/file20244/cgi_diff.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4953>
_______________________________________

From report at bugs.python.org  Thu Jan 13 14:23:23 2011
From: report at bugs.python.org (Pierre Quentel)
Date: Thu, 13 Jan 2011 13:23:23 +0000
Subject: [issue4953] cgi module cannot handle POST with multipart/form-data in
	3.x
In-Reply-To: <1232010166.79.0.972664060868.issue4953@psf.upfronthosting.co.za>
Message-ID: <1294925003.9.0.727505875365.issue4953@psf.upfronthosting.co.za>


Pierre Quentel <pierre.quentel at gmail.com> added the comment:

Ok Eric, thanks for the tips

I attach the diff for the 2 modified modules (cgi.py and test_cgi.py). For the other tests, they are not in the branch and there are many test files so I leave the zip file

I removed outdated diffs

----------
Added file: http://bugs.python.org/file20387/cgi_32.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4953>
_______________________________________

From report at bugs.python.org  Thu Jan 13 14:49:34 2011
From: report at bugs.python.org (SilentGhost)
Date: Thu, 13 Jan 2011 13:49:34 +0000
Subject: [issue2650] re.escape should not escape underscore
In-Reply-To: <1208441650.53.0.945063086485.issue2650@psf.upfronthosting.co.za>
Message-ID: <1294926574.43.0.0279360226639.issue2650@psf.upfronthosting.co.za>


SilentGhost <ghost.adh at gmail.com> added the comment:

Here is the patch, including adjustment to the test.

----------
Added file: http://bugs.python.org/file20388/issue2650.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2650>
_______________________________________

From report at bugs.python.org  Thu Jan 13 14:54:47 2011
From: report at bugs.python.org (Scott Dial)
Date: Thu, 13 Jan 2011 13:54:47 +0000
Subject: [issue10899] No function type annotations in the standard library
In-Reply-To: <1294869005.61.0.164570460851.issue10899@psf.upfronthosting.co.za>
Message-ID: <1294926887.74.0.670733449698.issue10899@psf.upfronthosting.co.za>


Scott Dial <scott at scottdial.com> added the comment:

Raymond Hettinger wrote:
> I think those annotations should be replaced with comments.

In your revisions, you didn't do anything but blow away the annotations despite what you said here, which is an unfortunate loss of information for implementers and users of those interfaces.

----------
nosy: +scott.dial

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10899>
_______________________________________

From report at bugs.python.org  Thu Jan 13 15:10:32 2011
From: report at bugs.python.org (David Beazley)
Date: Thu, 13 Jan 2011 14:10:32 +0000
Subject: [issue7322] Socket timeout can cause file-like readline() method to
	lose data
In-Reply-To: <1258218993.08.0.764402701678.issue7322@psf.upfronthosting.co.za>
Message-ID: <1294927832.04.0.431521575126.issue7322@psf.upfronthosting.co.za>


David Beazley <dave at dabeaz.com> added the comment:

Have any other programming environments ever had a feature where a socket timeout returns an exception containing partial data?    I'm not aware of one offhand and speaking as a systems programmer, something like this might be somewhat unexpected.

My concern is that in the presence of timeouts, the programmer will be forced to reassemble the message themselves from fragments returned in the exception.  However, one reason for using readline() in the first place is precisely so that you don't have to do that sort of thing.

Is there any reason why the input buffer can't be preserved across calls?   You've already got a file-like wrapper around the socket.  Just keep the unconsumed buffer in that instance.

----------
nosy: +dabeaz

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7322>
_______________________________________

From report at bugs.python.org  Thu Jan 13 15:24:14 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 13 Jan 2011 14:24:14 +0000
Subject: [issue7322] Socket timeout can cause file-like readline() method to
	lose data
In-Reply-To: <1258218993.08.0.764402701678.issue7322@psf.upfronthosting.co.za>
Message-ID: <1294928654.88.0.951092856764.issue7322@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

This is an interesting approach. The problem is that AFAICT the issue is not limited to readline. If you call e.g. read(10000) and the socket times out after having returned the first 5000 bytes, then those 5000 bytes might get lost as well (depending on specifics e.g. buffer size in the IO stack).

Generally there is no guarantee that a buffered object works "properly" when the raw IO object raises some exception intermittently; perhaps this should be fixed in a systemic way, although this would complicate things quite a bit.

Also, I don't think people try to reuse a socket after a timeout (or even try to salvage whatever data could be read before the timeout); usually they would instead abort the connection and treat the remote resource as unavailable. IMO, that's the one obvious use case for socket timeouts.

----------
nosy: +amaury.forgeotdarc
stage: needs patch -> patch review
versions: +Python 3.3 -Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7322>
_______________________________________

From report at bugs.python.org  Thu Jan 13 15:28:01 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 13 Jan 2011 14:28:01 +0000
Subject: [issue7322] Socket timeout can cause file-like readline() method to
	lose data
In-Reply-To: <1258218993.08.0.764402701678.issue7322@psf.upfronthosting.co.za>
Message-ID: <1294928881.83.0.503027903196.issue7322@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

By the way, I recently fixed the makefile() documentation:

?The socket must be in blocking mode; it can have a timeout, but the file object?s internal buffer may end up in a inconsistent state if a timeout occurs.?
(in http://docs.python.org/dev/library/socket.html#socket.socket.makefile)

I also added a small section dedicated to socket timeouts:
http://docs.python.org/dev/library/socket.html#notes-on-socket-timeouts

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7322>
_______________________________________

From report at bugs.python.org  Thu Jan 13 15:31:49 2011
From: report at bugs.python.org (R. David Murray)
Date: Thu, 13 Jan 2011 14:31:49 +0000
Subject: [issue4953] cgi module cannot handle POST with multipart/form-data in
	3.x
In-Reply-To: <1232010166.79.0.972664060868.issue4953@psf.upfronthosting.co.za>
Message-ID: <1294929109.94.0.832089464717.issue4953@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

It getting in to 3.2 would be a release manager call, so I've set it to release blocker so Georg can make the call.  My opinion is that while I would *really* like to see this fixed in 3.2, the changes really should have a thorough *design* review as well as a code review.  

The argument for putting it in would be that it is broken as is (at least for binary file upload, possibly in other ways as well), and if we can get agreement on the API changes, we can fix any remaining bugs in 3.2.1.  However, making API changes at this point (post-beta) requires a significant exception to our normal development rules, and I don't like doing things this rushed and last minute.  But I also don't like the thought of having FieldStorage be broken in 3.2.

Georg, I'm really busy this week, and don't have time to do a review, unfortunately.  If you think it worth considering putting it in, I can try to take a look at the API changes tomorrow, but unfortunately can make no promise to do so.  Hopefully others can, if needed.

----------
nosy: +georg.brandl
priority: high -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4953>
_______________________________________

From report at bugs.python.org  Thu Jan 13 15:44:23 2011
From: report at bugs.python.org (Ralf Schmitt)
Date: Thu, 13 Jan 2011 14:44:23 +0000
Subject: [issue10897] UNIX mmap unnecessarily dup() file descriptor
In-Reply-To: <1294845379.76.0.427887707002.issue10897@psf.upfronthosting.co.za>
Message-ID: <1294929863.21.0.906448308788.issue10897@psf.upfronthosting.co.za>


Changes by Ralf Schmitt <schmir at gmail.com>:


----------
nosy: +schmir

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10897>
_______________________________________

From report at bugs.python.org  Thu Jan 13 16:32:42 2011
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Thu, 13 Jan 2011 15:32:42 +0000
Subject: =?utf-8?q?=5Bissue10013=5D_fix_=60=2E/libpython2=2E6=2Eso=3A_undefined_re?=
	=?utf-8?q?ference_to_=60=5FPyParser=5FGrammar=C2=B4=60_in_parallel_builds?=
In-Reply-To: <1286018023.44.0.511102577172.issue10013@psf.upfronthosting.co.za>
Message-ID: <1294932762.55.0.198171224843.issue10013@psf.upfronthosting.co.za>


Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com> added the comment:

This change was backported to 2.7 (r87701) and 3.1 (r87702).

----------
nosy: +Arfrever

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10013>
_______________________________________

From report at bugs.python.org  Thu Jan 13 16:38:20 2011
From: report at bugs.python.org (SilentGhost)
Date: Thu, 13 Jan 2011 15:38:20 +0000
Subject: =?utf-8?q?=5Bissue10013=5D_fix_=60=2E/libpython2=2E6=2Eso=3A_undefined_re?=
	=?utf-8?q?ference_to_=60=5FPyParser=5FGrammar=C2=B4=60_in_parallel_builds?=
In-Reply-To: <1286018023.44.0.511102577172.issue10013@psf.upfronthosting.co.za>
Message-ID: <1294933100.5.0.393304791807.issue10013@psf.upfronthosting.co.za>


Changes by SilentGhost <ghost.adh at gmail.com>:


----------
resolution:  -> accepted
status: open -> closed
versions: +Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10013>
_______________________________________

From report at bugs.python.org  Thu Jan 13 16:38:35 2011
From: report at bugs.python.org (Pierre Quentel)
Date: Thu, 13 Jan 2011 15:38:35 +0000
Subject: [issue4953] cgi module cannot handle POST with multipart/form-data in
	3.x
In-Reply-To: <1232010166.79.0.972664060868.issue4953@psf.upfronthosting.co.za>
Message-ID: <1294933115.28.0.459255192572.issue4953@psf.upfronthosting.co.za>


Pierre Quentel <pierre.quentel at gmail.com> added the comment:

Ok, thanks. Here is a summary of the API changes :

- the argument fp passed to FieldStorage is either an instance of (a subclass of) io.TextIOBase with a "buffer" attribute for the underlying binary layer (thus, it can't be a StringIO instance) ; or an object with read() and readline() methods that return bytes
Defaults to sys.stdin

- 2 additional arguments can be passed to the FieldStorage constructor :
. stream_encoding : the encoding used by the user agent to encode submitted data. It must be the same as the content-type of the HTML page where the form stands. Defaults to utf-8
. charset : the encoding used by the CGI script (the one used by the print() function to encode and send to sys.stdout). It must be the same as the charset in the content-type header sent by this script. Defaults to None, in which case the default encoding of sys.stdout is used

- the only change in the object returned by FieldStorage() is that, if a field represents a file (its argument filename is not None), the read() method on this field returns bytes, and its attribute "value" is a bytestring, not a string

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4953>
_______________________________________

From report at bugs.python.org  Thu Jan 13 16:44:42 2011
From: report at bugs.python.org (SilentGhost)
Date: Thu, 13 Jan 2011 15:44:42 +0000
Subject: [issue2650] re.escape should not escape underscore
In-Reply-To: <1208441650.53.0.945063086485.issue2650@psf.upfronthosting.co.za>
Message-ID: <1294933482.12.0.0715201202762.issue2650@psf.upfronthosting.co.za>


Changes by SilentGhost <ghost.adh at gmail.com>:


Removed file: http://bugs.python.org/file20388/issue2650.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2650>
_______________________________________

From report at bugs.python.org  Thu Jan 13 16:48:23 2011
From: report at bugs.python.org (SilentGhost)
Date: Thu, 13 Jan 2011 15:48:23 +0000
Subject: [issue2650] re.escape should not escape underscore
In-Reply-To: <1208441650.53.0.945063086485.issue2650@psf.upfronthosting.co.za>
Message-ID: <1294933703.13.0.39806898853.issue2650@psf.upfronthosting.co.za>


SilentGhost <ghost.adh at gmail.com> added the comment:

The na?ve version of the code proposed was about 3 times slower than existing version. However, the test, I think, is valuable enough. So, I'm reinstating it.

----------
Added file: http://bugs.python.org/file20389/test_re.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2650>
_______________________________________

From report at bugs.python.org  Thu Jan 13 17:02:30 2011
From: report at bugs.python.org (SilentGhost)
Date: Thu, 13 Jan 2011 16:02:30 +0000
Subject: =?utf-8?q?=5Bissue10013=5D_fix_=60=2E/libpython2=2E6=2Eso=3A_undefined_re?=
	=?utf-8?q?ference_to_=60=5FPyParser=5FGrammar=C2=B4=60_in_parallel_builds?=
In-Reply-To: <1286018023.44.0.511102577172.issue10013@psf.upfronthosting.co.za>
Message-ID: <1294934550.75.0.54247615344.issue10013@psf.upfronthosting.co.za>


Changes by SilentGhost <ghost.adh at gmail.com>:


----------
resolution: accepted -> fixed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10013>
_______________________________________

From report at bugs.python.org  Thu Jan 13 17:09:06 2011
From: report at bugs.python.org (James Y Knight)
Date: Thu, 13 Jan 2011 16:09:06 +0000
Subject: [issue2650] re.escape should not escape underscore
In-Reply-To: <1208441650.53.0.945063086485.issue2650@psf.upfronthosting.co.za>
Message-ID: <1294934946.76.0.177612632325.issue2650@psf.upfronthosting.co.za>


James Y Knight <foom at users.sourceforge.net> added the comment:

Show your speed test? Looks 2.5x faster to me. But I'm running this on python 2.6, so I guess it's possible that the re module's speed was decimated in Py3k.


python -m timeit -s "$(printf "import re\ndef escape(s):\n return re.sub('([][.^$*+?{}\\|()])', '\\\1', s)")" 'escape("!@#$%^&*()!@#$%^&*()!@#$%^&*()!@#$%^&*()!@#$%^&*()!@#$%^&*()!@#$%^&*()!@#$%^&*()")'
100000 loops, best of 3: 18.4 usec per loop


python -m timeit -s "import re" 're.escape("!@#$%^&*()!@#$%^&*()!@#$%^&*()!@#$%^&*()!@#$%^&*()!@#$%^&*()!@#$%^&*()!@#$%^&*()")'
10000 loops, best of 3: 45.7 usec per loop

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2650>
_______________________________________

From report at bugs.python.org  Thu Jan 13 17:36:09 2011
From: report at bugs.python.org (Guido van Rossum)
Date: Thu, 13 Jan 2011 16:36:09 +0000
Subject: [issue10899] No function type annotations in the standard library
In-Reply-To: <1294926887.74.0.670733449698.issue10899@psf.upfronthosting.co.za>
Message-ID: <AANLkTinwMqeRBknvxLhp9f9XUbvQnLon-MwJ75hv0PAw@mail.gmail.com>


Guido van Rossum <guido at python.org> added the comment:

Yes, please add the lost info back to docstrings.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10899>
_______________________________________

From report at bugs.python.org  Thu Jan 13 17:42:42 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 13 Jan 2011 16:42:42 +0000
Subject: [issue10577] (Fancy) URL opener stuck when trying to open redirected
	url
In-Reply-To: <1291039199.23.0.655972335921.issue10577@psf.upfronthosting.co.za>
Message-ID: <1294936962.88.0.697131045784.issue10577@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Ok, closing as duplicate.

----------
resolution:  -> duplicate
status: open -> closed
superseder:  -> urllib.request.urlretrieve hangs

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10577>
_______________________________________

From report at bugs.python.org  Thu Jan 13 17:45:29 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 13 Jan 2011 16:45:29 +0000
Subject: [issue8035] urllib.request.urlretrieve hangs waiting for connection
	close after a redirect
In-Reply-To: <1267470113.93.0.44679631442.issue8035@psf.upfronthosting.co.za>
Message-ID: <1294937129.38.0.765218648011.issue8035@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

issue10577 is a duplicate. See an URL allowing reproducing in msg122831.

----------
nosy: +pitrou
priority: high -> normal
stage: unit test needed -> needs patch
title: urllib.request.urlretrieve hangs -> urllib.request.urlretrieve hangs waiting for connection close after a redirect

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8035>
_______________________________________

From report at bugs.python.org  Thu Jan 13 17:48:48 2011
From: report at bugs.python.org (SilentGhost)
Date: Thu, 13 Jan 2011 16:48:48 +0000
Subject: [issue2650] re.escape should not escape underscore
In-Reply-To: <1208441650.53.0.945063086485.issue2650@psf.upfronthosting.co.za>
Message-ID: <1294937328.42.0.0833275900517.issue2650@psf.upfronthosting.co.za>


SilentGhost <ghost.adh at gmail.com> added the comment:

James, I think the setup statement should have been:

"import re\ndef escape(s):\n return re.sub(r'([][.^$*+?{}\\|()])', r'\\\1', s)")"

note the raw string literals.

The timings that I got after applying file20388 (http://bugs.python.org/file20388/issue2650.diff) were:
>PCbuild\python.exe -m timeit -s "import re, string" "re.escape(string.printable)"
10000 loops, best of 3: 63.3 usec per loop

>python.exe -m timeit -s "import re, string" "re.escape(string.printable)"
100000 loops, best of 3: 19.3 usec per loop

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2650>
_______________________________________

From report at bugs.python.org  Thu Jan 13 17:59:03 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 13 Jan 2011 16:59:03 +0000
Subject: [issue2710] error: (10035,
	'The socket operation could not complete without blocking')
In-Reply-To: <1209411891.51.0.595506842897.issue2710@psf.upfronthosting.co.za>
Message-ID: <1294937943.78.0.231085808413.issue2710@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

This can be reopened if the problem ever appears in a current issue.

----------
resolution:  -> out of date
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2710>
_______________________________________

From report at bugs.python.org  Thu Jan 13 18:09:00 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 13 Jan 2011 17:09:00 +0000
Subject: [issue10899] No function type annotations in the standard library
In-Reply-To: <1294869005.61.0.164570460851.issue10899@psf.upfronthosting.co.za>
Message-ID: <1294938540.0.0.869321377358.issue10899@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Will do :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10899>
_______________________________________

From report at bugs.python.org  Thu Jan 13 18:12:05 2011
From: report at bugs.python.org (James Y Knight)
Date: Thu, 13 Jan 2011 17:12:05 +0000
Subject: [issue2650] re.escape should not escape underscore
In-Reply-To: <1208441650.53.0.945063086485.issue2650@psf.upfronthosting.co.za>
Message-ID: <1294938725.27.0.899566937513.issue2650@psf.upfronthosting.co.za>


James Y Knight <foom at users.sourceforge.net> added the comment:

Right you are, it seems that python's regexp implementation is terribly slow when doing replacements with a substitution in them. (fixing the broken test, as you pointed out changed the timing to 97.6 usec vs the in-error-reported 18.3usec.)

Oh well. I still think it's crazy not to use re for this in its own module. Someone just needs to fix re to not be horrifically slow, too. :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2650>
_______________________________________

From report at bugs.python.org  Thu Jan 13 18:13:41 2011
From: report at bugs.python.org (yeswanth)
Date: Thu, 13 Jan 2011 17:13:41 +0000
Subject: [issue2650] re.escape should not escape underscore
In-Reply-To: <1208441650.53.0.945063086485.issue2650@psf.upfronthosting.co.za>
Message-ID: <1294938821.87.0.458861763863.issue2650@psf.upfronthosting.co.za>


yeswanth <swamiyeswanth at yahoo.com> added the comment:

@James test results for py3k 


python -m timeit -s "$(printf "import re\ndef escape(s):\n return re.sub('([][.^$*+?{}\\|()])', '\\\1', s)")" 'escape("!@#$%^&*()!@#$%^&*()!@#$%^&*()!@#$%^&*()!@#$%^&*()!@#$%^&*()!@#$%^&*()!@#$%^&*()")'

100000 loops, best of 3: 17.1 usec per loop


python -m timeit -s "import re" 're.escape("!@#$%^&*()!@#$%^&*()!@#$%^&*()!@#$%^&*()!@#$%^&*()!@#$%^&*()!@#$%^&*()!@#$%^&*()")'

10000 loops, best of 3: 102 usec per loop

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2650>
_______________________________________

From report at bugs.python.org  Thu Jan 13 18:14:25 2011
From: report at bugs.python.org (wrobell)
Date: Thu, 13 Jan 2011 17:14:25 +0000
Subject: [issue10900] bz2 module fails to uncompress large files
In-Reply-To: <1294938865.74.0.735458664613.issue10900@psf.upfronthosting.co.za>
Message-ID: <1294938865.74.0.735458664613.issue10900@psf.upfronthosting.co.za>


New submission from wrobell <wrobell at pld-linux.org>:

There is problem to uncompress large files with bz2 module.

For example, please download 13GB OpenStreetMap file using following torrent

http://osm-torrent.torres.voyager.hr/files/planet-latest.osm.bz2.torrent

Try to count lines in the compressed file with command...

   python3.2 bz2wc.py planet-110105.osm.bz2 
   3971

... but there is much more lines in that file

   bzip2 -dc < planet-110105.osm.bz2 | wc -l
   
The command

   bzip2 -t planet-110105.osm.bz2

validates the file successfully.

----------
components: Library (Lib)
files: bz2wc.py
messages: 126186
nosy: wrobell
priority: normal
severity: normal
status: open
title: bz2 module fails to uncompress large files
versions: Python 2.7, Python 3.2
Added file: http://bugs.python.org/file20390/bz2wc.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10900>
_______________________________________

From report at bugs.python.org  Thu Jan 13 18:22:25 2011
From: report at bugs.python.org (Brandon Craig Rhodes)
Date: Thu, 13 Jan 2011 17:22:25 +0000
Subject: [issue10901] Python 3 MIME generator dies if not given boundary
In-Reply-To: <1294939345.9.0.334725926474.issue10901@psf.upfronthosting.co.za>
Message-ID: <1294939345.9.0.334725926474.issue10901@psf.upfronthosting.co.za>


New submission from Brandon Craig Rhodes <brandon at rhodesmill.org>:

If you try doing "msg.as_string()" to a MIMEMultipart message that has not been given a boundary, then it dies with this exception:

Traceback (most recent call last):
  File "mime_gen_alt.py", line 40, in <module>
    print(msg.as_string())
  File "/home/brandon/python3.2b2/lib/python3.2/email/message.py", line 164, in as_string
    g.flatten(self, unixfrom=unixfrom)
  File "/home/brandon/python3.2b2/lib/python3.2/email/generator.py", line 88, in flatten
    self._write(msg)
  File "/home/brandon/python3.2b2/lib/python3.2/email/generator.py", line 134, in _write
    self._dispatch(msg)
  File "/home/brandon/python3.2b2/lib/python3.2/email/generator.py", line 160, in _dispatch
    meth(msg)
  File "/home/brandon/python3.2b2/lib/python3.2/email/generator.py", line 234, in _handle_multipart
    self.write('--' + boundary + self._NL)
TypeError: Can't convert 'NoneType' object to str implicitly

----------
components: Library (Lib)
messages: 126187
nosy: brandon-rhodes
priority: normal
severity: normal
status: open
title: Python 3 MIME generator dies if not given boundary
type: crash
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10901>
_______________________________________

From report at bugs.python.org  Thu Jan 13 18:24:41 2011
From: report at bugs.python.org (Brandon Craig Rhodes)
Date: Thu, 13 Jan 2011 17:24:41 +0000
Subject: [issue10901] Python 3 MIME generator dies if not given boundary
In-Reply-To: <1294939345.9.0.334725926474.issue10901@psf.upfronthosting.co.za>
Message-ID: <1294939481.12.0.745605402013.issue10901@psf.upfronthosting.co.za>


Brandon Craig Rhodes <brandon at rhodesmill.org> added the comment:

Here is a patch that fixes the problem. The problem probably only occurs if the MIMEMultipart is actually given several MIME parts to use in its interior.

----------
keywords: +patch
Added file: http://bugs.python.org/file20391/email-boundary.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10901>
_______________________________________

From report at bugs.python.org  Thu Jan 13 18:29:37 2011
From: report at bugs.python.org (A.M. Kuchling)
Date: Thu, 13 Jan 2011 17:29:37 +0000
Subject: [issue2650] re.escape should not escape underscore
In-Reply-To: <1208441650.53.0.945063086485.issue2650@psf.upfronthosting.co.za>
Message-ID: <1294939777.44.0.0960373032092.issue2650@psf.upfronthosting.co.za>


Changes by A.M. Kuchling <lists at amk.ca>:


----------
nosy:  -akuchling

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2650>
_______________________________________

From report at bugs.python.org  Thu Jan 13 18:38:40 2011
From: report at bugs.python.org (SilentGhost)
Date: Thu, 13 Jan 2011 17:38:40 +0000
Subject: [issue10900] bz2 module fails to uncompress large files
In-Reply-To: <1294938865.74.0.735458664613.issue10900@psf.upfronthosting.co.za>
Message-ID: <1294940320.61.0.0464321075836.issue10900@psf.upfronthosting.co.za>


Changes by SilentGhost <ghost.adh at gmail.com>:


----------
nosy: +gustavo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10900>
_______________________________________

From report at bugs.python.org  Thu Jan 13 18:39:31 2011
From: report at bugs.python.org (SilentGhost)
Date: Thu, 13 Jan 2011 17:39:31 +0000
Subject: [issue10900] bz2 module fails to uncompress large files
In-Reply-To: <1294938865.74.0.735458664613.issue10900@psf.upfronthosting.co.za>
Message-ID: <1294940371.08.0.9900685569.issue10900@psf.upfronthosting.co.za>


Changes by SilentGhost <ghost.adh at gmail.com>:


----------
nosy: +niemeyer -gustavo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10900>
_______________________________________

From report at bugs.python.org  Thu Jan 13 18:47:08 2011
From: report at bugs.python.org (SilentGhost)
Date: Thu, 13 Jan 2011 17:47:08 +0000
Subject: [issue10901] Python 3 MIME generator dies if not given boundary
In-Reply-To: <1294939345.9.0.334725926474.issue10901@psf.upfronthosting.co.za>
Message-ID: <1294940828.22.0.880878993147.issue10901@psf.upfronthosting.co.za>


SilentGhost <ghost.adh at gmail.com> added the comment:

It is a duplicate of #1243654. Closing.

----------
nosy: +SilentGhost
resolution:  -> duplicate
status: open -> closed
superseder:  -> Faster output if message already has a boundary

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10901>
_______________________________________

From report at bugs.python.org  Thu Jan 13 18:47:31 2011
From: report at bugs.python.org (Gregory P. Smith)
Date: Thu, 13 Jan 2011 17:47:31 +0000
Subject: [issue7322] Socket timeout can cause file-like readline() method to
	lose data
In-Reply-To: <1258218993.08.0.764402701678.issue7322@psf.upfronthosting.co.za>
Message-ID: <1294940851.48.0.259636610004.issue7322@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

"""Generally there is no guarantee that a buffered object works "properly" when the raw IO object raises some exception intermittently"""

I disagree.  EINTR is a classic case of this and is something that buffering IO layers deal with all the time.  (readline is just one example of a buffering io layer)

if there is a timeout and we can't determine if there is enough data to return for readline, we should buffer it and not return.

maybe this means we need to disallow readline() with timeouts on unbuffered sockets since we can't determine if data will need to be buffered or not due to such a condition in advance.

The normal behavior for code calling readline() on a socket with a timeout is likely going to be to close it.  Anything else does not make much sense.  (someone may try, but really they're writing their I/O code wrong if they are using a socket timeout a poor form of task switching ;)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7322>
_______________________________________

From report at bugs.python.org  Thu Jan 13 18:52:01 2011
From: report at bugs.python.org (SilentGhost)
Date: Thu, 13 Jan 2011 17:52:01 +0000
Subject: [issue1243654] Faster output if message already has a boundary
Message-ID: <1294941121.52.0.998054857576.issue1243654@psf.upfronthosting.co.za>


SilentGhost <ghost.adh at gmail.com> added the comment:

Issue #10901 was closed as a duplicate of this issue.

----------
nosy: +SilentGhost
versions: +Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1243654>
_______________________________________

From report at bugs.python.org  Thu Jan 13 19:06:35 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 13 Jan 2011 18:06:35 +0000
Subject: [issue7322] Socket timeout can cause file-like readline() method to
	lose data
In-Reply-To: <1294940851.48.0.259636610004.issue7322@psf.upfronthosting.co.za>
Message-ID: <1294941987.3687.17.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> """Generally there is no guarantee that a buffered object works
> "properly" when the raw IO object raises some exception
> intermittently"""
> 
> I disagree.  EINTR is a classic case of this and is something that
> buffering IO layers deal with all the time.  (readline is just one
> example of a buffering io layer)

EINTR is a different matter. To handle EINTR in Python, it is enough to
call the signal handlers and then retry the system call (that's what is
done in SocketIO.readinto, although FileIO doesn't have such logic).
Only if the signal handler raises an exception (which it probably
shouldn't do, since asynchronous exceptions are very bad) do you abort
the operation.

You can't apply the same logic to a socket timeout; the timeout is
really an error condition and you certainly shouldn't retry the system
call (that would defeat the point of using a timeout). So, to handle it
in an entirely correct way, you need to add some out-of-band buffering
logic where you store the pending raw reads which have been done but
could not be returned to the user. That complicates things quite a bit,
especially given that it has to be grafted on at least two layers of the
IO stack (the raw IO layer, and the buffered IO layer). Ross' patch does
it, but incompletely (it lets the user handle the out-of-band data) and
only for readline() (while buffered read() would probably need it too).

> The normal behavior for code calling readline() on a socket with a
> timeout is likely going to be to close it.  Anything else does not
> make much sense.  (someone may try, but really they're writing their
> I/O code wrong if they are using a socket timeout a poor form of task
> switching ;)

That's my opinion too. So, instead, of doing the above surgery inside
the IO stack, the SocketIO layer could detect the timeout and disallow
further access. What do you think?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7322>
_______________________________________

From report at bugs.python.org  Thu Jan 13 20:06:24 2011
From: report at bugs.python.org (wrobell)
Date: Thu, 13 Jan 2011 19:06:24 +0000
Subject: [issue10900] bz2 module fails to uncompress large files
In-Reply-To: <1294938865.74.0.735458664613.issue10900@psf.upfronthosting.co.za>
Message-ID: <1294945584.43.0.824075326895.issue10900@psf.upfronthosting.co.za>


wrobell <wrobell at pld-linux.org> added the comment:

Forgot the mention the real amount of lines!

    bzip2 -dc < planet-110105.osm.bz2 | wc -l
    2783595867

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10900>
_______________________________________

From report at bugs.python.org  Thu Jan 13 20:50:50 2011
From: report at bugs.python.org (wrobell)
Date: Thu, 13 Jan 2011 19:50:50 +0000
Subject: [issue5863] bz2.BZ2File should accept other file-like objects.
In-Reply-To: <1240898269.47.0.592056792771.issue5863@psf.upfronthosting.co.za>
Message-ID: <1294948250.93.0.0287434509288.issue5863@psf.upfronthosting.co.za>


wrobell <wrobell at pld-linux.org> added the comment:

A use case

    wget -O http://planet.openstreetmap.org/planet-110112.osm.bz2 | tee planet.bz2 | osm2sql | psql osm

planet-*osm.bz2 files are 14GB at the moment. it would be great to read them from stdin while downloading from a server and uploading to a database at the same time.

Of course, you can insert "bzip2 -d" into the pipe... but then why to bother with bz2 module in Python? ;)

----------
nosy: +wrobell

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5863>
_______________________________________

From report at bugs.python.org  Thu Jan 13 20:53:28 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 13 Jan 2011 19:53:28 +0000
Subject: [issue5863] bz2.BZ2File should accept other file-like objects.
In-Reply-To: <1240898269.47.0.592056792771.issue5863@psf.upfronthosting.co.za>
Message-ID: <1294948408.18.0.730357587985.issue5863@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

We?ve already agreed the feature is desirable; what?s missing is a patch, not user stories :)

----------
nosy: +niemeyer
versions: +Python 3.3 -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5863>
_______________________________________

From report at bugs.python.org  Thu Jan 13 21:02:13 2011
From: report at bugs.python.org (wrobell)
Date: Thu, 13 Jan 2011 20:02:13 +0000
Subject: [issue5863] bz2.BZ2File should accept other file-like objects.
In-Reply-To: <1240898269.47.0.592056792771.issue5863@psf.upfronthosting.co.za>
Message-ID: <1294948933.17.0.865124386375.issue5863@psf.upfronthosting.co.za>


wrobell <wrobell at pld-linux.org> added the comment:

OK! :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5863>
_______________________________________

From report at bugs.python.org  Thu Jan 13 21:25:08 2011
From: report at bugs.python.org (Ross Lagerwall)
Date: Thu, 13 Jan 2011 20:25:08 +0000
Subject: [issue7322] Socket timeout can cause file-like readline() method to
	lose data
In-Reply-To: <1258218993.08.0.764402701678.issue7322@psf.upfronthosting.co.za>
Message-ID: <1294950308.72.0.636887108661.issue7322@psf.upfronthosting.co.za>


Ross Lagerwall <rosslagerwall at gmail.com> added the comment:

> That complicates things quite a bit,
> especially given that it has to be grafted on at least two layers of the
> IO stack (the raw IO layer, and the buffered IO layer).

Also the TextIO layer I think.

> That's my opinion too. So, instead, of doing the above surgery inside
> the IO stack, the SocketIO layer could detect the timeout and disallow
> further access. What do you think?

So after a timeout occurs the file-object basically becomes worthless? Would it make sense to automatically call the close method of the file-object after this occurs?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7322>
_______________________________________

From report at bugs.python.org  Thu Jan 13 21:35:10 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 13 Jan 2011 20:35:10 +0000
Subject: [issue7322] Socket timeout can cause file-like readline() method to
	lose data
In-Reply-To: <1294950308.72.0.636887108661.issue7322@psf.upfronthosting.co.za>
Message-ID: <1294950896.3687.20.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> > That's my opinion too. So, instead, of doing the above surgery inside
> > the IO stack, the SocketIO layer could detect the timeout and disallow
> > further access. What do you think?
> 
> So after a timeout occurs the file-object basically becomes worthless?
> Would it make sense to automatically call the close method of the
> file-object after this occurs?

Actually, we only need to forbid further reads (writes would always
work). I think we should still let the user call the close method
themselves.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7322>
_______________________________________

From report at bugs.python.org  Thu Jan 13 21:47:07 2011
From: report at bugs.python.org (Andy Harrington)
Date: Thu, 13 Jan 2011 20:47:07 +0000
Subject: [issue4953] cgi module cannot handle POST with multipart/form-data in
	3.x
In-Reply-To: <1232010166.79.0.972664060868.issue4953@psf.upfronthosting.co.za>
Message-ID: <1294951627.11.0.126725172196.issue4953@psf.upfronthosting.co.za>


Andy Harrington <aharrin at luc.edu> added the comment:

I found a similar issue.  If you want more simple files demonstrating the issue, I have attached some.  If I start my localCGIServer.py, then I can use adder.html fine (uses get), but with adderpost.html (uses post) the cgi action file, adder.cgi (that worked fine with the get version) hangs.

----------
nosy: +andyharrington
Added file: http://bugs.python.org/file20392/localCGIServer.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4953>
_______________________________________

From report at bugs.python.org  Thu Jan 13 21:49:45 2011
From: report at bugs.python.org (Andy Harrington)
Date: Thu, 13 Jan 2011 20:49:45 +0000
Subject: [issue4953] cgi module cannot handle POST with multipart/form-data in
	3.x
In-Reply-To: <1232010166.79.0.972664060868.issue4953@psf.upfronthosting.co.za>
Message-ID: <1294951785.07.0.247773227199.issue4953@psf.upfronthosting.co.za>


Changes by Andy Harrington <aharrin at luc.edu>:


Removed file: http://bugs.python.org/file20392/localCGIServer.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4953>
_______________________________________

From report at bugs.python.org  Thu Jan 13 21:52:07 2011
From: report at bugs.python.org (Andy Harrington)
Date: Thu, 13 Jan 2011 20:52:07 +0000
Subject: [issue4953] cgi module cannot handle POST with multipart/form-data in
	3.x
In-Reply-To: <1232010166.79.0.972664060868.issue4953@psf.upfronthosting.co.za>
Message-ID: <1294951927.73.0.662901552928.issue4953@psf.upfronthosting.co.za>


Changes by Andy Harrington <aharrin at luc.edu>:


Added file: http://bugs.python.org/file20393/adder.html

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4953>
_______________________________________

From report at bugs.python.org  Thu Jan 13 21:52:53 2011
From: report at bugs.python.org (Andy Harrington)
Date: Thu, 13 Jan 2011 20:52:53 +0000
Subject: [issue4953] cgi module cannot handle POST with multipart/form-data in
	3.x
In-Reply-To: <1232010166.79.0.972664060868.issue4953@psf.upfronthosting.co.za>
Message-ID: <1294951973.78.0.382679077759.issue4953@psf.upfronthosting.co.za>


Changes by Andy Harrington <aharrin at luc.edu>:


Added file: http://bugs.python.org/file20394/adderpost.html

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4953>
_______________________________________

From report at bugs.python.org  Thu Jan 13 21:54:02 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 13 Jan 2011 20:54:02 +0000
Subject: [issue4953] cgi module cannot handle POST with multipart/form-data in
	3.x
In-Reply-To: <1232010166.79.0.972664060868.issue4953@psf.upfronthosting.co.za>
Message-ID: <1294952042.44.0.160961411969.issue4953@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/issue4953>
_______________________________________

From report at bugs.python.org  Thu Jan 13 21:55:27 2011
From: report at bugs.python.org (Andy Harrington)
Date: Thu, 13 Jan 2011 20:55:27 +0000
Subject: [issue4953] cgi module cannot handle POST with multipart/form-data in
	3.x
In-Reply-To: <1232010166.79.0.972664060868.issue4953@psf.upfronthosting.co.za>
Message-ID: <1294952127.25.0.637613892754.issue4953@psf.upfronthosting.co.za>


Changes by Andy Harrington <aharrin at luc.edu>:


Added file: http://bugs.python.org/file20395/localCGIServer.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4953>
_______________________________________

From report at bugs.python.org  Thu Jan 13 21:56:31 2011
From: report at bugs.python.org (Andy Harrington)
Date: Thu, 13 Jan 2011 20:56:31 +0000
Subject: [issue4953] cgi module cannot handle POST with multipart/form-data in
	3.x
In-Reply-To: <1232010166.79.0.972664060868.issue4953@psf.upfronthosting.co.za>
Message-ID: <1294952191.44.0.350102667723.issue4953@psf.upfronthosting.co.za>


Changes by Andy Harrington <aharrin at luc.edu>:


Added file: http://bugs.python.org/file20396/adder.cgi

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4953>
_______________________________________

From report at bugs.python.org  Thu Jan 13 22:37:51 2011
From: report at bugs.python.org (Ram Rachum)
Date: Thu, 13 Jan 2011 21:37:51 +0000
Subject: [issue10893] The docs mark staticmethod as a function
In-Reply-To: <1294837196.34.0.0437845342766.issue10893@psf.upfronthosting.co.za>
Message-ID: <1294954671.21.0.0580434394268.issue10893@psf.upfronthosting.co.za>


Ram Rachum <cool-rr at cool-rr.com> added the comment:

But why? What's the reason for that? Why mislabel a type as a function?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10893>
_______________________________________

From report at bugs.python.org  Thu Jan 13 22:40:21 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 13 Jan 2011 21:40:21 +0000
Subject: [issue10893] The docs mark staticmethod as a function
In-Reply-To: <1294837196.34.0.0437845342766.issue10893@psf.upfronthosting.co.za>
Message-ID: <1294954821.42.0.112491349166.issue10893@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

staticmethod being a type or int being a function is really a CPython implementation detail.  If the docs say something is a class, it behaves as a class, you can subclass it and everything, and the other VMs implement it as a class, why would you want to consider the detail that it?s really a C function?

----------
nosy: +eric.araujo
stage:  -> committed/rejected
versions:  -Python 2.5, Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10893>
_______________________________________

From report at bugs.python.org  Thu Jan 13 22:47:49 2011
From: report at bugs.python.org (Ram Rachum)
Date: Thu, 13 Jan 2011 21:47:49 +0000
Subject: [issue10893] The docs mark staticmethod as a function
In-Reply-To: <1294837196.34.0.0437845342766.issue10893@psf.upfronthosting.co.za>
Message-ID: <1294955269.62.0.461861031932.issue10893@psf.upfronthosting.co.za>


Ram Rachum <cool-rr at cool-rr.com> added the comment:

I'm really confused by your comment.

"int being a function is really a CPython implementation detail"

I don't understand this. I should be able to do isinstance(x, int) in all implementations of Python, no? So `int` must be a class across all Python implementation, no?

"why would you want to consider the detail that it?s really a C function?"

I don't want to consider the detail that int is a C function, I thought that int is a class and expected it to be marked :class:`int` in the documentation.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10893>
_______________________________________

From report at bugs.python.org  Thu Jan 13 23:00:07 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 13 Jan 2011 22:00:07 +0000
Subject: [issue9268] Document annotation option to pickletools.dis
In-Reply-To: <1279222638.31.0.459529413565.issue9268@psf.upfronthosting.co.za>
Message-ID: <1294956007.91.0.330086218204.issue9268@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Committed documentation changes in revision 87990.

----------
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9268>
_______________________________________

From report at bugs.python.org  Thu Jan 13 23:00:46 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 13 Jan 2011 22:00:46 +0000
Subject: [issue10893] The docs mark staticmethod as a function
In-Reply-To: <1294837196.34.0.0437845342766.issue10893@psf.upfronthosting.co.za>
Message-ID: <1294956046.59.0.992550470772.issue10893@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Okay, scratch the comment about int, it?s not been accurate for quite a number of years.  Going back to staticmethod, my point still applies: Follow what the docs say.

staticmethod is a type in CPython probably due to the way descriptors work; contextlib.closing is a class for simplicity and efficiency; both of these examples are irrelevant internal details, they?re marked up as functions, so you should treat them as functions.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10893>
_______________________________________

From report at bugs.python.org  Thu Jan 13 23:03:26 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 13 Jan 2011 22:03:26 +0000
Subject: [issue4953] cgi module cannot handle POST with multipart/form-data in
	3.x
In-Reply-To: <1232010166.79.0.972664060868.issue4953@psf.upfronthosting.co.za>
Message-ID: <1294956206.87.0.701835061356.issue4953@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Ok, there are 10+ files attached, 20+ comments, no up-to-date patch. It's really too late for 3.2 IMO.

----------
nosy: +pitrou
priority: release blocker -> normal
stage: patch review -> needs patch
versions:  -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4953>
_______________________________________

From report at bugs.python.org  Thu Jan 13 23:07:37 2011
From: report at bugs.python.org (Pierre Bourgault)
Date: Thu, 13 Jan 2011 22:07:37 +0000
Subject: [issue7936] sys.argv contains only scriptname
In-Reply-To: <1266260840.45.0.891652447218.issue7936@psf.upfronthosting.co.za>
Message-ID: <1294956457.43.0.251433935906.issue7936@psf.upfronthosting.co.za>


Pierre Bourgault <pbourgault at quazal.com> added the comment:

I had the same problem with another version of python on Windows 7.

We are using python 2.4.2 for production and it is installed in D:\Tools\Python. For experimentation purpose, I installed Python 2.7 in the usual location. It broke a few things and I uninstalled both python, and reinstalled only 2.4.2.

After that, using python 2.4.2, I got the problem described by this issue. None of my colleagues (who did not install Python 2.7) had the issue. 

The registry entry HKEY_CLASSES_ROOT\py_auto_file\shell\open\command was reading: D:\Tools\Python\python.exe "%1"

It was missing %*. I added it and my issue went away.

----------
nosy: +pierrebourgault

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7936>
_______________________________________

From report at bugs.python.org  Thu Jan 13 23:09:08 2011
From: report at bugs.python.org (Pierre Quentel)
Date: Thu, 13 Jan 2011 22:09:08 +0000
Subject: [issue4953] cgi module cannot handle POST with multipart/form-data in
	3.x
In-Reply-To: <1232010166.79.0.972664060868.issue4953@psf.upfronthosting.co.za>
Message-ID: <1294956548.5.0.297499151912.issue4953@psf.upfronthosting.co.za>


Pierre Quentel <pierre.quentel at gmail.com> added the comment:

Comment ?a, no up to date patch ? cgi_32.patch is up to date, the API changes are documented, the unittests work, what else do you want ?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4953>
_______________________________________

From report at bugs.python.org  Thu Jan 13 23:10:49 2011
From: report at bugs.python.org (Ram Rachum)
Date: Thu, 13 Jan 2011 22:10:49 +0000
Subject: [issue10893] The docs mark staticmethod as a function
In-Reply-To: <1294837196.34.0.0437845342766.issue10893@psf.upfronthosting.co.za>
Message-ID: <1294956649.75.0.278266927201.issue10893@psf.upfronthosting.co.za>


Ram Rachum <cool-rr at cool-rr.com> added the comment:

So if int is officially a class, why not start doing :class:`int` instead of :func:`int`?

"they?re marked up as functions, so you should treat them as functions."

Here, I've treated staticmethod as a function:

    >>> assert isinstance(staticmethod, types.FunctionType)
    Traceback (most recent call last):
      File "<pyshell#1>", line 1, in <module>
        assert isinstance(staticmethod, types.FunctionType)
    AssertionError

I get an error.

So I understand that you are using Sphinx's :func: role in a liberal way; You consider it okay to use it to mark anything that is callable, regardless of whether it's a function or a class. Am I right?

This looks to me like an abuse of Sphinx notation. When I read documentation I don't want to be second-guessing the author's intentions. If someone writes :func:`whatever` I expect `whatever` to be a function and not a class.

Perhaps we need a :callable: role?

----------
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10893>
_______________________________________

From report at bugs.python.org  Thu Jan 13 23:14:37 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 13 Jan 2011 22:14:37 +0000
Subject: [issue10893] The docs mark staticmethod as a function
In-Reply-To: <1294837196.34.0.0437845342766.issue10893@psf.upfronthosting.co.za>
Message-ID: <1294956877.43.0.0305330309263.issue10893@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I don?t have enough experience to make a judgment call here.  Raymond or Georg, can you?

----------
nosy: +georg.brandl
versions: +Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10893>
_______________________________________

From report at bugs.python.org  Thu Jan 13 23:14:58 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 13 Jan 2011 22:14:58 +0000
Subject: [issue4953] cgi module cannot handle POST with multipart/form-data in
	3.x
In-Reply-To: <1294956548.5.0.297499151912.issue4953@psf.upfronthosting.co.za>
Message-ID: <1294956893.3687.21.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Comment ?a, no up to date patch ? cgi_32.patch is up to date, the API
> changes are documented, the unittests work, what else do you want ?

The O_BINARY stuff looks obsolete to me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4953>
_______________________________________

From report at bugs.python.org  Thu Jan 13 23:22:46 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 13 Jan 2011 22:22:46 +0000
Subject: [issue10893] The docs mark staticmethod as a function
In-Reply-To: <1294837196.34.0.0437845342766.issue10893@psf.upfronthosting.co.za>
Message-ID: <1294957366.6.0.837890014617.issue10893@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

That's just the way we do our markup.
Sorry, but this is a total non-issue.
You're trying to create finer distinctions
than the markup needs to support.

Besides, the distinction between types,
objects, callables, functions, instances,
descriptors and whatnot are much less
black and white than you might imagine.

----------
nosy: +rhettinger
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10893>
_______________________________________

From report at bugs.python.org  Thu Jan 13 23:27:15 2011
From: report at bugs.python.org (Glenn Linderman)
Date: Thu, 13 Jan 2011 22:27:15 +0000
Subject: [issue4953] cgi module cannot handle POST with multipart/form-data in
	3.x
In-Reply-To: <1232010166.79.0.972664060868.issue4953@psf.upfronthosting.co.za>
Message-ID: <1294957635.72.0.4336406038.issue4953@psf.upfronthosting.co.za>


Glenn Linderman <v+python at g.nevcal.com> added the comment:

The O_BINARY stuff was probably necessary because issue 10841 is not yet in the build Pierre was using?  I agree it in not necessary with the fix for that issue, but neither does it hurt.

It could be stripped out, if you think that is best, Antoine.

But there is a working patch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4953>
_______________________________________

From report at bugs.python.org  Thu Jan 13 23:29:58 2011
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 13 Jan 2011 22:29:58 +0000
Subject: [issue10893] The docs mark staticmethod as a function
In-Reply-To: <1294837196.34.0.0437845342766.issue10893@psf.upfronthosting.co.za>
Message-ID: <1294957798.57.0.515667539822.issue10893@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Fully agreed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10893>
_______________________________________

From report at bugs.python.org  Thu Jan 13 23:39:59 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 13 Jan 2011 22:39:59 +0000
Subject: [issue4953] cgi module cannot handle POST with multipart/form-data in
	3.x
In-Reply-To: <1232010166.79.0.972664060868.issue4953@psf.upfronthosting.co.za>
Message-ID: <1294958399.54.0.430915726272.issue4953@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Can one person please

1) Sum up the discussion and its outcome briefly

2) Remove all patches and replace them with one diff with docs, tests and code (even if you have new files, you don?t have to put them in a zip, use svn add and they will show up in the svn diff, which is really easier to review)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4953>
_______________________________________

From report at bugs.python.org  Thu Jan 13 23:42:32 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 13 Jan 2011 22:42:32 +0000
Subject: [issue4953] cgi module cannot handle POST with multipart/form-data in
	3.x
In-Reply-To: <1232010166.79.0.972664060868.issue4953@psf.upfronthosting.co.za>
Message-ID: <1294958552.43.0.51175879773.issue4953@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


Removed file: http://bugs.python.org/file20288/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4953>
_______________________________________

From report at bugs.python.org  Thu Jan 13 23:43:37 2011
From: report at bugs.python.org (Etienne Robillard)
Date: Thu, 13 Jan 2011 22:43:37 +0000
Subject: [issue4953] cgi module cannot handle POST with multipart/form-data
	in	3.x
In-Reply-To: <1294958399.54.0.430915726272.issue4953@psf.upfronthosting.co.za>
Message-ID: <4D2F7E6E.7070100@gthcfoundation.org>


Etienne Robillard <erob at gthcfoundation.org> added the comment:

+1

----------
title: cgi module cannot handle POST with multipart/form-data in 3.x -> cgi module cannot handle POST with multipart/form-data in	3.x

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4953>
_______________________________________

From report at bugs.python.org  Fri Jan 14 00:05:32 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 13 Jan 2011 23:05:32 +0000
Subject: [issue6697] Check that _PyUnicode_AsString() result is not NULL
In-Reply-To: <1250194052.29.0.344352855764.issue6697@psf.upfronthosting.co.za>
Message-ID: <1294959932.55.0.965366560451.issue6697@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

I am replacing issue6697-lsprof.diff with a (hopefully) more carefully written version that addresses the issues that Victor noted.

Victor,

I take your comment as +1 for adding PyModule_GetNameObject().


I started looking into adding unit tests that would exercise this code, but is does not seem possible to trigger the fn->m_self == NULL condition.  According to the comment in the code, this is supposed to be the case when fn is a builtin function, but I observe the following in the debugger when running test_cprofile:

(gdb) pyo fn
object  : <built-in function exec>
type    : builtin_function_or_method
refcount: 4
address : 0x10038c678
$5 = void
(gdb) pyo fn->m_self 
object  : <module 'builtins' (built-in)>
type    : module
refcount: 51
address : 0x100388ee8
$6 = void

----------
Added file: http://bugs.python.org/file20397/issue6697-lsprof.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6697>
_______________________________________

From report at bugs.python.org  Fri Jan 14 00:05:54 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 13 Jan 2011 23:05:54 +0000
Subject: [issue6697] Check that _PyUnicode_AsString() result is not NULL
In-Reply-To: <1250194052.29.0.344352855764.issue6697@psf.upfronthosting.co.za>
Message-ID: <1294959954.67.0.862946981666.issue6697@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


Removed file: http://bugs.python.org/file19980/issue6697-lsprof.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6697>
_______________________________________

From report at bugs.python.org  Fri Jan 14 00:23:55 2011
From: report at bugs.python.org (Giampaolo Rodola')
Date: Thu, 13 Jan 2011 23:23:55 +0000
Subject: [issue2292] Missing *-unpacking generalizations
In-Reply-To: <1205595680.3.0.859525264867.issue2292@psf.upfronthosting.co.za>
Message-ID: <1294961035.49.0.00248424903811.issue2292@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/issue2292>
_______________________________________

From report at bugs.python.org  Fri Jan 14 00:28:00 2011
From: report at bugs.python.org (anatoly techtonik)
Date: Thu, 13 Jan 2011 23:28:00 +0000
Subject: [issue7662] time.utcoffset()
In-Reply-To: <1263057341.16.0.947515103763.issue7662@psf.upfronthosting.co.za>
Message-ID: <1294961280.59.0.655541987699.issue7662@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

This one is a different issue. Even though it can not be solved without by #9527, it is not superseded by it. So, better add to dependencies.

----------
resolution: rejected -> 
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7662>
_______________________________________

From report at bugs.python.org  Fri Jan 14 00:29:14 2011
From: report at bugs.python.org (Brian Curtin)
Date: Thu, 13 Jan 2011 23:29:14 +0000
Subject: [issue7662] time.utcoffset()
In-Reply-To: <1263057341.16.0.947515103763.issue7662@psf.upfronthosting.co.za>
Message-ID: <1294961354.63.0.656656396251.issue7662@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
nosy:  -brian.curtin

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7662>
_______________________________________

From report at bugs.python.org  Fri Jan 14 00:39:22 2011
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 13 Jan 2011 23:39:22 +0000
Subject: [issue7662] time.utcoffset()
In-Reply-To: <1263057341.16.0.947515103763.issue7662@psf.upfronthosting.co.za>
Message-ID: <1294961962.99.0.720069680235.issue7662@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

You can discuss within the comments whether this issue should be re-opened or not, but do not take it upon yourself to change the status on your own once a core developer has already closed an issue as their decision supersedes that of a regular user.

----------
resolution:  -> rejected
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7662>
_______________________________________

From report at bugs.python.org  Fri Jan 14 00:39:30 2011
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 13 Jan 2011 23:39:30 +0000
Subject: [issue7662] time.utcoffset()
In-Reply-To: <1263057341.16.0.947515103763.issue7662@psf.upfronthosting.co.za>
Message-ID: <1294961970.19.0.821509624531.issue7662@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
nosy:  -brett.cannon
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7662>
_______________________________________

From report at bugs.python.org  Fri Jan 14 00:54:55 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 13 Jan 2011 23:54:55 +0000
Subject: [issue4953] cgi module cannot handle POST with multipart/form-data
	in	3.x
In-Reply-To: <1232010166.79.0.972664060868.issue4953@psf.upfronthosting.co.za>
Message-ID: <1294962895.05.0.719397761716.issue4953@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

I tested cgi_32.patch on Windows with Apache:
 - a test with a binary file works: I get a binary file instead of a text file
 - a test with a non-ASCII character (a\xe9b) works: the text is correctly decoded

I used the test script from full_source_and_error.zip.

Comments on cgi_32.patch:

 - I don't understand why FieldStorage changes sys.stdout and sys.stderr (see remarks about IOMix above): please remove the charset argument (it is also confusing to have two encoding arguments). it should be done somewhere else
 - please remove the O_BINARY hack: the patch is for Python 3.2 and I closed issue #10841. If you would like a backport, another patch should be written later
 - "encoding = 'latin-1' # ?": write a real comment or remove it
 - 'self.fp.read(...) # bytes': you should add a test on the type if you are not sure that fp.read() gives bytes
 - "file: the file(-like) object from which you can read the data *as bytes*": you should mention that TextIOWrapper is also tolerated (accepted?)
 - you may set fp directly to sys.stdin.buffer (instead of sys.stdin) if fp is None (it will be easier after removing the O_BINARY thing)
 - the patch adds a tab in an empty line, please don't do that :-)
 - you should add a (private?) attribute to FieldStorage to decide if it works on bytes or unicode, instead of using "self.filename is not None" test (eg. self._use_bytes = (self.filename is not None)
 - i don't like the idea of having a generic self.__write() method supporting bytes and unicode. it would prefer two methods, eg. self.__write_text() and self.__write_binary() (they can share a third private method)
 - i don't like "stream_encoding" name: what is the "stream" here? do you process a "file", a "string" or a "stream"? why not just "self.encoding"?
 - "import email.parser,email.feedparser" one import is useless here. I prefer "from email.feedparser import FeedParser" because you get directly a ImportError if the symbol is missing. And it's already faster to get FeedParser instead of email.feedparser.FeedParser in a loop (dummy micro-optimization)
 - even I like the following change, please do it in a separated patch:
-            if type(value) is type([]):
+            if isinstance(value,list):


I really don't like the IOMix thing:

 - sys.stdout.write() should not accept bytes
 - FieldStorage should not replace sys.stdout and sys.stderr: if you want to set the encoding of these files, set PYTHONIOENCODING environment variable before running your program (it changes also the encoding of sys.stdio)
 - IOMix should not accept bytes *and* unicode. It's better to have an explicit API like stdout.write('unicode') and stdout.buffer.write(b'bytes)


Most parts of the patch are correct and fix real bugs. Since cgi is broken currently (eg. it doesn't handle binary files correctly), anything making the situation better would be nice.

I vote +0 to commit the patch now (if the release manager agrees), and +1 if all of my remarks are fixed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4953>
_______________________________________

From report at bugs.python.org  Fri Jan 14 01:18:44 2011
From: report at bugs.python.org (anatoly techtonik)
Date: Fri, 14 Jan 2011 00:18:44 +0000
Subject: [issue7662] time.utcoffset()
In-Reply-To: <1263057341.16.0.947515103763.issue7662@psf.upfronthosting.co.za>
Message-ID: <1294964324.16.0.466173413973.issue7662@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

I am tired. Do as you wish.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7662>
_______________________________________

From report at bugs.python.org  Fri Jan 14 01:19:03 2011
From: report at bugs.python.org (anatoly techtonik)
Date: Fri, 14 Jan 2011 00:19:03 +0000
Subject: [issue7662] time.utcoffset()
In-Reply-To: <1263057341.16.0.947515103763.issue7662@psf.upfronthosting.co.za>
Message-ID: <1294964343.24.0.58262494622.issue7662@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/issue7662>
_______________________________________

From report at bugs.python.org  Fri Jan 14 01:36:31 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 14 Jan 2011 00:36:31 +0000
Subject: [issue6697] Check that _PyUnicode_AsString() result is not NULL
In-Reply-To: <1294959932.55.0.965366560451.issue6697@psf.upfronthosting.co.za>
Message-ID: <1294965542.28561.3.camel@marge>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Le jeudi 13 janvier 2011 ? 23:05 +0000, Alexander Belopolsky a ?crit :
> I take your comment as +1 for adding PyModule_GetNameObject().

I wrote a similar patch to add PyModule_GetNameObject() (I am working on
another huge patch, to fix #3080). You have to document the new function
in Doc/c-api/module.rst.

Yes, it's better to work on unicode than encode unicode to bytes
(PyModule_GetName() with UTF-8) and then decode bytes from unicode
(PyUnicode_FromFormat with %s).

I am too tired to review the patch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6697>
_______________________________________

From report at bugs.python.org  Fri Jan 14 02:52:04 2011
From: report at bugs.python.org (Glenn Linderman)
Date: Fri, 14 Jan 2011 01:52:04 +0000
Subject: [issue4953] cgi module cannot handle POST with multipart/form-data
	in	3.x
In-Reply-To: <1232010166.79.0.972664060868.issue4953@psf.upfronthosting.co.za>
Message-ID: <1294969924.49.0.472463488607.issue4953@psf.upfronthosting.co.za>


Glenn Linderman <v+python at g.nevcal.com> added the comment:

Victor, thanks for your comments, and interest in this bug.  Other than the existence of the charset parameter, and whether or not to include IOMix, I think all of the others could be fixed later, and do not hurt at present.  So I will just comment on those two comments.

I would prefer to see FieldStorage not have the charset attribute also, but I don't have the practice to produce an alternate patch, and I can see that it would be a convenience for some CGI scripts to specify that parameter, and have one API call do all the work necessary to adjust the IO streams, and read all the parameters, and then the rest of the logic of the web app can follow.  Personally, I adjust the stdout/stderr streams earlier in my scripts, and only optionally call FieldStorage, if I determine the request needs such.

I've been using IOMix for some months (I have a version for both Python 2 and 3), and it solves a real problem in generating web page data streams... the data stream should be bytes, but a lot of the data is manipulated using str, which would then need to be decoded.  The default encoding of stdout is usually wrong, so must somehow be changed.  And when you have chunks of bytes (in my experience usually from a database or file) to copy to the output stream, if your prior write was str, and then you write bytes to sys.stdout.binary, you have to also remember to flush the TextIOBuffer first.  IOMix provides a convenient solution to all these problems, doing the flushing for you automatically, and just taking what comes and doing the right thing.  If I hadn't already invented IOMix to help write web pages, I would want to :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4953>
_______________________________________

From report at bugs.python.org  Fri Jan 14 04:25:24 2011
From: report at bugs.python.org (Glenn Maynard)
Date: Fri, 14 Jan 2011 03:25:24 +0000
Subject: [issue10278] add time.wallclock() method
In-Reply-To: <1288624210.23.0.0497533122542.issue10278@psf.upfronthosting.co.za>
Message-ID: <1294975524.44.0.275755066955.issue10278@psf.upfronthosting.co.za>


Glenn Maynard <glennfmaynard at gmail.com> added the comment:

I agree with Victor: Python should provide a function to supply monotonic time, which is what's really wanted for measuring time deltas.  Far too many applications incorrectly use the system clock for this, and Python makes this worse by not providing any standard library function to allow people to do this correctly.

In Windows, it should probably use GetTickCount64 if available, otherwise GetTickCount with logic to handle wrapping.  I think QueryPerformanceCounter is problematic as a general-purpose timer: depending on the hardware and Windows version, it can be offset differently across CPUs, and may not be reliable on some processors.  It may be fixed in Vista or Win7, I'm not sure; if so it's much higher resolution than GTC.

----------
nosy: +glenn

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10278>
_______________________________________

From report at bugs.python.org  Fri Jan 14 05:25:32 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 14 Jan 2011 04:25:32 +0000
Subject: [issue7662] time.utcoffset()
In-Reply-To: <1263057341.16.0.947515103763.issue7662@psf.upfronthosting.co.za>
Message-ID: <1294979132.3.0.789173248662.issue7662@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Just to clarify: Anatoly changed the resolution, not status (and I agree that was not appropriate.)  The status was set to "pending" and that would change to "open" automatically if a new comment is posted.

As for the substance of Anatoly's objection - I agree that this proposal is different from #9527.   That is why I set resolution to "rejected" rathe than "duplicate".  This issue can probably be properly classified as a duplicate of #1647654, but I consider #9527 the most promising solution to the problem of finding the system timezone offset.

----------
stage: needs patch -> committed/rejected

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7662>
_______________________________________

From report at bugs.python.org  Fri Jan 14 05:27:08 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 14 Jan 2011 04:27:08 +0000
Subject: [issue1647654] No obvious and correct way to get the time zone offset
Message-ID: <1294979228.92.0.598217458548.issue1647654@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Closing this in favor of #9527.  See msg126064 for more details.

----------
stage: patch review -> committed/rejected

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1647654>
_______________________________________

From report at bugs.python.org  Fri Jan 14 05:55:20 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 14 Jan 2011 04:55:20 +0000
Subject: [issue6083] Reference counting bug in PyArg_ParseTuple and
	PyArg_ParseTupleAndKeywords
In-Reply-To: <1242980336.93.0.332167282409.issue6083@psf.upfronthosting.co.za>
Message-ID: <1294980920.06.0.0192263893688.issue6083@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Let me summarize the issue: the PyArg_ParseTuple format code 'O' returns a borrowed reference.  However, when the 'O' code appears inside parenthesis, there may not be an object to hold the reference to borrow from.  This is what happens in the test-functools.py crasher:  partial.__setstate__() takes a 4-tuple argument that is unpacked using a "(OOOO)" format.  The test case passes an instance instead of a tuple that supports the sequence methods, but does not hold the reference to the "items" that its []-operator returns.  This is not a problem at the top level because args argument to PyArg_ParseTuple is always a real tuple.

I think that rather than deprecating the use of 'O' format inside parentheses, "(..O..)" unpacking should reject to unpack arguments other than tuples or maybe lists.

----------
nosy: +belopolsky
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6083>
_______________________________________

From report at bugs.python.org  Fri Jan 14 06:15:43 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Fri, 14 Jan 2011 05:15:43 +0000
Subject: [issue9844] calling nonexisting function under __INSURE__
In-Reply-To: <1284358768.31.0.932745075936.issue9844@psf.upfronthosting.co.za>
Message-ID: <1294982143.89.0.925084713599.issue9844@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

This code is in Modules/main.c, function Py_Main.


In 2.7, only _Py_ReleaseInternedStrings is called, and this function is defined in Objects/stringobject.c

In 3k, the two functions are called as specified above. _Py_ReleaseInternedStrings doesn't exist in 3k, and _Py_ReleaseInternedUnicodeStrings is defined in Objects/unicodeobject.c

I will now supply a patch that removes the call.

----------
nosy: +ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9844>
_______________________________________

From report at bugs.python.org  Fri Jan 14 06:21:03 2011
From: report at bugs.python.org (Ross Lagerwall)
Date: Fri, 14 Jan 2011 05:21:03 +0000
Subject: [issue7322] Socket timeout can cause file-like readline() method to
	lose data
In-Reply-To: <1258218993.08.0.764402701678.issue7322@psf.upfronthosting.co.za>
Message-ID: <1294982463.57.0.371383558632.issue7322@psf.upfronthosting.co.za>


Ross Lagerwall <rosslagerwall at gmail.com> added the comment:

Attached patch disallows further reads after a timeout.

----------
Added file: http://bugs.python.org/file20398/i7322.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7322>
_______________________________________

From report at bugs.python.org  Fri Jan 14 06:29:50 2011
From: report at bugs.python.org (Bill Hayes)
Date: Fri, 14 Jan 2011 05:29:50 +0000
Subject: [issue7936] sys.argv contains only scriptname
In-Reply-To: <1266260840.45.0.891652447218.issue7936@psf.upfronthosting.co.za>
Message-ID: <1294982990.37.0.338638306205.issue7936@psf.upfronthosting.co.za>


Bill Hayes <bhayes84 at yahoo.com> added the comment:

I finally found a solution from a page on StackOverflow.
I had to add the two characters  %*
to the end of the Data value for the Windows registry key:
  HKEY_CLASSES_ROOT\Applications\python.exe\shell\open\command
So the Data value is now:
   "C:\Python26\python.exe" "%1" %*
just as it appears above including the two sets of double quotes.

I had modified or added six other keys but only the one above solved the problem.
I am running Python 2.6 under MS Windows Vista Home Premium 32 bit.
For completeness I tested potential fixes as follows:
I had a program show_args.py which had the two lines:
  import sys
  print 'argv length is ', len(sys.argv)
In order for show_args.py to receive args from the command line invocation (before I did the registry fix) I had to explicitly call the python interpreter, so ...

Before the fix:
C:\...>python show_args.py aaa bbb ccc
argv length is 4
C:\...>show_args.py aaa bbb ccc
argv length is 1

After the fix:
C:\...>show_args.py aaa bbb ccc
argv length is 4

In hindsight I should have searched the registry for python paths that didn't have the ending %*.

Very briefly, for those unfamiliar with Windows' RegEdit:
Click the Start button and enter   regedit    in the Search box and the Regedit.exe name will appear in the list above - click it.
Repeatedly do Edit/Find   python.exe   
until you find a python path of the form: ...\python.exe" "%1"
instead of the form ...\python.exe" "%1" %*
In the right pane of Regedit, under Name click the word (Default), it will turn blue, then select Edit/Modify...
Simply add a space and the two chars  %* to the end of the entry in the Value data box, then click OK.
Changes take effect immediately; you don't have to reboot or re-open your prompt window, but if you are using IDLE or another IDE you probably have to close and restart it.

----------
versions: +Python 2.6 -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7936>
_______________________________________

From report at bugs.python.org  Fri Jan 14 06:32:09 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Fri, 14 Jan 2011 05:32:09 +0000
Subject: [issue9844] calling nonexisting function under __INSURE__
In-Reply-To: <1284358768.31.0.932745075936.issue9844@psf.upfronthosting.co.za>
Message-ID: <1294983129.57.0.5571815612.issue9844@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

Attaching a patch that removes the call of the non-existing function in py3k. I ran the test suite and make patchcheck.

I don't remove the whole __INSURE__ since someone might still want it in (and I don't have the tool to play around with it). But the call should definitely go, since it won't compile this way.

Nick, Terry - your approval - and I'll commit this.

----------
keywords: +patch
Added file: http://bugs.python.org/file20399/issue9844.py3k.1.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9844>
_______________________________________

From report at bugs.python.org  Fri Jan 14 06:55:53 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Fri, 14 Jan 2011 05:55:53 +0000
Subject: [issue7936] sys.argv contains only scriptname
In-Reply-To: <1266260840.45.0.891652447218.issue7936@psf.upfronthosting.co.za>
Message-ID: <1294984553.33.0.00719687657251.issue7936@psf.upfronthosting.co.za>


Changes by Martin v. L?wis <martin at v.loewis.de>:


----------
versions: +Python 2.7, Python 3.1, Python 3.2, Python 3.3 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7936>
_______________________________________

From report at bugs.python.org  Fri Jan 14 07:04:07 2011
From: report at bugs.python.org (Jean Jordaan)
Date: Fri, 14 Jan 2011 06:04:07 +0000
Subject: [issue10902] Doc type: "run_*" instead of "run*" on
	http://docs.python.org/library/pdb.html
In-Reply-To: <1294985047.82.0.945168102626.issue10902@psf.upfronthosting.co.za>
Message-ID: <1294985047.82.0.945168102626.issue10902@psf.upfronthosting.co.za>


New submission from Jean Jordaan <jean.jordaan at gmail.com>:

http://docs.python.org/library/pdb.html states "The run_* functions and set_trace() are aliases" but the functions in question are "run", "runeval" and "runcall": no underscores.

----------
assignee: docs at python
components: Documentation
messages: 126231
nosy: docs at python, neaj
priority: normal
severity: normal
status: open
title: Doc type: "run_*" instead of "run*" on http://docs.python.org/library/pdb.html
type: performance
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10902>
_______________________________________

From report at bugs.python.org  Fri Jan 14 07:08:11 2011
From: report at bugs.python.org (Graham Dumpleton)
Date: Fri, 14 Jan 2011 06:08:11 +0000
Subject: [issue4953] cgi module cannot handle POST with multipart/form-data
	in	3.x
In-Reply-To: <1232010166.79.0.972664060868.issue4953@psf.upfronthosting.co.za>
Message-ID: <1294985291.35.0.154518389234.issue4953@psf.upfronthosting.co.za>


Graham Dumpleton <Graham.Dumpleton at gmail.com> added the comment:

FWIW, keep in mind that cgi.FieldStorage is also quite often used in WSGI scripts in arbitrary WSGI servers which have got nothing to do with CGI. Having cgi.FieldStorage muck around with stdout/stderr under WSGI, even where using a CGI/WSGI bridge, would potentially be a bad thing to do, especially in embedded systems like mod_wsgi where sys.stdout and sys.stderr are replaced with file like objects that map onto Apache error logging. Even in non embedded systems, you could very well screw up any application logging done via stdout/stderr and break the application.

So, the default or common code paths should never play with sys.stdout or sys.stderr. It is already a PITA that the implementation falls back to using sys.argv when QUERY_STRING isn't defined which also could produce strange results under a WSGI server. In other words, please don't go adding any more code which makes the wrong assumption that this is only used in CGI scripts.

----------
nosy: +grahamd

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4953>
_______________________________________

From report at bugs.python.org  Fri Jan 14 07:17:41 2011
From: report at bugs.python.org (Glenn Linderman)
Date: Fri, 14 Jan 2011 06:17:41 +0000
Subject: [issue4953] cgi module cannot handle POST with multipart/form-data
	in	3.x
In-Reply-To: <1232010166.79.0.972664060868.issue4953@psf.upfronthosting.co.za>
Message-ID: <1294985861.32.0.846726240977.issue4953@psf.upfronthosting.co.za>


Glenn Linderman <v+python at g.nevcal.com> added the comment:

Graham, Thanks for your comments.  Fortunately, if the new charset parameter is not supplied, no mucking with stdout or stderr is done, which is the only reason I cannot argue strongly against the feature, which I would have implemented as a separate API... it doesn't get in the way if you don't use it.

I would be happy to see the argv code removed, but it has been there longer than I have been a Python user, so I just live with it ... and don't pass arguments to my CGI scripts anyway.  I've assumed that is some sort of a debug feature, but I also saw some code in the HTTPCGIServer and http.server that apparently, on some platforms, actually do pass parameters to CGI on the command lines.  I would be happy to see that code removed too, but it also predates my Python experience.  And no signs of "if debug:" by either of them!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4953>
_______________________________________

From report at bugs.python.org  Fri Jan 14 07:42:09 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 14 Jan 2011 06:42:09 +0000
Subject: [issue6083] Reference counting bug in PyArg_ParseTuple and
	PyArg_ParseTupleAndKeywords
In-Reply-To: <1242980336.93.0.332167282409.issue6083@psf.upfronthosting.co.za>
Message-ID: <1294987329.21.0.573848785065.issue6083@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Attached patch passes the regrtest and makes test-functools.py raise an exception rather than crash.  The proposed change will make functions like partial.__setstate__ require tuple argument even though currently it would accept any container.  This is not an issue with __setstate__ because it should only be called with arguments produced by __reduce__ and in the case of partial, __reduce__ produces state as a tuple.  Other functions may need to be modified if they need to continue to accept arbitrary sequences.

----------
stage: needs patch -> patch review
Added file: http://bugs.python.org/file20400/issue6083.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6083>
_______________________________________

From report at bugs.python.org  Fri Jan 14 08:15:38 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Fri, 14 Jan 2011 07:15:38 +0000
Subject: [issue10902] Doc type: "run_*" instead of "run*" on
	http://docs.python.org/library/pdb.html
In-Reply-To: <1294985047.82.0.945168102626.issue10902@psf.upfronthosting.co.za>
Message-ID: <1294989338.43.0.318155384901.issue10902@psf.upfronthosting.co.za>


Changes by Eli Bendersky <eliben at gmail.com>:


----------
nosy: +eli.bendersky
stage:  -> needs patch
type: performance -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10902>
_______________________________________

From report at bugs.python.org  Fri Jan 14 08:18:32 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Fri, 14 Jan 2011 07:18:32 +0000
Subject: [issue8957] strptime(.., '%c') fails to parse output of strftime('%c',
	..) in some locales
In-Reply-To: <1276115080.37.0.388300880324.issue8957@psf.upfronthosting.co.za>
Message-ID: <1294989512.8.0.832975299117.issue8957@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

Alexander, I get the same error for the he_IL locale. Will look into this

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8957>
_______________________________________

From report at bugs.python.org  Fri Jan 14 08:23:58 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 14 Jan 2011 07:23:58 +0000
Subject: [issue9844] calling nonexisting function under __INSURE__
In-Reply-To: <1284358768.31.0.932745075936.issue9844@psf.upfronthosting.co.za>
Message-ID: <1294989838.59.0.638137243572.issue9844@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

A quick Google search suggests that code is there to make Insure++ happy, so +1 for Eli's simple fix. Georg hasn't closed the py3k branch yet, so go ahead and commit it.

(3.2c1 is due this Saturday, so it's worth keeping a close eye on python-committers for the freeze notice - time zones means the relative timing of things can be surprising)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9844>
_______________________________________

From report at bugs.python.org  Fri Jan 14 08:27:49 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Fri, 14 Jan 2011 07:27:49 +0000
Subject: [issue10902] Doc type: "run_*" instead of "run*" on
	http://docs.python.org/library/pdb.html
In-Reply-To: <1294985047.82.0.945168102626.issue10902@psf.upfronthosting.co.za>
Message-ID: <1294990069.44.0.815747010298.issue10902@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

Here's a patch that fixes it to "run*". 
If it's OK I will commit it and port to py3k where the problem also exists

----------
keywords: +patch
nosy: +ncoghlan
Added file: http://bugs.python.org/file20401/issue10902.py27.1.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10902>
_______________________________________

From report at bugs.python.org  Fri Jan 14 08:32:15 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Fri, 14 Jan 2011 07:32:15 +0000
Subject: [issue9844] calling nonexisting function under __INSURE__
In-Reply-To: <1284358768.31.0.932745075936.issue9844@psf.upfronthosting.co.za>
Message-ID: <1294990335.89.0.140860821908.issue9844@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

Committed r87991

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9844>
_______________________________________

From report at bugs.python.org  Fri Jan 14 08:39:16 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 14 Jan 2011 07:39:16 +0000
Subject: [issue10902] Doc type: "run_*" instead of "run*" on
	http://docs.python.org/library/pdb.html
In-Reply-To: <1294985047.82.0.945168102626.issue10902@psf.upfronthosting.co.za>
Message-ID: <1294990756.18.0.91958770586.issue10902@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Yep, go ahead.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10902>
_______________________________________

From report at bugs.python.org  Fri Jan 14 09:13:44 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Fri, 14 Jan 2011 08:13:44 +0000
Subject: [issue10902] Doc type: "run_*" instead of "run*" on
	http://docs.python.org/library/pdb.html
In-Reply-To: <1294985047.82.0.945168102626.issue10902@psf.upfronthosting.co.za>
Message-ID: <1294992824.52.0.953342287529.issue10902@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

Committed to release27-maint r87992

----------
resolution:  -> fixed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10902>
_______________________________________

From report at bugs.python.org  Fri Jan 14 09:21:31 2011
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 14 Jan 2011 08:21:31 +0000
Subject: [issue10902] Doc type: "run_*" instead of "run*" on
	http://docs.python.org/library/pdb.html
In-Reply-To: <1294985047.82.0.945168102626.issue10902@psf.upfronthosting.co.za>
Message-ID: <1294993291.04.0.199549691092.issue10902@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

That's the wrong way of porting though... py3k first, then 2.7 and 3.1.

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10902>
_______________________________________

From report at bugs.python.org  Fri Jan 14 09:23:47 2011
From: report at bugs.python.org (Pierre Quentel)
Date: Fri, 14 Jan 2011 08:23:47 +0000
Subject: [issue4953] cgi module cannot handle POST with multipart/form-data
	in	3.x
In-Reply-To: <1232010166.79.0.972664060868.issue4953@psf.upfronthosting.co.za>
Message-ID: <1294993427.24.0.3563737062.issue4953@psf.upfronthosting.co.za>


Pierre Quentel <pierre.quentel at gmail.com> added the comment:

@Victor

Thanks for the comments

"- I don't understand why FieldStorage changes sys.stdout and sys.stderr (see remarks about IOMix above): please remove the charset argument (it is also confusing to have two encoding arguments). it should be done somewhere else"

done

"please remove the O_BINARY hack: the patch is for Python 3.2 and I closed issue #10841. If you would like a backport, another patch should be written later"

done

""encoding = 'latin-1' # ?": write a real comment or remove it"

I removed this part

"'self.fp.read(...) # bytes': you should add a test on the type if you are not sure that fp.read() gives bytes"

added tests in read_urlencoded(), read_multi() and read_binary()

 "file: the file(-like) object from which you can read the data *as bytes*": you should mention that TextIOWrapper is also tolerated (accepted?)"

not done : here "file" is not the argument passed to the FieldStorage constructor, but the attribute of values returned from calls to FieldStorage. In the new implementation, its read() method always returns bytes

"you may set fp directly to sys.stdin.buffer (instead of sys.stdin) if fp is None (it will be easier after removing the O_BINARY thing)"
 
done
 
 "the patch adds a tab in an empty line, please don't do that :-)"
 
done (hopefully :-)
 
"you should add a (private?) attribute to FieldStorage to decide if it works on bytes or unicode, instead of using "self.filename is not None" test (eg. self._use_bytes = (self.filename is not None)"

done

 "i don't like the idea of having a generic self.__write() method supporting bytes and unicode. it would prefer two methods, eg. self.__write_text() and self.__write_binary() (they can share a third private method)"
 
not done, the argument of __write is always bytes
 
"i don't like "stream_encoding" name: what is the "stream" here? do you process a "file", a "string" or a "stream"? why not just "self.encoding"?"

done

 - "import email.parser,email.feedparser" one import is useless here. I prefer "from email.feedparser import FeedParser" because you get directly a ImportError if the symbol is missing. And it's already faster to get FeedParser instead of email.feedparser.FeedParser in a loop (dummy micro-optimization)

done

" even I like the following change, please do it in a separated patch:
-            if type(value) is type([]):
+            if isinstance(value,list):"

not done

"I really don't like the IOMix thing:"

removed

"I vote +0 to commit the patch now (if the release manager agrees), and +1 if all of my remarks are fixed."

should be close to +0.8 now ;-)

----------
Added file: http://bugs.python.org/file20402/cgi_32.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4953>
_______________________________________

From report at bugs.python.org  Fri Jan 14 09:25:21 2011
From: report at bugs.python.org (Pierre Quentel)
Date: Fri, 14 Jan 2011 08:25:21 +0000
Subject: [issue4953] cgi module cannot handle POST with multipart/form-data
	in	3.x
In-Reply-To: <1232010166.79.0.972664060868.issue4953@psf.upfronthosting.co.za>
Message-ID: <1294993521.17.0.164677528222.issue4953@psf.upfronthosting.co.za>


Changes by Pierre Quentel <pierre.quentel at gmail.com>:


Removed file: http://bugs.python.org/file20387/cgi_32.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4953>
_______________________________________

From report at bugs.python.org  Fri Jan 14 09:26:09 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Fri, 14 Jan 2011 08:26:09 +0000
Subject: [issue10902] Doc type: "run_*" instead of "run*" on
	http://docs.python.org/library/pdb.html
In-Reply-To: <1294985047.82.0.945168102626.issue10902@psf.upfronthosting.co.za>
Message-ID: <1294993569.31.0.43704152575.issue10902@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

Committed to py3k r87993

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10902>
_______________________________________

From report at bugs.python.org  Fri Jan 14 09:30:24 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 14 Jan 2011 08:30:24 +0000
Subject: [issue10902] Doc type: "run_*" instead of "run*" on
	http://docs.python.org/library/pdb.html
In-Reply-To: <1294985047.82.0.945168102626.issue10902@psf.upfronthosting.co.za>
Message-ID: <1294993824.12.0.595310216315.issue10902@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Ah, true - I forgot svnmerge for 27-maint was based on the py3k branch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10902>
_______________________________________

From report at bugs.python.org  Fri Jan 14 09:40:54 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Fri, 14 Jan 2011 08:40:54 +0000
Subject: [issue10902] Doc type: "run_*" instead of "run*" on
	http://docs.python.org/library/pdb.html
In-Reply-To: <1294985047.82.0.945168102626.issue10902@psf.upfronthosting.co.za>
Message-ID: <1294994454.71.0.541390412309.issue10902@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

Georg, thanks - will keep that in mind. Here I started with 2.7 since this is what the user reported on. I plan to have it committed to all 3 branches today anyhow.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10902>
_______________________________________

From report at bugs.python.org  Fri Jan 14 09:53:17 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Fri, 14 Jan 2011 08:53:17 +0000
Subject: [issue9844] calling nonexisting function under __INSURE__
In-Reply-To: <1284358768.31.0.932745075936.issue9844@psf.upfronthosting.co.za>
Message-ID: <1294995197.65.0.525470964416.issue9844@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

Backported to release31: r87994 (with svnmerge)

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9844>
_______________________________________

From report at bugs.python.org  Fri Jan 14 09:56:03 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Fri, 14 Jan 2011 08:56:03 +0000
Subject: [issue10902] Doc type: "run_*" instead of "run*" on
	http://docs.python.org/library/pdb.html
In-Reply-To: <1294985047.82.0.945168102626.issue10902@psf.upfronthosting.co.za>
Message-ID: <1294995363.09.0.83905659896.issue10902@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

Committed to release31 in r87995 (with svnmerge)

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10902>
_______________________________________

From report at bugs.python.org  Fri Jan 14 10:20:29 2011
From: report at bugs.python.org (Matt Joiner)
Date: Fri, 14 Jan 2011 09:20:29 +0000
Subject: [issue10278] add time.wallclock() method
In-Reply-To: <1288624210.23.0.0497533122542.issue10278@psf.upfronthosting.co.za>
Message-ID: <1294996829.5.0.671439625759.issue10278@psf.upfronthosting.co.za>


Matt Joiner <anacrolix at gmail.com> added the comment:

This is sorely needed. IMO the current behaviour of time.clock works for Windows, and clock_gettime(CLOCK_MONOTONIC) on POSIX or clock_gettime(CLOCK_MONOTONIC_RAW) on Linux>=2.6.28.

There are some related discussions on StackOverflow that may contain useful ideas also:
http://stackoverflow.com/questions/1205722/how-do-i-get-monotonic-time-durations-in-python
http://stackoverflow.com/questions/4687408/retrieve-wall-time-in-python-using-the-standard-library

----------
nosy: +anacrolix

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10278>
_______________________________________

From report at bugs.python.org  Fri Jan 14 10:26:01 2011
From: report at bugs.python.org (Etienne Robillard)
Date: Fri, 14 Jan 2011 09:26:01 +0000
Subject: [issue4953] cgi module cannot handle POST with multipart/form-data
	in	3.x
In-Reply-To: <1294985291.35.0.154518389234.issue4953@psf.upfronthosting.co.za>
Message-ID: <4D301976.8080409@gthcfoundation.org>


Etienne Robillard <erob at gthcfoundation.org> added the comment:

+1

thanks for this input. I agree for the most part. However if the io
semantics in python 3 is radically different than on python 2, I could
have expected that WSGI scripts would similarly depend on a newer
type of file descriptor access using the ``sys`` module.

cheers!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4953>
_______________________________________

From report at bugs.python.org  Fri Jan 14 10:43:34 2011
From: report at bugs.python.org (arindam)
Date: Fri, 14 Jan 2011 09:43:34 +0000
Subject: [issue10903] ZipExtFile:_update_crc fails for CRC >= 0x80000000
In-Reply-To: <1294998214.06.0.837210563153.issue10903@psf.upfronthosting.co.za>
Message-ID: <1294998214.06.0.837210563153.issue10903@psf.upfronthosting.co.za>


New submission from arindam <arindampanna at gmail.com>:

File: zipfile.py
Function: _update_crc
statement: if eof and self._running_crc != self._expected_crc:

Due to comparison of long with int, "if eof and self._running_crc != self._expected_crc:" fails when _expected_crc is negative (0x80000000 or more). Type of _running_crc is long while _expected_crc is int.

How to reproduce: Unzip a zip file containing a file having CRC >= 0x80000000.

The issue is seen with 3.1 also.

----------
components: Library (Lib)
messages: 126250
nosy: arindam
priority: normal
severity: normal
status: open
title: ZipExtFile:_update_crc fails for CRC >= 0x80000000
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10903>
_______________________________________

From report at bugs.python.org  Fri Jan 14 11:04:23 2011
From: report at bugs.python.org (Glenn Linderman)
Date: Fri, 14 Jan 2011 10:04:23 +0000
Subject: [issue4953] cgi module cannot handle POST with multipart/form-data
	in	3.x
In-Reply-To: <1232010166.79.0.972664060868.issue4953@psf.upfronthosting.co.za>
Message-ID: <1294999463.0.0.388883280256.issue4953@psf.upfronthosting.co.za>


Glenn Linderman <v+python at g.nevcal.com> added the comment:

Pierre, Thank you for the new patch, with the philosophy of "it's broke, so let's produce something the committers like to get it fixed".

I see you overlooked removing the second use of O_BINARY.  Locally, I removed that also, and tested your newest patch, and it still functions great for me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4953>
_______________________________________

From report at bugs.python.org  Fri Jan 14 11:27:20 2011
From: report at bugs.python.org (Peter Kleiweg)
Date: Fri, 14 Jan 2011 10:27:20 +0000
Subject: [issue10904] PYTHONIOENCODING is not in manpage
In-Reply-To: <1295000840.3.0.0583509737047.issue10904@psf.upfronthosting.co.za>
Message-ID: <1295000840.3.0.0583509737047.issue10904@psf.upfronthosting.co.za>


New submission from Peter Kleiweg <pkleiweg at xs4all.nl>:

The environment variable PYTHONIOENCODING should be documented in de manpage

----------
assignee: docs at python
components: Documentation, IO
messages: 126252
nosy: docs at python, pebbe
priority: normal
severity: normal
status: open
title: PYTHONIOENCODING is not in manpage
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/issue10904>
_______________________________________

From report at bugs.python.org  Fri Jan 14 11:48:20 2011
From: report at bugs.python.org (Pierre Quentel)
Date: Fri, 14 Jan 2011 10:48:20 +0000
Subject: [issue4953] cgi module cannot handle POST with multipart/form-data
	in	3.x
In-Reply-To: <1232010166.79.0.972664060868.issue4953@psf.upfronthosting.co.za>
Message-ID: <1295002100.42.0.10354275795.issue4953@psf.upfronthosting.co.za>


Pierre Quentel <pierre.quentel at gmail.com> added the comment:

Glenn, you read my mind ;-)

Thanks for mentioning the O_BINARY thing. New (last !) patch attached

----------
Added file: http://bugs.python.org/file20403/cgi_32.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4953>
_______________________________________

From report at bugs.python.org  Fri Jan 14 11:48:29 2011
From: report at bugs.python.org (Pierre Quentel)
Date: Fri, 14 Jan 2011 10:48:29 +0000
Subject: [issue4953] cgi module cannot handle POST with multipart/form-data
	in	3.x
In-Reply-To: <1232010166.79.0.972664060868.issue4953@psf.upfronthosting.co.za>
Message-ID: <1295002109.01.0.389920623333.issue4953@psf.upfronthosting.co.za>


Changes by Pierre Quentel <pierre.quentel at gmail.com>:


Removed file: http://bugs.python.org/file20402/cgi_32.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4953>
_______________________________________

From report at bugs.python.org  Fri Jan 14 13:03:48 2011
From: report at bugs.python.org (Zhigang Wang)
Date: Fri, 14 Jan 2011 12:03:48 +0000
Subject: [issue10905] zipfile: fix arcname with leading '///' or '..'
In-Reply-To: <1295006628.53.0.290414123413.issue10905@psf.upfronthosting.co.za>
Message-ID: <1295006628.53.0.290414123413.issue10905@psf.upfronthosting.co.za>


New submission from Zhigang Wang <w1z2g3 at gmail.com>:

We only support arcname with one leading '/', but not more. This patch fixes it.

We don't support arcname with '..' well. The default behavior of unzip and 7z is to ignore all '..'. This patch does the same.

Also updated the doc. If there are other security related issues exist, we should revise the doc.

Please review.

----------
components: Library (Lib)
files: python-zipfile-fix-arcname.patch
keywords: patch
messages: 126254
nosy: zhigang
priority: normal
severity: normal
status: open
title: zipfile: fix arcname with leading '///' or '..'
type: security
versions: Python 3.3
Added file: http://bugs.python.org/file20404/python-zipfile-fix-arcname.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10905>
_______________________________________

From report at bugs.python.org  Fri Jan 14 13:20:31 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 14 Jan 2011 12:20:31 +0000
Subject: [issue10905] zipfile: fix arcname with leading '///' or '..'
In-Reply-To: <1295006628.53.0.290414123413.issue10905@psf.upfronthosting.co.za>
Message-ID: <1295007631.39.0.463885084104.issue10905@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

What happens when the archive contains both 'foo' and '../foo'? They seem to be extracted at the same place.

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10905>
_______________________________________

From report at bugs.python.org  Fri Jan 14 14:12:28 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 14 Jan 2011 13:12:28 +0000
Subject: [issue4953] cgi module cannot handle POST with multipart/form-data
	in	3.x
In-Reply-To: <1232010166.79.0.972664060868.issue4953@psf.upfronthosting.co.za>
Message-ID: <1295010748.88.0.100398277605.issue4953@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

r87996+r87997 adds encoding and errors argument to parse_qs() and parse_qsl() of urllib.parse. It is needed to decoded correctly %XX syntax in cgi.

r87998 is the patch on the cgi module.

Changes with cgi_32.patch:

 * Use TextIOWrapper instead of TextIOBase, because TextIOBase has no buffer
   attribute
 * typo in a docstring: "it must must" => "must"
 * (docstring) default: sys.stdin => default: sys.stdin.buffer
 * PEP 8: hasattr(a,b) => hasattr(a, b) (same for isinstance) and
   "encoding = 'utf-8'" => "encoding='utf-8'" (in the argument list)
 * "xxx.decode(...) # str": remove useless # str comment. decode() always give
   unicode in Python 3 (same change for ".encode() # bytes")
 * Rename "next" variables to "next_boundary" because next is a builtin
   function in Python 3 (unrelated change).
 * FieldStorage.innerboundary and FieldStorage.outerboundary are bytes objects:
   encode innerboundary in the constructor, and raise an error if outerboundary
   is not a bytes object
 * Rename _use_bytes to _binary_file
 * isinstance(bytes) test: write the type, not the value, in the error message
 * Replace line[:2] == b'--' by line.startswith(b'--'), and then replace
   line.strip() by line.rstrip()
 * test_fieldstorage_multipart() uses ASCII (and specifiy the encoding to FieldStorage)
 * add FieldStorage.errors attribute: pass it to parse_qsl()
 * add errors attribute to FieldStorage: same default value than urllib.parse.unquote(): 'replace'
 * parse(): pass encoding argument to parse_qs()
 * FieldStorage: pass encoding and errors arguments to parse_qsl()

Because the patch on TextIOBase, it patched the docstring:
---
        fp              : file pointer; default: sys.stdin.buffer
            (not used when the request method is GET)
            Can be :
            1. an instance of (a subclass of) TextIOWrapper, in this case it
            must provide an attribute "buffer" = the binary layer that returns
            bytes from its read() method, and preferably an attribute
            "encoding" (defaults to latin-1)
            2. an object whose read() and readline() methods return bytes
---
becomes
---
        fp              : file pointer; default: sys.stdin.buffer
            (not used when the request method is GET)
            Can be :
            1. a TextIOWrapper object
            2. an object whose read() and readline() methods return bytes
---

Replace "type(value) is type([])" is done in another commit: r87999.

I consider that the work on this issue is done, and so I close it. If I am wrong, explain why and repoen the issue.

Please test the cgi as much as possible before Python 3.2 final: reopen the issue if it doesn't work.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4953>
_______________________________________

From report at bugs.python.org  Fri Jan 14 14:14:11 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 14 Jan 2011 13:14:11 +0000
Subject: [issue4953] cgi module cannot handle POST with multipart/form-data
	in	3.x
In-Reply-To: <1232010166.79.0.972664060868.issue4953@psf.upfronthosting.co.za>
Message-ID: <1295010851.73.0.259562459784.issue4953@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Oh, I forgot to credit the author(s): who wrote the patch?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4953>
_______________________________________

From report at bugs.python.org  Fri Jan 14 14:20:52 2011
From: report at bugs.python.org (Zhigang Wang)
Date: Fri, 14 Jan 2011 13:20:52 +0000
Subject: [issue10905] zipfile: fix arcname with leading '///' or '..'
In-Reply-To: <1295006628.53.0.290414123413.issue10905@psf.upfronthosting.co.za>
Message-ID: <1295011252.06.0.77492197672.issue10905@psf.upfronthosting.co.za>


Zhigang Wang <w1z2g3 at gmail.com> added the comment:

$ unzip -l t.zip 
Archive:  t.zip
  Length      Date    Time    Name
---------  ---------- -----   ----
        3  01-14-2011 21:11   ../foo
        3  01-14-2011 21:11   foo
---------                     -------
        6                     2 files
[zhigang at localhost tmp]$ unzip -d aa t.zip
Archive:  t.zip
warning:  skipped "../" path component(s) in ../foo
 extracting: aa/foo                  
replace aa/foo? [y]es, [n]o, [A]ll, [N]one, [r]ename: A
 extracting: aa/foo                  


$ 7za x -oaa t.zip 

7-Zip (A) 9.13 beta  Copyright (c) 1999-2010 Igor Pavlov  2010-04-15
p7zip Version 9.13 (locale=en_US.UTF-8,Utf16=on,HugeFiles=on,1 CPU)

Processing archive: t.zip

file aa/foo
already exists. Overwrite with 
../foo?
(Y)es / (N)o / (A)lways / (S)kip all / A(u)to rename all / (Q)uit? A
Extracting  ../foo
Extracting  foo

Everything is Ok

Files: 2
Size:       6
Compressed: 198

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10905>
_______________________________________

From report at bugs.python.org  Fri Jan 14 14:29:50 2011
From: report at bugs.python.org (Zhigang Wang)
Date: Fri, 14 Jan 2011 13:29:50 +0000
Subject: [issue10905] zipfile: fix arcname with leading '///' or '..'
In-Reply-To: <1295006628.53.0.290414123413.issue10905@psf.upfronthosting.co.za>
Message-ID: <1295011790.7.0.9746192082.issue10905@psf.upfronthosting.co.za>


Zhigang Wang <w1z2g3 at gmail.com> added the comment:

Yes, in zipfile, we just overwrite it. Actually, ZipFile.extract() overwrite existing files already. If we want it more powerful, we can add a 'overwrite' parameter. But turning zipfile a full featured zip/unzip tool needs much more extra work...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10905>
_______________________________________

From report at bugs.python.org  Fri Jan 14 14:39:38 2011
From: report at bugs.python.org (Andre Berg)
Date: Fri, 14 Jan 2011 13:39:38 +0000
Subject: [issue3978] ZipFileExt.read() can be incredibly slow; patch included
In-Reply-To: <1222457019.27.0.267576306603.issue3978@psf.upfronthosting.co.za>
Message-ID: <1295012378.79.0.592168079311.issue3978@psf.upfronthosting.co.za>


Andre Berg <andre.berg at email.de> added the comment:

If I may chime in, as I don't know where else to put this.

I am still seeing the same performance as the OP when I use extractall() with a password protected ZIP of size 287 MB (containing one compressed movie file of size 297 MB).

The total running time for extractall.py was
real    35m24.448s
user    34m52.423s
sys    0m1.448s

For a bash script using unzip -P the running time on the same file was

real	0m19.026s
user	0m8.359s
sys	0m0.414s

extractall.py loops over the contents of a directory using os.walk, identifies zip files by file extension and extracts a certain portion of the filename as password using a regex. If I leave the ZipFile.extractall part out of it and run it it takes 0.15 s.

This is with Python 2.7.1 and Python 3.1.2 on Mac OS X 10.6.4 on an 8-core MacPro with 16 GB of RAM. The file is read from an attached USB drive. Maybe that makes a difference. I wish I could tell you more.

This is just for the record. I don't expect this to be fixed.

----------
nosy: +andreb

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3978>
_______________________________________

From report at bugs.python.org  Fri Jan 14 14:48:09 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 14 Jan 2011 13:48:09 +0000
Subject: [issue3978] ZipFileExt.read() can be incredibly slow; patch included
In-Reply-To: <1295012378.79.0.592168079311.issue3978@psf.upfronthosting.co.za>
Message-ID: <1295012881.3699.0.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> I am still seeing the same performance as the OP when I use
> extractall() with a password protected ZIP of size 287 MB (containing
> one compressed movie file of size 297 MB).

Please try with a non-password protected file.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3978>
_______________________________________

From report at bugs.python.org  Fri Jan 14 15:07:56 2011
From: report at bugs.python.org (Pierre Quentel)
Date: Fri, 14 Jan 2011 14:07:56 +0000
Subject: [issue4953] cgi module cannot handle POST with multipart/form-data in
	3.x
In-Reply-To: <1295010851.73.0.259562459784.issue4953@psf.upfronthosting.co.za>
Message-ID: <AANLkTi=a7LBv3wW9+vROXBriX6rGV36PK8gxvVBaY=As@mail.gmail.com>


Pierre Quentel <pierre.quentel at gmail.com> added the comment:

Thanks a lot Victor !

I wrote the patch : Pierre Quentel (pierre.quentel at gmail.com) with many
inputs by Glenn Linderman

2011/1/14 STINNER Victor <report at bugs.python.org>

>
> STINNER Victor <victor.stinner at haypocalc.com> added the comment:
>
> Oh, I forgot to credit the author(s): who wrote the patch?
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue4953>
> _______________________________________
>

----------
title: cgi module cannot handle POST with multipart/form-data in	3.x -> cgi module cannot handle POST with multipart/form-data in 3.x
Added file: http://bugs.python.org/file20405/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4953>
_______________________________________
-------------- next part --------------
Thanks a lot Victor !<br><br>I wrote the patch : Pierre Quentel (<a href="mailto:pierre.quentel at gmail.com">pierre.quentel at gmail.com</a>) with many inputs by Glenn Linderman<br><br><div class="gmail_quote">2011/1/14 STINNER Victor <span dir="ltr">&lt;<a href="mailto:report at bugs.python.org">report at bugs.python.org</a>&gt;</span><br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div class="im"><br>
STINNER Victor &lt;<a href="mailto:victor.stinner at haypocalc.com">victor.stinner at haypocalc.com</a>&gt; added the comment:<br>
<br>
</div>Oh, I forgot to credit the author(s): who wrote the patch?<br>
<br>
----------<br>
<div><div></div><div class="h5"><br>
_______________________________________<br>
Python tracker &lt;<a href="mailto:report at bugs.python.org">report at bugs.python.org</a>&gt;<br>
&lt;<a href="http://bugs.python.org/issue4953" target="_blank">http://bugs.python.org/issue4953</a>&gt;<br>
_______________________________________<br>
</div></div></blockquote></div><br><div class="ogc-tooltip-class" id="ogc_tooltip_id"></div>

From report at bugs.python.org  Fri Jan 14 15:14:36 2011
From: report at bugs.python.org (anatoly techtonik)
Date: Fri, 14 Jan 2011 14:14:36 +0000
Subject: [issue10906] wsgiref should mention that CGI scripts usually expect
	HTTPS variable to be set to 'on'
In-Reply-To: <1295014476.87.0.519263477862.issue10906@psf.upfronthosting.co.za>
Message-ID: <1295014476.87.0.519263477862.issue10906@psf.upfronthosting.co.za>


New submission from anatoly techtonik <techtonik at gmail.com>:

http://docs.python.org/library/wsgiref.html#wsgiref.util.guess_scheme

The documentation says servers typically set HTTPS variable to a value of ?1? or ?yes?, when a request is received via SSL, but CGI tutorials, IIS and Apache set this to ?on?.

Misleading documentation may be the reason of the bug with mod_wsgi that changes Apache's variable from ?on? to ?1? - https://issues.apache.org/bugzilla/show_bug.cgi?id=50581

The documentation should at least stress that ?on? is the mainstream value for this variable. It will help to mention at least one popular server that returns ?1?.

----------
assignee: docs at python
components: Documentation
messages: 126263
nosy: docs at python, techtonik
priority: normal
severity: normal
status: open
title: wsgiref should mention that CGI scripts usually expect HTTPS variable to be set to 'on'
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10906>
_______________________________________

From report at bugs.python.org  Fri Jan 14 15:15:23 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 14 Jan 2011 14:15:23 +0000
Subject: [issue4953] cgi module cannot handle POST with multipart/form-data in
	3.x
In-Reply-To: <1232010166.79.0.972664060868.issue4953@psf.upfronthosting.co.za>
Message-ID: <1295014523.99.0.0357527729431.issue4953@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

TODO: Add more tests to test_cgi. What is the latest patch for test_cgi?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4953>
_______________________________________

From report at bugs.python.org  Fri Jan 14 15:35:29 2011
From: report at bugs.python.org (Dev Player)
Date: Fri, 14 Jan 2011 14:35:29 +0000
Subject: [issue8232] webbrowser.open incomplete on Windows
In-Reply-To: <1269541962.46.0.762619344208.issue8232@psf.upfronthosting.co.za>
Message-ID: <1295015729.03.0.253891691461.issue8232@psf.upfronthosting.co.za>


Dev Player <devplayer at gmail.com> added the comment:

Don't forget to check if the MS Internet Explorer's advanced option to open new URLS in a seperate windows effects this.  Users can have this advanced setting set differently on different computers(or even accounts). Also different browser versions call that option by different names. And I think there may even be a way to turn off tabs altogether, so check that too.

----------
nosy: +devplayer

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8232>
_______________________________________

From report at bugs.python.org  Fri Jan 14 15:39:23 2011
From: report at bugs.python.org (Pierre Quentel)
Date: Fri, 14 Jan 2011 14:39:23 +0000
Subject: [issue4953] cgi module cannot handle POST with multipart/form-data in
	3.x
In-Reply-To: <1232010166.79.0.972664060868.issue4953@psf.upfronthosting.co.za>
Message-ID: <1295015963.19.0.741425434504.issue4953@psf.upfronthosting.co.za>


Changes by Pierre Quentel <pierre.quentel at gmail.com>:


Removed file: http://bugs.python.org/file20405/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4953>
_______________________________________

From report at bugs.python.org  Fri Jan 14 15:41:22 2011
From: report at bugs.python.org (Pierre Quentel)
Date: Fri, 14 Jan 2011 14:41:22 +0000
Subject: [issue4953] cgi module cannot handle POST with multipart/form-data in
	3.x
In-Reply-To: <1232010166.79.0.972664060868.issue4953@psf.upfronthosting.co.za>
Message-ID: <1295016082.76.0.469962363369.issue4953@psf.upfronthosting.co.za>


Pierre Quentel <pierre.quentel at gmail.com> added the comment:

My latest patch for test_cgi is in cgi_32.patch

I will try to add more tests later

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4953>
_______________________________________

From report at bugs.python.org  Fri Jan 14 15:58:03 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 14 Jan 2011 14:58:03 +0000
Subject: [issue4953] cgi module cannot handle POST with multipart/form-data in
	3.x
In-Reply-To: <1232010166.79.0.972664060868.issue4953@psf.upfronthosting.co.za>
Message-ID: <1295017083.1.0.262650062511.issue4953@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

haypo>> What is the latest patch for test_cgi?
quentel> My latest patch for test_cgi is in cgi_32.patch

Ok, but cgi_32.patch doesn't add any test. I only adapt existing tests for your other changes.

I remove cgi_32.patch because it was commited.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4953>
_______________________________________

From report at bugs.python.org  Fri Jan 14 15:58:10 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 14 Jan 2011 14:58:10 +0000
Subject: [issue4953] cgi module cannot handle POST with multipart/form-data in
	3.x
In-Reply-To: <1232010166.79.0.972664060868.issue4953@psf.upfronthosting.co.za>
Message-ID: <1295017090.1.0.507580070729.issue4953@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Removed file: http://bugs.python.org/file20403/cgi_32.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4953>
_______________________________________

From report at bugs.python.org  Fri Jan 14 16:00:11 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 14 Jan 2011 15:00:11 +0000
Subject: [issue4953] cgi module cannot handle POST with multipart/form-data in
	3.x
In-Reply-To: <1232010166.79.0.972664060868.issue4953@psf.upfronthosting.co.za>
Message-ID: <1295017211.62.0.185596439322.issue4953@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Remove cgi_plus_tests.diff: it looks to be an old version of cgi_32.patch.

@r.david.murray: Did you write cgi_plus_tests.diff, or is it based on the work on Pierre Quentel?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4953>
_______________________________________

From report at bugs.python.org  Fri Jan 14 16:01:34 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 14 Jan 2011 15:01:34 +0000
Subject: [issue4953] cgi module cannot handle POST with multipart/form-data in
	3.x
In-Reply-To: <1232010166.79.0.972664060868.issue4953@psf.upfronthosting.co.za>
Message-ID: <1295017294.72.0.438734081642.issue4953@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Removed file: http://bugs.python.org/file20269/cgi_plus_tests.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4953>
_______________________________________

From report at bugs.python.org  Fri Jan 14 16:01:46 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 14 Jan 2011 15:01:46 +0000
Subject: [issue4953] cgi module cannot handle POST with multipart/form-data in
	3.x
In-Reply-To: <1232010166.79.0.972664060868.issue4953@psf.upfronthosting.co.za>
Message-ID: <1295017306.33.0.897134779213.issue4953@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Removed file: http://bugs.python.org/file12750/tmpav1vve.html

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4953>
_______________________________________

From report at bugs.python.org  Fri Jan 14 16:01:53 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 14 Jan 2011 15:01:53 +0000
Subject: [issue4953] cgi module cannot handle POST with multipart/form-data in
	3.x
In-Reply-To: <1232010166.79.0.972664060868.issue4953@psf.upfronthosting.co.za>
Message-ID: <1295017313.03.0.467352631057.issue4953@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Removed file: http://bugs.python.org/file12751/tmpy44zj7.html

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4953>
_______________________________________

From report at bugs.python.org  Fri Jan 14 16:03:01 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 14 Jan 2011 15:03:01 +0000
Subject: [issue4953] cgi module cannot handle POST with multipart/form-data in
	3.x
In-Reply-To: <1232010166.79.0.972664060868.issue4953@psf.upfronthosting.co.za>
Message-ID: <1295017381.73.0.188176015449.issue4953@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Remove tmpy44zj7.html and tmpav1vve.html: a similar file is included in full_source_and_error.zip.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4953>
_______________________________________

From report at bugs.python.org  Fri Jan 14 16:11:51 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 14 Jan 2011 15:11:51 +0000
Subject: [issue4953] cgi module cannot handle POST with multipart/form-data in
	3.x
In-Reply-To: <1232010166.79.0.972664060868.issue4953@psf.upfronthosting.co.za>
Message-ID: <1295017911.87.0.514088741143.issue4953@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/issue4953>
_______________________________________

From report at bugs.python.org  Fri Jan 14 16:52:42 2011
From: report at bugs.python.org (Ned Deily)
Date: Fri, 14 Jan 2011 15:52:42 +0000
Subject: [issue10907] OS X installer: warn users of buggy Tcl/Tk in OS X 10.6
In-Reply-To: <1295020361.6.0.15646249296.issue10907@psf.upfronthosting.co.za>
Message-ID: <1295020361.6.0.15646249296.issue10907@psf.upfronthosting.co.za>


New submission from Ned Deily <nad at acm.org>:

With 2.7 and now 3.2, we have been supplying two variants of OS X installers: the traditional 32-bit only version dynamically linked with Tk 8.4, the only version available across all supported OS X releases; and a new 64-bit/32-bit version dynamically linked with Tk 8.5 for 10.6 only.  The Tcl/Tk 8.5 version supplied by Apple in OS X 10.6 has proven to work badly with IDLE and other Tkinter applications; issues reported include hangs when pasting text or opening new editor windows or after syntax errors.  Until recently, it was the only standard version of non-X11 Tcl/Tk that was supported for both 64-bit and 32-bit executables.  Recently, ActiveState has released a newer version of Tk 8.5 that is ABI-compatible with the Apple 10.6 one but which behaves much better with IDLE and Tkinter, with none of the previously reproducible hangs detected so far.  Since the Python OS X installer depends on an external source for Tk, either the default Apple-suppled one or, now, an optional 3rd-party install like those from ActiveState, it is important that users are aware that there are options and that they can avoid bad experiences with IDLE crashing, etc.  Because we are dependent on dynamic libraries, it is possible that the situation could change over the lifetime of the Python release, i.e. the Apple could update Tk in 10.6 or new problems could be found.  So the solution here should allow for that.

The attached patches take the following approach:

1. Define a canonical URL on the Python web site for a page that provides the latest status information on supported and recommended Tcl/Tk versions for all recent Python OS X installers.  The URL chosen is:  http://www.python.org/download/mac/tcltk/

2. Add to the OS X Installer Welcome message and ReadMe files prominent references to the new web page.

3. Add an OS X only check in IDLE initialization to see if tkinter is running with the known buggy Apple version.  If so, output a warning message via a print statement executed in the IDLE shell window:

   WARNING: The version of Tcl/Tk (8.5.7) in use may be unstable.
   Visit http://www.python.org/download/mac/tcltk/ for current information.

Since it is possible the user will not be able to install ActiveTcl for some reason (licensing issues, perhaps), issuing the warning through the existing shell window will be much less obtrusive than opening an error window that would need to be dismissed every time IDLE is invoked.

4. Populate and maintain the new web page with the relevant information about OS X installer versions and Tcl/Tk versions.  Make it easy for the user to find do the right thing.  Attached is a first draft of the web page to show the basic approach.

5. Add and maintain references on the main Download page and the release-specific pages to the new web page.  Those changes are also included in the web site patch.

6. Document and publish workarounds for 2.7.1 64-bit installer users.

7. Backport the 3.2 fixes for 2.7.2.

----------
assignee: ned.deily
components: Build, IDLE, Macintosh
files: issue_10_6_tk.patch
keywords: patch
messages: 126270
nosy: benjamin.peterson, georg.brandl, ned.deily
priority: release blocker
severity: normal
status: open
title: OS X installer: warn users of buggy Tcl/Tk in OS X 10.6
versions: Python 2.7, Python 3.2
Added file: http://bugs.python.org/file20406/issue_10_6_tk.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10907>
_______________________________________

From report at bugs.python.org  Fri Jan 14 16:52:56 2011
From: report at bugs.python.org (SilentGhost)
Date: Fri, 14 Jan 2011 15:52:56 +0000
Subject: [issue10908] Improvements to trace._Ignore
In-Reply-To: <1295020376.03.0.967767300509.issue10908@psf.upfronthosting.co.za>
Message-ID: <1295020376.03.0.967767300509.issue10908@psf.upfronthosting.co.za>


New submission from SilentGhost <ghost.adh at gmail.com>:

In the course of fixing #10896 I've noticed a few things:

 1. --ignore-dir='$prefix' doesn't work on windows. I don't know if it has to, there is no information in docs regarding it at all. It does work on Unix.
 2. The way module check is done is inefficient.
 3. I'm not sure if filename could ever get the value of None in _Ignore.names (there is check for that though)
 4. it's not clear why _Ignore initialised with default values of None, that path was never exercised and while I've added a test for it, I'm actually not sure if it's needed.
 5. general clean up was needed for the code dealing with ignoring.

Attached is the patch.
 The only change, that I consider beneficial, is that the ignored dir doesn't have actually be a directory.

----------
components: Library (Lib)
files: trace_ignore.diff
keywords: easy, patch
messages: 126271
nosy: SilentGhost, belopolsky, vrutsky
priority: normal
severity: normal
status: open
title: Improvements to trace._Ignore
versions: Python 2.7, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file20407/trace_ignore.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10908>
_______________________________________

From report at bugs.python.org  Fri Jan 14 16:55:22 2011
From: report at bugs.python.org (SilentGhost)
Date: Fri, 14 Jan 2011 15:55:22 +0000
Subject: [issue10896] trace module compares directories as strings
	(--ignore-dir)
In-Reply-To: <1294843489.43.0.983792093108.issue10896@psf.upfronthosting.co.za>
Message-ID: <1295020522.26.0.766297201444.issue10896@psf.upfronthosting.co.za>


SilentGhost <ghost.adh at gmail.com> added the comment:

#10908 is dealing with this and other issue re ignored dirs.

----------
status: open -> closed
superseder:  -> Improvements to trace._Ignore

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10896>
_______________________________________

From report at bugs.python.org  Fri Jan 14 16:57:16 2011
From: report at bugs.python.org (Ned Deily)
Date: Fri, 14 Jan 2011 15:57:16 +0000
Subject: [issue10907] OS X installer: warn users of buggy Tcl/Tk in OS X 10.6
In-Reply-To: <1295020361.6.0.15646249296.issue10907@psf.upfronthosting.co.za>
Message-ID: <1295020636.9.0.790136400199.issue10907@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

(I'll plan to commit to py3k later today pending any review comments and submit expanded pydotorg changes.)

----------
nosy: +michael.foord, ronaldoussoren
stage:  -> commit review
Added file: http://bugs.python.org/file20408/pydotorg_10_6_tk.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10907>
_______________________________________

From report at bugs.python.org  Fri Jan 14 17:34:40 2011
From: report at bugs.python.org (Brian Curtin)
Date: Fri, 14 Jan 2011 16:34:40 +0000
Subject: [issue10278] add time.wallclock() method
In-Reply-To: <1288624210.23.0.0497533122542.issue10278@psf.upfronthosting.co.za>
Message-ID: <1295022880.89.0.0780117098464.issue10278@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

> In Windows, it should probably use GetTickCount64 if available,
> otherwise GetTickCount with logic to handle wrapping.  I think
> QueryPerformanceCounter is problematic as a general-purpose timer:
> depending on the hardware and Windows version, it can be offset
> differently across CPUs, and may not be reliable on some processors.  It
> may be fixed in Vista or Win7, I'm not sure; if so it's much higher
> resolution than GTC.

I don't have a ton of experience with this, but by creating a synchronization point based on when the system clock changes, QueryPerformanceCounter can be pretty accurate and as you already stated, and higher resolution than most other solutions. http://msdn.microsoft.com/en-us/magazine/cc163996.aspx is where I got the idea and most of the implementation from. I'm essentially using the code from Figure 2 in a C extension right now to do something similar to threading.Timer in a performance testing tool.

----------
nosy: +brian.curtin

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10278>
_______________________________________

From report at bugs.python.org  Fri Jan 14 17:39:33 2011
From: report at bugs.python.org (Andre Berg)
Date: Fri, 14 Jan 2011 16:39:33 +0000
Subject: [issue3978] ZipFileExt.read() can be incredibly slow; patch included
In-Reply-To: <1222457019.27.0.267576306603.issue3978@psf.upfronthosting.co.za>
Message-ID: <1295023173.49.0.276344631388.issue3978@psf.upfronthosting.co.za>


Andre Berg <andre.berg at email.de> added the comment:

"Decryption is extremely slow as it is implemented in native Python rather than C"

Right, of course, I missed this when reading the docs.
I have a habit of jumping straight to the point.

As I was asked to try it with a non-password protected zip file here's the numbers for comparison.

Same file, re-zipped without encryption, extractall.py now finishes in  16 s.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3978>
_______________________________________

From report at bugs.python.org  Fri Jan 14 17:46:35 2011
From: report at bugs.python.org (David Beazley)
Date: Fri, 14 Jan 2011 16:46:35 +0000
Subject: [issue10907] OS X installer: warn users of buggy Tcl/Tk in OS X 10.6
In-Reply-To: <1295020361.6.0.15646249296.issue10907@psf.upfronthosting.co.za>
Message-ID: <1295023595.33.0.0752988464678.issue10907@psf.upfronthosting.co.za>


David Beazley <dave at dabeaz.com> added the comment:

A comment from the training world:  The instability of IDLE on the Mac makes teaching introductory Python courses a nightmare at the moment.   Sure, one might argue that students should install an alternative editor, but then you usually end up with two problems instead of one.  It would be great if IDLE just "worked" out of the box for starting out.

Glad to see someone looking at this.

----------
nosy: +dabeaz

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10907>
_______________________________________

From report at bugs.python.org  Fri Jan 14 17:50:55 2011
From: report at bugs.python.org (Michael Foord)
Date: Fri, 14 Jan 2011 16:50:55 +0000
Subject: [issue10907] OS X installer: warn users of buggy Tcl/Tk in OS X 10.6
In-Reply-To: <1295020361.6.0.15646249296.issue10907@psf.upfronthosting.co.za>
Message-ID: <1295023855.26.0.627245016632.issue10907@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

This looks good Ned. My main concern is that we make it clear from the *Download* page that users who want IDLE to "just work" (even on 10.6) they should install the 32 bit version.

Noting that Activestate Tcl/Tk 8.5 is a *requirement* for Tkinter/IDLE with the 64bit (10.6) build sounds wise. Just putting it in the installer README isn't enough as it is too late. Obviously fine to put it in the README as *well*.

Having a page linked to from the download page with up to date info on Mac OS X 10.6 is good. You'll probably want website commit rights to maintain this Ned. You can get it by emailing the pydotorg mailing list and preferably should also join pydotorg-www. :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10907>
_______________________________________

From report at bugs.python.org  Fri Jan 14 18:06:48 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 14 Jan 2011 17:06:48 +0000
Subject: [issue10903] ZipExtFile:_update_crc fails for CRC >= 0x80000000
In-Reply-To: <1294998214.06.0.837210563153.issue10903@psf.upfronthosting.co.za>
Message-ID: <1295024808.1.0.51868254314.issue10903@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Can you provide such a file? What system are you testing on?

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10903>
_______________________________________

From report at bugs.python.org  Fri Jan 14 18:21:25 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 14 Jan 2011 17:21:25 +0000
Subject: [issue10854] Output DLL name in error message of ImportError when DLL
	is missing
In-Reply-To: <1294415325.09.0.315523226252.issue10854@psf.upfronthosting.co.za>
Message-ID: <1295025685.73.0.937452530809.issue10854@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

As Martin says, we aren't inclined to implement or maintain the equivalent of depends.exe in order to provide a slightly better error message.

If anyone wants to reopen this issue, provide a patch. Otherwise devs are just going to close it again.

Optionally, campaign for a fix on python-list and see if you can persuade someone *else* to provide a patch.

You could even go to the source of the problem and ask *Microsoft* to provide a better error message.

----------
nosy: +ncoghlan
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10854>
_______________________________________

From report at bugs.python.org  Fri Jan 14 18:24:59 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 14 Jan 2011 17:24:59 +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: <1295025899.71.0.402698496767.issue10854@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Sorry, I missed that the request had changed to just the .pyd name. That at least is useful, since you then know where to start with depends.exe. It should be fairly straightforward to implement as well.

Adjusted issue title accordingly.

----------
resolution: wont fix -> 
status: closed -> open
title: Output DLL name in error message of ImportError when DLL is missing -> Output .pyd name in error message of ImportError when DLL load fails

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10854>
_______________________________________

From report at bugs.python.org  Fri Jan 14 18:37:27 2011
From: report at bugs.python.org (Scott M)
Date: Fri, 14 Jan 2011 17:37:27 +0000
Subject: [issue10909] thread hang, possibly related to print
In-Reply-To: <1295026647.31.0.671636636712.issue10909@psf.upfronthosting.co.za>
Message-ID: <1295026647.31.0.671636636712.issue10909@psf.upfronthosting.co.za>


New submission from Scott M <scott.mayo at comcast.net>:

New to Python; be gentle if I've simply missed something. i'M running on Windows XP, using a recently downloaded 2.7.1. I'm running by hitting F5 in IDLE.

The attached .py creates 2 threads, one which updates a Tkinter label 10 times a second forever, and one which sleeps for a second and then thrashes the CPU for ~4 seconds, forever. I wrote this to see how Python dealt with CPU-pig threads, and was pleased to see both threads got to run in a decently interleaved way, even in the face of a tight loop.

But at a random point, one of the threads (which one varies) stops running. The other continues fine. The problem manifests in less then 5 minutes (often less than 1).

At least once, but not ever time, the thread that stopped gave a traceback:

Exception in thread Thread-1:
Traceback (most recent call last):
  File "D:\Python27\lib\threading.py", line 530, in __bootstrap_inner
    self.run()
  File "F:\Python27\MyProjects\e.py", line 24, in run
    print "evil!"              #<--- point 1
  File "D:\Python27\lib\idlelib\rpc.py", line 595, in __call__
    value = self.sockio.remotecall(self.oid, self.name, args, kwargs)
  File "D:\Python27\lib\idlelib\rpc.py", line 211, in remotecall
    return self.asyncreturn(seq)
  File "D:\Python27\lib\idlelib\rpc.py", line 240, in asyncreturn
    response = self.getresponse(seq, wait=0.05)
  File "D:\Python27\lib\idlelib\rpc.py", line 280, in getresponse
    response = self._getresponse(myseq, wait)
  File "D:\Python27\lib\idlelib\rpc.py", line 305, in _getresponse
    cvar = self.cvars[myseq]
KeyError: 8680

BUT in some cases there wasn't a traceback (the last time there wasn't, it was BThread that had stopped running; the label was no longer updating.)

If you comment out the print at point 2, or point 1, it seems to work fine, at least for as long as I cared to watch it.

Also, I've noticed that if I close the app's window, that at least one thread keeps running and writing to the Python shell console. (One generally dies because the Tkinter label has gone away). They are both marked as daemonic; shouldn't they stop more or less instantly?

----------
components: Interpreter Core
files: e.py
messages: 126282
nosy: PythonInTheGrass
priority: normal
severity: normal
status: open
title: thread hang, possibly related to print
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file20409/e.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10909>
_______________________________________

From report at bugs.python.org  Fri Jan 14 18:45:41 2011
From: report at bugs.python.org (anatoly techtonik)
Date: Fri, 14 Jan 2011 17:45:41 +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: <1295027141.3.0.988168835284.issue10854@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

Great. Thanks!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10854>
_______________________________________

From report at bugs.python.org  Fri Jan 14 19:37:30 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 14 Jan 2011 18:37:30 +0000
Subject: [issue10904] PYTHONIOENCODING is not in manpage
In-Reply-To: <1295000840.3.0.0583509737047.issue10904@psf.upfronthosting.co.za>
Message-ID: <1295030250.48.0.797221882548.issue10904@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

What "manpage" are you reporting?  In py3k branch,

$ groff -Tascii -man Misc/python.man
..

       PYTHONIOENCODING
              If this is set before running the interpreter, it overrides  the
              encoding  used  for stdin/stdout/stderr, in the syntax encoding-
              name:errorhandler The errorhandler part is optional and has  the
              same meaning as in str.encode. For stderr, the errorhandler
               part is ignored; the handler will always be 'backslashreplace'.
..

There is a missing period after the first sentence, but otherwise LGTM.

It is also documented in the reST manual and python -h help, 

http://docs.python.org/dev/using/cmdline.html#envvar-PYTHONIOENCODING

----------
nosy: +belopolsky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10904>
_______________________________________

From report at bugs.python.org  Fri Jan 14 19:41:41 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 14 Jan 2011 18:41:41 +0000
Subject: [issue10904] PYTHONIOENCODING is not in manpage
In-Reply-To: <1295000840.3.0.0583509737047.issue10904@psf.upfronthosting.co.za>
Message-ID: <1295030501.64.0.646040559636.issue10904@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On the second thought, maybe "de manpage" is not a misspelling of "the manpage", but a reference to a German locale manpage?  I don't think python.org releases include manpage translations.  You may need to report it to your system vendor.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10904>
_______________________________________

From report at bugs.python.org  Fri Jan 14 20:00:18 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 14 Jan 2011 19:00:18 +0000
Subject: [issue1602] windows console doesn't print or input Unicode
In-Reply-To: <1197453390.87.0.813702844893.issue1602@psf.upfronthosting.co.za>
Message-ID: <1295031618.27.0.766946721115.issue1602@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

http://www.python.org/dev/peps/pep-0011/ says

Name:             Win9x, WinME, NT4
    Unsupported in:   Python 2.6 (warning in 2.5 installer)
    Code removed in:  Python 2.6

Only xp+ now. email sent to webmaster at ...

Even if the best fix only applies to win7, please include it.

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1602>
_______________________________________

From report at bugs.python.org  Fri Jan 14 20:01:59 2011
From: report at bugs.python.org (Peter)
Date: Fri, 14 Jan 2011 19:01:59 +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: <1295031719.48.0.790077199691.issue9257@psf.upfronthosting.co.za>


Peter <p.j.a.cock at googlemail.com> added the comment:

This wasn't fixed in Python 3.1.3 either.

Is the trunk commit Amaury identified from py3k branch (r78942) suitable to back port to Python 3.1.x?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9257>
_______________________________________

From report at bugs.python.org  Fri Jan 14 20:06:16 2011
From: report at bugs.python.org (Brian Curtin)
Date: Fri, 14 Jan 2011 19:06:16 +0000
Subject: [issue1602] windows console doesn't print or input Unicode
In-Reply-To: <1197453390.87.0.813702844893.issue1602@psf.upfronthosting.co.za>
Message-ID: <1295031976.24.0.650450432958.issue1602@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

I think we even agreed to drop 2000, although the PEP hasn't been updated and I couldn't find the supposed email where this was said.

For implementing functionality that isn't supported on all Windows versions or architectures, you can look at PC/winreg.c for a few examples. DisableReflectionKey is a good example off the top of my head.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1602>
_______________________________________

From report at bugs.python.org  Fri Jan 14 20:11:14 2011
From: report at bugs.python.org (R. David Murray)
Date: Fri, 14 Jan 2011 19:11:14 +0000
Subject: [issue4953] cgi module cannot handle POST with multipart/form-data in
	3.x
In-Reply-To: <1232010166.79.0.972664060868.issue4953@psf.upfronthosting.co.za>
Message-ID: <1295032274.88.0.0497306315975.issue4953@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Victor: we normally leave the patch file that was committed attached to the issue for future reference.

The _plus_tests file was just the original patch plus the existing cgi tests adjusted to pass in bytes instead of strings to cgi, if I recall correctly.  Nor original code of mine in either part :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4953>
_______________________________________

From report at bugs.python.org  Fri Jan 14 20:15:39 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 14 Jan 2011 19:15:39 +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: <1295032539.68.0.176901769633.issue9257@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

r78942 is quite large unfortunately.
But just patching _elementree.c::xmlparser_setevents() should be possible.
This would at least fix the "invalid event tuple" error.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9257>
_______________________________________

From report at bugs.python.org  Fri Jan 14 20:23:29 2011
From: report at bugs.python.org (Peter Kleiweg)
Date: Fri, 14 Jan 2011 19:23:29 +0000
Subject: [issue10904] PYTHONIOENCODING is not in manpage
In-Reply-To: <1295000840.3.0.0583509737047.issue10904@psf.upfronthosting.co.za>
Message-ID: <1295033009.45.0.545947806979.issue10904@psf.upfronthosting.co.za>


Peter Kleiweg <pkleiweg at xs4all.nl> added the comment:

Ah, I see it's fixed in the latest version.

The variable PYTHONIOENCODING was present at least since Python 2.6.4, but not documented in the manpage of versions 2.6.4, 2.7 and 3.1.1.
I thought I had recent versions, but I see now versions 2.7.1 and 3.1.3, and they both have the variable in the manpage.

I'm sorry for the inconveniance.

----------
resolution:  -> out of date
status: open -> closed
versions:  -Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10904>
_______________________________________

From report at bugs.python.org  Fri Jan 14 20:39:10 2011
From: report at bugs.python.org (Glenn Linderman)
Date: Fri, 14 Jan 2011 19:39:10 +0000
Subject: [issue4953] cgi module cannot handle POST with multipart/form-data in
	3.x
In-Reply-To: <1232010166.79.0.972664060868.issue4953@psf.upfronthosting.co.za>
Message-ID: <1295033950.36.0.268359065079.issue4953@psf.upfronthosting.co.za>


Changes by Glenn Linderman <v+python at g.nevcal.com>:


----------
versions: +Python 3.2 -Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4953>
_______________________________________

From report at bugs.python.org  Fri Jan 14 20:39:37 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 14 Jan 2011 19:39:37 +0000
Subject: [issue9527] Add aware local time support to datetime module
In-Reply-To: <1281066500.35.0.441616276688.issue9527@psf.upfronthosting.co.za>
Message-ID: <1295033977.28.0.274371593604.issue9527@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Following Anatoly's review, I renamed datetime argument and a local variable, added comments and expanded docstring.  I am uploading a new patch: datetime-localtime-proto-1.diff.

Martin, I could not figure out how to add the new patch to rietveld and I don't think auto-review feature works.

----------
nosy: +loewis
Added file: http://bugs.python.org/file20410/datetime-localtime-proto-1.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9527>
_______________________________________

From report at bugs.python.org  Fri Jan 14 20:41:10 2011
From: report at bugs.python.org (Glenn Linderman)
Date: Fri, 14 Jan 2011 19:41:10 +0000
Subject: [issue4953] cgi module cannot handle POST with multipart/form-data in
	3.x
In-Reply-To: <1232010166.79.0.972664060868.issue4953@psf.upfronthosting.co.za>
Message-ID: <1295034070.88.0.462272144984.issue4953@psf.upfronthosting.co.za>


Glenn Linderman <v+python at g.nevcal.com> added the comment:

Thanks to Pierre for producing patch after patch and testing testing testing, and to Victor for committing it, as well as others that contributed in smaller ways, as I tried to.  I look forward to 3.2 rc1 so I can discard all my temporary patched copies of cgi.py

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4953>
_______________________________________

From report at bugs.python.org  Fri Jan 14 20:44:32 2011
From: report at bugs.python.org (ronnix)
Date: Fri, 14 Jan 2011 19:44:32 +0000
Subject: [issue2636] Regexp 2.7 (modifications to current re 2.2.2)
In-Reply-To: <1208260672.14.0.711874677361.issue2636@psf.upfronthosting.co.za>
Message-ID: <1295034272.55.0.435956510952.issue2636@psf.upfronthosting.co.za>


ronnix <ronan.amicel at gmail.com> added the comment:

The regex 0.1.20110106 package fails to install with Python 2.6, due to the use of 2.7 string formatting syntax in setup.py:

    print("Copying {} to {}".format(unicodedata_db_h, SRC_DIR))

This line should be changed to:

    print("Copying {0} to {1}".format(unicodedata_db_h, SRC_DIR))

Reference: http://docs.python.org/library/string.html#formatstrings

----------
nosy: +ronnix

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2636>
_______________________________________

From report at bugs.python.org  Fri Jan 14 20:47:26 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 14 Jan 2011 19:47:26 +0000
Subject: [issue9527] Add aware local time support to datetime module
	(issue9527)
In-Reply-To: <20110114172850.19175.66872@psf.upfronthosting.co.za>
Message-ID: <AANLkTi=OjYgHMBCiBGh=gXPEFU75ija9OB4v9_z8SXNK@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Forwarding Rietveld conversation to the tracker.  It looks like
Rietveld integration has a bug and sends reviews to
None at psf.upfronthosting.co.za rather than to report at bugs.python.org.

Forwarded conversation
Subject: Add aware local time support to datetime module (issue9527)
------------------------

From: <techtonik at gmail.com>
Date: Thu, Jan 13, 2011 at 7:14 PM
To: belopolsky at users.sourceforge.net
Cc: None at psf.upfronthosting.co.za

I'm not proficient in C and not an expert in datetime issues either, but
because nobody else stepped in to do review, I've left some comments.
Perhaps making the issue more acceptable by general public will help to
close it faster.

http://bugs.python.org/review/9527/diff/1568/2704
File Lib/datetime.py (right):

http://bugs.python.org/review/9527/diff/1568/2704#newcode1420
Lib/datetime.py:1420: def localtime(cls, t=None, isdst=-1):
The t param should probably be called 'time'.

http://bugs.python.org/review/9527/diff/1568/2704#newcode1421
Lib/datetime.py:1421: """Return local time as an aware datetime object.
ISTM that we need an object hierarchy like DateTime->DateTimeTZ, because
debugging which object is TZ aware and which is not is rather hard.

http://bugs.python.org/review/9527/diff/1568/2704#newcode1435
Lib/datetime.py:1435: t = _time.time()
Here we should always receive aware object, but I couldn't find
reference to C standard to ensure that all systems return this
correctly.

http://bugs.python.org/review/9527/diff/1568/2704#newcode1437
Lib/datetime.py:1437: if t.tzinfo is None:
I'd replace this with elif and place comment that here we detect
non-aware time object. Docstring above is nice, but it will probably be
parsed into documentation, and I am not sure if these details should be
present in user manual.

http://bugs.python.org/review/9527/diff/1568/2704#newcode1438
Lib/datetime.py:1438: tm = t.timetuple()[:-1] + (isdst,)
IIUC return result of time() value is time.struct_time which doesn't
have timetuple() method. If you work with datetime objects only, then
you need to name variables accordingly.

http://bugs.python.org/review/9527/show

----------
From: <techtonik at gmail.com>
Date: Fri, Jan 14, 2011 at 12:28 PM
To: belopolsky at users.sourceforge.net
Cc: None at psf.upfronthosting.co.za

On 2011/01/14 04:30:11, sasha wrote:
> Can you comment on whether you find the
> proposed function useful? ?Is the interface intuitive?

I prefer to threat UTC time and timezone separately. My API wannabe:

global.time() - returns value that can be printed and it will be in UTC
global.offset() - difference in seconds between current timezone and UTC
(so that +2 will be 7200 seconds and -2 is -7200)
global.fromiso() - returns value parsed from ISO 8601 format, probably
pair (UTC time, offset)
global.toiso(time, [offset]) - for symmetry

Maybe its even better if global.time() returns tuple (UTC time, offset)

As you may see I am not interested in DST details etc. All I need is the
ability to parse and generate timestamps. If your datetime.localtime()
returns datetime object, how should I use it to generate Atom timestamp
with proper TZ modifier?

http://www.atomenabled.org/developers/syndication/atom-format-spec.php#date.constructs

In my low-level and non-OOP API it is:

global.toiso(global.time(), global.offset())

epoch as an
> argument (unlike the eponymous time module function). ?It takes an
arbitrary
> datetime instance and converts it to an aware datetime instance with
tzinfo set
> to an appropriate fixed offset timezone.

At first I thought about datetime.toaware(dt), but this description of
yours is better than the one provided in docstring. If
datetime.localtime([dt]) gets local time in timezone aware object or
converts existing datetime (how about other types?), then the name
datetime.localtime() seems fine. But I would consider alternative
datetime.globaltime() name with the meaning that we get datetime object
that is globally synchronized, in other words it can be used not only
locally. .localtime() is ambiguous in this respect.
On 2011/01/14 04:30:11, sasha wrote:
> implementation. ? I would not call it "time" because that conflicts
with the
> time class and localtime expects a datetime instance in t.

dt is a consistent name for datetime parameters in Python manual.
On 2011/01/14 04:30:11, sasha wrote:
> Early versions of datetime has a separate datetimetz class. ?I don't
remember
> what were the actual reasons for removing it, but I am glad that this
was done.
> Hopefully applications will stop using naive datetime objects at some
point, so
> there will be less need to distinguish naive and aware instances.

It must be recorded for history if we want to get rid of date/time curse
in Python4 without missing any details. Removing naive objects in favor
of normalized objects with UTC timestamps seems like a way to go.
On 2011/01/14 04:30:11, sasha wrote:
> No. ?_time.time() returns seconds since epoch. Naive/aware distinction
is not
> applicable.

But these seconds are in UTC. There is no TZ correction.

----------
title: Add aware local time support to datetime module -> Add aware local time support to datetime module (issue9527)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9527>
_______________________________________

From report at bugs.python.org  Fri Jan 14 20:48:20 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 14 Jan 2011 19:48:20 +0000
Subject: [issue9527] Add aware local time support to datetime module
In-Reply-To: <1281066500.35.0.441616276688.issue9527@psf.upfronthosting.co.za>
Message-ID: <1295034500.61.0.0939706977031.issue9527@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


----------
title: Add aware local time support to datetime module (issue9527) -> Add aware local time support to datetime module

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9527>
_______________________________________

From report at bugs.python.org  Fri Jan 14 20:51:22 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 14 Jan 2011 19:51:22 +0000
Subject: [issue7322] Socket timeout can cause file-like readline() method to
	lose data
In-Reply-To: <1258218993.08.0.764402701678.issue7322@psf.upfronthosting.co.za>
Message-ID: <1295034682.7.0.30474108648.issue7322@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Looks good and simple enough. I would probably shift the timeout test after the closed test, but that's almost a detail.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7322>
_______________________________________

From report at bugs.python.org  Fri Jan 14 21:00:54 2011
From: report at bugs.python.org (David Beazley)
Date: Fri, 14 Jan 2011 20:00:54 +0000
Subject: [issue7322] Socket timeout can cause file-like readline() method to
	lose data
In-Reply-To: <1258218993.08.0.764402701678.issue7322@psf.upfronthosting.co.za>
Message-ID: <1295035254.36.0.429500193171.issue7322@psf.upfronthosting.co.za>


David Beazley <dave at dabeaz.com> added the comment:

Just wanted to say that I agree it's nonsense to continue reading on a socket that timed out (I'm not even sure what I might have been thinking when I first submitted this bug other than just experimenting with edge cases of the socket interface).    It's still probably good to precisely specify what the behavior is in any case.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7322>
_______________________________________

From report at bugs.python.org  Fri Jan 14 21:01:48 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 14 Jan 2011 20:01:48 +0000
Subject: [issue10694] zipfile.py end of central directory detection not robust
In-Reply-To: <1292266671.15.0.914079935044.issue10694@psf.upfronthosting.co.za>
Message-ID: <1295035308.32.0.720533168159.issue10694@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
stage: unit test needed -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10694>
_______________________________________

From report at bugs.python.org  Fri Jan 14 21:16:45 2011
From: report at bugs.python.org (Doug Hellmann)
Date: Fri, 14 Jan 2011 20:16:45 +0000
Subject: [issue1170] shlex have problems with parsing unicode
In-Reply-To: <1190045833.27.0.172281845017.issue1170@psf.upfronthosting.co.za>
Message-ID: <1295036205.97.0.0658246424916.issue1170@psf.upfronthosting.co.za>


Changes by Doug Hellmann <doug.hellmann at gmail.com>:


----------
nosy: +doughellmann

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1170>
_______________________________________

From report at bugs.python.org  Fri Jan 14 21:30:29 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 14 Jan 2011 20:30:29 +0000
Subject: [issue10874] test_urllib2 shouldn't use is operator for comparing
	strings
In-Reply-To: <1294591963.25.0.901803829485.issue10874@psf.upfronthosting.co.za>
Message-ID: <1295037029.39.0.364845926314.issue10874@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

?ukasz, please close issues when they are fixed.

----------
nosy: +pitrou
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10874>
_______________________________________

From report at bugs.python.org  Fri Jan 14 22:21:40 2011
From: report at bugs.python.org (Bert JW Regeer)
Date: Fri, 14 Jan 2011 21:21:40 +0000
Subject: [issue10910] pyport.h FreeBSD/Mac OS X "fix" causes errors in C++
	compilation
In-Reply-To: <1295040100.28.0.0907494738582.issue10910@psf.upfronthosting.co.za>
Message-ID: <1295040100.28.0.0907494738582.issue10910@psf.upfronthosting.co.za>


New submission from Bert JW Regeer <bertjw at regeer.org>:

I was recently attempting to get Botan (http://botan.randombit.net) working with Python 2.6.6 on FreeBSD when it failed to compile, I filled a bug with Botan (http://bugs.randombit.net/show_bug.cgi?id=135) and first thought it was a compiler issue, and then thought it might be a Boost.Python issue.

However after further digging, see comment 3 (http://bugs.randombit.net/show_bug.cgi?id=135#c3) I figured out it had to do with the fix that went in to pyport.h for issues with isspace/toupper/et al. on FreeBSD's libc and also Mac OS X.

As can be seen in http://svn.python.org/view/python/trunk/Include/pyport.h?r1=36519&r2=36793 a change was added to override the original definitions with a new one that used the wide character support. It was modified again in http://svn.python.org/view/python/trunk/Include/pyport.h?r1=77585&r2=80178 to also include Mac OS X for http://bugs.python.org/issue7072.

The issue here is that if this file is included in any C++ code that then also includes <locale> or any of other functions that might pull in localefwd.h the defines will cause actual C++ code functions to be overwritten with invalid data, and the C++ compiler will throw errors such as:

/usr/include/c++/4.2/bits/localefwd.h:58:34: error: macro "isspace" passed 2
arguments, but takes just 1

Putting an #if 0, #endif around that block of code allows Botan's python module to cleanly compile without issues.

I do apologise that I don't have a simple C++ program that reproduces the problem.

----------
assignee: ronaldoussoren
components: Build, Extension Modules, Library (Lib), Macintosh, Unicode, ctypes
messages: 126299
nosy: X-Istence, ronaldoussoren
priority: normal
severity: normal
status: open
title: pyport.h FreeBSD/Mac OS X "fix" causes errors in C++ compilation
type: compile error
versions: Python 2.6, Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10910>
_______________________________________

From report at bugs.python.org  Fri Jan 14 22:34:37 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 14 Jan 2011 21:34:37 +0000
Subject: [issue10911] cgi: add more tests
In-Reply-To: <1295040877.8.0.0807786274615.issue10911@psf.upfronthosting.co.za>
Message-ID: <1295040877.8.0.0807786274615.issue10911@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

cgi was recently fixed just before Python 3.2 final, but the module has few tests. More tests should be written.

You can find some examples attached to #4953.

----------
components: Library (Lib), Tests
messages: 126300
nosy: haypo
priority: normal
severity: normal
status: open
title: cgi: add more tests
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10911>
_______________________________________

From report at bugs.python.org  Fri Jan 14 22:36:11 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 14 Jan 2011 21:36:11 +0000
Subject: [issue4953] cgi module cannot handle POST with multipart/form-data in
	3.x
In-Reply-To: <1232010166.79.0.972664060868.issue4953@psf.upfronthosting.co.za>
Message-ID: <1295040971.78.0.445241112044.issue4953@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Because I'm unable to read the whole history and analyze each file attached to this issue, I opened #10911 to ask to write more tests for the cgi module.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4953>
_______________________________________

From report at bugs.python.org  Fri Jan 14 23:05:08 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 14 Jan 2011 22:05:08 +0000
Subject: [issue10833] Replace %.100s by %s in PyErr_Format(): the arbitrary
	limit of 500 bytes is outdated
In-Reply-To: <1294196554.94.0.785505480291.issue10833@psf.upfronthosting.co.za>
Message-ID: <1295042708.41.0.786360452265.issue10833@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

belopolsky> Limiting field width when formatting error messages is 
belopolsky> a good safety measure.

The problem is that PyUnicode_FromFormatV() doesn't support %.100s format (it ignores .100). If we truncate at 100 bytes, it may truncate an UTF-8 string in the middle of a character :-/ And I don't want to implement it because I don't like arbitrary limitations in Python.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10833>
_______________________________________

From report at bugs.python.org  Fri Jan 14 23:18:04 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 14 Jan 2011 22:18:04 +0000
Subject: [issue2128] sys.argv is wrong for unicode strings
In-Reply-To: <1203179266.7.0.767749493824.issue2128@psf.upfronthosting.co.za>
Message-ID: <1295043484.21.0.459844524573.issue2128@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/issue2128>
_______________________________________

From report at bugs.python.org  Sat Jan 15 00:31:49 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 14 Jan 2011 23:31:49 +0000
Subject: [issue1602] windows console doesn't print or input Unicode
In-Reply-To: <1197453390.87.0.813702844893.issue1602@psf.upfronthosting.co.za>
Message-ID: <1295047909.67.0.279399668122.issue1602@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Here are some results of my test of unicode2.py. I'm testing py3k on Windows XP, OEM: cp850, ANSI: cp1252.

Raster fonts
------------

With a fresh console, unicode2.py displays "?????????????????". input() accepts characters encodable to the OEM code page.

If I set the code page to 65001 (chcp program+set PYTHONIOENCODING=utf-8; or SetConsoleCP() + SetConsoleOutputCP()), it displays weird characters. input() accepts ASCII characters, but non-ASCII characters (encodable to the console and OEM code pages) display weird characters (smileys! control characters?).

Lucida console
--------------

With my system code page (OEM: cp850), characters not encodable to the code pages are displayed correctly. I can type some non-ASCII characters (encodable to the code page). If I copy/paste characters non encodable to the code page, there are replaced by similar glyph (eg. ? => L) or ? (? => ?).

If I set the code page to 65001, all characters are still correctly displayed. But I cannot type non-ASCII characters anymore: input() fails with EOFError (I suppose that Python gets control characters).

Redirect output to a pipe
-------------------------

I patched unicode2.py to use sys.stdout.buffer instead of sys.stdout for UnicodeOutput stream. I also patched UnicodeOutput to replace \n by \r\n. 

It works correctly with any character. No UTF-8 BOM is written. But "Here 1" is written at the end. I suppose that sys.stdout should be flushed before the creation of UnicodeOutput.

But it always use UTF-8. I don't know if UTF-8 is well supported by any application on Windows.

Without unicode2.py, only characters encodable to OEM code page are supported, and \n is used as end of line string.

Let's try to summarize
----------------------

Tests:
 d1) Display characters encodable to the console code page
 t1) Type characters encodable to the console code page
 d2) Display characters not encodable to any code page
 t2) Type characters not encodable to any code page

I'm using Windows with OEM=cp850 and ANSI=cp1252. For test (t2), I copy ?-? and paste it to the console (right click on the window title > Edit > Paste).

Raster fonts, console=cp850:

d1) ok
t1) ok
d2) FAIL: ?-? is displayed ?-L
t2) FAIL: ?-? is read as ?-L

Raster fonts, console=cp65001:

d1) FAIL: ? is displayed as 2 strange glyphs
t1) FAIL: EOFError
d2) FAIL: only display unreadable glyphs
t2) FAIL: EOFError

Lucida console, console=cp850:

d1) ok
t1) ok
d2) ok
t2) FAIL: ?-? is read as ?-L

Lucida console, console=cp65001:

d1) ok
t1) FAIL: EOFError
d2) ok
t2) FAIL: EOFError

So, setting the console code page to 65001 doesn't solve any issue, but it breaks the input (input with the keyboard or pasting text).

With Raster fonts or Lucida console, it's possible to display characters encodable to the code page. But it is not new, it's already possible with Python 3. But for characters not encodable to the code page, it works with unicode2.py and Lucida console, with is something new :-)

For the input, I suppose that we need also to use a Windows console function, to support unencodable characters.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1602>
_______________________________________

From report at bugs.python.org  Sat Jan 15 00:38:13 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 14 Jan 2011 23:38:13 +0000
Subject: [issue1602] windows console doesn't print or input Unicode
In-Reply-To: <1197453390.87.0.813702844893.issue1602@psf.upfronthosting.co.za>
Message-ID: <1295048293.66.0.946051448277.issue1602@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> ..., because right now, I'm including instructions for the use to 
> (1) choose Lucida or Consolas font if they can't figure out 
>     any other font that gets rid of the square boxes 
> (2) chcp 65001 
> (3) set PYTHONIOENCODING=UTF-8

Why do you set the code page to 65001? In all my tests (on Windows XP), it always break the standard input.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1602>
_______________________________________

From report at bugs.python.org  Sat Jan 15 00:46:48 2011
From: report at bugs.python.org (Radiant)
Date: Fri, 14 Jan 2011 23:46:48 +0000
Subject: [issue6771] Curses.wrapper: documentation/implementation error
In-Reply-To: <1251099236.05.0.0799674766136.issue6771@psf.upfronthosting.co.za>
Message-ID: <1295048808.99.0.914974570163.issue6771@psf.upfronthosting.co.za>


Radiant <abbconsulting at gmail.com> added the comment:

Adding version=3.2 and component=Documentation.

----------
assignee:  -> docs at python
components: +Documentation
nosy: +Radiant, docs at python
versions: +Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6771>
_______________________________________

From report at bugs.python.org  Sat Jan 15 01:10:47 2011
From: report at bugs.python.org (Robert Siemer)
Date: Sat, 15 Jan 2011 00:10:47 +0000
Subject: [issue10817] urllib.request.urlretrieve never raises
	ContentTooShortError if no reporthook
In-Reply-To: <1294069804.34.0.860239284714.issue10817@psf.upfronthosting.co.za>
Message-ID: <1295050247.28.0.640281614894.issue10817@psf.upfronthosting.co.za>


Changes by Robert Siemer <Robert.Siemer-python.org at backsla.sh>:


----------
nosy: +siemer

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10817>
_______________________________________

From report at bugs.python.org  Sat Jan 15 02:01:00 2011
From: report at bugs.python.org (Devin Jeanpierre)
Date: Sat, 15 Jan 2011 01:01:00 +0000
Subject: [issue10912] PyObject_RichCompare differs in behaviour from
	PyObject_RichCompareBool ; difference not noted in documentation
In-Reply-To: <1295053260.1.0.0634834443195.issue10912@psf.upfronthosting.co.za>
Message-ID: <1295053260.1.0.0634834443195.issue10912@psf.upfronthosting.co.za>


New submission from Devin Jeanpierre <jeanpierreda at gmail.com>:

PyObject_RichCoareBool is, according to the documentation in trunk (Doc\c-api\object.rst), exactly the same as PyObject_RichCompare, except it 1, 0, or -1 for error, false, and true respectively. However, it differs in behavior by both that, and also by assuming that identity implies equality. This noted in a two year-old ML post (sadly, no bug report was posted as best as I can find): http://mail.python.org/pipermail/python-list/2009-March/1195170.html

Ideally PyObject_RichCompareBool should probably be named something else, since it can no longer be used, strictly, as "PyObject_RichCompare, but returning a C bool" (or, rather, a C int). Some suggestions were offered in the mailing list thread above.

I'm filing this as a documentation bug because I find that outcome unlikely. At least the documentation should note the difference in behavior, so that people do not accidentally write C code that does not behave as intended.

This issue is related to, but different from issue 4296, which objected to the new container behavior created by the change to PyObject_RichCompareBool. My only objection here is that the latter change does not appear to be documented.

I would supply a patch for the tests, but PyObject_RichCompareBool is apparently not directly tested anywhere, just tested obliquely through testing the containment operator, and this was changed by the same commit that changed PyObject_RichCompareBool. I don't know how to word the (very small!) change to the docs.

----------
assignee: docs at python
components: Documentation
messages: 126306
nosy: Devin Jeanpierre, docs at python
priority: normal
severity: normal
status: open
title: PyObject_RichCompare differs in behaviour from PyObject_RichCompareBool ; difference not noted in documentation

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10912>
_______________________________________

From report at bugs.python.org  Sat Jan 15 02:19:32 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 15 Jan 2011 01:19:32 +0000
Subject: [issue4953] cgi module cannot handle POST with multipart/form-data in
	3.x
In-Reply-To: <1295032274.88.0.0497306315975.issue4953@psf.upfronthosting.co.za>
Message-ID: <1295043121.16273.46.camel@marge>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Le vendredi 14 janvier 2011 ? 19:11 +0000, R. David Murray a ?crit :
> Victor: we normally leave the patch file that was committed attached
> to the issue for future reference.

Sorry, but there were too much files. I was trying to figure out if
there is something useful in the files.

> The _plus_tests file was just the original patch plus the existing cgi
> tests adjusted to pass in bytes instead of strings to cgi, if I recall
> correctly.  Nor original code of mine in either part :)

Ok.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4953>
_______________________________________

From report at bugs.python.org  Sat Jan 15 02:46:45 2011
From: report at bugs.python.org (Glenn Linderman)
Date: Sat, 15 Jan 2011 01:46:45 +0000
Subject: [issue1602] windows console doesn't print or input Unicode
In-Reply-To: <1197453390.87.0.813702844893.issue1602@psf.upfronthosting.co.za>
Message-ID: <1295056005.63.0.0883950744111.issue1602@psf.upfronthosting.co.za>


Glenn Linderman <v+python at g.nevcal.com> added the comment:

Victor said:
Why do you set the code page to 65001? In all my tests (on Windows XP), it always break the standard input.

My response:
Because when I searched Windows for Unicode and/or UTF-8 stuff, I found 65001, and it seems like it might help, and it does a bit.  And then I find PYTHONIOENCODING, and that helps some.  And that got me something that works better enough than what I had before, so I quit searching.

You did a better job of analyzing and testing all the cases.  I will have to go subtract the 65001 part, and confirm your results, maybe it is useless now that other pieces of the puzzle are in place.  Certainly with David-Sarah's code it seems to not be needed, whether it was a necessary part of the previous workaround I am not sure, because of the limited number of cases I tried (trying to find something that worked well enough, but not having enough knowledge to find David-Sarah's solution, nor a good enough testing methodology to try the pieces independently.

Thank your for your interest in this issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1602>
_______________________________________

From report at bugs.python.org  Sat Jan 15 05:52:41 2011
From: report at bugs.python.org (Ned Deily)
Date: Sat, 15 Jan 2011 04:52:41 +0000
Subject: [issue10907] OS X installer: warn users of buggy Tcl/Tk in OS X 10.6
In-Reply-To: <1295020361.6.0.15646249296.issue10907@psf.upfronthosting.co.za>
Message-ID: <1295067161.74.0.797413606855.issue10907@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Patch for items 2 and 3 committed (with release manager approval for 3.2) in r88003.  Updated the OS X installer build instructions to better reflect current practices including use of A/S Tcl/Tk in r88004.

Pending website changes and 2.7 backport (items 4 through 7).

----------
resolution:  -> fixed
stage: commit review -> committed/rejected
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10907>
_______________________________________

From report at bugs.python.org  Sat Jan 15 05:57:24 2011
From: report at bugs.python.org (Ross Lagerwall)
Date: Sat, 15 Jan 2011 04:57:24 +0000
Subject: [issue1535504] CGIHTTPServer doesn't handle path names with embeded
	space
Message-ID: <1295067444.08.0.585624961754.issue1535504@psf.upfronthosting.co.za>


Ross Lagerwall <rosslagerwall at gmail.com> added the comment:

Shouldn't this be closed? CGIHTTPServer *has* been updated to use subprocess on windows and the dependency has been closed as wont fix.

----------
nosy: +rosslagerwall

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1535504>
_______________________________________

From report at bugs.python.org  Sat Jan 15 06:07:26 2011
From: report at bugs.python.org (Ned Deily)
Date: Sat, 15 Jan 2011 05:07:26 +0000
Subject: [issue10843] OS X installer: install the Tools source directory
In-Reply-To: <1294307103.62.0.440849003452.issue10843@psf.upfronthosting.co.za>
Message-ID: <1295068046.26.0.0917830819263.issue10843@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Committed (with release manager approval for 3.2) in r88005.

----------
assignee: ronaldoussoren -> ned.deily
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10843>
_______________________________________

From report at bugs.python.org  Sat Jan 15 06:31:25 2011
From: report at bugs.python.org (Ned Deily)
Date: Sat, 15 Jan 2011 05:31:25 +0000
Subject: [issue10842] Update third-party libraries for OS X installer builds
In-Reply-To: <1294305637.23.0.341106753223.issue10842@psf.upfronthosting.co.za>
Message-ID: <1295069485.25.0.41793031697.issue10842@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Committed (with release manager approval for 3.2) to py3k in r88006.

Pending potential backport to 2.7.

----------
assignee: ronaldoussoren -> ned.deily
priority: release blocker -> 
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10842>
_______________________________________

From report at bugs.python.org  Sat Jan 15 07:06:10 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Sat, 15 Jan 2011 06:06:10 +0000
Subject: [issue8957] strptime(.., '%c') fails to parse output of strftime('%c',
	..) in some locales
In-Reply-To: <1276115080.37.0.388300880324.issue8957@psf.upfronthosting.co.za>
Message-ID: <1295071570.99.0.860916493729.issue8957@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

The problem for Hebrew appears to be the same as the one Victor stated for French. March in Hebrew is also a 3-letter word which means it's equal to its abbreviation.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8957>
_______________________________________

From report at bugs.python.org  Sat Jan 15 07:17:01 2011
From: report at bugs.python.org (Ned Deily)
Date: Sat, 15 Jan 2011 06:17:01 +0000
Subject: [issue10502] Add unittestguirunner to Tools/
In-Reply-To: <1290424978.75.0.300298743015.issue10502@psf.upfronthosting.co.za>
Message-ID: <1295072221.74.0.805259259231.issue10502@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

FYI, as of 3.2rc1, Tools/ is now included in Mac OS X distributions in /Applications/Python 3.2/Extras/.

----------
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10502>
_______________________________________

From report at bugs.python.org  Sat Jan 15 07:47:56 2011
From: report at bugs.python.org (Ross Lagerwall)
Date: Sat, 15 Jan 2011 06:47:56 +0000
Subject: [issue1227748] subprocess: inheritance of std descriptors inconsistent
Message-ID: <1295074076.04.0.614383081812.issue1227748@psf.upfronthosting.co.za>


Ross Lagerwall <rosslagerwall at gmail.com> added the comment:

I think all that is needed is a documentation patch. Attached is a doc patch which changes the doc to explicitly describe what happens on unix & windows (as described by Peter).

----------
components: +Documentation
keywords: +patch
nosy: +rosslagerwall
Added file: http://bugs.python.org/file20411/1227748.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1227748>
_______________________________________

From report at bugs.python.org  Sat Jan 15 08:20:54 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Sat, 15 Jan 2011 07:20:54 +0000
Subject: [issue8957] strptime(.., '%c') fails to parse output of strftime('%c',
	..) in some locales
In-Reply-To: <1276115080.37.0.388300880324.issue8957@psf.upfronthosting.co.za>
Message-ID: <1295076054.4.0.0289597522539.issue8957@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

I'm attaching a patch for Lib/_strptime.py that handles the month differently in __calc_date_time. It cycles all months, trying to find one where the full and abbrev names are different and matches it against the timestamp created by strftime. 

This solution is a hack, but so is the whole __calc_date_time function :-) [IMHO]

All tests pass and I also tried it manually with all the problematic locales reported by Alexander - seems to work correctly.

If this looks OK to you guys I can commit and backport.

----------
keywords: +patch
Added file: http://bugs.python.org/file20412/issue8957.py3k.1.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8957>
_______________________________________

From report at bugs.python.org  Sat Jan 15 09:00:00 2011
From: report at bugs.python.org (Ross Lagerwall)
Date: Sat, 15 Jan 2011 08:00:00 +0000
Subject: [issue9532] pipe.read hang,
	when calling commands.getstatusoutput in multi-threading code of
	python 2.4
In-Reply-To: <1281087012.75.0.995842004424.issue9532@psf.upfronthosting.co.za>
Message-ID: <1295078400.11.0.273672302467.issue9532@psf.upfronthosting.co.za>


Ross Lagerwall <rosslagerwall at gmail.com> added the comment:

After trying to reproduce this bug in 2.7.1 & 3.2b2 and failing, I think this should be closed (even the OP couldn't reproduce it in anything other than 2.4).

----------
nosy: +rosslagerwall

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9532>
_______________________________________

From report at bugs.python.org  Sat Jan 15 09:44:22 2011
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 15 Jan 2011 08:44:22 +0000
Subject: [issue1535504] CGIHTTPServer doesn't handle path names with embeded
	space
Message-ID: <1295081062.47.0.767416577373.issue1535504@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Right, closing this one too.  Thanks!

----------
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1535504>
_______________________________________

From report at bugs.python.org  Sat Jan 15 09:51:07 2011
From: report at bugs.python.org (sorin)
Date: Sat, 15 Jan 2011 08:51:07 +0000
Subject: [issue1602] windows console doesn't print or input Unicode
In-Reply-To: <1197453390.87.0.813702844893.issue1602@psf.upfronthosting.co.za>
Message-ID: <1295081467.97.0.705468705657.issue1602@psf.upfronthosting.co.za>


sorin <sorin.sbarnea at gmail.com> added the comment:

remeber that cp65001 cannot be set on windows. Also please read http://blogs.msdn.com/b/michkap/archive/2010/10/07/10072032.aspx and contact the author, Michael Kaplan from Microsoft, if you have more questions. I'm sure he will be glad to help.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1602>
_______________________________________

From report at bugs.python.org  Sat Jan 15 10:00:41 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Sat, 15 Jan 2011 09:00:41 +0000
Subject: [issue10912] PyObject_RichCompare differs in behaviour from
	PyObject_RichCompareBool ; difference not noted in documentation
In-Reply-To: <1295053260.1.0.0634834443195.issue10912@psf.upfronthosting.co.za>
Message-ID: <1295082041.54.0.463012724202.issue10912@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

I agree that the difference in behavior between the two functions is unfortunate, but that's unlikely to change now.

The least we can do is make the documentation precise. I'm attaching a proposed patch to Doc/c-api/object.rst

Nick/Terry/Georg - if this looks OK I can commit.

----------
keywords: +easy, patch
nosy: +eli.bendersky, ncoghlan, terry.reedy -Devin Jeanpierre
type:  -> behavior
Added file: http://bugs.python.org/file20413/issue10912.py3k.1.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10912>
_______________________________________

From report at bugs.python.org  Sat Jan 15 10:17:03 2011
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 15 Jan 2011 09:17:03 +0000
Subject: [issue10912] PyObject_RichCompare differs in behaviour from
	PyObject_RichCompareBool ; difference not noted in documentation
In-Reply-To: <1295053260.1.0.0634834443195.issue10912@psf.upfronthosting.co.za>
Message-ID: <1295083023.55.0.626005247168.issue10912@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Sure.

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10912>
_______________________________________

From report at bugs.python.org  Sat Jan 15 11:23:56 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Sat, 15 Jan 2011 10:23:56 +0000
Subject: [issue10912] PyObject_RichCompare differs in behaviour from
	PyObject_RichCompareBool ; difference not noted in documentation
In-Reply-To: <1295053260.1.0.0634834443195.issue10912@psf.upfronthosting.co.za>
Message-ID: <1295087036.07.0.463337224401.issue10912@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

Committed the fix to py3k in r88009

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10912>
_______________________________________

From report at bugs.python.org  Sat Jan 15 11:35:10 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Sat, 15 Jan 2011 10:35:10 +0000
Subject: [issue10912] PyObject_RichCompare differs in behaviour from
	PyObject_RichCompareBool ; difference not noted in documentation
In-Reply-To: <1295053260.1.0.0634834443195.issue10912@psf.upfronthosting.co.za>
Message-ID: <1295087710.53.0.586489224309.issue10912@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

Backport to release31 branch in r88010

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10912>
_______________________________________

From report at bugs.python.org  Sat Jan 15 12:22:14 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 15 Jan 2011 11:22:14 +0000
Subject: [issue10913] Deprecate PyEval_AcquireLock() and PyEval_ReleaseLock()
In-Reply-To: <1295090534.64.0.681277352782.issue10913@psf.upfronthosting.co.za>
Message-ID: <1295090534.64.0.681277352782.issue10913@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

These two functions are very low-level and no good to use outside the interpreter core (actually, inside the core I don't think they are useful either). We should deprecate them and recommend the thread-state aware functions instead. See #1720250 for an example confusion.

----------
assignee: pitrou
components: Documentation
messages: 126324
nosy: grahamd, pitrou
priority: high
severity: normal
status: open
title: Deprecate PyEval_AcquireLock() and PyEval_ReleaseLock()
type: behavior
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10913>
_______________________________________

From report at bugs.python.org  Sat Jan 15 14:11:49 2011
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 15 Jan 2011 13:11:49 +0000
Subject: [issue8754] ImportError: quote bad module name in message
In-Reply-To: <1274202200.16.0.392487565261.issue8754@psf.upfronthosting.co.za>
Message-ID: <1295097109.6.0.792491126685.issue8754@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Won't make it into 3.2.

----------
priority: deferred blocker -> high
versions: +Python 3.3 -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8754>
_______________________________________

From report at bugs.python.org  Sat Jan 15 14:12:17 2011
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 15 Jan 2011 13:12:17 +0000
Subject: [issue3243] Support iterable bodies in httplib
In-Reply-To: <1214848938.76.0.928668674728.issue3243@psf.upfronthosting.co.za>
Message-ID: <1295097137.38.0.224274777052.issue3243@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Anything left to do here, Senthil?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3243>
_______________________________________

From report at bugs.python.org  Sat Jan 15 14:23:43 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 15 Jan 2011 13:23:43 +0000
Subject: [issue10913] Deprecate PyEval_AcquireLock() and PyEval_ReleaseLock()
In-Reply-To: <1295090534.64.0.681277352782.issue10913@psf.upfronthosting.co.za>
Message-ID: <1295097823.53.0.358707095054.issue10913@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Done in r88018.

----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10913>
_______________________________________

From report at bugs.python.org  Sat Jan 15 14:38:40 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 15 Jan 2011 13:38:40 +0000
Subject: [issue10914] Python sub-interpreter test
In-Reply-To: <1295098719.73.0.016388283782.issue10914@psf.upfronthosting.co.za>
Message-ID: <1295098719.73.0.016388283782.issue10914@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

Here is a prototype test for embedding and sub-interpreters.

----------
components: Interpreter Core, Tests
files: embedtest.patch
keywords: patch
messages: 126328
nosy: christian.heimes, grahamd, haypo, loewis, pitrou
priority: normal
severity: normal
status: open
title: Python sub-interpreter test
versions: Python 3.2, Python 3.3
Added file: http://bugs.python.org/file20414/embedtest.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10914>
_______________________________________

From report at bugs.python.org  Sat Jan 15 14:38:49 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 15 Jan 2011 13:38:49 +0000
Subject: [issue1977] Python reinitialization test
In-Reply-To: <1201720244.02.0.0976736262476.issue1977@psf.upfronthosting.co.za>
Message-ID: <1295098729.55.0.233053851263.issue1977@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

See also #10914.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1977>
_______________________________________

From report at bugs.python.org  Sat Jan 15 15:32:49 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 15 Jan 2011 14:32:49 +0000
Subject: [issue10912] PyObject_RichCompare differs in behaviour from
	PyObject_RichCompareBool ; difference not noted in documentation
In-Reply-To: <1295053260.1.0.0634834443195.issue10912@psf.upfronthosting.co.za>
Message-ID: <1295101969.72.0.488169028743.issue10912@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

For the record, the gory details as to *why* RichCompareBool makes more assumptions as to the meaning of equality than the basic RichCompare function can be found in issue 4296 (I just found that issue myself by looking at Mark's response to the python-list thread).

It may be worth explicitly pointing out that use cases where this assumption is unacceptable would be better served by direct invocation RichCompare function.

----------
nosy: +mark.dickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10912>
_______________________________________

From report at bugs.python.org  Sat Jan 15 15:37:08 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Sat, 15 Jan 2011 14:37:08 +0000
Subject: [issue10912] PyObject_RichCompare differs in behaviour from
	PyObject_RichCompareBool ; difference not noted in documentation
In-Reply-To: <1295053260.1.0.0634834443195.issue10912@psf.upfronthosting.co.za>
Message-ID: <1295102228.06.0.894522784472.issue10912@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

Nick, I read the protocol of issue 4296 and I understand the reasoning behind the code, but I still think the naming is mightily confusing. Two distinct changes went into a single function (A) Return -1/0/+1 instead of PyObject and (B) the id() shortcut, and its name is inappropriate. Were an API change feasible, some other naming would be better.

> "It may be worth explicitly pointing out that use cases where this assumption is unacceptable would be better served by direct invocation RichCompare function."

Do you mean write it down in the docs?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10912>
_______________________________________

From report at bugs.python.org  Sat Jan 15 15:51:01 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 15 Jan 2011 14:51:01 +0000
Subject: [issue10912] PyObject_RichCompare differs in behaviour from
	PyObject_RichCompareBool ; difference not noted in documentation
In-Reply-To: <1295053260.1.0.0634834443195.issue10912@psf.upfronthosting.co.za>
Message-ID: <1295103061.07.0.621738264434.issue10912@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Yeah, to prevent perfectly reasonable "why" questions, it is probably worth providing a little extra justification as an addendum to your new note (which is already an improvement on the complete silence on the topic that existed before).

A possible addition:

"... This assumption allows invariants such as "x in [x]" to be more easily guaranteed by the interpreter. If the assumption is not valid for a given use case, call PyObject_RichCompare() directly instead of using this function."

For 3.3, it *may* make sense to provide a PyObject_RichCompareBoolEx() function which includes an additional "reflexive" parameter. Then the existing PyObject_RichCompareBool() semantics would just be the new function with the reflexive argument set to 1.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10912>
_______________________________________

From report at bugs.python.org  Sat Jan 15 15:52:41 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 15 Jan 2011 14:52:41 +0000
Subject: [issue10915] Make the PyGILState API compatible with multiple
	interpreters
In-Reply-To: <1295103161.75.0.771875465176.issue10915@psf.upfronthosting.co.za>
Message-ID: <1295103161.75.0.771875465176.issue10915@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

It should be relatively easy to devise a new PyGILState API with support for multiple interpreters. We just need two new functions (similar to the two existing ones) taking a PyInterpreterState* parameter; a TLS key can be added to the PyInterpreterState structure (instead of the current global TLS key).

It will be up to the caller to know which interpreter they want to hook into when calling these functions (which is application-dependent and is normally well-defined, e.g. when calling a Python callback, you should call it with the interpreter which was in use when registering the callback (i.e. ``PyThreadState_Get()->interp``)).

----------
components: Interpreter Core
messages: 126333
nosy: amaury.forgeotdarc, grahamd, loewis, pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: Make the PyGILState API compatible with multiple interpreters
type: feature request
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10915>
_______________________________________

From report at bugs.python.org  Sat Jan 15 15:52:49 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 15 Jan 2011 14:52:49 +0000
Subject: [issue10915] Make the PyGILState API compatible with multiple
	interpreters
In-Reply-To: <1295103161.75.0.771875465176.issue10915@psf.upfronthosting.co.za>
Message-ID: <1295103169.01.0.688492692564.issue10915@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10915>
_______________________________________

From report at bugs.python.org  Sat Jan 15 15:53:35 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 15 Jan 2011 14:53:35 +0000
Subject: [issue10914] Python sub-interpreter test
In-Reply-To: <1295098719.73.0.016388283782.issue10914@psf.upfronthosting.co.za>
Message-ID: <1295103215.17.0.808111902695.issue10914@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +amaury.forgeotdarc, ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10914>
_______________________________________

From report at bugs.python.org  Sat Jan 15 16:19:02 2011
From: report at bugs.python.org (Ross Lagerwall)
Date: Sat, 15 Jan 2011 15:19:02 +0000
Subject: [issue10916] mmap segfault
In-Reply-To: <1295104742.35.0.155960214415.issue10916@psf.upfronthosting.co.za>
Message-ID: <1295104742.35.0.155960214415.issue10916@psf.upfronthosting.co.za>


New submission from Ross Lagerwall <rosslagerwall at gmail.com>:

If a mmap length 0 is used and an offset is used as well, the size to mmap() is calculated as the size of the file instead of the size of the file minus offset. This means that trying to access a certain part does not result in an index error but a segfault (bus error).

Attached is a patch that fixes the issue + a unit test.

----------
components: Extension Modules
files: mmap.patch
keywords: patch
messages: 126334
nosy: amaury.forgeotdarc, loewis, pitrou, r.david.murray, rosslagerwall
priority: normal
severity: normal
status: open
title: mmap segfault
type: crash
versions: Python 2.7, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file20415/mmap.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10916>
_______________________________________

From report at bugs.python.org  Sat Jan 15 16:22:59 2011
From: report at bugs.python.org (SilentGhost)
Date: Sat, 15 Jan 2011 15:22:59 +0000
Subject: [issue5800] make wsgiref.headers.Headers accept empty constructor
In-Reply-To: <1240243265.38.0.0946630520568.issue5800@psf.upfronthosting.co.za>
Message-ID: <1295104979.77.0.601790612282.issue5800@psf.upfronthosting.co.za>


Changes by SilentGhost <ghost.adh at gmail.com>:


----------
status: open -> languishing

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5800>
_______________________________________

From report at bugs.python.org  Sat Jan 15 17:08:39 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 15 Jan 2011 16:08:39 +0000
Subject: [issue10915] Make the PyGILState API compatible with multiple
	interpreters
In-Reply-To: <1295103161.75.0.771875465176.issue10915@psf.upfronthosting.co.za>
Message-ID: <1295107719.17.0.194234627056.issue10915@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Here is a sketch, including conversion of ctypes to the new API.
Converting sqlite would require a bit more work.

----------
keywords: +patch
Added file: http://bugs.python.org/file20416/gilstateinterp.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10915>
_______________________________________

From report at bugs.python.org  Sat Jan 15 17:13:54 2011
From: report at bugs.python.org (R. David Murray)
Date: Sat, 15 Jan 2011 16:13:54 +0000
Subject: [issue9532] pipe.read hang,
	when calling commands.getstatusoutput in multi-threading code of
	python 2.4
In-Reply-To: <1281087012.75.0.995842004424.issue9532@psf.upfronthosting.co.za>
Message-ID: <1295108034.63.0.665825715447.issue9532@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
resolution:  -> out of date
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9532>
_______________________________________

From report at bugs.python.org  Sat Jan 15 17:19:20 2011
From: report at bugs.python.org (SilentGhost)
Date: Sat, 15 Jan 2011 16:19:20 +0000
Subject: [issue10908] Improvements to trace._Ignore
In-Reply-To: <1295020376.03.0.967767300509.issue10908@psf.upfronthosting.co.za>
Message-ID: <1295108360.86.0.761360471982.issue10908@psf.upfronthosting.co.za>


SilentGhost <ghost.adh at gmail.com> added the comment:

The patch aside from fixing directory names on case-insensitive file systems, also:
 * implements more efficient handling of directory and module comparison (put into _Ignoore.__init__ instead of _Ignore.names).
 * changes integer return codes to boolean
 * doesn't require any more that the directory is actually a directory name.
 * moves --ignore-dir processing into a directory so that it can be expanded if $prefix support on windows is needed.
 * adds tests.

----------
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10908>
_______________________________________

From report at bugs.python.org  Sat Jan 15 17:19:30 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 15 Jan 2011 16:19:30 +0000
Subject: [issue10916] mmap segfault
In-Reply-To: <1295104742.35.0.155960214415.issue10916@psf.upfronthosting.co.za>
Message-ID: <1295108370.3.0.605536728621.issue10916@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Thanks for the patch. Committed in r88022 (3.2), r88023 (3.1) and r88024 (2.7).

----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10916>
_______________________________________

From report at bugs.python.org  Sat Jan 15 17:20:45 2011
From: report at bugs.python.org (SilentGhost)
Date: Sat, 15 Jan 2011 16:20:45 +0000
Subject: [issue10896] trace module compares directories as strings
	(--ignore-dir)
In-Reply-To: <1294843489.43.0.983792093108.issue10896@psf.upfronthosting.co.za>
Message-ID: <1295108445.57.0.493230376941.issue10896@psf.upfronthosting.co.za>


Changes by SilentGhost <ghost.adh at gmail.com>:


----------
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10896>
_______________________________________

From report at bugs.python.org  Sat Jan 15 17:21:38 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 15 Jan 2011 16:21:38 +0000
Subject: [issue10908] Improvements to trace._Ignore
In-Reply-To: <1295020376.03.0.967767300509.issue10908@psf.upfronthosting.co.za>
Message-ID: <1295108498.18.0.892884003645.issue10908@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


----------
nosy: +eli.bendersky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10908>
_______________________________________

From report at bugs.python.org  Sat Jan 15 17:21:43 2011
From: report at bugs.python.org (SilentGhost)
Date: Sat, 15 Jan 2011 16:21:43 +0000
Subject: [issue10896] trace module compares directories as strings
	(--ignore-dir)
In-Reply-To: <1294843489.43.0.983792093108.issue10896@psf.upfronthosting.co.za>
Message-ID: <1295108503.35.0.348414817431.issue10896@psf.upfronthosting.co.za>


Changes by SilentGhost <ghost.adh at gmail.com>:


----------
nosy:  -SilentGhost

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10896>
_______________________________________

From report at bugs.python.org  Sat Jan 15 17:26:12 2011
From: report at bugs.python.org (SilentGhost)
Date: Sat, 15 Jan 2011 16:26:12 +0000
Subject: [issue10908] Improvements to trace._Ignore
In-Reply-To: <1295020376.03.0.967767300509.issue10908@psf.upfronthosting.co.za>
Message-ID: <1295108772.08.0.444822562076.issue10908@psf.upfronthosting.co.za>


Changes by SilentGhost <ghost.adh at gmail.com>:


----------
dependencies: +trace module compares directories as strings (--ignore-dir)
type:  -> performance

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10908>
_______________________________________

From report at bugs.python.org  Sat Jan 15 17:35:10 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 15 Jan 2011 16:35:10 +0000
Subject: [issue10915] Make the PyGILState API compatible with multiple
	interpreters
In-Reply-To: <1295103161.75.0.771875465176.issue10915@psf.upfronthosting.co.za>
Message-ID: <1295109310.51.0.23138697941.issue10915@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


Removed file: http://bugs.python.org/file20416/gilstateinterp.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10915>
_______________________________________

From report at bugs.python.org  Sat Jan 15 17:35:20 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 15 Jan 2011 16:35:20 +0000
Subject: [issue10915] Make the PyGILState API compatible with multiple
	interpreters
In-Reply-To: <1295103161.75.0.771875465176.issue10915@psf.upfronthosting.co.za>
Message-ID: <1295109320.91.0.810580470633.issue10915@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
stage: needs patch -> patch review
Added file: http://bugs.python.org/file20417/gilstateinterp.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10915>
_______________________________________

From report at bugs.python.org  Sat Jan 15 17:39:39 2011
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 15 Jan 2011 16:39:39 +0000
Subject: [issue10694] zipfile.py end of central directory detection not robust
In-Reply-To: <1292266671.15.0.914079935044.issue10694@psf.upfronthosting.co.za>
Message-ID: <1295109579.62.0.244752467522.issue10694@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Not important enough to block release.

----------
priority: deferred blocker -> critical

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10694>
_______________________________________

From report at bugs.python.org  Sat Jan 15 17:39:51 2011
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 15 Jan 2011 16:39:51 +0000
Subject: [issue3243] Support iterable bodies in httplib
In-Reply-To: <1214848938.76.0.928668674728.issue3243@psf.upfronthosting.co.za>
Message-ID: <1295109591.72.0.367373729627.issue3243@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
priority: deferred blocker -> critical

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3243>
_______________________________________

From report at bugs.python.org  Sat Jan 15 17:40:00 2011
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 15 Jan 2011 16:40:00 +0000
Subject: [issue8746] os.chflags() and os.lchflags() are not built when they
	should be be
In-Reply-To: <1274173521.53.0.771933425772.issue8746@psf.upfronthosting.co.za>
Message-ID: <1295109600.93.0.765008865706.issue8746@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
priority: deferred blocker -> critical

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8746>
_______________________________________

From report at bugs.python.org  Sat Jan 15 17:40:16 2011
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 15 Jan 2011 16:40:16 +0000
Subject: [issue10736] test_ttk_guionly fails on OS X using ActiveState Tcl
	8.5.9 (Cocoa)
In-Reply-To: <1292765395.17.0.260810328922.issue10736@psf.upfronthosting.co.za>
Message-ID: <1295109616.03.0.877028367168.issue10736@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
priority: deferred blocker -> critical

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10736>
_______________________________________

From report at bugs.python.org  Sat Jan 15 17:40:26 2011
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 15 Jan 2011 16:40:26 +0000
Subject: [issue10734] test_ttk failure under Windows
In-Reply-To: <1292706922.45.0.208964037247.issue10734@psf.upfronthosting.co.za>
Message-ID: <1295109626.42.0.00773193060169.issue10734@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
priority: deferred blocker -> critical

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10734>
_______________________________________

From report at bugs.python.org  Sat Jan 15 17:42:28 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 15 Jan 2011 16:42:28 +0000
Subject: [issue8957] strptime(.., '%c') fails to parse output of strftime('%c',
	..) in some locales
In-Reply-To: <1295076054.4.0.0289597522539.issue8957@psf.upfronthosting.co.za>
Message-ID: <AANLkTi=n7aoZCY9UFdCQ5wuwb+K-gD4N7425jG9opQyn@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Sat, Jan 15, 2011 at 2:20 AM, Eli Bendersky <report at bugs.python.org> wrote:
..
> This solution is a hack, but so is the whole __calc_date_time function :-) [IMHO]
>

I am not sure how to proceed.   On one hand, I opened this issue to
demonstrate that the current implementation is flawed, on the other
hand, Eli has succeeded in improving the hack so that we can live with
it a bit longer.  Note that I did not have any real life application
that would misbehave because of this bug and I don't think developers
expect %c format to be parseable in the first place.

I made this issue depend on #8915 because I think strptime should
query the locale for format information directly rather than reverse
engineer what strftime does.

I don't think this fix solves all the problems.  For example, in most
locales (including plain C locale), day of the month in %c format uses
%e format, but current implementation guesses it as %d:

'%a %b %e %H:%M:%S %Y'
>>> LocaleTime().LC_date_time
'%a %b %d %H:%M:%S %Y'

This does not seem to be an issue because strptime with %d seems to be
able to parse space-filled as well as zero-filled numbers.  However,
there may be platforms that are less forgiving.

On the patch itself:

1. Unit tests are needed.

2. Please don't use datetime as a local variable.

3. I am not sure what the purpose of .lower() is.  Are a_month and
f_month lowercased?

4. Please keep lines under 79 characters long.

5. "for m in range(1, 13)" loop is better written as "for am, fm in
zip(self.a_month, self.f_month)"

Eli, what do you think yourself:  should we try to perfect the hack or
is it better to reimplement strptime using locale?  Note that the
latter may be a stepping stone to implementing strftime as well.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8957>
_______________________________________

From report at bugs.python.org  Sat Jan 15 17:47:25 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 15 Jan 2011 16:47:25 +0000
Subject: [issue8957] strptime(.., '%c') fails to parse output of strftime('%c',
	..) in some locales
In-Reply-To: <AANLkTi=n7aoZCY9UFdCQ5wuwb+K-gD4N7425jG9opQyn@mail.gmail.com>
Message-ID: <AANLkTikfHvu4NiPScWEpBgeSsv-ME5EDNFSivbNrGr1K@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

6. datetime.find(self.f_month[m]) >= 0 -> self.f_month[m] in datetime

Python is not C!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8957>
_______________________________________

From report at bugs.python.org  Sat Jan 15 18:11:48 2011
From: report at bugs.python.org (Rui Carmo)
Date: Sat, 15 Jan 2011 17:11:48 +0000
Subject: [issue2275] urllib2 header capitalization
In-Reply-To: <1205270540.47.0.336665756101.issue2275@psf.upfronthosting.co.za>
Message-ID: <1295111508.16.0.166625408379.issue2275@psf.upfronthosting.co.za>


Rui Carmo <rcarmo at gmail.com> added the comment:

I'd like to add that when supplying custom headers for things like UPNP (which uses SOAPACTION as a header to talk to frequently very limited servers), the library shouldn't mangle the headers in any way whatsoever and send them verbatim. 

(I consider that mangling to be a bug, and not a new feature. HTTP headers may be case-insensitve according to standards, but embedded implementations require us to have a degree of control over the headers, and failing to preserve header case is a bug.)

Right now I've had to replace httplib and urllib2 with my own custom code because the SOAPACTION header is capitalized and sent to the server as "Soapaction", which breaks the Intel embedded UPNP daemon.

----------
nosy: +Rui.Carmo
type: feature request -> behavior
versions: +Python 2.7 -Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2275>
_______________________________________

From report at bugs.python.org  Sat Jan 15 18:32:43 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Sat, 15 Jan 2011 17:32:43 +0000
Subject: [issue3243] Support iterable bodies in httplib
In-Reply-To: <1295109591.77.0.618551748872.issue3243@psf.upfronthosting.co.za>
Message-ID: <20110115173231.GA1179@rubuntu>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

Hi Georg,

In the previous comment, I had written that

'let me see if we have to accommodate those "very special case"
where data can be a zero length string just to accommodate the mistake
it was present in the earlier version.'

More, I think about it, the more it seems to me that accommodating that
special wrong case is not required.

The decision boils down to this.

1. In py3k, data for POST should be bytes.

2. But urllib.request had a 'bug/hole' that when a zero length string
was passed as a data, it did not raise an exception. There were cases
in test_urllib2 where zero length string was passed. I argue that it
was more of a mistake than, what we actually wanted to test it.

Because there is NO practical scenario where Zero length data as a
POST is useful.

3. Now, with the introduction of this feature requested in this issue,
this zero length string would raise an Exception and would demand that
even if it is zero length, please send it as bytes.

IMO, this is correct behavior and we need not accommodate the previous
one. 

So, I would recommend closing this bug as Fixed without further change.
At most, a NEWS item can be added to explain point 2.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3243>
_______________________________________

From report at bugs.python.org  Sat Jan 15 18:40:19 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 15 Jan 2011 17:40:19 +0000
Subject: [issue10916] mmap segfault
In-Reply-To: <1295104742.35.0.155960214415.issue10916@psf.upfronthosting.co.za>
Message-ID: <1295113219.0.0.420139671898.issue10916@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

It also needed fixing on Windows: committed in r88036, r88037 and r88038.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10916>
_______________________________________

From report at bugs.python.org  Sat Jan 15 18:41:12 2011
From: report at bugs.python.org (Xuanji Li)
Date: Sat, 15 Jan 2011 17:41:12 +0000
Subject: [issue3243] Support iterable bodies in httplib
In-Reply-To: <1214848938.76.0.928668674728.issue3243@psf.upfronthosting.co.za>
Message-ID: <1295113272.88.0.190981116825.issue3243@psf.upfronthosting.co.za>


Xuanji Li <xuanji at gmail.com> added the comment:

Yes, I think we should close it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3243>
_______________________________________

From report at bugs.python.org  Sat Jan 15 19:23:17 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Sat, 15 Jan 2011 18:23:17 +0000
Subject: [issue8957] strptime(.., '%c') fails to parse output of strftime('%c',
	..) in some locales
In-Reply-To: <1276115080.37.0.388300880324.issue8957@psf.upfronthosting.co.za>
Message-ID: <1295115797.98.0.377581389683.issue8957@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

Alexander,

1) Patch comments - thanks for those. Will have them fixed.
2) General strategy for implementing strptime. I must confess I don't fully understand the reason for doing what the _strptime module does. Standard C AFAIK has nothing of the sort - it only has strftime and strptime, both using a given format string. Neither tries to guess it from an actual formatted time! Does it exist just to circumvent platforms where strptime isn't implemented in C or is buggy? Can you please shed some light on this (or point me somewhere)?

With understanding of (2) I will be able to also logically reason about the next steps :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8957>
_______________________________________

From report at bugs.python.org  Sat Jan 15 19:26:54 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Sat, 15 Jan 2011 18:26:54 +0000
Subject: [issue3243] Support iterable bodies in httplib
In-Reply-To: <1214848938.76.0.928668674728.issue3243@psf.upfronthosting.co.za>
Message-ID: <1295116014.41.0.500430987933.issue3243@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

Thanks for the note. I shall some details to the NEWS entry before the release. Closing this report.

----------
priority: critical -> low
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3243>
_______________________________________

From report at bugs.python.org  Sat Jan 15 19:27:50 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Sat, 15 Jan 2011 18:27:50 +0000
Subject: [issue3243] Support iterable bodies in httplib
In-Reply-To: <1214848938.76.0.928668674728.issue3243@psf.upfronthosting.co.za>
Message-ID: <1295116070.84.0.338676844097.issue3243@psf.upfronthosting.co.za>


Changes by Senthil Kumaran <orsenthil at gmail.com>:


----------
priority: low -> normal

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3243>
_______________________________________

From report at bugs.python.org  Sat Jan 15 19:48:41 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 15 Jan 2011 18:48:41 +0000
Subject: [issue8957] strptime(.., '%c') fails to parse output of strftime('%c',
	..) in some locales
In-Reply-To: <1295115797.98.0.377581389683.issue8957@psf.upfronthosting.co.za>
Message-ID: <C6599539-E55C-47CD-9658-56B2BD495C15@gmail.com>


Alexander Belopolsky <alexander.belopolsky at gmail.com> added the comment:

You pretty much hit the nail on the head. Some platforms don't  have strptime or did not have it at the time this code was written. The locale module is probably more recent than this code as well.

----------
nosy: +Alexander.Belopolsky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8957>
_______________________________________

From report at bugs.python.org  Sat Jan 15 20:26:34 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 15 Jan 2011 19:26:34 +0000
Subject: [issue10912] PyObject_RichCompare differs in behaviour from
	PyObject_RichCompareBool ; difference not noted in documentation
In-Reply-To: <1295053260.1.0.0634834443195.issue10912@psf.upfronthosting.co.za>
Message-ID: <1295119594.27.0.351109615772.issue10912@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +Devin Jeanpierre

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10912>
_______________________________________

From report at bugs.python.org  Sat Jan 15 21:15:43 2011
From: report at bugs.python.org (Graham Dumpleton)
Date: Sat, 15 Jan 2011 20:15:43 +0000
Subject: [issue10915] Make the PyGILState API compatible with multiple
	interpreters
In-Reply-To: <1295103161.75.0.771875465176.issue10915@psf.upfronthosting.co.za>
Message-ID: <1295122543.7.0.0369609684868.issue10915@psf.upfronthosting.co.za>


Graham Dumpleton <Graham.Dumpleton at gmail.com> added the comment:

Can you please provide an example of what user would do and what changes existing extension modules would need to make?

When I looked at this exact problem some time back, I worked out that you probably only need a single new public API function. This would be something like PyInterpreterState_Swap().

By default stuff would work on the main interpreter, but if for a specific thread it wanted to operate in context of a different sub interpreter, would call PyInterpreterState_Swap() to indicate that. That would store in TLS outside of any existing data structures. Functions like existing PyGILState_Ensure()/PyGILState_Release() would then look up that TLS variable to know which interpreter they are working with.

Doing it this way meant that no C extension modules using PyGILState_??? functions would need to change at all, as what interpreter is being operated on dictated by who created the thread and initiated call in to Python interpreter.

You probably want validation checks to say that PyInterpreterState_Swap() can only be called when not GIL lock held.

It worries me that you are talking about new PyGILState_??? functions as that would suggest to me that extension modules would need to change to be aware of this stuff. That you are saying that sqlite needs changes is what makes me things the way you are going is a problem. It isn't practical to make SWIG change to use something other than PyGILState_Ensure()/PyGILState_Release(), it should be transparent and required no changes to existing C extensions.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10915>
_______________________________________

From report at bugs.python.org  Sat Jan 15 21:30:34 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 15 Jan 2011 20:30:34 +0000
Subject: [issue10915] Make the PyGILState API compatible with multiple
	interpreters
In-Reply-To: <1295122543.7.0.0369609684868.issue10915@psf.upfronthosting.co.za>
Message-ID: <1295123427.3717.14.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Can you please provide an example of what user would do and what
> changes existing extension modules would need to make?

The patch contains such a change for ctypes. It's quite simple actually.

> By default stuff would work on the main interpreter, but if for a
> specific thread it wanted to operate in context of a different sub
> interpreter, would call PyInterpreterState_Swap() to indicate that.
> That would store in TLS outside of any existing data structures.
> Functions like existing PyGILState_Ensure()/PyGILState_Release() would
> then look up that TLS variable to know which interpreter they are
> working with.

That sounds like an ugly hack to avoid passing the desired interpreter
state directly to PyGILState_Ensure()/PyGILState_Release().

Besides, it will only work if a thread always serves the same
sub-interpreter.

> Doing it this way meant that no C extension modules using
> PyGILState_??? functions would need to change at all, as what
> interpreter is being operated on dictated by who created the thread
> and initiated call in to Python interpreter.

Who would do that, if it's not the extensions in question?
"who created the thread" is often a third-party library (e.g. sqlite)
that has no notion of a Python interpreter. That's the whole point of
using the PyGILState_* API, really. So extensions *will* have to be
fixed.

> That you are saying that sqlite needs changes is what makes me things
> the way you are going is a problem. It isn't practical to make SWIG
> change to use something other than
> PyGILState_Ensure()/PyGILState_Release(), it should be transparent and
> required no changes to existing C extensions.

What does SWIG use them for?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10915>
_______________________________________

From report at bugs.python.org  Sun Jan 16 00:10:49 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 15 Jan 2011 23:10:49 +0000
Subject: [issue10912] PyObject_RichCompare differs in behaviour from
	PyObject_RichCompareBool ; difference not noted in documentation
In-Reply-To: <1295053260.1.0.0634834443195.issue10912@psf.upfronthosting.co.za>
Message-ID: <1295133049.69.0.908174459706.issue10912@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <rhettinger at users.sourceforge.net>:


----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10912>
_______________________________________

From report at bugs.python.org  Sun Jan 16 00:23:19 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 15 Jan 2011 23:23:19 +0000
Subject: [issue10912] PyObject_RichCompare differs in behaviour from
	PyObject_RichCompareBool ; difference not noted in documentation
In-Reply-To: <1295053260.1.0.0634834443195.issue10912@psf.upfronthosting.co.za>
Message-ID: <1295133799.91.0.898119061076.issue10912@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

-1 on PyObject_RichCompareBoolEx() for 3.3 -- it is simply an invitation to shoot yourself (or others) in the foot.

I've not seen real world code using bool(a==b) or its C equivalent, so it's hard to believe that there is a use case here (unless you're trying to commit atrocities with NaN-like objects).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10912>
_______________________________________

From report at bugs.python.org  Sun Jan 16 00:41:31 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 15 Jan 2011 23:41:31 +0000
Subject: [issue10915] Make the PyGILState API compatible with multiple
	interpreters
In-Reply-To: <1295103161.75.0.771875465176.issue10915@psf.upfronthosting.co.za>
Message-ID: <1295134891.43.0.141462766065.issue10915@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

A TLS based approach would presumably allow an embedding application like mod_wsgi to tinker with the state of threads created by naive modules that are unaware of the existence of subinterpreters.

That said, I don't see anything that prevents us from pursuing a TLS based override for the existing PyGILState functions later if the simpler, more explicit approach proves inadequate. As it stands, the new explicit calls allow something like mod_wsgi to define its *own* TLS location for the interpreter that is currently handling callbacks into Python, then use SWIG to generate PyGILState_*Ex calls in callback wrappers that reference that TLS interpreter state.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10915>
_______________________________________

From report at bugs.python.org  Sun Jan 16 00:52:49 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 15 Jan 2011 23:52:49 +0000
Subject: [issue10912] PyObject_RichCompare differs in behaviour from
	PyObject_RichCompareBool ; difference not noted in documentation
In-Reply-To: <1295053260.1.0.0634834443195.issue10912@psf.upfronthosting.co.za>
Message-ID: <1295135569.26.0.0616941834765.issue10912@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Indeed. I was actually wondering if it would be worth trying to write up a section for the language reference to describe the cases where a Python implementation is *expected* to assume reflexive equality. We (IMO) have a problem at the moment due to situations like:

>>> class PyContains(list):
...   def __contains__(self, obj):
...     return any(x==obj for x in self)
... 
>>> nan = float("nan")
>>> nan in [nan]
True
>>> nan in PyContains([nan])
False

This is a bug in the __contains__ definition (it should use "x is obj or x == obj" rather than just the latter expression) but there isn't anything in the language reference to point that out.

Assuming reflexive equality in some places and not in others based on the underlying implementation language is going to be a source of subtle bugs relating to types like float and decimal.Decimal.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10912>
_______________________________________

From report at bugs.python.org  Sun Jan 16 01:10:57 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Sun, 16 Jan 2011 00:10:57 +0000
Subject: [issue10903] ZipExtFile:_update_crc fails for CRC >= 0x80000000
In-Reply-To: <1294998214.06.0.837210563153.issue10903@psf.upfronthosting.co.za>
Message-ID: <1295136657.76.0.458683221324.issue10903@psf.upfronthosting.co.za>


Nadeem Vawda <nadeem.vawda at gmail.com> added the comment:

I have been unable to reproduce this on either 3.2rc1 or 2.6. I used a Zip archive containing a single file with the data b"a\n" (CRC 0xDDEAA107).

----------
nosy: +nvawda

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10903>
_______________________________________

From report at bugs.python.org  Sun Jan 16 01:29:40 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 16 Jan 2011 00:29:40 +0000
Subject: [issue10915] Make the PyGILState API compatible with multiple
	interpreters
In-Reply-To: <1295134891.43.0.141462766065.issue10915@psf.upfronthosting.co.za>
Message-ID: <1295137774.3717.34.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> A TLS based approach would presumably allow an embedding application
> like mod_wsgi to tinker with the state of threads created by naive
> modules that are unaware of the existence of subinterpreters.

The question is how mod_wsgi could know about the existence of these
threads, let alone decide which subinterpreter an arbitrary OS thread
should belong to; only the extension module can safely tell.
And it becomes totally hopeless if those threads are actually *shared*
between subinterpreters, as might be the case with a 3rd-party library
managing its own helper threads (I don't know if that's the case with
sqlite).

IMO we should really promote clean APIs which allow solving the whole
problem, rather than devise an internal hack to try to "improve" things
slightly.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10915>
_______________________________________

From report at bugs.python.org  Sun Jan 16 01:42:03 2011
From: report at bugs.python.org (Graham Dumpleton)
Date: Sun, 16 Jan 2011 00:42:03 +0000
Subject: [issue10915] Make the PyGILState API compatible with multiple
	interpreters
In-Reply-To: <1295103161.75.0.771875465176.issue10915@psf.upfronthosting.co.za>
Message-ID: <1295138523.82.0.559114316537.issue10915@psf.upfronthosting.co.za>


Graham Dumpleton <Graham.Dumpleton at gmail.com> added the comment:

The bulk of use cases is going to be simple callbacks via the same thread that called out of Python in the first place. Thus ultimately all it is doing is:

Py_BEGIN_ALLOW_THREADS

Call into some foreign C library.
C library wants to do a callback into Python.

PyGILState_STATE gstate;
gstate = PyGILState_Ensure();

/* Perform Python actions here. */
result = CallSomeFunction();
/* evaluate result or handle exception */

/* Release the thread. No Python API allowed beyond this point. */
PyGILState_Release(gstate);

More stuff in C library.
Return back into the C extension wrapper.

Py_END_ALLOW_THREADS

This is what SWIG effectively does in its generated wrappers for callbacks.

Using a TLS solution, all these modules that simply do this will now start working where as they currently usually deadlock or have other problems.

In your solution, all these modules would need to be modified to some how transfer information about the current interpreter into the callback which is called by the foreign C library and use new PyGILState_??? functions rather than the old.

I do accept that more complicated extension modules which create their own foreign threads and perform the call back into interpreter from that thread, or systems like mod_wsgi which have a persistent thread pool from which calls originate, will have to be modified, but this is the lessor use case from what I have seen.

Overall, it is an easy win if TLS is used because a lot of code wouldn't need to change. Some will, but expect that a lot of the common stuff like lxml for example wouldn't.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10915>
_______________________________________

From report at bugs.python.org  Sun Jan 16 01:50:10 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 16 Jan 2011 00:50:10 +0000
Subject: [issue10912] PyObject_RichCompare differs in behaviour from
	PyObject_RichCompareBool ; difference not noted in documentation
In-Reply-To: <1295053260.1.0.0634834443195.issue10912@psf.upfronthosting.co.za>
Message-ID: <1295139010.57.0.758659856522.issue10912@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

If something needs to be written about NaNs or other invariant destroying objects, perhaps a FAQ entry would suffice (perhaps referencing http://bertrandmeyer.com/2010/02/06/reflexivity-and-other-pillars-of-civilization/ ).

----------
assignee: docs at python -> rhettinger
keywords:  -easy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10912>
_______________________________________

From report at bugs.python.org  Sun Jan 16 01:51:59 2011
From: report at bugs.python.org (Graham Dumpleton)
Date: Sun, 16 Jan 2011 00:51:59 +0000
Subject: [issue10915] Make the PyGILState API compatible with multiple
	interpreters
In-Reply-To: <1295103161.75.0.771875465176.issue10915@psf.upfronthosting.co.za>
Message-ID: <1295139119.17.0.360470380045.issue10915@psf.upfronthosting.co.za>


Graham Dumpleton <Graham.Dumpleton at gmail.com> added the comment:

As to the comment:

"""IMO we should really promote clean APIs which allow solving the whole
problem, rather than devise an internal hack to try to "improve" things
slightly."""

The reality is that if you force a change on every single extension module doing callbacks into the interpreter without having the GIL first, you will never see people update their code as they will likely not care about this special use case. And so the whole point of adding the additional APIs will be wasted effort and have achieved nothing.

The TLS solution means many modules will work without the authors having to do anything.

You therefore have to balance between what you perceive as a cleaner API and what is actually going to see a benefit without having to wait a half dozen years before people realise they should change their ways.

BTW, TLS is currently used for current thread state for simplified GIL API, why isn't that use of TLS a hack where as doing the same for interpreter is?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10915>
_______________________________________

From report at bugs.python.org  Sun Jan 16 06:28:48 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Sun, 16 Jan 2011 05:28:48 +0000
Subject: [issue8957] strptime(.., '%c') fails to parse output of strftime('%c',
	..) in some locales
In-Reply-To: <1276115080.37.0.388300880324.issue8957@psf.upfronthosting.co.za>
Message-ID: <1295155728.37.0.715845652881.issue8957@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

Alexander, but still - this isn't just an implementation of strptime. strptime, AFAIU strptime gets the format string as a parameter and uses it to parse a date string into a "tm" struct. So why do we need to parse a date string *without* a format string in Python, resorting to heuristics and pseudo-AI instead?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8957>
_______________________________________

From report at bugs.python.org  Sun Jan 16 06:43:57 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Sun, 16 Jan 2011 05:43:57 +0000
Subject: [issue10912] PyObject_RichCompare differs in behaviour from
	PyObject_RichCompareBool ; difference not noted in documentation
In-Reply-To: <1295053260.1.0.0634834443195.issue10912@psf.upfronthosting.co.za>
Message-ID: <1295156637.54.0.324126393717.issue10912@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

Raymond, 
I initially set "easy" on this issue because I considered it a documentation issue, not the place to resolve the harder debate of the semantics of these functions. Perhaps I was wrong?

Also, I agree with Nick that the difference must be further clarified in "stronger words". If there's no debate on this issue, I will commit a fix after the freeze is over.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10912>
_______________________________________

From report at bugs.python.org  Sun Jan 16 07:01:33 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 16 Jan 2011 06:01:33 +0000
Subject: [issue10912] PyObject_RichCompare differs in behaviour from
	PyObject_RichCompareBool ; difference not noted in documentation
In-Reply-To: <1295053260.1.0.0634834443195.issue10912@psf.upfronthosting.co.za>
Message-ID: <1295157693.01.0.974517707754.issue10912@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Yes, it is a doc issue but sometimes those aren't easy to get right (in terms of being beneficial to the reader and in good alignment with the design intentions).  Please attach the doc patch you want to go in and I'll review it sometime the freeze.

----------
priority: normal -> low

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10912>
_______________________________________

From report at bugs.python.org  Sun Jan 16 08:50:08 2011
From: report at bugs.python.org (anatoly techtonik)
Date: Sun, 16 Jan 2011 07:50:08 +0000
Subject: [issue10917] PEP 333 link to CGI specification is broken
In-Reply-To: <1295164208.27.0.610516311421.issue10917@psf.upfronthosting.co.za>
Message-ID: <1295164208.27.0.610516311421.issue10917@psf.upfronthosting.co.za>


New submission from anatoly techtonik <techtonik at gmail.com>:

http://www.python.org/dev/peps/pep-0333/#id7

Link to CGI spec is broken.

----------
assignee: docs at python
components: Documentation
messages: 126361
nosy: docs at python, techtonik
priority: normal
severity: normal
status: open
title: PEP 333 link to CGI specification is broken
versions: 3rd party, Python 2.5, Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10917>
_______________________________________

From report at bugs.python.org  Sun Jan 16 10:57:38 2011
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 16 Jan 2011 09:57:38 +0000
Subject: [issue10917] PEP 333 link to CGI specification is broken
In-Reply-To: <1295164208.27.0.610516311421.issue10917@psf.upfronthosting.co.za>
Message-ID: <1295171858.61.0.0787828990538.issue10917@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Fixed in r88045 (also in PEP 3333).

----------
nosy: +georg.brandl
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10917>
_______________________________________

From report at bugs.python.org  Sun Jan 16 11:56:44 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 16 Jan 2011 10:56:44 +0000
Subject: [issue10915] Make the PyGILState API compatible with multiple
	interpreters
In-Reply-To: <1295139119.17.0.360470380045.issue10915@psf.upfronthosting.co.za>
Message-ID: <1295175399.3784.23.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> The bulk of use cases is going to be simple callbacks via the same
> thread that called out of Python in the first place. [...]
> This is what SWIG effectively does in its generated wrappers for
> callbacks.

Thanks for clarifying. I agree the TLS scheme would help in these cases.
There is still the question of what/who updates the TLS mapping; you are
proposing a new API call; an alternative is to do the mapping in e.g.
PyEval_SaveThread().

> The reality is that if you force a change on every single extension
> module doing callbacks into the interpreter without having the GIL
> first, you will never see people update their code as they will likely
> not care about this special use case. And so the whole point of adding
> the additional APIs will be wasted effort and have achieved nothing.

I'm not sure I care. If people don't want to use the new APIs on the
basis that they are slightly more complex, then it's their problem. The
Python C API tries not to be too cumbersome, but it cannot pretend to be
as transparent as a high-level API in a dynamic language.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10915>
_______________________________________

From report at bugs.python.org  Sun Jan 16 13:45:06 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 16 Jan 2011 12:45:06 +0000
Subject: [issue10915] Make the PyGILState API compatible with multiple
	interpreters
In-Reply-To: <1295103161.75.0.771875465176.issue10915@psf.upfronthosting.co.za>
Message-ID: <1295181906.09.0.689376839421.issue10915@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

There's no point improving the multiple interpreter support if it doesn't help applications that are currently broken because of that lack of support.

I believe the patch as currently proposed actually makes things *worse*. With "autoTLSkey" as a static variable, all subinterpreters will use the same key to point into thread local storage (which is defined process-wide). This means they won't tread on each other's toes: the interpreter that creates a thread owns that thread. So Graham's simple use case *should already work*, as the creation of the thread by the subinterpreter will populate autoTLSkey with a valid thread state, which will then be used by calls back in to the GILState API.

Looking at 3.2, there appear to be two ways for an application to get itself into trouble:

1. Hand off an OS level thread from the creating interpreter to a different subinterpreter. As far as I can tell, calling GILState_Ensure in such a thread will still acquire the GIL of the creating interpreter (or something equally nonsensical). I may be misreading that though - this isn't exactly the easiest part of the code base to follow :)

2. Native (non-Python) threads will always have their temporary thread state created in the main interpreter unless the application takes steps to precreate a thread state using a different interpreter.

So, a new PyGILState_EnsureEx API may be beneficial regardless in order to help with part 2 of the problem, but I think it should be used solely as a way to override "autoInterpreterState". "autoTLSkey" should be left alone so that a given OS level thread can only be owned by one interpreter at a time.

Further, there is no need for any function with access to a valid thread state (i.e. _PyGILState_NoteThreadState, as well as PyGILState_Release if autoTLSkey remains a static variable) to take an interpreter argument. These functions can identify the relevant interpreter from the "interp" field of the thread state.

TL;DR version:
- I agree the compatibility between multiple interpreters and the GILState API can be improved
- I agree a PyGILState_EnsureEx that takes an interpreter argument should be part of that solution.
- I *disagree* with making autoTLSkey interpreter specific, as it seems to me that will make the situation worse rather than better.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10915>
_______________________________________

From report at bugs.python.org  Sun Jan 16 13:53:28 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 16 Jan 2011 12:53:28 +0000
Subject: [issue2275] urllib/httplib header capitalization
In-Reply-To: <1205270540.47.0.336665756101.issue2275@psf.upfronthosting.co.za>
Message-ID: <1295182408.18.0.0658572182459.issue2275@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Title case is not the right thing for all headers: TE, WWW-Authenticate, etc.

While we're changing this, why not implement something to return headers in the order recommended in the RFC?  (Probably another feature request)

----------
nosy: +eric.araujo
stage:  -> patch review
title: urllib2 header capitalization -> urllib/httplib header capitalization
versions: +Python 3.3 -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2275>
_______________________________________

From report at bugs.python.org  Sun Jan 16 13:59:00 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 16 Jan 2011 12:59:00 +0000
Subject: [issue10915] Make the PyGILState API compatible with multiple
	interpreters
In-Reply-To: <1295103161.75.0.771875465176.issue10915@psf.upfronthosting.co.za>
Message-ID: <1295182740.48.0.293390348695.issue10915@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Added Mark Hammond to the nosy list, as the original author and implementor of PEP 311 (which added the GILState APIs).

Mark, since your PEP deliberately punted on multiple interpreter support, feel free to take yourself off the list again. If you spot any glaring errors in my post above it would be nice to know, though :)

----------
nosy: +mhammond

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10915>
_______________________________________

From report at bugs.python.org  Sun Jan 16 16:49:52 2011
From: report at bugs.python.org (Adrian Dries)
Date: Sun, 16 Jan 2011 15:49:52 +0000
Subject: [issue10918] **kwargs unnecessarily restricted in API
In-Reply-To: <1295192992.12.0.880697566702.issue10918@psf.upfronthosting.co.za>
Message-ID: <1295192992.12.0.880697566702.issue10918@psf.upfronthosting.co.za>


New submission from Adrian Dries <adries at gmail.com>:

An API such as in, e.g. futures:

   def submit(self, fn, *args, **kwargs):
       pass

cannot be used thus:

submit(foo, 1, 2, fn=bar)

I can see two options: either mangle the named parameters:

    def submit(__self, __fn, *args, **kwargs):
        pass

Or fiddle with *args:

    def submit(*args, **kwargs):
        self, fn = args[:2]
        args = args[2:]

----------
components: Library (Lib)
messages: 126367
nosy: avdd
priority: normal
severity: normal
status: open
title: **kwargs unnecessarily restricted in API
type: behavior
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10918>
_______________________________________

From report at bugs.python.org  Sun Jan 16 17:04:55 2011
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 16 Jan 2011 16:04:55 +0000
Subject: [issue10918] **kwargs unnecessarily restricted in API
In-Reply-To: <1295192992.12.0.880697566702.issue10918@psf.upfronthosting.co.za>
Message-ID: <1295193895.21.0.404330580351.issue10918@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
assignee:  -> bquinlan
nosy: +bquinlan
versions: +Python 3.3 -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10918>
_______________________________________

From report at bugs.python.org  Sun Jan 16 19:23:30 2011
From: report at bugs.python.org (Richard Nienaber)
Date: Sun, 16 Jan 2011 18:23:30 +0000
Subject: [issue10919] Environment variables are not expanded in _winreg when
	using REG_EXPAND_SZ.
In-Reply-To: <1295202210.05.0.625952484383.issue10919@psf.upfronthosting.co.za>
Message-ID: <1295202210.05.0.625952484383.issue10919@psf.upfronthosting.co.za>


New submission from Richard Nienaber <rjnienaber at gmail.com>:

According to Microsoft documentation (http://msdn.microsoft.com/en-us/library/ms724884(v=vs.85).aspx) when using the REG_EXPAND_SZ value type, environment variables (e.g. %programfiles%) should be expanded to their values (e.g. 'C:\Program Files'). 

I've added a test case that reproduces this error.

----------
components: Library (Lib)
files: testcase-24042.py
messages: 126368
nosy: rjnienaber
priority: normal
severity: normal
status: open
title: Environment variables are not expanded in _winreg when using REG_EXPAND_SZ.
versions: Python 2.7
Added file: http://bugs.python.org/file20418/testcase-24042.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10919>
_______________________________________

From report at bugs.python.org  Sun Jan 16 20:06:31 2011
From: report at bugs.python.org (Brian Curtin)
Date: Sun, 16 Jan 2011 19:06:31 +0000
Subject: [issue10919] Environment variables are not expanded in _winreg when
	using REG_EXPAND_SZ.
In-Reply-To: <1295202210.05.0.625952484383.issue10919@psf.upfronthosting.co.za>
Message-ID: <1295204791.04.0.361713026279.issue10919@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

Assigning to myself.
Relevant IronPython issue: http://ironpython.codeplex.com/workitem/24042

----------
assignee:  -> brian.curtin
components: +Extension Modules, Windows -Library (Lib)
nosy: +brian.curtin
stage:  -> needs patch
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10919>
_______________________________________

From report at bugs.python.org  Sun Jan 16 20:47:42 2011
From: report at bugs.python.org (Jean-Michel Fauth)
Date: Sun, 16 Jan 2011 19:47:42 +0000
Subject: [issue10920] cp65001, PowerShell, Python crash.
In-Reply-To: <1295207262.38.0.033573856036.issue10920@psf.upfronthosting.co.za>
Message-ID: <1295207262.38.0.033573856036.issue10920@psf.upfronthosting.co.za>


New submission from Jean-Michel Fauth <wxjmfauth at gmail.com>:

Just relying a discussion open on comp.lang.python,
http://groups.google.com/group/comp.lang.python/browse_thread/thread/771aa9081ad6584c#

1) Windows 7, open PowerShell
2) Change code page to cp65001
3) Launch Python3.1.2 or Python3.2.rc1 -> crash

Key points:
- The fact that Python does not recognize cp65001 is "ok".
- The Python crash is unexpected.

----------
components: Windows
messages: 126370
nosy: Jean-Michel.Fauth
priority: normal
severity: normal
status: open
title: cp65001, PowerShell, Python crash.
type: crash
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10920>
_______________________________________

From report at bugs.python.org  Sun Jan 16 21:01:49 2011
From: report at bugs.python.org (anatoly techtonik)
Date: Sun, 16 Jan 2011 20:01:49 +0000
Subject: [issue10917] PEP 333 link to CGI specification is broken
In-Reply-To: <1295164208.27.0.610516311421.issue10917@psf.upfronthosting.co.za>
Message-ID: <1295208109.92.0.810417676682.issue10917@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

w00t

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10917>
_______________________________________

From report at bugs.python.org  Sun Jan 16 21:19:42 2011
From: report at bugs.python.org (Matthew Barnett)
Date: Sun, 16 Jan 2011 20:19:42 +0000
Subject: [issue2636] Regexp 2.7 (modifications to current re 2.2.2)
In-Reply-To: <1208260672.14.0.711874677361.issue2636@psf.upfronthosting.co.za>
Message-ID: <1295209182.66.0.572646878616.issue2636@psf.upfronthosting.co.za>


Matthew Barnett <python at mrabarnett.plus.com> added the comment:

That line crept in somehow.

As it's been there since the 2010-12-24 release and you're the first one to have a problem with it (and you've already fixed it), it looks like a new upload isn't urgently needed (I don't have any other changes to make at present).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2636>
_______________________________________

From report at bugs.python.org  Sun Jan 16 22:18:00 2011
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 16 Jan 2011 21:18:00 +0000
Subject: [issue10917] PEP 333 link to CGI specification is broken
In-Reply-To: <1295164208.27.0.610516311421.issue10917@psf.upfronthosting.co.za>
Message-ID: <1295212680.74.0.0314135093219.issue10917@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Not sure I understand you...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10917>
_______________________________________

From report at bugs.python.org  Sun Jan 16 22:30:21 2011
From: report at bugs.python.org (anatoly techtonik)
Date: Sun, 16 Jan 2011 21:30:21 +0000
Subject: [issue10917] PEP 333 link to CGI specification is broken
In-Reply-To: <1295164208.27.0.610516311421.issue10917@psf.upfronthosting.co.za>
Message-ID: <1295213421.74.0.49946260318.issue10917@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

Nevermind. It's just another word for gr8.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10917>
_______________________________________

From report at bugs.python.org  Sun Jan 16 22:31:59 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 16 Jan 2011 21:31:59 +0000
Subject: [issue10917] PEP 333 link to CGI specification is broken
In-Reply-To: <1295164208.27.0.610516311421.issue10917@psf.upfronthosting.co.za>
Message-ID: <1295213519.36.0.859150848618.issue10917@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Well, that really grates on the eyes.

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10917>
_______________________________________

From report at bugs.python.org  Sun Jan 16 22:35:35 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 16 Jan 2011 21:35:35 +0000
Subject: [issue10917] PEP 333 link to CGI specification is broken
In-Reply-To: <1295213421.74.0.49946260318.issue10917@psf.upfronthosting.co.za>
Message-ID: <AANLkTi=TD+ggk48QZKgCt7tX0LfgVHrM+kBdQhAhV6dW@mail.gmail.com>


Benjamin Peterson <benjamin at python.org> added the comment:

2011/1/16 anatoly techtonik <report at bugs.python.org>:
>
> anatoly techtonik <techtonik at gmail.com> added the comment:
>
> Nevermind. It's just another word for gr8.

Well, it really grates on the eyes.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10917>
_______________________________________

From report at bugs.python.org  Sun Jan 16 23:01:47 2011
From: report at bugs.python.org (anatoly techtonik)
Date: Sun, 16 Jan 2011 22:01:47 +0000
Subject: [issue10917] PEP 333 link to CGI specification is broken
In-Reply-To: <1295164208.27.0.610516311421.issue10917@psf.upfronthosting.co.za>
Message-ID: <1295215307.95.0.830768119533.issue10917@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

No surprises. Core Python community is so old that it is unlikely that people there ever experienced online gameplay. The only online game they've ever installed was probably EVE Online and if they've installed it - that was just because Stackless wiki is not sane enough in describing all awesomeness of this Python flavor. But it is more likely in this situation that they've just watched CCP videos. =)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10917>
_______________________________________

From report at bugs.python.org  Sun Jan 16 23:09:25 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 16 Jan 2011 22:09:25 +0000
Subject: [issue10920] cp65001, PowerShell, Python crash.
In-Reply-To: <1295207262.38.0.033573856036.issue10920@psf.upfronthosting.co.za>
Message-ID: <1295215765.81.0.983829697524.issue10920@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +haypo
priority: normal -> high

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10920>
_______________________________________

From report at bugs.python.org  Sun Jan 16 23:11:22 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 16 Jan 2011 22:11:22 +0000
Subject: [issue10920] cp65001, PowerShell, Python crash.
In-Reply-To: <1295207262.38.0.033573856036.issue10920@psf.upfronthosting.co.za>
Message-ID: <1295215882.28.0.886314265864.issue10920@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Probably a legitimate "crash" (aka deliberate abort), since Python needs an encoding for its standard input/output text streams, and the encoding suggested by the system ("cp65001") isn't supported.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10920>
_______________________________________

From report at bugs.python.org  Sun Jan 16 23:12:48 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 16 Jan 2011 22:12:48 +0000
Subject: [issue10911] cgi: add more tests
In-Reply-To: <1295040877.8.0.0807786274615.issue10911@psf.upfronthosting.co.za>
Message-ID: <1295215968.83.0.162284583342.issue10911@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
type:  -> feature request
versions: +Python 3.3 -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10911>
_______________________________________

From report at bugs.python.org  Sun Jan 16 23:16:20 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 16 Jan 2011 22:16:20 +0000
Subject: [issue10920] cp65001, PowerShell, Python crash.
In-Reply-To: <1295207262.38.0.033573856036.issue10920@psf.upfronthosting.co.za>
Message-ID: <1295216180.3.0.179754747796.issue10920@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> PS D:\jm> chcp 65001 
> Page de codes active : 65001 

Please don't do that: it is useless (it doesn't help to display or read more unicode characters) and it breaks Windows console: see issue #1602 (especially msg120414 and msg126303), and maybe also issue #6058.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10920>
_______________________________________

From report at bugs.python.org  Sun Jan 16 23:16:47 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sun, 16 Jan 2011 22:16:47 +0000
Subject: [issue10914] Python sub-interpreter test
In-Reply-To: <1295098719.73.0.016388283782.issue10914@psf.upfronthosting.co.za>
Message-ID: <1295216207.89.0.321624350458.issue10914@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

+1 for this kind of tests. 
But I would not have their source in the "official" Modules directory. I expect that there will be several tests of this kind, each one with different modules to import, functions to run, global settings to change.
IMO the C code should be somewhere in the test directory; later we could use templates to generate source code for similar tests.

Is it possible to use distutils to compile this test, and remove it from the Makefile?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10914>
_______________________________________

From report at bugs.python.org  Sun Jan 16 23:19:29 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 16 Jan 2011 22:19:29 +0000
Subject: [issue10920] cp65001, PowerShell, Python crash.
In-Reply-To: <1295207262.38.0.033573856036.issue10920@psf.upfronthosting.co.za>
Message-ID: <1295216369.97.0.785959601481.issue10920@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

If the "crash" is the following message, this issue is a duplicate of  #6058.
---
PS D:\jm> c:\python31\python.exe 
Fatal Python error: Py_Initialize: can't initialize sys standard 
streams 
LookupError: unknown encoding: cp65001
---
It is not a crash: Python has no codec for the code page 65001, that's all. I closed #6058 because cp65001 cannot be set as an alias to utf-8. Anyway, use 65001 as console encoding is not a good idea. I close this issue: see #1602 for more information.

----------
resolution:  -> duplicate

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10920>
_______________________________________

From report at bugs.python.org  Sun Jan 16 23:27:20 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 16 Jan 2011 22:27:20 +0000
Subject: [issue10914] Python sub-interpreter test
In-Reply-To: <1295098719.73.0.016388283782.issue10914@psf.upfronthosting.co.za>
Message-ID: <1295216840.64.0.733502475062.issue10914@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

There's already precedent for test modules in Modules/ what with xxmodule.c and _testcapimodule.c.

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10914>
_______________________________________

From report at bugs.python.org  Sun Jan 16 23:28:13 2011
From: report at bugs.python.org (Richard Nienaber)
Date: Sun, 16 Jan 2011 22:28:13 +0000
Subject: [issue10919] Environment variables are not expanded in _winreg when
	using REG_EXPAND_SZ.
In-Reply-To: <1295202210.05.0.625952484383.issue10919@psf.upfronthosting.co.za>
Message-ID: <1295216893.66.0.198895472646.issue10919@psf.upfronthosting.co.za>


Richard Nienaber <rjnienaber at gmail.com> added the comment:

Further documentation on the RegEnumValue function (used by the _winreg module): http://msdn.microsoft.com/en-us/library/ms724865(v=vs.85).aspx. The documentation doesn't say whether the string is expanded or not on retrieval. 

Given the current behaviour plus the ExpandEnvironmentStrings function, this seems like a non-issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10919>
_______________________________________

From report at bugs.python.org  Sun Jan 16 23:32:59 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 16 Jan 2011 22:32:59 +0000
Subject: [issue10914] Python sub-interpreter test
In-Reply-To: <1295216207.89.0.321624350458.issue10914@psf.upfronthosting.co.za>
Message-ID: <1295217171.3683.1.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Is it possible to use distutils to compile this test, and remove it
> from the Makefile?

I'm not aware that distutils is able to compile applications rather than
extension modules, but that would certainly be better than a rule in the
Makefile, yes.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10914>
_______________________________________

From report at bugs.python.org  Sun Jan 16 23:46:51 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sun, 16 Jan 2011 22:46:51 +0000
Subject: [issue10914] Python sub-interpreter test
In-Reply-To: <1295098719.73.0.016388283782.issue10914@psf.upfronthosting.co.za>
Message-ID: <1295218011.47.0.59353819638.issue10914@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

In distutils.command.config, config().try_run(body) is probably what we need. Now, I don't know how to use it...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10914>
_______________________________________

From report at bugs.python.org  Mon Jan 17 00:32:36 2011
From: report at bugs.python.org (Joe Peterson)
Date: Sun, 16 Jan 2011 23:32:36 +0000
Subject: [issue10921] imaplib: Internaldate2tuple crashes,
	does not handle negative TZ offsets,
	does not handle DST correctly, and outputs localtime (not UTC)
In-Reply-To: <1295220756.66.0.509737296044.issue10921@psf.upfronthosting.co.za>
Message-ID: <1295220756.66.0.509737296044.issue10921@psf.upfronthosting.co.za>


New submission from Joe Peterson <joe at skyrush.com>:

Internaldate2tuple() is broken in several ways.  The last two issues have existed in the code for some time.

New issues in Python 3:

1. It crashes with "KeyError".  This is because the Mon2num dictionary's keys are strings, not bytes objects (note that other strings in imaplib have been updated, but not Mon2num).

2. The sign of the TZ offset (e.g. -0700) is compared to the string '-', not b'-', so the compare is never true, causing a large error when TZ offset is negative.

Left over from Python 2.x:

3. DST is not handled correctly.  Specifically, when the date is such that its local time form and its UTC form (if both interpreted as local time) are on different sides of a DST changeover, the result will be off by one hour.  This is because the check for DST is done after treating the time as local time, even if it is not local time, causing it be tested while sometimes on the wrong side of a DST change.  This can be corrected by using calls that keep time in UTC.

4. Related to #3, the result is returned in local time, whereas the documentation states that the result is in UT.  The fix for #3 takes care of this one, as well.

Here is an example:  Run the following two dates, that represent exactly the same time, through Internaldate2tuple:

'25 (INTERNALDATE "01-Apr-2000 19:02:23 -0700")'
'101 (INTERNALDATE "02-Apr-2000 02:02:23 +0000")'

Once the Mon2num issue is fixed, Python 3 will perform the conversions, but with a 15 hour difference.  Python 2 will produce results with a one hour difference.

Note that the last two issues (but describing only #4 above) were also addressed in a similar way in an old post I found by Colin Brown in 2004 (http://www.velocityreviews.com/forums/t336162-imaplib-function-bug.html).

----------
components: Library (Lib)
files: imaplib_Internaldate2tuple.patch
keywords: patch
messages: 126386
nosy: lavajoe
priority: normal
severity: normal
status: open
title: imaplib: Internaldate2tuple crashes, does not handle negative TZ offsets, does not handle DST correctly, and outputs localtime (not UTC)
versions: Python 3.2
Added file: http://bugs.python.org/file20419/imaplib_Internaldate2tuple.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10921>
_______________________________________

From report at bugs.python.org  Mon Jan 17 00:32:46 2011
From: report at bugs.python.org (Joe Peterson)
Date: Sun, 16 Jan 2011 23:32:46 +0000
Subject: [issue10921] imaplib: Internaldate2tuple crashes,
	does not handle negative TZ offsets,
	does not handle DST correctly, and outputs localtime (not UTC)
In-Reply-To: <1295220756.66.0.509737296044.issue10921@psf.upfronthosting.co.za>
Message-ID: <1295220766.24.0.00624480057524.issue10921@psf.upfronthosting.co.za>


Changes by Joe Peterson <joe at skyrush.com>:


----------
type:  -> crash

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10921>
_______________________________________

From report at bugs.python.org  Mon Jan 17 00:35:50 2011
From: report at bugs.python.org (Joe Peterson)
Date: Sun, 16 Jan 2011 23:35:50 +0000
Subject: [issue10921] imaplib: Internaldate2tuple() crashes,
	does not handle negative TZ offsets,
	does not handle DST correctly, and outputs localtime (not UTC)
In-Reply-To: <1295220756.66.0.509737296044.issue10921@psf.upfronthosting.co.za>
Message-ID: <1295220950.26.0.0335973024036.issue10921@psf.upfronthosting.co.za>


Changes by Joe Peterson <joe at skyrush.com>:


----------
title: imaplib: Internaldate2tuple crashes, does not handle negative TZ offsets, does not handle DST correctly, and outputs localtime (not UTC) -> imaplib: Internaldate2tuple() crashes, does not handle negative TZ offsets, does not handle DST correctly, and outputs localtime (not UTC)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10921>
_______________________________________

From report at bugs.python.org  Mon Jan 17 01:55:13 2011
From: report at bugs.python.org (Graham Dumpleton)
Date: Mon, 17 Jan 2011 00:55:13 +0000
Subject: [issue10915] Make the PyGILState API compatible with multiple
	interpreters
In-Reply-To: <1295103161.75.0.771875465176.issue10915@psf.upfronthosting.co.za>
Message-ID: <1295225713.64.0.986394317058.issue10915@psf.upfronthosting.co.za>


Graham Dumpleton <Graham.Dumpleton at gmail.com> added the comment:

Nick, I think you are making the wrong assumption that an external threads will only ever call into the same interpreter. This is not the case. In mod_wsgi and mod_python there is a pool of external threads that for distinct HTTP requests, delegated to a specific thread, can make calls into different interpreters. This is all fine so long as you ensure that for each thread, it uses a distinct thread state for that thread for each interpreter. In other words, you cant use the same thread state instance across multiple interpreters as it is bound to a specific interpreter.

This is because autoInterpreterState is always going to be set to the main interpreter. This means that when the thread is calling into a new sub interpreter it will either inherit via current GIL state API an existing thread state bound to the main interpreter, or if one is created, will still get bound to the main interpreter. As soon as you start using a thread state bound to one interpreter against another, problems start occurring.

After thinking about this all some more I believe now what is needed is a mix of the TLS idea for current interpreter state that I am suggesting and in part the extended GIL state functions that Antoine describes.

So, the TLS records what interpreter a thread is currently running against so that GIL state APIs work for existing unmodified extension modules. At the same time though, you still need a way of switching what interpreter a thread is running against. For the latter, various of the thread state related functions that exist already could do this automatically. In some cases you will still need the extended function for acquisition that Antoine suggested.

Consider a few scenarios of usage.

First off, when an external thread calls PyInterpreter_New(), it creates a new thread state object against that new sub interpreter automatically and returns it. With this new systems, it would also automatically update the TLS for the current thread to be that new interpreter also. That way when it calls into Python which then calls back out to code which releases the GIL and then calls back in through PyGILState_Ensure(), with no arguments, it will work. This obviously implies though that PyGILState_Ensure() makes use of the TLS for the interpreter being used and isn't hard wired to the main interpreter like it is now.

Second, consider some of the other API functions such as PyThreadState_Swap(). When passing it a non NULL pointer, you are giving it a thread state object which is already bound to an interpreter. It thus can also update the TLS for the interpreter automatically. If you pass it a NULL then it clears the TLS with all functions later that rely on that TLS asserting that it is not NULL when used. Another similar case where TLS can be auto updated is functions which clear/delete an interpreter state and leave GIL unlocked at the end. These also would clear the TLS.

So, it is possible that that no new API functions may be needed to manage the TLS for what interpreter is associated with the current thread, as I thought, as existing API functions can do that management themselves transparently.

The third and final scenario, and the one where the extended GIL state functions for Ensure is still required, is where code doesn't have the GIL as yet and wants to make a call into sub interpreter rather than the main interpreter, where it already has a pointer to the sub interpreter and nothing more. In this case the new PyGILState_EnsureEx() function is used, with the sub interpreter being passed as argument.

The beauty of existing API functions of PyThreadState_Swap() etc managing the TLS for the interpreter is that the only code that needs to change is the embedded systems which are creating and using multiple interpreters in the first place. In other words, mod_wsgi would need to change, with it simply replacing all the equivalent stuff it already has for doing what PyGILState_??? functions do now but against sub interpreters. If I am right, all extension modules that don't really care about whether sub interpreters are being used should work without modification.

Oh, and I also think you probably don't need PyGILState_ReleaseEx() if all made TLS aware, just the single PyGILState_EnsureEx() is needed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10915>
_______________________________________

From report at bugs.python.org  Mon Jan 17 02:46:38 2011
From: report at bugs.python.org (Joe Peterson)
Date: Mon, 17 Jan 2011 01:46:38 +0000
Subject: [issue10921] imaplib: Internaldate2tuple() crashes,
	does not handle negative TZ offsets, does not handle DST correctly
In-Reply-To: <1295220756.66.0.509737296044.issue10921@psf.upfronthosting.co.za>
Message-ID: <1295228798.1.0.908043955064.issue10921@psf.upfronthosting.co.za>


Joe Peterson <joe at skyrush.com> added the comment:

Regarding problem #4, it actually appears that returning local time is the right thing to do, since it matches the behavior of Time2Internaldate().  Returning UTC, as the doc states, would potentially break IMAP append() that can include an internaldate possibly returned from Internaldate2tuple() in typical usage (like when copying messages).  In this case, the doc is wrong on Internaldate2tuple().

I have attached a new patch to both the code and doc that replaces the old patch.  I now return localtime rather than gmtime, but other than that, the DST fix remains the same and now handles the cases near DST changes correctly.

Ultimately, it might be desirable to be able always stay in UTC, so perhaps adding UTC variants of both Internaldate2tuple() and Time2Internaldate() (and a UTC option to append()) would be a good enhancement for later.

----------
assignee:  -> docs at python
components: +Documentation
nosy: +docs at python
title: imaplib: Internaldate2tuple() crashes, does not handle negative TZ offsets, does not handle DST correctly, and outputs localtime (not UTC) -> imaplib: Internaldate2tuple() crashes, does not handle negative TZ offsets, does not handle DST correctly
Added file: http://bugs.python.org/file20420/imaplib_Internaldate2tuple.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10921>
_______________________________________

From report at bugs.python.org  Mon Jan 17 02:47:26 2011
From: report at bugs.python.org (Joe Peterson)
Date: Mon, 17 Jan 2011 01:47:26 +0000
Subject: [issue10921] imaplib: Internaldate2tuple() crashes,
	does not handle negative TZ offsets, does not handle DST correctly
In-Reply-To: <1295220756.66.0.509737296044.issue10921@psf.upfronthosting.co.za>
Message-ID: <1295228846.21.0.383315979207.issue10921@psf.upfronthosting.co.za>


Changes by Joe Peterson <joe at skyrush.com>:


Removed file: http://bugs.python.org/file20419/imaplib_Internaldate2tuple.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10921>
_______________________________________

From report at bugs.python.org  Mon Jan 17 02:51:59 2011
From: report at bugs.python.org (Joe Peterson)
Date: Mon, 17 Jan 2011 01:51:59 +0000
Subject: [issue10921] imaplib: Internaldate2tuple() crashes,
	does not handle negative TZ offsets, does not handle DST correctly
In-Reply-To: <1295220756.66.0.509737296044.issue10921@psf.upfronthosting.co.za>
Message-ID: <1295229119.99.0.321038987335.issue10921@psf.upfronthosting.co.za>


Changes by Joe Peterson <joe at skyrush.com>:


----------
components:  -Documentation

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10921>
_______________________________________

From report at bugs.python.org  Mon Jan 17 02:53:07 2011
From: report at bugs.python.org (Joe Peterson)
Date: Mon, 17 Jan 2011 01:53:07 +0000
Subject: [issue10921] imaplib: Internaldate2tuple() crashes,
	does not handle negative TZ offsets, does not handle DST correctly
In-Reply-To: <1295220756.66.0.509737296044.issue10921@psf.upfronthosting.co.za>
Message-ID: <1295229187.05.0.0264366733183.issue10921@psf.upfronthosting.co.za>


Changes by Joe Peterson <joe at skyrush.com>:


----------
components: +Documentation

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10921>
_______________________________________

From report at bugs.python.org  Mon Jan 17 03:10:18 2011
From: report at bugs.python.org (=?utf-8?q?Daniel_Neuh=C3=A4user?=)
Date: Mon, 17 Jan 2011 02:10:18 +0000
Subject: [issue10922] Unexpected exception when calling
	function_proxy.__class__.__call__(function_proxy)
In-Reply-To: <1295230218.02.0.641570555776.issue10922@psf.upfronthosting.co.za>
Message-ID: <1295230218.02.0.641570555776.issue10922@psf.upfronthosting.co.za>


New submission from Daniel Neuh?user <dasdasich at googlemail.com>:

Upon trying to create a proxy I stumbled upon this exception:

Traceback (most recent call last):
  File "foo.py", line 11, in <module>
    p.__class__.__call__(p)
SystemError: PyEval_EvalCodeEx: NULL globals

Investigating further led me to this code which reproduces the exception:

class Proxy(object):
    def __init__(self, proxied):
        self.proxied = proxied
    @property
    def __class__(self):
        return self.proxied.__class__
    def __call__(self):
        return self.proxied.__call__()

p = Proxy(lambda: 1)
p.__class__.__call__(p)

I understand that `p.__class__.__call__()` expects an argument of a different type however this is not obvious from the exception itself. PyPy on the other hand raises this exception:

Traceback (most recent call last):
  File "app_main.py", line 53, in run_toplevel
  File "foo.py", line 11, in <module>
    p.__class__.__call__(p)
TypeError: 'function' object expected, got 'Proxy' instead

Which explains the issue and is expected (at least by me) and apparently Jython raises an exception at least similar to PyPy's.

----------
components: Interpreter Core
messages: 126389
nosy: DasIch
priority: normal
severity: normal
status: open
title: Unexpected exception when calling function_proxy.__class__.__call__(function_proxy)
type: behavior
versions: Python 2.5, Python 2.6, Python 2.7, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10922>
_______________________________________

From report at bugs.python.org  Mon Jan 17 03:17:33 2011
From: report at bugs.python.org (=?utf-8?q?Piotr_Ma=C5=9Blanka?=)
Date: Mon, 17 Jan 2011 02:17:33 +0000
Subject: [issue10923] Python 2.7 hangs on Unicode+threading
In-Reply-To: <1295230653.16.0.00822246437847.issue10923@psf.upfronthosting.co.za>
Message-ID: <1295230653.16.0.00822246437847.issue10923@psf.upfronthosting.co.za>


New submission from Piotr Ma?lanka <piotr.maslanka at henrietta.com.pl>:

Python 2.7.1(x86 MSI), binary downloaded from python.org, hangs quite reliably. Code:

with open(threadspecific, 'ab') as x:
 txt = unicode(str_or_unicode_parameter).encode('utf8')
 x.write(txt+'\r\n')

However, it doesn't hang if I insert a print statement between with and txt, with anything. Previous testing determined that it hangs on encode().

Aforementioned code is executed in a threading environment, and it hangs in thread that is spawned by master thread. Interpreter is left with an open file.

Same behaviour is repeatable on Python 2.5.1.

----------
components: None
messages: 126390
nosy: henrietta
priority: normal
severity: normal
status: open
title: Python 2.7 hangs on Unicode+threading
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10923>
_______________________________________

From report at bugs.python.org  Mon Jan 17 03:50:18 2011
From: report at bugs.python.org (=?utf-8?q?Andreas_St=C3=BChrk?=)
Date: Mon, 17 Jan 2011 02:50:18 +0000
Subject: [issue10922] Unexpected exception when calling
	function_proxy.__class__.__call__(function_proxy)
In-Reply-To: <1295230218.02.0.641570555776.issue10922@psf.upfronthosting.co.za>
Message-ID: <1295232618.79.0.667282638529.issue10922@psf.upfronthosting.co.za>


Andreas St?hrk <andy-python at hammerhartes.de> added the comment:

I think this is a duplicate of issue #9756: `methoddescr_call()` checks whether the given argument is acceptable as "self" argument and does so using `PyObject_IsInstance()`. As the class in the given code returns the type of the proxied object for the `__class__` attribute, that check will return true.

As a quick fix, the attached patch (against release27-maint branch) will raise a TypeError as expected by the OP, but the real issue is much broader.

----------
keywords: +patch
nosy: +Trundle
Added file: http://bugs.python.org/file20421/check_is_func.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10922>
_______________________________________

From report at bugs.python.org  Mon Jan 17 04:07:45 2011
From: report at bugs.python.org (=?utf-8?q?Piotr_Ma=C5=9Blanka?=)
Date: Mon, 17 Jan 2011 03:07:45 +0000
Subject: [issue10923] Python 2.7 hangs on Unicode+threading
In-Reply-To: <1295230653.16.0.00822246437847.issue10923@psf.upfronthosting.co.za>
Message-ID: <1295233665.64.0.771906138788.issue10923@psf.upfronthosting.co.za>


Piotr Ma?lanka <piotr.maslanka at henrietta.com.pl> added the comment:

I runned it over again with code:

print 'Acquiring lock'
self.loglock.acquire()
print 'Attempting to convert'
if type(text) == unicode: text = text.encode('utf8', errors='strict')
print 'Opening '+threadspecific
with open(threadspecific, 'ab') as x: x.write(text+'\r\n')
print 'Closing '+threadspecific
self.loglock.release()
print 'Releasing lock'

It behaves erratically, sometimes working and yielding:
Acquiring lock
Acquiring lock
Attempting to convert
Opening threadspecific_master
Closing threadspecific_master
Releasing lock
Attempting to convert
Opening threadspecific_slave
Closing threadspecific_slave
Releasing lock

And sometimes hanging with:

Acquiring lock
Attempting to convert
Acquiring lock

Looks like a particularly nasty race condition. It gives off no exceptions. Platform is Windows 7 x64, running with admin privileges.

----------
type:  -> crash

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10923>
_______________________________________

From report at bugs.python.org  Mon Jan 17 08:06:37 2011
From: report at bugs.python.org (Sean Reifschneider)
Date: Mon, 17 Jan 2011 07:06:37 +0000
Subject: [issue10924] Adding salt and Modular Crypt Format to crypt library.
In-Reply-To: <1295247997.49.0.7150272714.issue10924@psf.upfronthosting.co.za>
Message-ID: <1295247997.49.0.7150272714.issue10924@psf.upfronthosting.co.za>


New submission from Sean Reifschneider <jafo at tummy.com>:

Over the years I've written the same code over and over to create a random salt string of 2 characters.  Worse, the Modular Crypt Format is difficult to find documentation on, so creating stronger hashed passwords is difficult to get right.

To that end, I'm proposing the addition of a "mksalt()" method which will generate a salt, and several METHOD_* values to select which hashing method to use.

I also figure there will need to be a "methods()" call that figures out what methods are available in the library crypt() and return a list of the available ones.

If we have a way to generate a salt, then I figure we could drop the salt argument of crypt.crypt(), and if not specified to generate one.  So to hash a password you could do: "crypt.crypt('password')".

I figure that the best way to accomplish this is to implement this all in Python and move the existing C crypt module to _crypt.

A patch accomplishing this is attached.  Please review.

Attached is a patch to accomplish this.

----------
components: Library (Lib)
files: python-underscore_crypt.patch
keywords: easy, needs review, patch
messages: 126393
nosy: jafo
priority: normal
severity: normal
stage: patch review
status: open
title: Adding salt and Modular Crypt Format to crypt library.
type: feature request
versions: Python 3.3
Added file: http://bugs.python.org/file20422/python-underscore_crypt.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10924>
_______________________________________

From report at bugs.python.org  Mon Jan 17 10:59:35 2011
From: report at bugs.python.org (Brian Quinlan)
Date: Mon, 17 Jan 2011 09:59:35 +0000
Subject: [issue10918] **kwargs unnecessarily restricted in API
In-Reply-To: <1295192992.12.0.880697566702.issue10918@psf.upfronthosting.co.za>
Message-ID: <1295258375.65.0.104113659585.issue10918@psf.upfronthosting.co.za>


Brian Quinlan <brian at sweetapp.com> added the comment:

Arian,

This seems like such an unimportant edge case that I don't want to mess with the API just to accommodate it.

If you really need to pass an "fn" keyword argument, use:

.submit(foo, 1, 2, **{'fn': bar})

----------
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10918>
_______________________________________

From report at bugs.python.org  Mon Jan 17 12:36:08 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 17 Jan 2011 11:36:08 +0000
Subject: [issue10924] Adding salt and Modular Crypt Format to crypt library.
In-Reply-To: <1295247997.49.0.7150272714.issue10924@psf.upfronthosting.co.za>
Message-ID: <1295264168.8.0.221034106201.issue10924@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <rhettinger at users.sourceforge.net>:


----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10924>
_______________________________________

From report at bugs.python.org  Mon Jan 17 12:36:45 2011
From: report at bugs.python.org (Adrian Dries)
Date: Mon, 17 Jan 2011 11:36:45 +0000
Subject: [issue10918] **kwargs unnecessarily restricted in API
In-Reply-To: <1295192992.12.0.880697566702.issue10918@psf.upfronthosting.co.za>
Message-ID: <1295264205.53.0.00528795417101.issue10918@psf.upfronthosting.co.za>


Adrian Dries <adries at gmail.com> added the comment:

What now?

Python 3.1.3 (r313:86834, Jan 17 2011, 22:33:40) 
[GCC 4.4.1] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> def foo(f, **kw):
...     pass
... 
>>> foo(1, **{'f': 2})
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: foo() got multiple values for keyword argument 'f'
>>>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10918>
_______________________________________

From report at bugs.python.org  Mon Jan 17 12:43:45 2011
From: report at bugs.python.org (Brian Quinlan)
Date: Mon, 17 Jan 2011 11:43:45 +0000
Subject: [issue10918] **kwargs unnecessarily restricted in API
In-Reply-To: <1295192992.12.0.880697566702.issue10918@psf.upfronthosting.co.za>
Message-ID: <1295264625.41.0.0537886012084.issue10918@psf.upfronthosting.co.za>


Brian Quinlan <brian at sweetapp.com> added the comment:

Good point! I'd suggest functools.partial.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10918>
_______________________________________

From report at bugs.python.org  Mon Jan 17 14:00:44 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 17 Jan 2011 13:00:44 +0000
Subject: [issue10925] Document pure Python version of integer-to-float
	correctly-rounded conversion
In-Reply-To: <1295269244.12.0.126728941356.issue10925@psf.upfronthosting.co.za>
Message-ID: <1295269244.12.0.126728941356.issue10925@psf.upfronthosting.co.za>


New submission from Mark Dickinson <dickinsm at gmail.com>:

It would be helpful (perhaps to developers of alternative implementations) to give a pure Python version of correctly-rounded long-to-float conversion.  Attached is such a version, as a patch to test_long in the release27-maint branch.

----------
assignee: mark.dickinson
files: pure_python_long_to_float.patch
keywords: patch
messages: 126398
nosy: mark.dickinson
priority: normal
severity: normal
status: open
title: Document pure Python version of integer-to-float correctly-rounded conversion
versions: Python 2.7, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file20423/pure_python_long_to_float.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10925>
_______________________________________

From report at bugs.python.org  Mon Jan 17 14:01:07 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 17 Jan 2011 13:01:07 +0000
Subject: [issue10925] Document pure Python version of integer-to-float
	correctly-rounded conversion
In-Reply-To: <1295269244.12.0.126728941356.issue10925@psf.upfronthosting.co.za>
Message-ID: <1295269267.24.0.637673503659.issue10925@psf.upfronthosting.co.za>


Changes by Mark Dickinson <dickinsm at gmail.com>:


----------
components: +Tests
type:  -> feature request

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10925>
_______________________________________

From report at bugs.python.org  Mon Jan 17 14:35:02 2011
From: report at bugs.python.org (Giampaolo Rodola')
Date: Mon, 17 Jan 2011 13:35:02 +0000
Subject: [issue1615158] POSIX capabilities support
Message-ID: <1295271302.06.0.633156115101.issue1615158@psf.upfronthosting.co.za>


Changes by Giampaolo Rodola' <g.rodola at gmail.com>:


----------
nosy: +giampaolo.rodola
versions: +Python 3.3 -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1615158>
_______________________________________

From report at bugs.python.org  Mon Jan 17 14:36:32 2011
From: report at bugs.python.org (Giampaolo Rodola')
Date: Mon, 17 Jan 2011 13:36:32 +0000
Subject: [issue9344] please add posix.getgrouplist()
In-Reply-To: <1279890657.77.0.804697326433.issue9344@psf.upfronthosting.co.za>
Message-ID: <1295271392.36.0.838099505027.issue9344@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/issue9344>
_______________________________________

From report at bugs.python.org  Mon Jan 17 15:21:44 2011
From: report at bugs.python.org (Brian Curtin)
Date: Mon, 17 Jan 2011 14:21:44 +0000
Subject: [issue10923] Python 2.7 hangs on Unicode+threading
In-Reply-To: <1295230653.16.0.00822246437847.issue10923@psf.upfronthosting.co.za>
Message-ID: <1295274104.15.0.296946149243.issue10923@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
type: crash -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10923>
_______________________________________

From report at bugs.python.org  Mon Jan 17 15:25:31 2011
From: report at bugs.python.org (Brian Curtin)
Date: Mon, 17 Jan 2011 14:25:31 +0000
Subject: [issue10921] imaplib: Internaldate2tuple() crashes,
	does not handle negative TZ offsets, does not handle DST correctly
In-Reply-To: <1295220756.66.0.509737296044.issue10921@psf.upfronthosting.co.za>
Message-ID: <1295274331.72.0.074004061653.issue10921@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
type: crash -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10921>
_______________________________________

From report at bugs.python.org  Mon Jan 17 15:28:46 2011
From: report at bugs.python.org (Mark Summerfield)
Date: Mon, 17 Jan 2011 14:28:46 +0000
Subject: [issue10926] Some Invalid Relative Imports succeed in Py 3.0 & 3.1 [&
	correctly fail in 3.2rc1]
In-Reply-To: <1295274525.96.0.0836159838622.issue10926@psf.upfronthosting.co.za>
Message-ID: <1295274525.96.0.0836159838622.issue10926@psf.upfronthosting.co.za>


New submission from Mark Summerfield <mark at qtrac.eu>:

I'm reporting this at Georg Brandl's suggestion.

If you unpack the attached (tiny) tarball you get this directory structure:

Graphics/
Graphics/Xpm.py
Graphics/Vector/
Graphics/Vector/__init__.py
Graphics/Vector/Svg.py
Graphics/__init__.py

The Svg.py file has this content:

#!/usr/bin/env python3
from ..Graphics import Xpm
SVG = 1

Here are 3 interactive actions, one each for 3.0, 3.1, and 3.2rc1:

$ python30
Python 3.0.1 (r301:69556, Jul 15 2010, 10:31:51) 
[GCC 4.4.4] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from Graphics.Vector import *
>>> Svg.SVG
1

$ python31
Python 3.1.2 (r312:79147, Jul 15 2010, 10:56:05) 
[GCC 4.4.4] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from Graphics.Vector import *
>>> Svg.SVG
1

$ ~/opt/python32rc1/bin/python3
Python 3.2rc1 (r32rc1:88035, Jan 16 2011, 08:32:59) 
[GCC 4.4.5] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from Graphics.Vector import *
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "Graphics/Vector/Svg.py", line 2, in <module>
    from ..Graphics import Xpm
ImportError: No module named Graphics

So clearly 3.0 and 3.1 have the same behavior as each other; and this is different from 3.2rc1, and Georg says that 3.0 and 3.1 have a bug and that 3.2rc1 is correct.

PS R. David Murray suggests that this might be related to
http://bugs.python.org/issue7902

----------
components: Interpreter Core
files: py-import-bug.tar.gz
messages: 126399
nosy: mark
priority: normal
severity: normal
status: open
title: Some Invalid Relative Imports succeed in Py 3.0 & 3.1 [& correctly fail in 3.2rc1]
type: behavior
versions: Python 3.1, Python 3.2
Added file: http://bugs.python.org/file20424/py-import-bug.tar.gz

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10926>
_______________________________________

From report at bugs.python.org  Mon Jan 17 15:56:34 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 17 Jan 2011 14:56:34 +0000
Subject: [issue10926] Some Invalid Relative Imports succeed in Py 3.0 & 3.1 [&
	correctly fail in 3.2rc1]
In-Reply-To: <1295274525.96.0.0836159838622.issue10926@psf.upfronthosting.co.za>
Message-ID: <1295276194.52.0.80929948806.issue10926@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10926>
_______________________________________

From report at bugs.python.org  Mon Jan 17 15:57:06 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 17 Jan 2011 14:57:06 +0000
Subject: [issue10915] Make the PyGILState API compatible with multiple
	interpreters
In-Reply-To: <1295103161.75.0.771875465176.issue10915@psf.upfronthosting.co.za>
Message-ID: <1295276226.15.0.311350204913.issue10915@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Graham - the cases you describe are the things I was saying don't currently work in my post and wouldn't be helped by Antoine's patch. Your thoughts on how we could possibly make it work actually parallel mine (although there may be fun and games with making sure the respective GILs are acquired and released in an appropriate order when switching interpreters).

However, if a given OS thread is created by a subinterpreter via thread_PyThread_start_new_thread, then the thread bootstrapping process will copy the thread state from that subinterpreter rather than the main interpreter.

Accordingly, the only thing that I believe should currently work with subinterpreters is the naive use case you described earlier (i.e. a call out to an extension module from a Python created thread that later calls back in using the PyGILState API in the exact same thread should work even in the presence of multiple interpreters).

This is the use case that I believe Antoine's patch as it currently stands actively *breaks* by making the autoTLSkey interpreter dependent.

Regardless, I'm marking 10914 as a dependency of this one, as I don't think we should change anything in this area until we have some unit tests to properly define what does and doesn't work. If we're going to promote subinterpreters to a robust, fully supported feature we may as well do it right.

----------
dependencies: +Python sub-interpreter test

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10915>
_______________________________________

From report at bugs.python.org  Mon Jan 17 15:58:13 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 17 Jan 2011 14:58:13 +0000
Subject: [issue10921] imaplib: Internaldate2tuple() crashes,
	does not handle negative TZ offsets, does not handle DST correctly
In-Reply-To: <1295220756.66.0.509737296044.issue10921@psf.upfronthosting.co.za>
Message-ID: <1295276293.86.0.975959416504.issue10921@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
assignee: docs at python -> 
nosy: +belopolsky, r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10921>
_______________________________________

From report at bugs.python.org  Mon Jan 17 15:58:18 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 17 Jan 2011 14:58:18 +0000
Subject: [issue10921] imaplib: Internaldate2tuple() crashes,
	does not handle negative TZ offsets, does not handle DST correctly
In-Reply-To: <1295220756.66.0.509737296044.issue10921@psf.upfronthosting.co.za>
Message-ID: <1295276298.29.0.617868174982.issue10921@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/issue10921>
_______________________________________

From report at bugs.python.org  Mon Jan 17 16:02:14 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 17 Jan 2011 15:02:14 +0000
Subject: [issue10914] Python sub-interpreter test
In-Reply-To: <1295098719.73.0.016388283782.issue10914@psf.upfronthosting.co.za>
Message-ID: <1295276534.26.0.288964467757.issue10914@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

I like the idea of adding these tests as well.

Probably worth bringing up on python-dev - folks like Tarek should definitely be able to help with alternative ways of building a test application for this.

There is also always the possibility of writing it in Python and using ctypes to get at the necessary C API calls to create subinterpreters.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10914>
_______________________________________

From report at bugs.python.org  Mon Jan 17 16:06:39 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 17 Jan 2011 15:06:39 +0000
Subject: [issue10915] Make the PyGILState API compatible with multiple
	interpreters
In-Reply-To: <1295276226.15.0.311350204913.issue10915@psf.upfronthosting.co.za>
Message-ID: <1295276794.3722.1.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Graham - the cases you describe are the things I was saying don't
> currently work in my post and wouldn't be helped by Antoine's patch.
> Your thoughts on how we could possibly make it work actually parallel
> mine (although there may be fun and games with making sure the
> respective GILs are acquired and released in an appropriate order when
> switching interpreters).

There is only a single GIL, not one per interpreter. And this mustn't
change since some objects are shared and their reference counts
shouldn't be touched concurrently.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10915>
_______________________________________

From report at bugs.python.org  Mon Jan 17 16:06:58 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Mon, 17 Jan 2011 15:06:58 +0000
Subject: [issue10926] Some Invalid Relative Imports succeed in Py 3.0 & 3.1 [&
	correctly fail in 3.2rc1]
In-Reply-To: <1295274525.96.0.0836159838622.issue10926@psf.upfronthosting.co.za>
Message-ID: <1295276818.78.0.675330806999.issue10926@psf.upfronthosting.co.za>


Changes by Senthil Kumaran <orsenthil at gmail.com>:


----------
nosy: +orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10926>
_______________________________________

From report at bugs.python.org  Mon Jan 17 16:14:07 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 17 Jan 2011 15:14:07 +0000
Subject: [issue10914] Python sub-interpreter test
In-Reply-To: <1295098719.73.0.016388283782.issue10914@psf.upfronthosting.co.za>
Message-ID: <1295277247.96.0.606748045102.issue10914@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> There is also always the possibility of writing it in Python and using 
> ctypes to get at the necessary C API calls to create subinterpreters.

Well, I don't think calling Py_Initialize, Py_Finalize and Py_NewInterpreter from pure Python code is a very good idea.

Tarek, can you help? We'd like to use distutils to compile an executable embedding the interpreter.

----------
nosy: +tarek

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10914>
_______________________________________

From report at bugs.python.org  Mon Jan 17 16:16:45 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 17 Jan 2011 15:16:45 +0000
Subject: [issue10926] Some Invalid Relative Imports succeed in Py 3.0 & 3.1 [&
	correctly fail in 3.2rc1]
In-Reply-To: <1295274525.96.0.0836159838622.issue10926@psf.upfronthosting.co.za>
Message-ID: <1295277405.67.0.690182199144.issue10926@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Yeah, 7902 was a bug that tried to do an absolute import if an explicit relative import failed to find anything (i.e. it had inherited the old implicit relative import fallback, which was entirely inappropriate for the new use case).

Since the significant import in these examples should correctly be written as "from .. import Xpm", it should fail in 2.6.6 and 3.1.3 as well.

If you could confirm that at least 3.1.3 also gives the expected error message, we'll close this as a dupe of 7902.

----------
nosy: +ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10926>
_______________________________________

From report at bugs.python.org  Mon Jan 17 16:44:06 2011
From: report at bugs.python.org (Geoffrey Bache)
Date: Mon, 17 Jan 2011 15:44:06 +0000
Subject: [issue10927] Allow universal line endings in filecmp module
In-Reply-To: <1295279046.42.0.435111163054.issue10927@psf.upfronthosting.co.za>
Message-ID: <1295279046.42.0.435111163054.issue10927@psf.upfronthosting.co.za>


New submission from Geoffrey Bache <gjb1002 at users.sourceforge.net>:

It would be useful to compare the contents of two files while not caring what platform they were produced on, perhaps a universal_line_endings parameter to e.g. filecmp.cmp and possibly other methods.

At the moment opening the files with "rb" is hardcoded in filecmp.py.

If there is another way to achieve this, please enlighten me...

----------
components: Library (Lib)
messages: 126405
nosy: gjb1002
priority: normal
severity: normal
status: open
title: Allow universal line endings in filecmp module
type: feature request

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10927>
_______________________________________

From report at bugs.python.org  Mon Jan 17 16:46:47 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 17 Jan 2011 15:46:47 +0000
Subject: [issue10915] Make the PyGILState API compatible with multiple
	interpreters
In-Reply-To: <1295103161.75.0.771875465176.issue10915@psf.upfronthosting.co.za>
Message-ID: <1295279207.47.0.448748841488.issue10915@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Good point - consider that comment revised to refer to the GIL acquisition counter in the thread state struct. It may just be a matter of having ThreadState_Swap complain loudly if the gilstate_counter isn't set to a value it knows how to handle.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10915>
_______________________________________

From report at bugs.python.org  Mon Jan 17 16:50:46 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 17 Jan 2011 15:50:46 +0000
Subject: [issue10923] Python 2.7 hangs on Unicode+threading
In-Reply-To: <1295230653.16.0.00822246437847.issue10923@psf.upfronthosting.co.za>
Message-ID: <1295279446.14.0.966399290501.issue10923@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Please attach a simple script reproducing the perceived problem.

----------
components: +Library (Lib) -None
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10923>
_______________________________________

From report at bugs.python.org  Mon Jan 17 17:24:33 2011
From: report at bugs.python.org (arindam)
Date: Mon, 17 Jan 2011 16:24:33 +0000
Subject: [issue10903] ZipExtFile:_update_crc fails for CRC >= 0x80000000
In-Reply-To: <1294998214.06.0.837210563153.issue10903@psf.upfronthosting.co.za>
Message-ID: <1295281473.43.0.684492205944.issue10903@psf.upfronthosting.co.za>


arindam <arindampanna at gmail.com> added the comment:

Attached test file a.zip. Happening with 2.7.1.3. The changes came with   /python/branches/release27-maint/Lib/zipfile.py revision 83961

----------
Added file: http://bugs.python.org/file20425/a.zip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10903>
_______________________________________

From report at bugs.python.org  Mon Jan 17 17:30:08 2011
From: report at bugs.python.org (Mark Summerfield)
Date: Mon, 17 Jan 2011 16:30:08 +0000
Subject: [issue10926] Some Invalid Relative Imports succeed in Py 3.0 & 3.1 [&
	correctly fail in 3.2rc1]
In-Reply-To: <1295274525.96.0.0836159838622.issue10926@psf.upfronthosting.co.za>
Message-ID: <1295281808.83.0.723479436566.issue10926@psf.upfronthosting.co.za>


Mark Summerfield <mark at qtrac.eu> added the comment:

I just installed 3.1.3 and it does indeed give the import error:

Python 3.1.3 (r313:86834, Jan 17 2011, 16:29:46) 
[GCC 4.4.5] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from Graphics.Vector import *
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "Graphics/Vector/Svg.py", line 2, in <module>
    from ..Graphics import Xpm
ImportError: No module named Graphics

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10926>
_______________________________________

From report at bugs.python.org  Mon Jan 17 17:51:50 2011
From: report at bugs.python.org (R. David Murray)
Date: Mon, 17 Jan 2011 16:51:50 +0000
Subject: [issue10918] **kwargs unnecessarily restricted in API
In-Reply-To: <1295192992.12.0.880697566702.issue10918@psf.upfronthosting.co.za>
Message-ID: <1295283110.09.0.39264371832.issue10918@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Adrian's suggestions don't look to me like they fiddle with the API, but rather make the behavior match the documented API.  The existing behavior is, IMO, a very surprising corner case, especially to a less experienced Python programmer.  I do note that assertRaises in unittest has the same issue.  However, I think people are quite a bit more likely to run in to the issue with submit, since 'fn' is going to occur as a keyword argument with considerably higher frequency than 'excClass' or 'callableObj'.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10918>
_______________________________________

From report at bugs.python.org  Mon Jan 17 17:57:23 2011
From: report at bugs.python.org (Kirill Bystrov)
Date: Mon, 17 Jan 2011 16:57:23 +0000
Subject: [issue10928] Strange input processing
In-Reply-To: <1295283443.74.0.675082012273.issue10928@psf.upfronthosting.co.za>
Message-ID: <1295283443.74.0.675082012273.issue10928@psf.upfronthosting.co.za>


New submission from Kirill Bystrov <kirrbyss at gmail.com>:

I have written a simple script which evaluates some numeric expressions and faced a strange problem at some point. Some of these expressions cannot evaluate correctly. Here is an example:
Python 2.7.1+ (r271:86832, Dec 24 2010, 10:03:35) 
[GCC 4.5.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> 3158 + 04
3162
>>> 3158 + 05
3163
>>> 3158 + 06
3164
>>> 3158 + 07
3165
>>> 3158 + 08
  File "<stdin>", line 1
    3158 + 08
            ^
SyntaxError: invalid token
>>> 3158 + 09
  File "<stdin>", line 1
    3158 + 09
            ^
SyntaxError: invalid token
>>> 
Both 2.6 and 2.7 raise this exception. My distro is Ubuntu Natty if this matters.
P.S.: sorry for my bad English :)

----------
components: Interpreter Core
messages: 126411
nosy: byss
priority: normal
severity: normal
status: open
title: Strange input processing
type: behavior
versions: Python 2.6, Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10928>
_______________________________________

From report at bugs.python.org  Mon Jan 17 18:01:49 2011
From: report at bugs.python.org (R. David Murray)
Date: Mon, 17 Jan 2011 17:01:49 +0000
Subject: [issue10926] Some Invalid Relative Imports succeed in Py 3.0 & 3.1 [&
	correctly fail in 3.2rc1]
In-Reply-To: <1295274525.96.0.0836159838622.issue10926@psf.upfronthosting.co.za>
Message-ID: <1295283709.85.0.773950306573.issue10926@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
resolution:  -> duplicate
stage:  -> committed/rejected
status: open -> closed
superseder:  -> relative import broken

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10926>
_______________________________________

From report at bugs.python.org  Mon Jan 17 18:08:49 2011
From: report at bugs.python.org (R. David Murray)
Date: Mon, 17 Jan 2011 17:08:49 +0000
Subject: [issue10928] Strange input processing
In-Reply-To: <1295283443.74.0.675082012273.issue10928@psf.upfronthosting.co.za>
Message-ID: <1295284129.7.0.713476172708.issue10928@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

08 is an invalid octal literal.  See

http://docs.python.org/reference/lexical_analysis.html#integer-and-long-integer-literals

----------
nosy: +r.david.murray
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10928>
_______________________________________

From report at bugs.python.org  Mon Jan 17 18:19:31 2011
From: report at bugs.python.org (Ron Adam)
Date: Mon, 17 Jan 2011 17:19:31 +0000
Subject: [issue10918] **kwargs unnecessarily restricted in API
In-Reply-To: <1295192992.12.0.880697566702.issue10918@psf.upfronthosting.co.za>
Message-ID: <1295284771.49.0.150634408768.issue10918@psf.upfronthosting.co.za>


Ron Adam <ron_adam at users.sourceforge.net> added the comment:

Why is this surprising?

>>> def foo(c, c=None):
...   pass
... 
  File "<stdin>", line 1
SyntaxError: duplicate argument 'c' in function definition

In the previous examples, it finds the duplicate at run time instead of compile time due to not being able to determine the contents of kwargs at compile time.  It's just a bug in your code if you do it, and it should raise an exception as it does.

----------
nosy: +ron_adam

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10918>
_______________________________________

From report at bugs.python.org  Mon Jan 17 18:24:09 2011
From: report at bugs.python.org (Ross Lagerwall)
Date: Mon, 17 Jan 2011 17:24:09 +0000
Subject: [issue2644] errors from msync ignored in mmap_object_dealloc
In-Reply-To: <1208363426.33.0.938357268178.issue2644@psf.upfronthosting.co.za>
Message-ID: <1295285049.0.0.88671484165.issue2644@psf.upfronthosting.co.za>


Ross Lagerwall <rosslagerwall at gmail.com> added the comment:

I think this can be closed.

msync() is only called in mmap.flush() and it is checked for an error.

----------
nosy: +rosslagerwall

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2644>
_______________________________________

From report at bugs.python.org  Mon Jan 17 18:29:58 2011
From: report at bugs.python.org (Kirill Bystrov)
Date: Mon, 17 Jan 2011 17:29:58 +0000
Subject: [issue10928] Strange input processing
In-Reply-To: <1295283443.74.0.675082012273.issue10928@psf.upfronthosting.co.za>
Message-ID: <1295285398.85.0.75751338456.issue10928@psf.upfronthosting.co.za>


Kirill Bystrov <kirrbyss at gmail.com> added the comment:

Sorry, i have really forgotten about these octals.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10928>
_______________________________________

From report at bugs.python.org  Mon Jan 17 18:30:39 2011
From: report at bugs.python.org (R. David Murray)
Date: Mon, 17 Jan 2011 17:30:39 +0000
Subject: [issue10918] **kwargs unnecessarily restricted in API
In-Reply-To: <1295192992.12.0.880697566702.issue10918@psf.upfronthosting.co.za>
Message-ID: <1295285439.91.0.302066841342.issue10918@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

The reason that it is surprising is that the API is designed to allow an arbitrary function to be called, with whatever arguments and keyword arguments that function takes.  The user of the API is not necessarily going to remember that the first argument to 'submit' is named 'fn', and that therefore they must jump through special hoops if they should happen to want to submit a function that takes a keyword argument named 'fn'.  This becomes especially problematic if the function calling submit is itself accepting an arbitrary callable from a higher layer in the application.

If the first argument to submit were named something less common than 'fn', this problem might never have been noticed :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10918>
_______________________________________

From report at bugs.python.org  Mon Jan 17 18:40:32 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 17 Jan 2011 17:40:32 +0000
Subject: [issue10921] imaplib: Internaldate2tuple() crashes,
	does not handle negative TZ offsets, does not handle DST correctly
In-Reply-To: <1295220756.66.0.509737296044.issue10921@psf.upfronthosting.co.za>
Message-ID: <1295286032.26.0.275614158577.issue10921@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

> 1. It crashes with "KeyError". ...

I assume this means it raises a KeyError when given a bytes object as an argument.

>>> Internaldate2tuple(b'INTERNALDATE "01-Jan-2000 12:00:00 +0000"')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "Lib/imaplib.py", line 1326, in Internaldate2tuple
    mon = Mon2num[mo.group('mon')]
KeyError: b'Jan'

> 2.  The sign of the TZ offset ..

Once Mon2num is fixed, the sign error show up as follows:

>>> Internaldate2tuple(b'INTERNALDATE "01-Jan-2000 12:00:00 +0500"')[3:6]
(2, 0, 0)
>>> Internaldate2tuple(b'INTERNALDATE "01-Jan-2000 12:00:00 -0500"')[3:6]
(2, 0, 0)

 
This looks like a 2 to 3 port oversight and we can probably fix it in RC.  Georg?

----------
nosy: +georg.brandl
stage: patch review -> unit test needed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10921>
_______________________________________

From report at bugs.python.org  Mon Jan 17 18:45:58 2011
From: report at bugs.python.org (Ron Adam)
Date: Mon, 17 Jan 2011 17:45:58 +0000
Subject: [issue10918] **kwargs unnecessarily restricted in API
In-Reply-To: <1295192992.12.0.880697566702.issue10918@psf.upfronthosting.co.za>
Message-ID: <1295286358.54.0.500821942245.issue10918@psf.upfronthosting.co.za>


Ron Adam <ron_adam at users.sourceforge.net> added the comment:

Is this issue referring to something in Python's library, or a hypothetical function someone may write?

If it's in the library, we can look at that case in more detail, otherwise, it's just a bad program design issue and there's nothing to do.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10918>
_______________________________________

From report at bugs.python.org  Mon Jan 17 18:51:40 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 17 Jan 2011 17:51:40 +0000
Subject: [issue10903] ZipExtFile:_update_crc fails for CRC >= 0x80000000
In-Reply-To: <1294998214.06.0.837210563153.issue10903@psf.upfronthosting.co.za>
Message-ID: <1295286700.65.0.258779154624.issue10903@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Attached test file a.zip. Happening with 2.7.1.3. The changes came
> with   /python/branches/release27-maint/Lib/zipfile.py revision 83961

I tested with 2.7.x and 3.2 (both from latest SVN) and couldn't reproduce (I used testzip() and extractall()), both in 32-bit and 64-bit builds.

Can you clarify which OS you are using? Also, what is 2.7.1.3? We don't have a such version (see http://python.org/download/releases/ for official releases). If you are using a Python provided by a third-party distributor (such as ActiveState or a Linux distribution), you might want to report the bug to them, since AFAICT the bug doesn't exist on the official builds.

----------
nosy: +srid

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10903>
_______________________________________

From report at bugs.python.org  Mon Jan 17 19:01:12 2011
From: report at bugs.python.org (Joe Peterson)
Date: Mon, 17 Jan 2011 18:01:12 +0000
Subject: [issue10921] imaplib: Internaldate2tuple() crashes,
	does not handle negative TZ offsets, does not handle DST correctly
In-Reply-To: <1295220756.66.0.509737296044.issue10921@psf.upfronthosting.co.za>
Message-ID: <1295287272.57.0.518096435974.issue10921@psf.upfronthosting.co.za>


Joe Peterson <joe at skyrush.com> added the comment:

> I assume this means it raises a KeyError when given a bytes object as an argument.

Yes, a KeyError is raised when arg is bytes, but passing a string also fails (raising TypeError).  The latter might also be a separate bug, in that strings cannot be passed as they could be in Python 2.

> This looks like a 2 to 3 port oversight and we can probably fix it in RC.

Probably, since many strings have been changed to bytes elsewhere in the file.

BTW, I just attached a patch for Python 2.7 that fixes the subset of non-py3k-related issues.

----------
versions: +Python 2.7
Added file: http://bugs.python.org/file20426/imaplib_Internaldate2tuple_python27.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10921>
_______________________________________

From report at bugs.python.org  Mon Jan 17 19:06:54 2011
From: report at bugs.python.org (R. David Murray)
Date: Mon, 17 Jan 2011 18:06:54 +0000
Subject: [issue10918] **kwargs unnecessarily restricted in concurrent.futures
	'submit' API
In-Reply-To: <1295192992.12.0.880697566702.issue10918@psf.upfronthosting.co.za>
Message-ID: <1295287614.1.0.26438090493.issue10918@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Yes, it's about the concurrent.futures 'submit' method:

http://docs.python.org/dev/py3k/library/concurrent.futures.html#executor-objects

I've updated the title to reflect this.  There are other places in the stdlib affected by this, but they should be opened as separate issues if someone is having a problem with them.

----------
title: **kwargs unnecessarily restricted in API -> **kwargs unnecessarily restricted in concurrent.futures 'submit' API

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10918>
_______________________________________

From report at bugs.python.org  Mon Jan 17 19:14:54 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 17 Jan 2011 18:14:54 +0000
Subject: [issue10924] Adding salt and Modular Crypt Format to crypt library.
In-Reply-To: <1295247997.49.0.7150272714.issue10924@psf.upfronthosting.co.za>
Message-ID: <1295288094.41.0.544014240071.issue10924@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

You forgot to add the new files to your patch.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10924>
_______________________________________

From report at bugs.python.org  Mon Jan 17 19:17:13 2011
From: report at bugs.python.org (R. David Murray)
Date: Mon, 17 Jan 2011 18:17:13 +0000
Subject: [issue10927] Allow universal line endings in filecmp module
In-Reply-To: <1295279046.42.0.435111163054.issue10927@psf.upfronthosting.co.za>
Message-ID: <1295288233.68.0.279118659441.issue10927@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Duplicate of issue 6306.

----------
nosy: +r.david.murray
resolution:  -> duplicate
stage:  -> committed/rejected
status: open -> closed
superseder:  -> filecmp.cmp can not compare two files from different OS with the same content

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10927>
_______________________________________

From report at bugs.python.org  Mon Jan 17 19:40:16 2011
From: report at bugs.python.org (Sean Reifschneider)
Date: Mon, 17 Jan 2011 18:40:16 +0000
Subject: [issue10924] Adding salt and Modular Crypt Format to crypt library.
In-Reply-To: <1295247997.49.0.7150272714.issue10924@psf.upfronthosting.co.za>
Message-ID: <1295289616.64.0.0117492365429.issue10924@psf.upfronthosting.co.za>


Sean Reifschneider <jafo at tummy.com> added the comment:

Oops, thanks.  It's in there now, though for some reason I can't get this patch to apply to trunk, but I'll have to look at that later this afternoon.  I wanted to get this new version up in the interim since it definitely does include the Lib/crypt.py file, the heart of the changes.

----------
Added file: http://bugs.python.org/file20427/python-underscore_crypt-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10924>
_______________________________________

From report at bugs.python.org  Mon Jan 17 19:40:30 2011
From: report at bugs.python.org (Sean Reifschneider)
Date: Mon, 17 Jan 2011 18:40:30 +0000
Subject: [issue10924] Adding salt and Modular Crypt Format to crypt library.
In-Reply-To: <1295247997.49.0.7150272714.issue10924@psf.upfronthosting.co.za>
Message-ID: <1295289630.02.0.369670108916.issue10924@psf.upfronthosting.co.za>


Changes by Sean Reifschneider <jafo at tummy.com>:


Removed file: http://bugs.python.org/file20422/python-underscore_crypt.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10924>
_______________________________________

From report at bugs.python.org  Mon Jan 17 19:42:29 2011
From: report at bugs.python.org (Adrian Dries)
Date: Mon, 17 Jan 2011 18:42:29 +0000
Subject: [issue10918] **kwargs unnecessarily restricted in concurrent.futures
	'submit' API
In-Reply-To: <1295192992.12.0.880697566702.issue10918@psf.upfronthosting.co.za>
Message-ID: <1295289749.97.0.316888151946.issue10918@psf.upfronthosting.co.za>


Adrian Dries <adries at gmail.com> added the comment:

The futures case is one example of a broader API design issue.

Note also that 'self' is similarly restricted.  You might think these are 'corner cases', but to me it is poor API design.  There may well be a reasonable case for passing 'self' as a keyword arg; what right has the API to dictate otherwise?

I think Python's private name mangling provides a reasonably clean, self-documenting solution, pushing the 'corner' case further to the corner (the restriction would then be on the much-less-likely mangled names).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10918>
_______________________________________

From report at bugs.python.org  Mon Jan 17 19:44:59 2011
From: report at bugs.python.org (arindam)
Date: Mon, 17 Jan 2011 18:44:59 +0000
Subject: [issue10903] ZipExtFile:_update_crc fails for CRC >= 0x80000000
In-Reply-To: <1294998214.06.0.837210563153.issue10903@psf.upfronthosting.co.za>
Message-ID: <1295289899.52.0.685771931608.issue10903@psf.upfronthosting.co.za>


arindam <arindampanna at gmail.com> added the comment:

Able to get the issue with
Python 2.7.1 (r271:86832, Nov 27 2010, 18:30:46) [MSC v.1500 32 bit (Intel)] on win32

This is the latest version for 2.7.x

Please try with the uploaded a.zip

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10903>
_______________________________________

From report at bugs.python.org  Mon Jan 17 20:18:39 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 17 Jan 2011 19:18:39 +0000
Subject: [issue10903] ZipExtFile:_update_crc fails for CRC >= 0x80000000
In-Reply-To: <1295289899.52.0.685771931608.issue10903@psf.upfronthosting.co.za>
Message-ID: <1295291913.3722.8.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Able to get the issue with
> Python 2.7.1 (r271:86832, Nov 27 2010, 18:30:46) [MSC v.1500 32 bit (Intel)] on win32

Ok, I tried with this exact version and I still can't reproduce.
Can you explain which steps exactly are necessary to exhibit this issue?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10903>
_______________________________________

From report at bugs.python.org  Mon Jan 17 20:33:38 2011
From: report at bugs.python.org (R. David Murray)
Date: Mon, 17 Jan 2011 19:33:38 +0000
Subject: [issue10918] **kwargs unnecessarily restricted in concurrent.futures
	'submit' API
In-Reply-To: <1295192992.12.0.880697566702.issue10918@psf.upfronthosting.co.za>
Message-ID: <1295292818.88.0.0256841798992.issue10918@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Name mangling applies only to attributes of classes, and so does not enter in to this issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10918>
_______________________________________

From report at bugs.python.org  Mon Jan 17 20:39:20 2011
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 17 Jan 2011 19:39:20 +0000
Subject: [issue10918] **kwargs unnecessarily restricted in concurrent.futures
	'submit' API
In-Reply-To: <1295192992.12.0.880697566702.issue10918@psf.upfronthosting.co.za>
Message-ID: <1295293160.8.0.319188957442.issue10918@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

def submit(*args, **kwds):

and picking out self and fn from *args might indeed be the most sensible solution here.

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10918>
_______________________________________

From report at bugs.python.org  Mon Jan 17 20:41:30 2011
From: report at bugs.python.org (Adrian Dries)
Date: Mon, 17 Jan 2011 19:41:30 +0000
Subject: [issue10918] **kwargs unnecessarily restricted in concurrent.futures
	'submit' API
In-Reply-To: <1295192992.12.0.880697566702.issue10918@psf.upfronthosting.co.za>
Message-ID: <1295293290.4.0.565521281546.issue10918@psf.upfronthosting.co.za>


Adrian Dries <adries at gmail.com> added the comment:

No, private mangling applies to any identifier in class-scope:

Python 2.6.4 (r264:75706, Dec  7 2009, 18:45:15) 
[GCC 4.4.1] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> class C:
...     def f(__x): pass
... 
>>> import inspect
>>> inspect.getargspec(C.f)
ArgSpec(args=['_C__x'], varargs=None, keywords=None, defaults=None)
>>>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10918>
_______________________________________

From report at bugs.python.org  Mon Jan 17 20:42:40 2011
From: report at bugs.python.org (arindam)
Date: Mon, 17 Jan 2011 19:42:40 +0000
Subject: [issue10903] ZipExtFile:_update_crc fails for CRC >= 0x80000000
In-Reply-To: <1294998214.06.0.837210563153.issue10903@psf.upfronthosting.co.za>
Message-ID: <1295293360.19.0.767119121464.issue10903@psf.upfronthosting.co.za>


arindam <arindampanna at gmail.com> added the comment:

Legacy code in my module was setting zipfile.structCentralDir to "<4s4B4H3l5H2L" (was added to fix some issues with older version of python) was the root cause of this issue. Sorry, should have checked before filing. Thanks for your time. Sorry once again.

----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10903>
_______________________________________

From report at bugs.python.org  Mon Jan 17 21:20:58 2011
From: report at bugs.python.org (Brian Curtin)
Date: Mon, 17 Jan 2011 20:20:58 +0000
Subject: [issue2644] errors from msync ignored in mmap_object_dealloc
In-Reply-To: <1208363426.33.0.938357268178.issue2644@psf.upfronthosting.co.za>
Message-ID: <1295295658.64.0.872047176768.issue2644@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

That was changed in r84950 from #2643.

----------
resolution:  -> out of date
stage: unit test needed -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2644>
_______________________________________

From report at bugs.python.org  Mon Jan 17 21:24:35 2011
From: report at bugs.python.org (R. David Murray)
Date: Mon, 17 Jan 2011 20:24:35 +0000
Subject: [issue10918] **kwargs unnecessarily restricted in concurrent.futures
	'submit' API
In-Reply-To: <1295192992.12.0.880697566702.issue10918@psf.upfronthosting.co.za>
Message-ID: <1295295875.11.0.558068057187.issue10918@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Adrian: you are correct of course, I was misremembering and did not check the docs.  I prefer the other solution, though.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10918>
_______________________________________

From report at bugs.python.org  Mon Jan 17 21:56:47 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 17 Jan 2011 20:56:47 +0000
Subject: [issue10917] PEP 333 link to CGI specification is broken
In-Reply-To: <1295164208.27.0.610516311421.issue10917@psf.upfronthosting.co.za>
Message-ID: <1295297807.39.0.0492788052872.issue10917@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

The age of core developers may surprise you.

For the anecdote, I used to game and use Internet slang, and to me w00t == wut == what; I?ve never seen it used to mean ?great?.

----------
assignee: docs at python -> georg.brandl
components:  -Documentation
nosy: +eric.araujo -docs at python
versions:  -3rd party, Python 2.5, Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10917>
_______________________________________

From report at bugs.python.org  Mon Jan 17 22:26:19 2011
From: report at bugs.python.org (Joe Bennett)
Date: Mon, 17 Jan 2011 21:26:19 +0000
Subject: [issue10929] telnetlib does not send FIN when self.close() issued
In-Reply-To: <1295299579.64.0.0384853745776.issue10929@psf.upfronthosting.co.za>
Message-ID: <1295299579.64.0.0384853745776.issue10929@psf.upfronthosting.co.za>


New submission from Joe Bennett <jammer10000 at ka3nam.com>:

Hi, am running Python 2.6.5 on Unbuntu 10.04 and am seeing no FIN when a self.close() is issued... I do see a reset issued, but it looks like some of the M$ servers do not appreciate on a reset and would like a graceful teardown... I understand that an RST can be issued in the event the buffer may have data to send, I do not believe that is the case. If there is a way to verify that, please let me know...

----------
components: IO
messages: 126436
nosy: jammer10000
priority: normal
severity: normal
status: open
title: telnetlib does not send FIN when self.close() issued
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10929>
_______________________________________

From report at bugs.python.org  Mon Jan 17 22:29:29 2011
From: report at bugs.python.org (Sean Reifschneider)
Date: Mon, 17 Jan 2011 21:29:29 +0000
Subject: [issue10924] Adding salt and Modular Crypt Format to crypt library.
In-Reply-To: <1295247997.49.0.7150272714.issue10924@psf.upfronthosting.co.za>
Message-ID: <1295299769.18.0.522751482087.issue10924@psf.upfronthosting.co.za>


Sean Reifschneider <jafo at tummy.com> added the comment:

I've made a new .patch file using "diff -c" rather than "svn diff".  This is the same code, but applies without manual intervention.

----------
Added file: http://bugs.python.org/file20428/python-underscore_crypt-3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10924>
_______________________________________

From report at bugs.python.org  Mon Jan 17 22:29:48 2011
From: report at bugs.python.org (Sean Reifschneider)
Date: Mon, 17 Jan 2011 21:29:48 +0000
Subject: [issue10924] Adding salt and Modular Crypt Format to crypt library.
In-Reply-To: <1295247997.49.0.7150272714.issue10924@psf.upfronthosting.co.za>
Message-ID: <1295299788.15.0.307733695845.issue10924@psf.upfronthosting.co.za>


Changes by Sean Reifschneider <jafo at tummy.com>:


Removed file: http://bugs.python.org/file20427/python-underscore_crypt-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10924>
_______________________________________

From report at bugs.python.org  Mon Jan 17 22:38:01 2011
From: report at bugs.python.org (=?utf-8?q?Piotr_Ma=C5=9Blanka?=)
Date: Mon, 17 Jan 2011 21:38:01 +0000
Subject: [issue10923] Python 2.7 hangs on Unicode+threading
In-Reply-To: <1295230653.16.0.00822246437847.issue10923@psf.upfronthosting.co.za>
Message-ID: <1295300281.96.0.815198872835.issue10923@psf.upfronthosting.co.za>


Piotr Ma?lanka <piotr.maslanka at henrietta.com.pl> added the comment:

I ripped some stuff from the project I'm working on, undependencing it on any my libraries.

Can someone with similar conf(Win7 x86-64, Python 2.7.1 (r271:86832, Nov 27 2010, 18:30:46) [MSC v.1500 32 bit (Intel)] on win32) confirm this?

Directory configuration when I run that script was that it was in a child directory and was invoked by a script with "import child_directory".

Before you say 'can't reproduce', run it at least 15 times, please.

----------
Added file: http://bugs.python.org/file20429/start.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10923>
_______________________________________

From report at bugs.python.org  Mon Jan 17 22:58:11 2011
From: report at bugs.python.org (Andre Wobst)
Date: Mon, 17 Jan 2011 21:58:11 +0000
Subject: [issue8846] cgi.py bug report + fix: tailing carriage return and
	newline characters in multipart cgi input broken
In-Reply-To: <1275080080.41.0.761400748474.issue8846@psf.upfronthosting.co.za>
Message-ID: <1295301491.34.0.441489866802.issue8846@psf.upfronthosting.co.za>


Andre Wobst <wobsta at users.sourceforge.net> added the comment:

I just declare this bug to be a duplicate of #4953. Due to the recent fix r87998 of the cgi module my extended/corrected testcases attached in this bug report now pass.

----------
resolution:  -> duplicate
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8846>
_______________________________________

From report at bugs.python.org  Mon Jan 17 23:28:25 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 17 Jan 2011 22:28:25 +0000
Subject: [issue10911] cgi: add more tests
In-Reply-To: <1295040877.8.0.0807786274615.issue10911@psf.upfronthosting.co.za>
Message-ID: <1295303305.49.0.34957139324.issue10911@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

See also #8846: Andre Wobst wrote other tests.

----------
nosy: +wobsta

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10911>
_______________________________________

From report at bugs.python.org  Tue Jan 18 00:29:52 2011
From: report at bugs.python.org (R. David Murray)
Date: Mon, 17 Jan 2011 23:29:52 +0000
Subject: [issue10929] telnetlib does not send FIN when self.close() issued
In-Reply-To: <1295299579.64.0.0384853745776.issue10929@psf.upfronthosting.co.za>
Message-ID: <1295306992.11.0.64980664258.issue10929@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

telnetlib closes the socket, which in turn calls the OS level socket close function.  What happens after that is up to the OS tcp/ip stack, and is not under Python's control.  So if there is a bug here it isn't in Python.

----------
nosy: +jackdied, r.david.murray
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10929>
_______________________________________

From report at bugs.python.org  Tue Jan 18 01:36:15 2011
From: report at bugs.python.org (Nicolas Dumazet)
Date: Tue, 18 Jan 2011 00:36:15 +0000
Subject: [issue10924] Adding salt and Modular Crypt Format to crypt library.
In-Reply-To: <1295247997.49.0.7150272714.issue10924@psf.upfronthosting.co.za>
Message-ID: <1295310975.78.0.856296559811.issue10924@psf.upfronthosting.co.za>


Nicolas Dumazet <nicdumz at gmail.com> added the comment:

Hello,

1) Can you please avoid putting several statements in the same line?

2) wouldnt it be better to compute only once the contents of methods()? I'm not sure that module-initialization time is okay for CPython, but at the very least you can lazily fill a module-level variable, and return it directly from methods()?

3) what happens when a user uses one of the Crypt methods that are referenced from the Module, if this method is not available? Arguably, if I know what I'm doing, I will call mksalt(METHOD_SHA512) without checking that METHOD_SHA512 was in methods(). That's not very intuitive, and it seems that mksalt could break.

4) saltchars should probably be string.ascii_letters+string.digits instead of the hardcoded value

5) you should mention in the documentation that if not salt parameter is given, a different salt will be used for each crypt() call

6) is _MethodClass an old-style class?

7) it seems that the patch duplicates twice the diff of crypt.py, not sure of what happened there?

----------
nosy: +nicdumz

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10924>
_______________________________________

From report at bugs.python.org  Tue Jan 18 02:03:20 2011
From: report at bugs.python.org (Garrett Cooper)
Date: Tue, 18 Jan 2011 01:03:20 +0000
Subject: [issue8746] os.chflags() and os.lchflags() are not built when they
	should be be
In-Reply-To: <1274173521.53.0.771933425772.issue8746@psf.upfronthosting.co.za>
Message-ID: <1295312600.24.0.451813012349.issue8746@psf.upfronthosting.co.za>


Garrett Cooper <yanegomi at gmail.com> added the comment:

Sorry -- got off-track for a while.

I assume these should go into Lib/test/test_os.py ?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8746>
_______________________________________

From report at bugs.python.org  Tue Jan 18 02:07:38 2011
From: report at bugs.python.org (Joe Peterson)
Date: Tue, 18 Jan 2011 01:07:38 +0000
Subject: [issue10921] imaplib: Internaldate2tuple() string/bytes issues,
	does not handle negative TZ offsets, does not handle DST correctly
In-Reply-To: <1295220756.66.0.509737296044.issue10921@psf.upfronthosting.co.za>
Message-ID: <1295312858.6.0.677793191669.issue10921@psf.upfronthosting.co.za>


Joe Peterson <joe at skyrush.com> added the comment:

Added fix for ParseFlags (another string/bytes issue) and now accept strings as args to ParseFlags and Internaldate2tuple.

Also added unit tests for changes.

----------
assignee:  -> docs at python
components: +Tests
title: imaplib: Internaldate2tuple() crashes, does not handle negative TZ offsets, does not handle DST correctly -> imaplib: Internaldate2tuple() string/bytes issues, does not handle negative TZ offsets, does not handle DST correctly
Added file: http://bugs.python.org/file20430/imaplib_Internaldate2tuple_python32.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10921>
_______________________________________

From report at bugs.python.org  Tue Jan 18 02:11:02 2011
From: report at bugs.python.org (Ned Deily)
Date: Tue, 18 Jan 2011 01:11:02 +0000
Subject: [issue8746] os.chflags() and os.lchflags() are not built when they
	should be be
In-Reply-To: <1274173521.53.0.771933425772.issue8746@psf.upfronthosting.co.za>
Message-ID: <1295313062.42.0.0844113937496.issue8746@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

There is an existing test_lchflags in Lib/test/test_posix.py.  Additional test cases should go there.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8746>
_______________________________________

From report at bugs.python.org  Tue Jan 18 02:22:24 2011
From: report at bugs.python.org (Joe Peterson)
Date: Tue, 18 Jan 2011 01:22:24 +0000
Subject: [issue10921] imaplib: Internaldate2tuple() string/bytes issues,
	does not handle negative TZ offsets, does not handle DST correctly
In-Reply-To: <1295220756.66.0.509737296044.issue10921@psf.upfronthosting.co.za>
Message-ID: <1295313744.92.0.204807724692.issue10921@psf.upfronthosting.co.za>


Changes by Joe Peterson <joe at skyrush.com>:


Removed file: http://bugs.python.org/file20420/imaplib_Internaldate2tuple.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10921>
_______________________________________

From report at bugs.python.org  Tue Jan 18 02:22:34 2011
From: report at bugs.python.org (Joe Peterson)
Date: Tue, 18 Jan 2011 01:22:34 +0000
Subject: [issue10921] imaplib: Internaldate2tuple() string/bytes issues,
	does not handle negative TZ offsets, does not handle DST correctly
In-Reply-To: <1295220756.66.0.509737296044.issue10921@psf.upfronthosting.co.za>
Message-ID: <1295313754.82.0.610575831533.issue10921@psf.upfronthosting.co.za>


Changes by Joe Peterson <joe at skyrush.com>:


Removed file: http://bugs.python.org/file20430/imaplib_Internaldate2tuple_python32.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10921>
_______________________________________

From report at bugs.python.org  Tue Jan 18 02:22:51 2011
From: report at bugs.python.org (Joe Peterson)
Date: Tue, 18 Jan 2011 01:22:51 +0000
Subject: [issue10921] imaplib: Internaldate2tuple() string/bytes issues,
	does not handle negative TZ offsets, does not handle DST correctly
In-Reply-To: <1295220756.66.0.509737296044.issue10921@psf.upfronthosting.co.za>
Message-ID: <1295313771.26.0.31239349074.issue10921@psf.upfronthosting.co.za>


Changes by Joe Peterson <joe at skyrush.com>:


Added file: http://bugs.python.org/file20431/imaplib_Internaldate2tuple_python32.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10921>
_______________________________________

From report at bugs.python.org  Tue Jan 18 02:25:07 2011
From: report at bugs.python.org (Garrett Cooper)
Date: Tue, 18 Jan 2011 01:25:07 +0000
Subject: [issue8746] os.chflags() and os.lchflags() are not built when they
	should be be
In-Reply-To: <1295313062.42.0.0844113937496.issue8746@psf.upfronthosting.co.za>
Message-ID: <AANLkTikGj91zjoe=G9q8vroS+z5L3myabK+mHDcEEviv@mail.gmail.com>


Garrett Cooper <yanegomi at gmail.com> added the comment:

On Mon, Jan 17, 2011 at 5:11 PM, Ned Deily <report at bugs.python.org> wrote:
>
> Ned Deily <nad at acm.org> added the comment:
>
> There is an existing test_lchflags in Lib/test/test_posix.py. ?Additional test cases should go there.

Ok, but again this isn't POSIX functionality -- it's a BSD functional piece.

    Another thing that's nasty that I've discovered is that the
function prototype isn't the same across the board. After things are
consolidated in FreeBSD I'll talk to the NetBSD and OpenBSD folks.
Thanks!
-Garrett

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8746>
_______________________________________

From report at bugs.python.org  Tue Jan 18 02:35:46 2011
From: report at bugs.python.org (Joe Peterson)
Date: Tue, 18 Jan 2011 01:35:46 +0000
Subject: [issue10921] imaplib: Internaldate2tuple() string/bytes issues,
	does not handle negative TZ offsets, does not handle DST correctly
In-Reply-To: <1295220756.66.0.509737296044.issue10921@psf.upfronthosting.co.za>
Message-ID: <1295314546.5.0.558885535147.issue10921@psf.upfronthosting.co.za>


Changes by Joe Peterson <joe at skyrush.com>:


Removed file: http://bugs.python.org/file20426/imaplib_Internaldate2tuple_python27.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10921>
_______________________________________

From report at bugs.python.org  Tue Jan 18 02:36:03 2011
From: report at bugs.python.org (Joe Peterson)
Date: Tue, 18 Jan 2011 01:36:03 +0000
Subject: [issue10921] imaplib: Internaldate2tuple() string/bytes issues,
	does not handle negative TZ offsets, does not handle DST correctly
In-Reply-To: <1295220756.66.0.509737296044.issue10921@psf.upfronthosting.co.za>
Message-ID: <1295314563.56.0.597944182594.issue10921@psf.upfronthosting.co.za>


Changes by Joe Peterson <joe at skyrush.com>:


Added file: http://bugs.python.org/file20432/imaplib_Internaldate2tuple_python27.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10921>
_______________________________________

From report at bugs.python.org  Tue Jan 18 03:21:13 2011
From: report at bugs.python.org (Tim Alexander)
Date: Tue, 18 Jan 2011 02:21:13 +0000
Subject: [issue4892] Sending Connection-objects over multiprocessing
	connections fails
In-Reply-To: <1231501567.81.0.886406215073.issue4892@psf.upfronthosting.co.za>
Message-ID: <1295317273.5.0.825296403289.issue4892@psf.upfronthosting.co.za>


Tim Alexander <dragonfyre13 at gmail.com> added the comment:

Wanted to quickly comment here, as I'm dealing with this issue as well, that I did find a workaround for avoiding it as far back as 2.6 (and it's not "don't pass a Pipe through a Pipe")

multiprocessing.reduction can already do this, though I don't entirely know why this isn't automatically done if it's a connection object.

>>> from multiprocessing import Pipe, reduction
>>> i, o = Pipe()
>>> reduced = reduction.reduce_connection(i)
>>> newi = reduced[0](*reduced[1])
>>> newi.send("hi")
>>> o.recv()
'hi'
>>> 

The reduced[0](*reduced[1]) line is actually calling reduction.rebuild_connection, as that function is the first element in the tuple, and the second element is the arguments to be passed to it. I can't seem to find any info on reduction.reduce_connection, so I don't know if this is how this was intended to be handled or not.

P.S. Tested on Win (XP) and Linux (Ubuntu 10.10), so there's no weird windows socket stuff that should go wrong with this.

----------
nosy: +dragonfyre13

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4892>
_______________________________________

From report at bugs.python.org  Tue Jan 18 04:18:47 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 18 Jan 2011 03:18:47 +0000
Subject: [issue10921] imaplib: Internaldate2tuple() string/bytes issues,
	does not handle negative TZ offsets, does not handle DST correctly
In-Reply-To: <1295220756.66.0.509737296044.issue10921@psf.upfronthosting.co.za>
Message-ID: <1295320727.28.0.261389654.issue10921@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

There are at least 3 issues here: a documentation issue, a py3k bug and at least one feature request.  Given that the logistics are different for different kinds of issues, I think it would be best to split them on the tracker.  Here is how I see what is being proposed:

1. Internaldate2tuple is documented to return UTC timetuple, but implemented to return local time (ignoring the DST issues.)  The proposal is to change the documentation.

2. There are a couple of str vs bytes bugs that obviously need to be fixed.

3. The proposed patch also make both str and bytes acceptable as Internaldate2tuple argument.

As discussed in issue 9864, it would be best if datetime formatting and parsing routines would operate on datetime objects.  Something along the lines of


def parseinternaldate(datestr):
    return datetime.strptime(datestr, "%d-%b-%Y %H:%M:%S %z")

def formatinternaldate(dateobj):
    return dateobj.strftime("%d-%b-%Y %H:%M:%S %z")

The above uses recently added timezone support in datetime module.

There is still a problem, though.  The code above would only work as expected in the C locale, but Time2Internaldate already has this limitation.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10921>
_______________________________________

From report at bugs.python.org  Tue Jan 18 05:02:36 2011
From: report at bugs.python.org (Ron Adam)
Date: Tue, 18 Jan 2011 04:02:36 +0000
Subject: [issue10918] **kwargs unnecessarily restricted in concurrent.futures
	'submit' API
In-Reply-To: <1295192992.12.0.880697566702.issue10918@psf.upfronthosting.co.za>
Message-ID: <1295323356.43.0.576092350838.issue10918@psf.upfronthosting.co.za>


Ron Adam <ron_adam at users.sourceforge.net> added the comment:

Here is the whole method for reference...

    def submit(self, fn, *args, **kwargs):
        with self._shutdown_lock:
            if self._shutdown_thread:
                raise RuntimeError('cannot schedule new futures after shutdown')

            f = _base.Future()
            w = _WorkItem(f, fn, args, kwargs)

            self._pending_work_items[self._queue_count] = w
            self._work_ids.put(self._queue_count)
            self._queue_count += 1

            self._start_queue_management_thread()
            self._adjust_process_count()
            return f
    submit.__doc__ = _base.Executor.submit.__doc__


If self and fn are in kwargs, they are probably a *different* self and fn, than the self and fn passed to submit!
 
The current submit definition doesn't allow that, and pulling out self, and fn, would not be correct either.  

If it's still possible to change the method call signature, it should be without asterisks...

    def submit(self, fn, args, kwargs):   
        ...

Then the correct way to call it would be...

    submit(foo, [1, 2], dict(fn=bar))

There wouldn't be a conflict because the args, and keywords, (to be eventually passed to fn), are never unpacked within submit.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10918>
_______________________________________

From report at bugs.python.org  Tue Jan 18 05:07:55 2011
From: report at bugs.python.org (Ron Adam)
Date: Tue, 18 Jan 2011 04:07:55 +0000
Subject: [issue10918] **kwargs unnecessarily restricted in concurrent.futures
	'submit' API
In-Reply-To: <1295192992.12.0.880697566702.issue10918@psf.upfronthosting.co.za>
Message-ID: <1295323675.62.0.950605448707.issue10918@psf.upfronthosting.co.za>


Ron Adam <ron_adam at users.sourceforge.net> added the comment:

Change...

   "are never unpacked within submit."

to...

    Are completely separate.   


It's the attempt to mix two function signatures together as one, that was/is the problem.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10918>
_______________________________________

From report at bugs.python.org  Tue Jan 18 05:19:14 2011
From: report at bugs.python.org (Joe Peterson)
Date: Tue, 18 Jan 2011 04:19:14 +0000
Subject: [issue10921] imaplib: Internaldate2tuple() string/bytes issues,
	does not handle negative TZ offsets, does not handle DST correctly
In-Reply-To: <1295220756.66.0.509737296044.issue10921@psf.upfronthosting.co.za>
Message-ID: <1295324354.11.0.617179618987.issue10921@psf.upfronthosting.co.za>


Joe Peterson <joe at skyrush.com> added the comment:

>There are at least 3 issues here: a documentation issue, a py3k bug and at least one feature request.

Which is a feature request?  In these patches, I am attempting to fix the DST problems and regain the previous behavior in Python 2.  Are you talking about the ability to accept a string vs. a bytes object?

> 1. Internaldate2tuple is documented to return UTC timetuple, but implemented to return local time (ignoring the DST issues.)  The proposal is to change the documentation.

I prefer UTC, so this is a bit of a shame, I agree, but the use of the pervious interfaces assumed localtime, so changing to UTC would definitely break existing code.  I do think it would be nice to extend this to deal with UTC instead, but in this patch, I am only trying to retain current functionality.

2. There are a couple of str vs bytes bugs that obviously need to be fixed.

> 3. The proposed patch also make both str and bytes acceptable as Internaldate2tuple argument.

True, but given the new role of str and bytes, it is unclear what existing code would try to pass.

> As discussed in issue 9864, it would be best if datetime formatting and parsing routines would operate on datetime objects.

I can see that redoing some of this would be a good idea.  But I am only trying to keep the existing stuff from being broken in this patch.  I agree that the interfaces could be a lot better, and I would indeed like to see it improved (and I am willing to help with doing that).

> There is still a problem, though.  The code above would only work as expected in the C locale, but Time2Internaldate already has this limitation.

As long as we assume strings passed are ASCII, it should work.  And email headers should be ASCII (although I have seen some really weird deviations from this on old emails).  It's not perfect, certainly, and going forward, the IMAP lib could be tightened up.  Maybe this first patch could be thought of as a step, at least fixing what is broken until improved.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10921>
_______________________________________

From report at bugs.python.org  Tue Jan 18 05:44:52 2011
From: report at bugs.python.org (Ned Deily)
Date: Tue, 18 Jan 2011 04:44:52 +0000
Subject: [issue6075] Patch for IDLE/OS X to work with Tk-Cocoa
In-Reply-To: <1242858324.92.0.20433040915.issue6075@psf.upfronthosting.co.za>
Message-ID: <1295325892.9.0.285360805452.issue6075@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Backported to 2.7 in r88090 (to appear in 2.7.2).

(I decided to not backport to 3.1 as some prereq backports would be needed and we do not supply a 64-bit OS X installer for 3.1.x anyway.)

----------
assignee: ronaldoussoren -> ned.deily
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed
versions:  -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6075>
_______________________________________

From report at bugs.python.org  Tue Jan 18 06:06:53 2011
From: report at bugs.python.org (Sean Reifschneider)
Date: Tue, 18 Jan 2011 05:06:53 +0000
Subject: [issue10924] Adding salt and Modular Crypt Format to crypt library.
In-Reply-To: <1295247997.49.0.7150272714.issue10924@psf.upfronthosting.co.za>
Message-ID: <1295327213.82.0.978114208381.issue10924@psf.upfronthosting.co.za>


Sean Reifschneider <jafo at tummy.com> added the comment:

Thanks for the review.  Attached is a new version of the patch.

1) Done.

2) Good point, I didn't think of that.  I've changed it into a class that stores the methods list, and made the module "methods" point to that method on an instance of that class.

3) This entirely depends on the underlying C library implementation of crypt.  It won't cause mksalt() to blow up, it's just that the crypt(3) call won't know how to deal with it.  On my Linux system using glibc, it simply uses the first two characters as the salt, which isn't entirely surprising except that "$" is not a valid salt character according to the standards.

4) I was being lazy and not looking up the locale implications of doing that.  They look fine, so I've changed it to use that.  Good suggestion.

5) I almost did that, but I figured that, generating a random salt, it was obvious that the return value would be different for the same result.  However, since you mentioned it as well, I've added a note.

6) I don't know, I thought everything in Python 3 was a new style class?

7) I don't see that.  Perhaps you mis-read "Lib/test/test_crypt.py" as being another copy of "Lib/crypt.py"?  In any case, I don't see it in v3 or v4 (the one addressing your questions).

----------
Added file: http://bugs.python.org/file20433/python-underscore_crypt-4.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10924>
_______________________________________

From report at bugs.python.org  Tue Jan 18 07:30:59 2011
From: report at bugs.python.org (Ross Lagerwall)
Date: Tue, 18 Jan 2011 06:30:59 +0000
Subject: [issue4681] mmap offset should be off_t instead of ssize_t,
	and size calculation needs corrected
In-Reply-To: <1229503209.88.0.900633557014.issue4681@psf.upfronthosting.co.za>
Message-ID: <1295332259.86.0.216285987754.issue4681@psf.upfronthosting.co.za>


Ross Lagerwall <rosslagerwall at gmail.com> added the comment:

Attached is a fix to make offset use off_t. This means that mmap will work with offset > 2GB on 32bit systems.

It also fixes that mmap.size() returns the correct value for files > 2GB on 32bit systems.

The first issue of msg78055 was fixed in issue10916, this also fixes the second part, raising an exception if the mmap length is too large instead of mmap()ing an invalid or wrong size.

----------
nosy: +rosslagerwall
Added file: http://bugs.python.org/file20434/mmap.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4681>
_______________________________________

From report at bugs.python.org  Tue Jan 18 08:14:27 2011
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 18 Jan 2011 07:14:27 +0000
Subject: [issue10918] **kwargs unnecessarily restricted in concurrent.futures
	'submit' API
In-Reply-To: <1295192992.12.0.880697566702.issue10918@psf.upfronthosting.co.za>
Message-ID: <1295334867.2.0.0937687998134.issue10918@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

> The current submit definition doesn't allow that, and pulling out self, and fn, would not be correct either.  

It would if they are pulled from *args.  The only difference to now is that you cannot give the self and fn args as keyword args anymore (but that is moot in the case of self, and for fn that was the aim of the issue).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10918>
_______________________________________

From report at bugs.python.org  Tue Jan 18 11:54:38 2011
From: report at bugs.python.org (Albert)
Date: Tue, 18 Jan 2011 10:54:38 +0000
Subject: [issue10930] dict.setdefault: Bug: default argument is ALWAYS
	evaluated, i.e. no short-circuit eval
In-Reply-To: <1295348078.83.0.563667045333.issue10930@psf.upfronthosting.co.za>
Message-ID: <1295348078.83.0.563667045333.issue10930@psf.upfronthosting.co.za>


New submission from Albert <albert.neu at gmail.com>:

Hello!

Is it intentional, that the default argument is ALWAYS evaluated, even if it is not needed???

Is it not a bug, that this method has no short-circuit eval (http://en.wikipedia.org/wiki/Short-circuit_evaluation)
??

Example1:
=========
infinite = 1e100

one_div_by = {0.0 : infinite}

def func(n):
    return one_div_by.setdefault(float(n), 1/float(n))

for i in [1, 2, 3, 4]:
    print i, func(i)
print one_div_by
# works!!

for i in [0, 1, 2, 3, 4]:     # added 0 -> FAIL!
    print i, func(i)
print one_div_by
# fail!!



Example2:
=========
fib_d = {0 : 0, 1 : 1}

def fibonacci(n):
    return fib_d.setdefault(n, fibonacci(n-1) + fibonacci(n-2))

for i in range(10):
    print i, fibonacci(i)
print fib_d

----------
messages: 126456
nosy: albert.neu
priority: normal
severity: normal
status: open
title: dict.setdefault: Bug: default argument is ALWAYS evaluated, i.e. no short-circuit eval
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10930>
_______________________________________

From report at bugs.python.org  Tue Jan 18 12:13:08 2011
From: report at bugs.python.org (ricardw)
Date: Tue, 18 Jan 2011 11:13:08 +0000
Subject: [issue10931] print() from pipe enclosed between 'b and 'pair on
	python3
In-Reply-To: <1295349188.44.0.579328833757.issue10931@psf.upfronthosting.co.za>
Message-ID: <1295349188.44.0.579328833757.issue10931@psf.upfronthosting.co.za>


New submission from ricardw <ricardw at intervisit.com>:

The following script produces different output on python2.6.6 vs. python3.1.2:
-------------
import subprocess, sys

ls = subprocess.Popen(['ls', '-l', '/etc/motd'], stdout=subprocess.PIPE,)

end_of_pipe = ls.stdout

print('Result:')

for line in end_of_pipe:
    print(line.strip())
-------------

Result from invoking with python2 and python3 are respectively:

Result:
-rw-rw---- 1 root root 25 Jan 18 10:25 /etc/motd

and:

Result:
b'-rw-rw---- 1 root root 25 Jan 18 10:25 /etc/motd'

Is this difference a feature, or a bug ?

----------
components: Interpreter Core
messages: 126457
nosy: ricardw
priority: normal
severity: normal
status: open
title: print() from pipe enclosed between 'b and 'pair on python3
type: behavior
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10931>
_______________________________________

From report at bugs.python.org  Tue Jan 18 12:41:49 2011
From: report at bugs.python.org (Sean Reifschneider)
Date: Tue, 18 Jan 2011 11:41:49 +0000
Subject: [issue10924] Adding salt and Modular Crypt Format to crypt library.
In-Reply-To: <1295247997.49.0.7150272714.issue10924@psf.upfronthosting.co.za>
Message-ID: <1295350909.62.0.351365706589.issue10924@psf.upfronthosting.co.za>


Changes by Sean Reifschneider <jafo at tummy.com>:


Removed file: http://bugs.python.org/file20428/python-underscore_crypt-3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10924>
_______________________________________

From report at bugs.python.org  Tue Jan 18 13:14:19 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 18 Jan 2011 12:14:19 +0000
Subject: [issue10930] dict.setdefault: Bug: default argument is ALWAYS
	evaluated, i.e. no short-circuit eval
In-Reply-To: <1295348078.83.0.563667045333.issue10930@psf.upfronthosting.co.za>
Message-ID: <1295352859.47.0.183030916297.issue10930@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

setdefault() is a method, its arguments are evaluated then the function is called. This is not a bug, and this behavior cannot change.

If you are trying to "cache" the computation of a function, you should try "memoizing" techniques, like the one mentioned here: http://code.activestate.com/recipes/52201-memoizing-cacheing-function-return-values/
Then you can write::

    @Memoize
    def fib(n):
        return fib(n-1) + fib(n-2)
    fib.memo = {(0,): 1, (1,): 1}

    @Memoize
    def func(n):
        return 1/float(n)
    func.memo = {(0.0,): infinite}

----------
nosy: +amaury.forgeotdarc
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10930>
_______________________________________

From report at bugs.python.org  Tue Jan 18 13:30:25 2011
From: report at bugs.python.org (Thorsten Simons)
Date: Tue, 18 Jan 2011 12:30:25 +0000
Subject: [issue10932] distutils.core.setup - data_files missbehaviour ?
In-Reply-To: <1295353825.23.0.755300594789.issue10932@psf.upfronthosting.co.za>
Message-ID: <1295353825.23.0.755300594789.issue10932@psf.upfronthosting.co.za>


New submission from Thorsten Simons <th at snomis.de>:

Hi !

when specifying additional files to be distributed by distutils.core.setup, documentation says that:

"Each file name in files is interpreted relative to the setup.py script at the top of the package source distribution. No directory information from files is used to determine the final location of the installed file; only the name of the file is used"

(http://docs.python.org/py3k/distutils/setupscript.html#distutils-additional-files)

Well, this seems to be incorrect - I tried to specify a file from a higher level directory, which get's copies to a target based on the whole path I specified, not just the name...

Pls. see attached file for details

----------
assignee: tarek
components: Distutils
files: issue.txt
messages: 126459
nosy: Thorsten.Simons, eric.araujo, tarek
priority: normal
severity: normal
status: open
title: distutils.core.setup - data_files missbehaviour ?
type: behavior
versions: Python 3.1
Added file: http://bugs.python.org/file20435/issue.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10932>
_______________________________________

From report at bugs.python.org  Tue Jan 18 13:31:12 2011
From: report at bugs.python.org (Fabio Zadrozny)
Date: Tue, 18 Jan 2011 12:31:12 +0000
Subject: [issue10933] Tracing disabled when a recursion error is triggered
	(even if properly handled)
In-Reply-To: <1295353872.95.0.129870258846.issue10933@psf.upfronthosting.co.za>
Message-ID: <1295353872.95.0.129870258846.issue10933@psf.upfronthosting.co.za>


New submission from Fabio Zadrozny <fabioz at users.sourceforge.net>:

It seems that tracing in the interpreter is lost after some recursion error is triggered (even if it's properly handled).

This breaks any debugger working after any recursion error is triggered (which suppose shouldn't happen).

The attached test case shows the problem in action.

Tested the problem with Python 2.6.5 and 3.1.3

----------
components: Interpreter Core
files: recursion_error_disables_tracing.py
messages: 126460
nosy: fabioz
priority: normal
severity: normal
status: open
title: Tracing disabled when a recursion error is triggered (even if properly handled)
type: behavior
versions: Python 2.6, Python 3.1
Added file: http://bugs.python.org/file20436/recursion_error_disables_tracing.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10933>
_______________________________________

From report at bugs.python.org  Tue Jan 18 13:38:02 2011
From: report at bugs.python.org (Ross Lagerwall)
Date: Tue, 18 Jan 2011 12:38:02 +0000
Subject: [issue10451] memoryview can be used to write into readonly buffer
In-Reply-To: <1290064697.49.0.308725501485.issue10451@psf.upfronthosting.co.za>
Message-ID: <1295354282.55.0.665111679362.issue10451@psf.upfronthosting.co.za>


Ross Lagerwall <rosslagerwall at gmail.com> added the comment:

>From what I can see, this issue is in memoryview and allows memoryview to export a readonly buffer as writable (because memoryview.getbuffer() removes the writable flag from flags before calling the underlying buffer).

This causes segfaults when using mmap. 

If a bytes object is used as the underlying buffer, it allows the bytes object to be changed.

Given this code:

import io
b=b"XXXX"
m=memoryview(b)
i=io.BytesIO(b'ZZZZ')
i.readinto(m)
print(b)
print(b == b"XXXX")

The output is:
b'ZZZZ'
True

I think this is due to interning.

Anyway, attached is a patch which hopefully fixes the issue + a test.

----------
keywords: +patch
nosy: +rosslagerwall
Added file: http://bugs.python.org/file20437/i10451.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10451>
_______________________________________

From report at bugs.python.org  Tue Jan 18 13:59:40 2011
From: report at bugs.python.org (ricardw)
Date: Tue, 18 Jan 2011 12:59:40 +0000
Subject: [issue10931] print() from pipe enclosed between b' and 'pair on
	python3
In-Reply-To: <1295349188.44.0.579328833757.issue10931@psf.upfronthosting.co.za>
Message-ID: <1295355580.25.0.621682691726.issue10931@psf.upfronthosting.co.za>


Changes by ricardw <ricardw at intervisit.com>:


----------
title: print() from pipe enclosed between 'b and 'pair on python3 -> print() from pipe enclosed between b' and 'pair on python3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10931>
_______________________________________

From report at bugs.python.org  Tue Jan 18 14:00:23 2011
From: report at bugs.python.org (ricardw)
Date: Tue, 18 Jan 2011 13:00:23 +0000
Subject: [issue10931] print() from pipe enclosed between b' and '&nbsp;
	pair on python3
In-Reply-To: <1295349188.44.0.579328833757.issue10931@psf.upfronthosting.co.za>
Message-ID: <1295355623.82.0.236080211077.issue10931@psf.upfronthosting.co.za>


Changes by ricardw <ricardw at intervisit.com>:


----------
title: print() from pipe enclosed between b' and 'pair on python3 -> print() from pipe enclosed between b' and '&nbsp;pair on python3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10931>
_______________________________________

From report at bugs.python.org  Tue Jan 18 14:01:13 2011
From: report at bugs.python.org (ricardw)
Date: Tue, 18 Jan 2011 13:01:13 +0000
Subject: [issue10931] print() from pipe enclosed between {b'} and {'}-pair on
	python3
In-Reply-To: <1295349188.44.0.579328833757.issue10931@psf.upfronthosting.co.za>
Message-ID: <1295355673.72.0.0551290763026.issue10931@psf.upfronthosting.co.za>


Changes by ricardw <ricardw at intervisit.com>:


----------
title: print() from pipe enclosed between b' and '&nbsp;pair on python3 -> print() from pipe enclosed between {b'} and {'}-pair on python3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10931>
_______________________________________

From report at bugs.python.org  Tue Jan 18 14:19:34 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 18 Jan 2011 13:19:34 +0000
Subject: [issue10931] print() from pipe enclosed between {b'} and {'}-pair on
	python3
In-Reply-To: <1295349188.44.0.579328833757.issue10931@psf.upfronthosting.co.za>
Message-ID: <1295356774.62.0.327340192768.issue10931@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

It's a feature. Subprocess output is binary data, not text; and since python3, the string type is now what python2 called unicode!

Please read http://docs.python.org/py3k/whatsnew/3.0.html#text-vs-data-instead-of-unicode-vs-8-bit
for an explanation of the most important difference between python2 and python3.

----------
nosy: +amaury.forgeotdarc
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10931>
_______________________________________

From report at bugs.python.org  Tue Jan 18 14:29:05 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 18 Jan 2011 13:29:05 +0000
Subject: [issue10451] memoryview can be used to write into readonly buffer
In-Reply-To: <1290064697.49.0.308725501485.issue10451@psf.upfronthosting.co.za>
Message-ID: <1295357345.24.0.654284882386.issue10451@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/issue10451>
_______________________________________

From report at bugs.python.org  Tue Jan 18 14:46:08 2011
From: report at bugs.python.org (Joe Peterson)
Date: Tue, 18 Jan 2011 13:46:08 +0000
Subject: [issue10934] imaplib: Internaldate2tuple() is documented to return
	UTC, but it returns local time
In-Reply-To: <1295358368.86.0.12522725261.issue10934@psf.upfronthosting.co.za>
Message-ID: <1295358368.86.0.12522725261.issue10934@psf.upfronthosting.co.za>


New submission from Joe Peterson <joe at skyrush.com>:

Patched documentation for Internaldate2tuple() to correctly state it returns local time.

Also, Time2Internaldate() (its inverse) did not state that it needs local time as input, so patched this as well.

Patches for 3.2 and 2.7 are attached.

----------
assignee: docs at python
components: Documentation
files: imaplib_Internaldate2tuple_doc_python32.patch
keywords: patch
messages: 126463
nosy: docs at python, lavajoe
priority: normal
severity: normal
status: open
title: imaplib: Internaldate2tuple() is documented to return UTC, but it returns local time
versions: Python 2.7, Python 3.2
Added file: http://bugs.python.org/file20438/imaplib_Internaldate2tuple_doc_python32.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10934>
_______________________________________

From report at bugs.python.org  Tue Jan 18 14:46:20 2011
From: report at bugs.python.org (Joe Peterson)
Date: Tue, 18 Jan 2011 13:46:20 +0000
Subject: [issue10934] imaplib: Internaldate2tuple() is documented to return
	UTC, but it returns local time
In-Reply-To: <1295358368.86.0.12522725261.issue10934@psf.upfronthosting.co.za>
Message-ID: <1295358380.84.0.269539469429.issue10934@psf.upfronthosting.co.za>


Changes by Joe Peterson <joe at skyrush.com>:


Added file: http://bugs.python.org/file20439/imaplib_Internaldate2tuple_doc_python27.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10934>
_______________________________________

From report at bugs.python.org  Tue Jan 18 14:59:46 2011
From: report at bugs.python.org (Joe Peterson)
Date: Tue, 18 Jan 2011 13:59:46 +0000
Subject: [issue10921] imaplib: Internaldate2tuple() string/bytes issues,
	does not handle negative TZ offsets, does not handle DST correctly
In-Reply-To: <1295220756.66.0.509737296044.issue10921@psf.upfronthosting.co.za>
Message-ID: <1295359186.67.0.3010059245.issue10921@psf.upfronthosting.co.za>


Joe Peterson <joe at skyrush.com> added the comment:

I have started splitting these up as recommended.  First one (documentation) is: issue 10934.  I will split out more later today...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10921>
_______________________________________

From report at bugs.python.org  Tue Jan 18 15:10:22 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 18 Jan 2011 14:10:22 +0000
Subject: [issue10924] Adding salt and Modular Crypt Format to crypt library.
In-Reply-To: <1295327213.82.0.978114208381.issue10924@psf.upfronthosting.co.za>
Message-ID: <1295359817.3668.1.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

Can you use "diff -u" (or simply "svn diff") when generating a patch?

> 6) I don't know, I thought everything in Python 3 was a new style
> class?

It is indeed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10924>
_______________________________________

From report at bugs.python.org  Tue Jan 18 16:10:00 2011
From: report at bugs.python.org (R. David Murray)
Date: Tue, 18 Jan 2011 15:10:00 +0000
Subject: [issue10921] imaplib: Internaldate2tuple() string/bytes issues,
	does not handle negative TZ offsets, does not handle DST correctly
In-Reply-To: <1295220756.66.0.509737296044.issue10921@psf.upfronthosting.co.za>
Message-ID: <1295363400.96.0.179462943951.issue10921@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

If I understand correctly, what Alexander means by "only work in the C locale" is that both strptime and strftime are locale dependent, and so if the locale is something other than C it may fail to parse the month name and may generate a non-standard month name.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10921>
_______________________________________

From report at bugs.python.org  Tue Jan 18 16:28:06 2011
From: report at bugs.python.org (Eric Smith)
Date: Tue, 18 Jan 2011 15:28:06 +0000
Subject: [issue10930] dict.setdefault: Bug: default argument is ALWAYS
	evaluated, i.e. no short-circuit eval
In-Reply-To: <1295348078.83.0.563667045333.issue10930@psf.upfronthosting.co.za>
Message-ID: <1295364486.52.0.182297938823.issue10930@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

Or use a collections.defaultdict, which has a factory function as a constructor argument. It sort of depends on what you're trying to do.

----------
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10930>
_______________________________________

From report at bugs.python.org  Tue Jan 18 16:59:43 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 18 Jan 2011 15:59:43 +0000
Subject: [issue10451] memoryview can be used to write into readonly buffer
In-Reply-To: <1290064697.49.0.308725501485.issue10451@psf.upfronthosting.co.za>
Message-ID: <1295366383.04.0.426753597715.issue10451@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

The patch produces a failure in test_getargs2, but that test is wrong and should be fixed:

======================================================================
ERROR: test_w_star (test.test_getargs2.Bytes_TestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/antoine/py3k/__svn__/Lib/test/test_getargs2.py", line 385, in test_w_star
    self.assertEqual(getargs_w_star(memoryview(b'memoryview')), b'[emoryvie]')
TypeError: must be read-write buffer, not memoryview


I'm surprised no other test failures arise. I did add that line (which I commented with "XXX for whatever reason...") for a reason, but I don't remember which one. It seemed necessary at the time, I'm glad it isn't anymore.

So, about the patch itself: you should simply use assertRaises. There's no reason for readinto() not to fail with a TypeError (silent failure is wrong). Thank you.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10451>
_______________________________________

From report at bugs.python.org  Tue Jan 18 17:02:25 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 18 Jan 2011 16:02:25 +0000
Subject: [issue10451] memoryview can be used to write into readonly buffer
In-Reply-To: <1290064697.49.0.308725501485.issue10451@psf.upfronthosting.co.za>
Message-ID: <1295366545.6.0.247342530165.issue10451@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +georg.brandl
priority: normal -> critical

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10451>
_______________________________________

From report at bugs.python.org  Tue Jan 18 17:51:49 2011
From: report at bugs.python.org (Ross Lagerwall)
Date: Tue, 18 Jan 2011 16:51:49 +0000
Subject: [issue10451] memoryview can be used to write into readonly buffer
In-Reply-To: <1290064697.49.0.308725501485.issue10451@psf.upfronthosting.co.za>
Message-ID: <1295369509.6.0.912601869272.issue10451@psf.upfronthosting.co.za>


Ross Lagerwall <rosslagerwall at gmail.com> added the comment:

Attached is an updated patch with a simpler test.

----------
Added file: http://bugs.python.org/file20440/i10451_v2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10451>
_______________________________________

From report at bugs.python.org  Tue Jan 18 18:01:11 2011
From: report at bugs.python.org (Ross Lagerwall)
Date: Tue, 18 Jan 2011 17:01:11 +0000
Subject: [issue10451] memoryview can be used to write into readonly buffer
In-Reply-To: <1290064697.49.0.308725501485.issue10451@psf.upfronthosting.co.za>
Message-ID: <1295370071.26.0.903680568417.issue10451@psf.upfronthosting.co.za>


Ross Lagerwall <rosslagerwall at gmail.com> added the comment:

And a simple fix for the test_getargs2 test - it wraps the memoryview around a bytearray.

----------
Added file: http://bugs.python.org/file20441/testfix.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10451>
_______________________________________

From report at bugs.python.org  Tue Jan 18 18:29:24 2011
From: report at bugs.python.org (Tim Perevezentsev)
Date: Tue, 18 Jan 2011 17:29:24 +0000
Subject: [issue10935] wsgiref.handlers.BaseHandler and subclasses of str
In-Reply-To: <1295371764.49.0.785710350986.issue10935@psf.upfronthosting.co.za>
Message-ID: <1295371764.49.0.785710350986.issue10935@psf.upfronthosting.co.za>


New submission from Tim Perevezentsev <riffm2005 at gmail.com>:

This code:

    assert type(val) is StringType,"Header values must be strings"

(from here http://svn.python.org/view/python/tags/r271/Lib/wsgiref/handlers.py?revision=86833&view=markup)

from "start_response" method, is not allowing to use str subclasses objects as header value.

Usecase:

I made class URL which subclasses str and has additional methods to manipulate query string. It is very handy. But when I need to set header
"Location" with URL object as value I get assertion error.

Can't we do this instead:

    assert isinstance(val, str),"Header values must be strings"

----------
components: Library (Lib)
messages: 126471
nosy: riffm
priority: normal
severity: normal
status: open
title: wsgiref.handlers.BaseHandler and subclasses of str
type: behavior
versions: Python 2.5, Python 2.6, Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10935>
_______________________________________

From report at bugs.python.org  Tue Jan 18 19:19:18 2011
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 18 Jan 2011 18:19:18 +0000
Subject: [issue10451] memoryview can be used to write into readonly buffer
In-Reply-To: <1290064697.49.0.308725501485.issue10451@psf.upfronthosting.co.za>
Message-ID: <1295374758.49.0.301430010222.issue10451@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

So, does "critical" mean "should be release blocker"?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10451>
_______________________________________

From report at bugs.python.org  Tue Jan 18 19:19:20 2011
From: report at bugs.python.org (Ron Adam)
Date: Tue, 18 Jan 2011 18:19:20 +0000
Subject: [issue10918] **kwargs unnecessarily restricted in concurrent.futures
	'submit' API
In-Reply-To: <1295192992.12.0.880697566702.issue10918@psf.upfronthosting.co.za>
Message-ID: <1295374760.32.0.87609637974.issue10918@psf.upfronthosting.co.za>


Ron Adam <ron_adam at users.sourceforge.net> added the comment:

Yes, you are correct.  Pulling the first value off of args would work.

This is new for 3.2, can it still be changed?


One more thing to consider...

One of the things I look at for functions like these is, how easy is it to separate the data from the program interface?

I prefer:
    submit_data = [fn, args, kwds]
    e.submit(*submit_data)

or..
    submit_args = [(a, k), (a, k), ... ]
    for args, kwds in submit_args:
        e.submit(fn, args, kwds)

But its a trade off against easier direct calling.  My feelings, is submit will be used more in an indirect way, like these examples, rather than being used directly by writing out each submit separately.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10918>
_______________________________________

From report at bugs.python.org  Tue Jan 18 19:25:41 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 18 Jan 2011 18:25:41 +0000
Subject: [issue10451] memoryview can be used to write into readonly buffer
In-Reply-To: <1295374758.49.0.301430010222.issue10451@psf.upfronthosting.co.za>
Message-ID: <1295375136.3668.20.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> So, does "critical" mean "should be release blocker"?

It's up to you to decide. It's not a new bug AFAICT.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10451>
_______________________________________

From report at bugs.python.org  Tue Jan 18 19:43:23 2011
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 18 Jan 2011 18:43:23 +0000
Subject: [issue10451] memoryview can be used to write into readonly buffer
In-Reply-To: <1290064697.49.0.308725501485.issue10451@psf.upfronthosting.co.za>
Message-ID: <1295376203.2.0.739403994902.issue10451@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

The patch looks trivial enough.  You're the memoryview guru, so if you have no doubts about it, I would say it can go in.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10451>
_______________________________________

From report at bugs.python.org  Tue Jan 18 20:07:58 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 18 Jan 2011 19:07:58 +0000
Subject: [issue10451] memoryview can be used to write into readonly buffer
In-Reply-To: <1290064697.49.0.308725501485.issue10451@psf.upfronthosting.co.za>
Message-ID: <1295377678.51.0.345724133186.issue10451@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Patch with modified tests committed in r88097 (3.2), r88098 (3.1) and r88099 (2.7). Thank you!

----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
versions: +Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10451>
_______________________________________

From report at bugs.python.org  Tue Jan 18 20:12:04 2011
From: report at bugs.python.org (Christopher Dunn)
Date: Tue, 18 Jan 2011 19:12:04 +0000
Subject: [issue10936] Simple CSS fix for left margin at docs.python.org
In-Reply-To: <1295377924.0.0.902429691003.issue10936@psf.upfronthosting.co.za>
Message-ID: <1295377924.0.0.902429691003.issue10936@psf.upfronthosting.co.za>


New submission from Christopher Dunn <cdunn2001 at gmail.com>:

This is an easy one.

When I zoom my browser in (with Ctrl+ or Apple+) the left-side navigation margin gets bigger and bigger, pushing the useful text off the screen. That has bothered me (and anyone else with 40+ year old eyes) ever since the switch to the newest doc format with Sphinx.

There is no fix that will satisfy everyone. People with perfect vision might like to zoom out (with Ctrl- or Apple-), since the margin currently gets smaller and smaller. But we need a compromise.

The relevant CSS, in default.css, is this:

 div.bodywrapper {
    margin: 0 0 0 230px;
 }

If instead it were something like this:

 div.bodywrapper {
    margin: 0 0 0 10%;
 }

then at least the navigation margin would stay the same size always.

If you really want it to grow and shrink, then you need some sort of javascript control of its position.

----------
assignee: docs at python
components: Documentation
messages: 126477
nosy: cdunn2001, docs at python
priority: normal
severity: normal
status: open
title: Simple CSS fix for left margin at docs.python.org
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10936>
_______________________________________

From report at bugs.python.org  Tue Jan 18 20:16:06 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 18 Jan 2011 19:16:06 +0000
Subject: [issue10935] wsgiref.handlers.BaseHandler and subclasses of str
In-Reply-To: <1295371764.49.0.785710350986.issue10935@psf.upfronthosting.co.za>
Message-ID: <1295378166.15.0.83604467909.issue10935@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

This is by design.  PEP 333 and PEP 3333 contain more information about that.  You?ll need to convert your objects to str before passing them to start_response.  Sorry!

----------
nosy: +eric.araujo, pje
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed
versions:  -Python 2.5, Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10935>
_______________________________________

From report at bugs.python.org  Tue Jan 18 20:23:39 2011
From: report at bugs.python.org (Jeremy Langley)
Date: Tue, 18 Jan 2011 19:23:39 +0000
Subject: [issue10937] WinPE 64 bit execution results with errors
In-Reply-To: <1295378619.67.0.475043721406.issue10937@psf.upfronthosting.co.za>
Message-ID: <1295378619.67.0.475043721406.issue10937@psf.upfronthosting.co.za>


New submission from Jeremy Langley <gettingback2basics at gmail.com>:

old versions of python worked on old versions of winpe by copying the c:\python25\ directory over to the mounted (iso,usb) filesystem, then rebooting with the media and running the python.exe from the ramdrive.
This formula no longer works with 64 bit versions of winpe (which is one way to push win7-64bit.

When it's tried one gets platform based errors.

----------
components: Build
messages: 126479
nosy: gettingback2basics
priority: normal
severity: normal
status: open
title: WinPE 64 bit execution results with errors
type: feature request

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10937>
_______________________________________

From report at bugs.python.org  Tue Jan 18 20:25:51 2011
From: report at bugs.python.org (Tim Perevezentsev)
Date: Tue, 18 Jan 2011 19:25:51 +0000
Subject: [issue10935] wsgiref.handlers.BaseHandler and subclasses of str
In-Reply-To: <1295371764.49.0.785710350986.issue10935@psf.upfronthosting.co.za>
Message-ID: <1295378751.7.0.571083168893.issue10935@psf.upfronthosting.co.za>


Tim Perevezentsev <riffm2005 at gmail.com> added the comment:

str - immutable. So every str subclass object is normal string. I don't see any design violation here.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10935>
_______________________________________

From report at bugs.python.org  Tue Jan 18 20:26:19 2011
From: report at bugs.python.org (Humberto Diogenes)
Date: Tue, 18 Jan 2011 19:26:19 +0000
Subject: [issue10938] Undocumented option for datetime.strftime: %s
In-Reply-To: <1295378779.48.0.643087757109.issue10938@psf.upfronthosting.co.za>
Message-ID: <1295378779.48.0.643087757109.issue10938@psf.upfronthosting.co.za>


New submission from Humberto Diogenes <humberto at digi.com.br>:

On some systems, datetime.strftime() accepts a %s format string that returns epoch / UNIX timestamp, but this behavior is not documented at http://docs.python.org/library/datetime.html

Python 2.7 (r27:82508, Jul  3 2010, 21:12:11) 
[GCC 4.0.1 (Apple Inc. build 5493)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import datetime
>>> datetime.datetime.now().strftime('%s')
'1295376929'

----------
assignee: docs at python
components: Documentation
messages: 126481
nosy: docs at python, hdiogenes
priority: normal
severity: normal
status: open
title: Undocumented option for datetime.strftime: %s
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10938>
_______________________________________

From report at bugs.python.org  Tue Jan 18 20:28:47 2011
From: report at bugs.python.org (Adrian Dries)
Date: Tue, 18 Jan 2011 19:28:47 +0000
Subject: [issue10918] **kwargs unnecessarily restricted in concurrent.futures
	'submit' API
In-Reply-To: <1295192992.12.0.880697566702.issue10918@psf.upfronthosting.co.za>
Message-ID: <1295378927.27.0.058312571589.issue10918@psf.upfronthosting.co.za>


Adrian Dries <adries at gmail.com> added the comment:

Have your cake and eat it:

def submit(self, fn, args, kw):
    # submit implementation

def sugar(*args, **kw):
    return args[0].submit(args[1], args[2:], kw)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10918>
_______________________________________

From report at bugs.python.org  Tue Jan 18 20:32:12 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 18 Jan 2011 19:32:12 +0000
Subject: [issue10937] WinPE 64 bit execution results with errors
In-Reply-To: <1295378619.67.0.475043721406.issue10937@psf.upfronthosting.co.za>
Message-ID: <1295379132.28.0.38183987829.issue10937@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/issue10937>
_______________________________________

From report at bugs.python.org  Tue Jan 18 20:34:34 2011
From: report at bugs.python.org (R. David Murray)
Date: Tue, 18 Jan 2011 19:34:34 +0000
Subject: [issue10935] wsgiref.handlers.BaseHandler and subclasses of str
In-Reply-To: <1295371764.49.0.785710350986.issue10935@psf.upfronthosting.co.za>
Message-ID: <1295379274.46.0.387632301623.issue10935@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Eric, could you point out the part of the specification that requires exactly a string and makes a string subclass invalid?  I did a quick scan and couldn't find it, and unfortunately don't have the time to re-read the whole spec right now.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10935>
_______________________________________

From report at bugs.python.org  Tue Jan 18 20:35:32 2011
From: report at bugs.python.org (Brian Curtin)
Date: Tue, 18 Jan 2011 19:35:32 +0000
Subject: [issue10937] WinPE 64 bit execution results with errors
In-Reply-To: <1295378619.67.0.475043721406.issue10937@psf.upfronthosting.co.za>
Message-ID: <1295379332.62.0.592495907229.issue10937@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

Do you have any log files or screenshots of what exactly happens?

I have zero experience with WinPE, so that's an obvious barrier here, but there's also nothing to go by in figuring out where the problem may be.

----------
nosy: +brian.curtin
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10937>
_______________________________________

From report at bugs.python.org  Tue Jan 18 20:38:35 2011
From: report at bugs.python.org (R. David Murray)
Date: Tue, 18 Jan 2011 19:38:35 +0000
Subject: [issue10938] Undocumented option for datetime.strftime: %s
In-Reply-To: <1295378779.48.0.643087757109.issue10938@psf.upfronthosting.co.za>
Message-ID: <1295379515.04.0.22327392443.issue10938@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

As you say, "on some systems".  The variation is documented, and the documented codes are documented as being just those required by the C standard.

----------
nosy: +r.david.murray
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10938>
_______________________________________

From report at bugs.python.org  Tue Jan 18 20:39:03 2011
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 18 Jan 2011 19:39:03 +0000
Subject: [issue10918] **kwargs unnecessarily restricted in concurrent.futures
	'submit' API
In-Reply-To: <1295192992.12.0.880697566702.issue10918@psf.upfronthosting.co.za>
Message-ID: <1295379543.62.0.618964709668.issue10918@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

It could be changed, as it is not an incompatible API change.  However, I'd like Brian to ok it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10918>
_______________________________________

From report at bugs.python.org  Tue Jan 18 20:41:48 2011
From: report at bugs.python.org (Brian Curtin)
Date: Tue, 18 Jan 2011 19:41:48 +0000
Subject: [issue10936] Simple CSS fix for left margin at docs.python.org
In-Reply-To: <1295377924.0.0.902429691003.issue10936@psf.upfronthosting.co.za>
Message-ID: <1295379708.71.0.970733745605.issue10936@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
nosy: +ezio.melotti, georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10936>
_______________________________________

From report at bugs.python.org  Tue Jan 18 20:46:36 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 18 Jan 2011 19:46:36 +0000
Subject: [issue10935] wsgiref.handlers.BaseHandler and subclasses of str
In-Reply-To: <1295371764.49.0.785710350986.issue10935@psf.upfronthosting.co.za>
Message-ID: <1295379996.58.0.8628775439.issue10935@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

See http://bugs.python.org/issue5800#msg121958

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10935>
_______________________________________

From report at bugs.python.org  Tue Jan 18 20:53:14 2011
From: report at bugs.python.org (R. David Murray)
Date: Tue, 18 Jan 2011 19:53:14 +0000
Subject: [issue10935] wsgiref.handlers.BaseHandler and subclasses of str
In-Reply-To: <1295371764.49.0.785710350986.issue10935@psf.upfronthosting.co.za>
Message-ID: <1295380394.63.0.744308862609.issue10935@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

OK.  So he is saying that when the spec says "an object of type str" he means 'type(x) is str' as opposed to 'isinstance(x, str)'.  I would naively have expected the latter, as other people clearly do as well.  I didn't participate in any of the discussions that led to this decision, so I won't pursue it further, but it does break the expectation that many people have about how python programs work, so I expect we'll be seeing this bug report again sometime :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10935>
_______________________________________

From report at bugs.python.org  Tue Jan 18 20:59:02 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 18 Jan 2011 19:59:02 +0000
Subject: [issue10898] posixmodule.c redefines FSTAT
In-Reply-To: <1294857148.96.0.548396285489.issue10898@psf.upfronthosting.co.za>
Message-ID: <1295380742.89.0.314132280905.issue10898@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

How about adding "#undef FSTAT" instead? Would it work for you?

----------
components: +Extension Modules
nosy: +pitrou
stage:  -> needs patch
versions: +Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10898>
_______________________________________

From report at bugs.python.org  Tue Jan 18 21:10:35 2011
From: report at bugs.python.org (Alan Hourihane)
Date: Tue, 18 Jan 2011 20:10:35 +0000
Subject: [issue10898] posixmodule.c redefines FSTAT
In-Reply-To: <1295380742.89.0.314132280905.issue10898@psf.upfronthosting.co.za>
Message-ID: <1295381413.11159.6.camel@jetpack.demon.co.uk>


Alan Hourihane <alanh at fairlite.co.uk> added the comment:

On Tue, 2011-01-18 at 19:59 +0000, Antoine Pitrou wrote:
> Antoine Pitrou <pitrou at free.fr> added the comment:
> 
> How about adding "#undef FSTAT" instead? Would it work for you?

Sure.

Alan.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10898>
_______________________________________

From report at bugs.python.org  Tue Jan 18 21:16:17 2011
From: report at bugs.python.org (Sean Reifschneider)
Date: Tue, 18 Jan 2011 20:16:17 +0000
Subject: [issue10924] Adding salt and Modular Crypt Format to crypt library.
In-Reply-To: <1295247997.49.0.7150272714.issue10924@psf.upfronthosting.co.za>
Message-ID: <1295381777.1.0.20848391153.issue10924@psf.upfronthosting.co.za>


Sean Reifschneider <jafo at tummy.com> added the comment:

Sure thing, here's an "svn diff".  I had switched to the diff because I couldn't get it to patch into a fresh trunk, but the format looked fine; not sure why it couldn't find the files.  Anyway, here's a new version.

----------
Added file: http://bugs.python.org/file20442/python-underscore_crypt-5.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10924>
_______________________________________

From report at bugs.python.org  Tue Jan 18 21:28:08 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 18 Jan 2011 20:28:08 +0000
Subject: [issue10924] Adding salt and Modular Crypt Format to crypt library.
In-Reply-To: <1295381777.1.0.20848391153.issue10924@psf.upfronthosting.co.za>
Message-ID: <1295382480.3668.29.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Sure thing, here's an "svn diff".  I had switched to the diff because
> I couldn't get it to patch into a fresh trunk, but the format looked
> fine; not sure why it couldn't find the files.  Anyway, here's a new
> version.

You also have to "svn add" the relevant files :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10924>
_______________________________________

From report at bugs.python.org  Tue Jan 18 21:54:09 2011
From: report at bugs.python.org (Humberto Diogenes)
Date: Tue, 18 Jan 2011 20:54:09 +0000
Subject: [issue10938] Undocumented option for datetime.strftime: %s
In-Reply-To: <1295378779.48.0.643087757109.issue10938@psf.upfronthosting.co.za>
Message-ID: <1295384049.67.0.225342884619.issue10938@psf.upfronthosting.co.za>


Humberto Diogenes <humberto at digi.com.br> added the comment:

David, as discussed on the IRC channel: maybe we could just add pointers to the OS-specific docs. Something like:

"""
If you want to use platform-specific format strings, search for strftime in your OS documentation (`man strftime` on POSIX systems).

Linux: http://www.kernel.org/doc/man-pages/online/pages/man3/strftime.3.html

Mac OS: http://developer.apple.com/library/mac/#documentation/Darwin/Reference/ManPages/man3/strftime.3.html
"""

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10938>
_______________________________________

From report at bugs.python.org  Tue Jan 18 22:26:51 2011
From: report at bugs.python.org (R. David Murray)
Date: Tue, 18 Jan 2011 21:26:51 +0000
Subject: [issue10938] Provide links to system specific strftime/ptime docs
In-Reply-To: <1295378779.48.0.643087757109.issue10938@psf.upfronthosting.co.za>
Message-ID: <1295386011.83.0.139701762901.issue10938@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

All right, I'll open it back up for that suggestion (I've changed the title accordingly) and let the docs folks decide.  The most useful link would be one to the relevant Windows documentation, since that's the hardest one to find.

Although this scheme avoids the problem of having to maintain a list of 'extra' format codes, it does have one of the same problems that doing so would have: the supported codes may change from OS version to OS version, and do we maintain the links accordingly?  The mitigating factor is that I don't think the supported codes do change much.

----------
resolution: invalid -> 
stage: committed/rejected -> needs patch
status: closed -> open
title: Undocumented option for datetime.strftime: %s -> Provide links to system specific strftime/ptime docs
type: behavior -> feature request
versions: +Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10938>
_______________________________________

From report at bugs.python.org  Tue Jan 18 22:30:32 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 18 Jan 2011 21:30:32 +0000
Subject: [issue10923] Python 2.7 hangs on Unicode+threading
In-Reply-To: <1295230653.16.0.00822246437847.issue10923@psf.upfronthosting.co.za>
Message-ID: <1295386232.58.0.996677888838.issue10923@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/issue10923>
_______________________________________

From report at bugs.python.org  Tue Jan 18 22:35:49 2011
From: report at bugs.python.org (Sean Reifschneider)
Date: Tue, 18 Jan 2011 21:35:49 +0000
Subject: [issue10924] Adding salt and Modular Crypt Format to crypt library.
In-Reply-To: <1295247997.49.0.7150272714.issue10924@psf.upfronthosting.co.za>
Message-ID: <1295386549.22.0.129711185931.issue10924@psf.upfronthosting.co.za>


Sean Reifschneider <jafo at tummy.com> added the comment:

Not sure if that was meant to be a suggestion for why my local patching wasn't working from the "svn diff" output, but obviously -5 was messed up.  Here's a new version that I can apply to my fresh trunk and passes "make test".

If the suggestion was how to fix my patching from "svn diff", the problem I ran into was that it had the files in it, say crypt.py, but it was trying to apply them as if I had specified "patch -p1", even though the "svn diff" contained the paths and I hadn't done "-p1".

Anyway, this diff is "diff -urN".  I just can't win, I usually use "diff -u", but in the distant past Guido asked me for "diff -c" instead.  :-)

----------
Added file: http://bugs.python.org/file20443/python-underscore_crypt-6.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10924>
_______________________________________

From report at bugs.python.org  Tue Jan 18 22:38:38 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 18 Jan 2011 21:38:38 +0000
Subject: [issue4681] mmap offset should be off_t instead of ssize_t,
	and size calculation needs corrected
In-Reply-To: <1229503209.88.0.900633557014.issue4681@psf.upfronthosting.co.za>
Message-ID: <1295386718.92.0.971448236467.issue4681@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/issue4681>
_______________________________________

From report at bugs.python.org  Tue Jan 18 22:40:47 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 18 Jan 2011 21:40:47 +0000
Subject: [issue10920] cp65001, PowerShell, Python crash.
In-Reply-To: <1295207262.38.0.033573856036.issue10920@psf.upfronthosting.co.za>
Message-ID: <1295386847.66.0.652000565804.issue10920@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10920>
_______________________________________

From report at bugs.python.org  Tue Jan 18 22:43:43 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 18 Jan 2011 21:43:43 +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: <1295387023.91.0.0622339490736.issue9257@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/issue9257>
_______________________________________

From report at bugs.python.org  Tue Jan 18 22:43:59 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Tue, 18 Jan 2011 21:43:59 +0000
Subject: [issue10937] WinPE 64 bit execution results with errors
In-Reply-To: <1295378619.67.0.475043721406.issue10937@psf.upfronthosting.co.za>
Message-ID: <1295387039.8.0.473813324021.issue10937@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

You need to install the MS CRT (msvcrt90.dll, along with its assembly manifests and stuff) as well; it's not surprising that copying over an installation doesn't work.

I'll also point out that this is not a bug: copying over an installation is not supposed to work.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10937>
_______________________________________

From report at bugs.python.org  Tue Jan 18 22:46:21 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 18 Jan 2011 21:46:21 +0000
Subject: [issue10924] Adding salt and Modular Crypt Format to crypt library.
In-Reply-To: <1295386549.22.0.129711185931.issue10924@psf.upfronthosting.co.za>
Message-ID: <1295387176.3668.31.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Not sure if that was meant to be a suggestion for why my local
> patching wasn't working from the "svn diff" output, but obviously -5
> was messed up.  Here's a new version that I can apply to my fresh
> trunk and passes "make test".

Thank you! The important is that we now have a workable patch in unified
diff format :)

> If the suggestion was how to fix my patching from "svn diff", the
> problem I ran into was that it had the files in it, say crypt.py, but
> it was trying to apply them as if I had specified "patch -p1", even
> though the "svn diff" contained the paths and I hadn't done "-p1".

For the record, when using "svn diff", you have to use "patch -p0" to
apply the resulting patch. Not -p1.

> Anyway, this diff is "diff -urN".  I just can't win, I usually use
> "diff -u", but in the distant past Guido asked me for "diff -c"
> instead.  :-)

I would bet even Guido changed his habits :) Rietveld computes and
displays unified diffs as far as I remember.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10924>
_______________________________________

From report at bugs.python.org  Tue Jan 18 23:12:59 2011
From: report at bugs.python.org (Philip Winston)
Date: Tue, 18 Jan 2011 22:12:59 +0000
Subject: [issue5527] multiprocessing won't work with Tkinter (under Linux)
In-Reply-To: <1237574081.02.0.0677822756927.issue5527@psf.upfronthosting.co.za>
Message-ID: <1295388779.59.0.0315176800148.issue5527@psf.upfronthosting.co.za>


Philip Winston <pwinston at gmail.com> added the comment:

We ran into this. Forking before importing Tkinter worked for us.  We did the following which seems pretty clean:

main.py
import stdlib only
if __name__ == 'main':
   <fork via multiprocessing.Process>
   from application import App
   App()

application.py
import Tkinter 
class App...

----------
nosy: +pbwinston

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5527>
_______________________________________

From report at bugs.python.org  Tue Jan 18 23:31:41 2011
From: report at bugs.python.org (Joe Peterson)
Date: Tue, 18 Jan 2011 22:31:41 +0000
Subject: [issue10939] imaplib: Internaldate2tuple fails to parse month and
	does not work with negative TZ offset due to bytes/str issues
In-Reply-To: <1295389900.99.0.76199090445.issue10939@psf.upfronthosting.co.za>
Message-ID: <1295389900.99.0.76199090445.issue10939@psf.upfronthosting.co.za>


New submission from Joe Peterson <joe at skyrush.com>:

There are two issues with conversion to Python 3:

1. It raise "KeyError".  This is because the Mon2num dictionary keys are strings (str), not bytes objects (note that many other strings in imaplib have been updated, but not Mon2num).

2. The sign character of the TZ offset (e.g. -0700) is compared to the string (str) '-', not bytes array b'-', so the compare is never true, causing a large error when the TZ offset is negative.

Patch attached that also adds a unit test.

----------
components: Library (Lib)
files: imaplib_Internaldate2tuple_bytes_fixes_python32.patch
keywords: patch
messages: 126499
nosy: lavajoe
priority: normal
severity: normal
status: open
title: imaplib: Internaldate2tuple fails to parse month and does not work with negative TZ offset due to bytes/str issues
type: behavior
versions: Python 3.2
Added file: http://bugs.python.org/file20444/imaplib_Internaldate2tuple_bytes_fixes_python32.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10939>
_______________________________________

From report at bugs.python.org  Tue Jan 18 23:37:58 2011
From: report at bugs.python.org (Joe Peterson)
Date: Tue, 18 Jan 2011 22:37:58 +0000
Subject: [issue10939] imaplib: Internaldate2tuple raises KeyError parsing
	month and does not work with negative TZ offset due to
	bytes/str issues
In-Reply-To: <1295389900.99.0.76199090445.issue10939@psf.upfronthosting.co.za>
Message-ID: <1295390278.09.0.298176737286.issue10939@psf.upfronthosting.co.za>


Changes by Joe Peterson <joe at skyrush.com>:


----------
title: imaplib: Internaldate2tuple fails to parse month and does not work with negative TZ offset due to bytes/str issues -> imaplib: Internaldate2tuple raises KeyError parsing month and does not work with negative TZ offset due to bytes/str issues

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10939>
_______________________________________

From report at bugs.python.org  Wed Jan 19 00:02:03 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 18 Jan 2011 23:02:03 +0000
Subject: [issue10940] IDLE hangs with Cmd-M hotkey on Mac O/S
Message-ID: <1295391723.69.0.280577623459.issue10940@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <rhettinger at users.sourceforge.net>:


----------
assignee: ned.deily
components: IDLE
nosy: brett.cannon, ned.deily, rhettinger
priority: high
severity: normal
status: open
title: IDLE hangs with Cmd-M hotkey on Mac O/S
type: crash
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10940>
_______________________________________

From report at bugs.python.org  Wed Jan 19 00:04:04 2011
From: report at bugs.python.org (Ned Deily)
Date: Tue, 18 Jan 2011 23:04:04 +0000
Subject: [issue10940] IDLE hangs with Cmd-M hotkey on Mac O/S
In-Reply-To: <1295391844.43.0.912463306116.issue10940@psf.upfronthosting.co.za>
Message-ID: <1295391844.43.0.912463306116.issue10940@psf.upfronthosting.co.za>


New submission from Ned Deily <nad at acm.org>:

Is this on OS X 10.6 with ActiveState 8.5.9 installed?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10940>
_______________________________________

From report at bugs.python.org  Wed Jan 19 00:04:30 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 18 Jan 2011 23:04:30 +0000
Subject: [issue10940] IDLE hangs with Cmd-M hotkey on Mac O/S
In-Reply-To: <1295391844.43.0.912463306116.issue10940@psf.upfronthosting.co.za>
Message-ID: <1295391870.4.0.903257969965.issue10940@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

On the Mac O/S 64-bit install, Idle hangs when the Cmd-M hotkey is pressed, but selecting OpenModule directly from the File menu works fine.

For me, it hangs with the pinwheel of death and requires a force-quit.  For Brett, it changes colors as if an unhandled event if being fired-off.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10940>
_______________________________________

From report at bugs.python.org  Wed Jan 19 00:16:48 2011
From: report at bugs.python.org (Ned Deily)
Date: Tue, 18 Jan 2011 23:16:48 +0000
Subject: [issue10940] IDLE 3.2 hangs with Cmd-M hotkey on OS X 10.6 with
	64-bit installer and A/S Tk 8.5
In-Reply-To: <1295391844.43.0.912463306116.issue10940@psf.upfronthosting.co.za>
Message-ID: <1295392608.74.0.58485187148.issue10940@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


----------
title: IDLE hangs with Cmd-M hotkey on Mac O/S -> IDLE 3.2 hangs with Cmd-M hotkey on OS X 10.6 with 64-bit installer and A/S Tk 8.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10940>
_______________________________________

From report at bugs.python.org  Wed Jan 19 00:23:23 2011
From: report at bugs.python.org (Brian Thorne)
Date: Tue, 18 Jan 2011 23:23:23 +0000
Subject: [issue4106] multiprocessing occasionally spits out exception during
	shutdown
In-Reply-To: <1223695822.85.0.145044917765.issue4106@psf.upfronthosting.co.za>
Message-ID: <1295393003.13.0.986995634168.issue4106@psf.upfronthosting.co.za>


Brian Thorne <hardbyte at gmail.com> added the comment:

With the example script attached I see the exception every time. On Ubuntu 10.10 with Python 2.6

Since the offending line in multiprocesing/queues.py (233) is a debug statement, just commenting it out seems to stop this exception.

Looking at the util file shows the logging functions to be all of the form:

    if _logger:
        _logger.log(...

Could it be possible that after the check the _logger global (or the debug function) is destroyed by the exit handler? Can we convince them to stick around until such a time that they cannot be called?

Adding a small delay before joining also seems to work, but is ugly. Why should another Process *have* to have a minimum amount of work to not throw an exception?

----------
nosy: +Thorney
versions: +Python 2.6 -Python 2.7
Added file: http://bugs.python.org/file20445/test_mult.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4106>
_______________________________________

From report at bugs.python.org  Wed Jan 19 00:41:47 2011
From: report at bugs.python.org (Joe Peterson)
Date: Tue, 18 Jan 2011 23:41:47 +0000
Subject: [issue10941] imaplib: Internaldate2tuple produces wrong result if
	date is near a DST change
In-Reply-To: <1295394107.36.0.490316527511.issue10941@psf.upfronthosting.co.za>
Message-ID: <1295394107.36.0.490316527511.issue10941@psf.upfronthosting.co.za>


New submission from Joe Peterson <joe at skyrush.com>:

DST is not handled correctly.  Specifically, when the input date/time, ignoring the TZ offset (and treated as if it is local time) is on the other side of the DST changeover from the actual local time represented, the result will be off by one hour.  This can happen, e.g., when the input date/time is actually UTC (offset +0000).

This is because the check for DST is done after converting the time into a local time tuple, thereby treating as real local time.  This can be corrected by keeping the time in real UTC (by using calendar.timegm() instead of checking the DST flag) until the final conversion to local time.

Here is an example:  Run the following two dates, that represent exactly the same time, through Internaldate2tuple:

'25 (INTERNALDATE "01-Apr-2000 19:02:23 -0700")'
'101 (INTERNALDATE "02-Apr-2000 02:02:23 +0000")'

Note that a variant of this issue (but identifying it as a different problem) was addressed in a similar way in an old post I found by Colin Brown in 2004 (http://www.velocityreviews.com/forums/t336162-imaplib-function-bug.html).

Patch also adds unit test to check the above example dates.  Python 3 version of patch assumes patch from issue 10939 has been applied.

Patch also corrects code python doc that currently states time is UT, not local (see issue 10934).

----------
components: Library (Lib)
messages: 126503
nosy: lavajoe
priority: normal
severity: normal
status: open
title: imaplib: Internaldate2tuple produces wrong result if date is near a DST change
type: behavior
versions: Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10941>
_______________________________________

From report at bugs.python.org  Wed Jan 19 00:46:45 2011
From: report at bugs.python.org (Joe Peterson)
Date: Tue, 18 Jan 2011 23:46:45 +0000
Subject: [issue10941] imaplib: Internaldate2tuple produces wrong result if
	date is near a DST change
In-Reply-To: <1295394107.36.0.490316527511.issue10941@psf.upfronthosting.co.za>
Message-ID: <1295394405.54.0.0602777565192.issue10941@psf.upfronthosting.co.za>


Changes by Joe Peterson <joe at skyrush.com>:


----------
keywords: +patch
Added file: http://bugs.python.org/file20446/imaplib_Internaldate2tuple_dst_fix_python32.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10941>
_______________________________________

From report at bugs.python.org  Wed Jan 19 00:47:06 2011
From: report at bugs.python.org (Joe Peterson)
Date: Tue, 18 Jan 2011 23:47:06 +0000
Subject: [issue10941] imaplib: Internaldate2tuple produces wrong result if
	date is near a DST change
In-Reply-To: <1295394107.36.0.490316527511.issue10941@psf.upfronthosting.co.za>
Message-ID: <1295394426.9.0.76864973273.issue10941@psf.upfronthosting.co.za>


Changes by Joe Peterson <joe at skyrush.com>:


Added file: http://bugs.python.org/file20447/imaplib_Internaldate2tuple_dst_fix_python27.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10941>
_______________________________________

From report at bugs.python.org  Wed Jan 19 00:49:53 2011
From: report at bugs.python.org (Joe Peterson)
Date: Tue, 18 Jan 2011 23:49:53 +0000
Subject: [issue10921] imaplib: Internaldate2tuple() string/bytes issues,
	does not handle negative TZ offsets, does not handle DST correctly
In-Reply-To: <1295220756.66.0.509737296044.issue10921@psf.upfronthosting.co.za>
Message-ID: <1295394593.64.0.688586347.issue10921@psf.upfronthosting.co.za>


Joe Peterson <joe at skyrush.com> added the comment:

Two more issues split out into their own issues:

issue 10939 (bytes/str issues)
issue 10941 (DST handled incorrectly)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10921>
_______________________________________

From report at bugs.python.org  Wed Jan 19 01:06:58 2011
From: report at bugs.python.org (Kira Erethon)
Date: Wed, 19 Jan 2011 00:06:58 +0000
Subject: [issue10876] Zipfile sometimes considers a false password to be
	correct
In-Reply-To: <1294611467.71.0.814994722037.issue10876@psf.upfronthosting.co.za>
Message-ID: <1295395618.57.0.60606363417.issue10876@psf.upfronthosting.co.za>


Kira Erethon <shinjierethon at gmail.com> added the comment:

Sorry to re-open this, but I consider it an important bug. Tried it in 3.1 also and it's still there. To sum up what's happening, zipfile sometimes considers a false password to be correct and proceeds with decrypting the file. Is there a workaround in this? Or even checking if a file has been decrypted correctly?

----------
resolution: invalid -> 
status: closed -> open
title: Zipfile crashes when zip password is set to 610/844/numerous other numbers -> Zipfile sometimes considers a false password to be correct

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10876>
_______________________________________

From report at bugs.python.org  Wed Jan 19 01:07:10 2011
From: report at bugs.python.org (Kira Erethon)
Date: Wed, 19 Jan 2011 00:07:10 +0000
Subject: [issue10876] Zipfile sometimes considers a false password to be
	correct
In-Reply-To: <1294611467.71.0.814994722037.issue10876@psf.upfronthosting.co.za>
Message-ID: <1295395630.1.0.620321927874.issue10876@psf.upfronthosting.co.za>


Changes by Kira Erethon <shinjierethon at gmail.com>:


----------
components: +Library (Lib) -Extension Modules

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10876>
_______________________________________

From report at bugs.python.org  Wed Jan 19 01:12:30 2011
From: report at bugs.python.org (J_Tom_Moon_79)
Date: Wed, 19 Jan 2011 00:12:30 +0000
Subject: [issue10942] xml.etree.ElementTree.tostring returns type bytes,
	expected type str
In-Reply-To: <1295395949.96.0.0409847573272.issue10942@psf.upfronthosting.co.za>
Message-ID: <1295395949.96.0.0409847573272.issue10942@psf.upfronthosting.co.za>


New submission from J_Tom_Moon_79 <jtm.moon.forum.user+python at gmail.com>:

method xml.etree.ElementTree.tostring from module returns type bytes.
The documentation reads
"""Returns an encoded string containing the XML data."""
(from http://docs.python.org/py3k/library/xml.etree.elementtree.html#xml.etree.ElementTree.tostring as of 2011-01-18)

=======================================================
Here is a test program:
-------------------------------------------------------
#!/usr/bin/python
# created for python 3.1

import sys
print(sys.version) # for help verifying version tested
from xml.etree import ElementTree

sampleinput = """<?xml version="1.0"?><Hello></Hello>"""
xmlobj = ElementTree.fromstring(sampleinput)
type(xmlobj)
xmlstr = ElementTree.tostring(xmlobj,'utf-8')
print("xmlstr value is '", xmlstr, "'", sep="")
print("xmlstr type is '", type(xmlstr), "'", sep="")
-------------------------------------------------------
test program output:
-------------------------------------------------------
3.1.3 (r313:86834, Nov 27 2010, 18:30:53) [MSC v.1500 32 bit (Intel)]
xmlstr value is 'b'<Hello />''
xmlstr type is '<class 'bytes'>'
=======================================================

This cheap "fix" for this bug may be simply be a change in documentation.
However, a method called "tostring" really should return something nearer to the built-in str.

----------
assignee: docs at python
components: Documentation, XML
messages: 126506
nosy: JTMoon79, docs at python
priority: normal
severity: normal
status: open
title: xml.etree.ElementTree.tostring returns type bytes, expected type str
type: behavior
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10942>
_______________________________________

From report at bugs.python.org  Wed Jan 19 01:14:31 2011
From: report at bugs.python.org (J_Tom_Moon_79)
Date: Wed, 19 Jan 2011 00:14:31 +0000
Subject: [issue10942] xml.etree.ElementTree.tostring returns type bytes,
	expected type str
In-Reply-To: <1295395949.96.0.0409847573272.issue10942@psf.upfronthosting.co.za>
Message-ID: <1295396071.89.0.200442985784.issue10942@psf.upfronthosting.co.za>


J_Tom_Moon_79 <jtm.moon.forum.user+python at gmail.com> added the comment:

Some other bugs affecting the tostring method (for consideration by the reviewer):
http://bugs.python.org/issue6233#msg89718
http://bugs.python.org/msg101037
http://bugs.python.org/issue9692

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10942>
_______________________________________

From report at bugs.python.org  Wed Jan 19 01:17:57 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 19 Jan 2011 00:17:57 +0000
Subject: [issue10876] Zipfile sometimes considers a false password to be
	correct
In-Reply-To: <1294611467.71.0.814994722037.issue10876@psf.upfronthosting.co.za>
Message-ID: <1295396277.96.0.21848179848.issue10876@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

As I already explained:
* why it doesn't detect that the password is bad is because the ZIP format is not well-designed enough
* you can catch the zlib error which indicates that decryption returned junk

----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10876>
_______________________________________

From report at bugs.python.org  Wed Jan 19 01:28:39 2011
From: report at bugs.python.org (Sean Reifschneider)
Date: Wed, 19 Jan 2011 00:28:39 +0000
Subject: [issue10924] Adding salt and Modular Crypt Format to crypt library.
In-Reply-To: <1295247997.49.0.7150272714.issue10924@psf.upfronthosting.co.za>
Message-ID: <1295396919.28.0.3728851574.issue10924@psf.upfronthosting.co.za>


Sean Reifschneider <jafo at tummy.com> added the comment:

Thanks for the pointer about "patch -p0".  I *HAD* tried that, but it didn't seem to work either.  I'll double check that though...  "svn diff" is what I'd prefer, because then I can "svn commit" it when it's ready.

Any other review feedback?  I'll probably let this sit until 3.2 goes to maintenance and then check it into trunk, so there's some time yet...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10924>
_______________________________________

From report at bugs.python.org  Wed Jan 19 01:43:43 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 19 Jan 2011 00:43:43 +0000
Subject: [issue10924] Adding salt and Modular Crypt Format to crypt library.
In-Reply-To: <1295396919.28.0.3728851574.issue10924@psf.upfronthosting.co.za>
Message-ID: <1295397816.3668.42.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Thanks for the pointer about "patch -p0".  I *HAD* tried that, but it
> didn't seem to work either.  I'll double check that though...  "svn
> diff" is what I'd prefer, because then I can "svn commit" it when it's
> ready.

Ok, it seems the code inside crypt.py is duplicated in your patch.
Also, when you commit, it'll be better if you use "svn rename" for the C
file, so that history isn't broken.

> Any other review feedback?  I'll probably let this sit until 3.2 goes
> to maintenance and then check it into trunk, so there's some time
> yet...

Looks good mostly. Why do you need _MethodListClass()? Executing code at
module startup sounds fine to me. Or, at worse, use a global variable.

+   *salt* (either a random 2 or 16 character string, possibly prefixed with
+   ``$digit$`` to indicate the method) which will be used to perturb the
+   encryption algorithm.  The characters in *salt* must be in the set
+   ``[./a-zA-Z0-9]``, with the exception of Modular Crypt Format which
+   prefixes a ``$digit$``.

That paragraph is a bit confusing. Also, other uses of *salt* are
described separately two paragraphs above.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10924>
_______________________________________

From report at bugs.python.org  Wed Jan 19 01:47:51 2011
From: report at bugs.python.org (Kira Erethon)
Date: Wed, 19 Jan 2011 00:47:51 +0000
Subject: [issue10876] Zipfile sometimes considers a false password to be
	correct
In-Reply-To: <1294611467.71.0.814994722037.issue10876@psf.upfronthosting.co.za>
Message-ID: <1295398071.55.0.235230202986.issue10876@psf.upfronthosting.co.za>


Kira Erethon <shinjierethon at gmail.com> added the comment:

I'm catching all errors and exceptions and zipfile still decompresses it, that's what I've been trying to tell you. I don't face my original problem anymore, I'm catching that exception, now zipfile considers some passwords to be correct and throw no exception, it just decompresses the file (which contains junk since the password was wrong). That's for the second bullet of your message.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10876>
_______________________________________

From report at bugs.python.org  Wed Jan 19 01:53:20 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 19 Jan 2011 00:53:20 +0000
Subject: [issue10876] Zipfile sometimes considers a false password to be
	correct
In-Reply-To: <1295398071.55.0.235230202986.issue10876@psf.upfronthosting.co.za>
Message-ID: <1295398391.3668.46.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> I'm catching all errors and exceptions and zipfile still decompresses
> it, that's what I've been trying to tell you. I don't face my original
> problem anymore, I'm catching that exception, now zipfile considers
> some passwords to be correct and throw no exception, it just
> decompresses the file (which contains junk since the password was
> wrong). That's for the second bullet of your message.

Then I suppose the file(s) inside the zip archive are not compressed,
or the compressed contents are miraculously "good" enough for the zlib
not to complain. But, really, unless you have a precise solution to
propose, that's nothing Python can do anything about.

(of course, if you have an idea about the contents of that zip file, you
can devise an application-specific algorithm for validating the
contents)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10876>
_______________________________________

From report at bugs.python.org  Wed Jan 19 02:03:29 2011
From: report at bugs.python.org (Kira Erethon)
Date: Wed, 19 Jan 2011 01:03:29 +0000
Subject: [issue10876] Zipfile sometimes considers a false password to be
	correct
In-Reply-To: <1294611467.71.0.814994722037.issue10876@psf.upfronthosting.co.za>
Message-ID: <1295399009.49.0.236825140412.issue10876@psf.upfronthosting.co.za>


Kira Erethon <shinjierethon at gmail.com> added the comment:

I'm a newbie in python and tried this in order to learn.I created all the zip files (first created a .txt file and zipped it with a password), so I know the file inside the zip is encrypted ( ofc I know the password too). Tried this with different .txt files and file names just in case there was some problem with the naming (didn't use any unicode file names). I'm not really at a level I can propose a solution, only thing I know is that zipfile can "decompress" the same file with 4 or more passwords without throwing any exception. Of course only one of those passwords is correct.
So, bottom line is it's a problem of the zip format and not Python eh?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10876>
_______________________________________

From report at bugs.python.org  Wed Jan 19 02:22:13 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 19 Jan 2011 01:22:13 +0000
Subject: [issue3080] Full unicode import system
In-Reply-To: <1213208697.49.0.984990811807.issue3080@psf.upfronthosting.co.za>
Message-ID: <1295400133.63.0.413112936466.issue3080@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Here is a work-in-progress patch: issue3080-3.patch. The patch is HUGE and written for Python 3.3.

$ diffstat issue3080-3.patch 
 Doc/c-api/module.rst   |   24 
 Include/import.h       |   73 +
 Include/moduleobject.h |    2 
 Include/pycapsule.h    |    4 
 Modules/zipimport.c    |  272 +++---
 Objects/moduleobject.c |   52 -
 PC/import_nt.c         |   84 +-
 Python/dynload_aix.c   |    2 
 Python/dynload_dl.c    |    2 
 Python/dynload_hpux.c  |    2 
 Python/dynload_next.c  |    4 
 Python/dynload_os2.c   |    2 
 Python/dynload_shlib.c |    2 
 Python/dynload_win.c   |    2 
 Python/import.c        | 1910 +++++++++++++++++++++++++++----------------------
 Python/importdl.c      |   79 +-
 Python/importdl.h      |    2 
 issue3080.py           |   29 
 18 files changed, 1484 insertions(+), 1063 deletions(-)

As expected, most of the work in done in import.c.

Decode the module name earlier and encode it later. Try to manipulate PyUnicodeObject objects instead of char* buffers (so we have directly the string length).

Split the huge and very complex find_module() function into 3 functions (find_module, find_module_filename and find_module2) and document them. Drop OS/2 support in find_module() (it can be kept, but it was easier for me to drop it and the OS/2 maintainer wrote that Python 3 is far from being compatible with OS/2).

The patch creates some functions: PyModule_GetNameObject(), PyImport_ExecCodeModuleUnicode(), PyImport_AddModuleUnicode(), PyImport_ImportFrozenModuleUnicode(), PyModule_NewUnicode(), ...

Use "U" format to parse a module name, and "%R" to format a module name (to escape surrogates characters and add quotes, instead of "... '%.200s' ...").

PyWin_FindRegisteredModule() is now private. Remove fqname argument from _PyImport_GetDynLoadFunc(), it wasn't used.

Replace open_exclusive() by fopen(name, "wb") on Windows: is it correct?

TODO:

 - rename xxxobj => xxx to keep original names and have a short patch (eg. I renamed name to nameobj during the transition to detect bugs)
 - catch encoding errors in case_ok()
 - don't encode in case_ok() if case_ok() does nothing (eg. on Linux)
 - find a better name for find_module2()

The patch contains a tiny script, issue3080.py, to test the patch using an ISO-8859-1 locale.

I will open a thread on the mailing list (python-dev) to decide if this patch is needed or not. If we agree that this issue should be fixed, I will split the patch into smaller parts and start a review process.

----------
keywords: +patch
Added file: http://bugs.python.org/file20448/issue3080-3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3080>
_______________________________________

From report at bugs.python.org  Wed Jan 19 02:25:19 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 19 Jan 2011 01:25:19 +0000
Subject: [issue3080] Full unicode import system
In-Reply-To: <1213208697.49.0.984990811807.issue3080@psf.upfronthosting.co.za>
Message-ID: <1295400319.94.0.656975994283.issue3080@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

This patch changes more lines of code than my previous crazy unicode patch (msg103663, issue #8242 #8611 #9425), but it changes less files.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3080>
_______________________________________

From report at bugs.python.org  Wed Jan 19 02:27:49 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 19 Jan 2011 01:27:49 +0000
Subject: [issue3080] Full unicode import system
In-Reply-To: <1213208697.49.0.984990811807.issue3080@psf.upfronthosting.co.za>
Message-ID: <1295400469.09.0.533082445438.issue3080@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Oh, msg103663 was not the final patch. A more recent version of my patch for #8611 / #9425 is http://codereview.appspot.com/1874048:

 Doc/library/sys.rst         |    6 
 Include/Python.h            |    4 
 Include/fileobject.h        |   20 
 Include/import.h            |   21 
 Include/moduleobject.h      |    1 
 Include/sysmodule.h         |    5 
 Include/warnings.h          |    2 
 Lib/distutils/file_util.py  |    2 
 Lib/platform.py             |   50 +-
 Lib/test/test_import.py     |    7 
 Lib/test/test_sax.py        |    5 
 Lib/test/test_subprocess.py |   14 
 Lib/test/test_sys.py        |    5 
 Lib/test/test_urllib.py     |    8 
 Lib/test/test_urllib2.py    |    5 
 Lib/test/test_xml_etree.py  |    6 
 Modules/getpath.c           |  209 +++++----
 Modules/main.c              |   99 +++-
 Modules/zipimport.c         |  202 +++++----
 Objects/codeobject.c        |   17 
 Objects/fileobject.c        |   32 +
 Objects/moduleobject.c      |   25 -
 Objects/object.c            |    6 
 Objects/typeobject.c        |   12 
 Objects/unicodeobject.c     |   11 
 PC/import_nt.c              |   18 
 Parser/tokenizer.c          |   12 
 Python/_warnings.c          |   69 ++-
 Python/ast.c                |   16 
 Python/bltinmodule.c        |   24 -
 Python/ceval.c              |    7 
 Python/compile.c            |   14 
 Python/errors.c             |    2 
 Python/import.c             |  958 ++++++++++++++++++++++++++------------------
 Python/importdl.c           |   27 -
 Python/importdl.h           |    2 
 Python/pythonrun.c          |  169 +++++++
 Python/sysmodule.c          |   60 ++
 38 files changed, 1404 insertions(+), 748 deletions(-)

So, issue3080-3.patch and issue1874048_1.diff are close :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3080>
_______________________________________

From report at bugs.python.org  Wed Jan 19 03:10:58 2011
From: report at bugs.python.org (R. David Murray)
Date: Wed, 19 Jan 2011 02:10:58 +0000
Subject: [issue10942] xml.etree.ElementTree.tostring returns type bytes,
	expected type str
In-Reply-To: <1295395949.96.0.0409847573272.issue10942@psf.upfronthosting.co.za>
Message-ID: <1295403058.22.0.853259499446.issue10942@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

This is indeed a doc problem, although there was some discussion of working toward a method rename.  See issue 8047 (but be prepared to read a novel to understand why tostring returns bytes...)  The doc for 3.2 is slightly clearer, but both 3.1 and 3.2 could be made clearer by referring to an 'encoded byte string' rather than just an 'encoded string'.  (An encoded string has to be a byte string, but that isn't obvious unless you've dealt with encode/decode a bunch.)

Technically this could be closed as a duplicate of issue 8047, since that issue proposes that the API fix (which would include the doc change) be backported to 3.1.  But no one has proposed a patch there, so at a minimum the 3.1 docs should be clarified.

----------
nosy: +r.david.murray
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10942>
_______________________________________

From report at bugs.python.org  Wed Jan 19 06:08:27 2011
From: report at bugs.python.org (Sean Reifschneider)
Date: Wed, 19 Jan 2011 05:08:27 +0000
Subject: [issue10924] Adding salt and Modular Crypt Format to crypt library.
In-Reply-To: <1295247997.49.0.7150272714.issue10924@psf.upfronthosting.co.za>
Message-ID: <1295413707.51.0.382725773535.issue10924@psf.upfronthosting.co.za>


Sean Reifschneider <jafo at tummy.com> added the comment:

Affirmative on the "svn mv" for the C module.

The duplicated code, thanks for pointing that out.  Someone else mentioned it, but I didn't understand what they were saying and they didn't reply to my request for clarification.  Fixed.

On the modules() list, how about if I just make it a list and build it at import time?  The class was the way I thought most straightforward to do it as a function, so maybe this is more reasonable?

Per the documentation, I pulled down the description from above, which I think captured the uses of *salt* and removed the duplication.

----------
Added file: http://bugs.python.org/file20449/python-underscore_crypt-7.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10924>
_______________________________________

From report at bugs.python.org  Wed Jan 19 06:10:15 2011
From: report at bugs.python.org (Sean Reifschneider)
Date: Wed, 19 Jan 2011 05:10:15 +0000
Subject: [issue10924] Adding salt and Modular Crypt Format to crypt library.
In-Reply-To: <1295247997.49.0.7150272714.issue10924@psf.upfronthosting.co.za>
Message-ID: <1295413815.61.0.599619939995.issue10924@psf.upfronthosting.co.za>


Changes by Sean Reifschneider <jafo at tummy.com>:


Removed file: http://bugs.python.org/file20433/python-underscore_crypt-4.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10924>
_______________________________________

From report at bugs.python.org  Wed Jan 19 06:10:24 2011
From: report at bugs.python.org (Sean Reifschneider)
Date: Wed, 19 Jan 2011 05:10:24 +0000
Subject: [issue10924] Adding salt and Modular Crypt Format to crypt library.
In-Reply-To: <1295247997.49.0.7150272714.issue10924@psf.upfronthosting.co.za>
Message-ID: <1295413824.35.0.807451986818.issue10924@psf.upfronthosting.co.za>


Changes by Sean Reifschneider <jafo at tummy.com>:


Removed file: http://bugs.python.org/file20442/python-underscore_crypt-5.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10924>
_______________________________________

From report at bugs.python.org  Wed Jan 19 06:10:30 2011
From: report at bugs.python.org (Sean Reifschneider)
Date: Wed, 19 Jan 2011 05:10:30 +0000
Subject: [issue10924] Adding salt and Modular Crypt Format to crypt library.
In-Reply-To: <1295247997.49.0.7150272714.issue10924@psf.upfronthosting.co.za>
Message-ID: <1295413830.42.0.763915069465.issue10924@psf.upfronthosting.co.za>


Changes by Sean Reifschneider <jafo at tummy.com>:


Removed file: http://bugs.python.org/file20443/python-underscore_crypt-6.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10924>
_______________________________________

From report at bugs.python.org  Wed Jan 19 09:38:50 2011
From: report at bugs.python.org (Leo)
Date: Wed, 19 Jan 2011 08:38:50 +0000
Subject: [issue10943] abitype: Need better support to port C extension modules
	to the stable C API
In-Reply-To: <1295426330.25.0.635363870245.issue10943@psf.upfronthosting.co.za>
Message-ID: <1295426330.25.0.635363870245.issue10943@psf.upfronthosting.co.za>


New submission from Leo <fhaxbox66 at googlemail.com>:

I tried to port the extension module at http://code.google.com/p/pyhyphen/source/browse/3.x/hnjmodule.c to the stable C API using abitype.py. I gave up after the following exceptions:
- execption raised for missing PyVarObject_HEAD: this could be rixed by deleting a /* */ comment before. I think abitype.py should properly skip comments rather than forcing the user to delete them.
- the xxxmodule.c on which hnjmodule.c is based, defines a PyObject Str_type wherr tp_basicsize is 0 rather than sizeof(XXX). This causes abitype.py to raise a key error as '0' seems to be ignored by abitype.py.

Finally, I suggest to add to the source tree a boiler plate C module conforming to the stable API such as xxxmodule-stable-api.c. This would help creating extensions from scratch.

----------
components: Extension Modules
messages: 126519
nosy: fhaxbox66 at googlemail.com
priority: normal
severity: normal
status: open
title: abitype: Need better support to port C extension modules to the stable C API
type: feature request
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10943>
_______________________________________

From report at bugs.python.org  Wed Jan 19 10:15:53 2011
From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=)
Date: Wed, 19 Jan 2011 09:15:53 +0000
Subject: [issue10944] ctypes documentation does not mention c_bool in table of
	standard types
In-Reply-To: <1295428553.77.0.0934599344466.issue10944@psf.upfronthosting.co.za>
Message-ID: <1295428553.77.0.0934599344466.issue10944@psf.upfronthosting.co.za>


New submission from ???? ????????? <socketpair at gmail.com>:

http://docs.python.org/library/ctypes.html:

-----------
15.16.1.4. Fundamental data types
[table without c_bool]
------------
15.16.2.7. Fundamental data types
class ctypes.c_bool

New in version 2.6.
------------

----------
assignee: docs at python
components: Documentation
messages: 126520
nosy: docs at python, mmarkk
priority: normal
severity: normal
status: open
title: ctypes documentation does not mention c_bool in table of standard types
type: feature request

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10944>
_______________________________________

From report at bugs.python.org  Wed Jan 19 11:18:42 2011
From: report at bugs.python.org (Peter Heiberg)
Date: Wed, 19 Jan 2011 10:18:42 +0000
Subject: [issue10834] Python 2.7 x86 IDLE fails to run in Windows 7
In-Reply-To: <1294224063.9.0.656095341139.issue10834@psf.upfronthosting.co.za>
Message-ID: <1295432322.81.0.806852361626.issue10834@psf.upfronthosting.co.za>


Peter Heiberg <peter at sveumsondre.no> added the comment:

Run -> C:\Python27\python.exe -m test.regrtest
...
stops at "test_asynchat", been there for about 20mins.

Can't seem to break the operation tho (Ctrl+C), it still hangs at test_asynchat with the blinking underscore one line down.

----------
Added file: http://bugs.python.org/file20450/python test halt.jpg

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10834>
_______________________________________

From report at bugs.python.org  Wed Jan 19 12:00:31 2011
From: report at bugs.python.org (Denis S. Otkidach)
Date: Wed, 19 Jan 2011 11:00:31 +0000
Subject: [issue10935] wsgiref.handlers.BaseHandler and subclasses of str
In-Reply-To: <1295371764.49.0.785710350986.issue10935@psf.upfronthosting.co.za>
Message-ID: <1295434831.18.0.43142599722.issue10935@psf.upfronthosting.co.za>


Denis S. Otkidach <denis.otkidach at gmail.com> added the comment:

Current behavior is unpythonic: documentation explicitly mentions isinstance as preferred way to check type (see http://docs.python.org/library/types.html ).

Also 2.7 is the last minor version with str as "main" string type. So I believe it should use isinstance(val, basestring) to help transition to Python 3.

----------
nosy: +ods

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10935>
_______________________________________

From report at bugs.python.org  Wed Jan 19 12:38:40 2011
From: report at bugs.python.org (anatoly techtonik)
Date: Wed, 19 Jan 2011 11:38:40 +0000
Subject: [issue8954] wininst regression: errors when building on linux
In-Reply-To: <1276093244.44.0.895217979727.issue8954@psf.upfronthosting.co.za>
Message-ID: <1295437120.35.0.361284562582.issue8954@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

Is this issue really critical? 
Bump.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8954>
_______________________________________

From report at bugs.python.org  Wed Jan 19 12:39:42 2011
From: report at bugs.python.org (anatoly techtonik)
Date: Wed, 19 Jan 2011 11:39:42 +0000
Subject: [issue8954] wininst regression: errors when building on linux
In-Reply-To: <1276093244.44.0.895217979727.issue8954@psf.upfronthosting.co.za>
Message-ID: <1295437182.07.0.235809445931.issue8954@psf.upfronthosting.co.za>


Changes by anatoly techtonik <techtonik at gmail.com>:


Added file: http://bugs.python.org/file20451/issue1774043_7001.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8954>
_______________________________________

From report at bugs.python.org  Wed Jan 19 14:09:49 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 19 Jan 2011 13:09:49 +0000
Subject: [issue10828] Python 3 doesn't support non-ASCII module names with a
	locale encoding different than UTF-8
In-Reply-To: <1294170257.81.0.980912064683.issue10828@psf.upfronthosting.co.za>
Message-ID: <1295442589.99.0.796044100152.issue10828@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
title: Cannot use nonascii utf8 in names of files imported from -> Python 3 doesn't support non-ASCII module names with a locale encoding different than UTF-8

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10828>
_______________________________________

From report at bugs.python.org  Wed Jan 19 14:56:32 2011
From: report at bugs.python.org (Vladimir Rutsky)
Date: Wed, 19 Jan 2011 13:56:32 +0000
Subject: [issue10896] trace module compares directories as strings
	(--ignore-dir)
In-Reply-To: <1294843489.43.0.983792093108.issue10896@psf.upfronthosting.co.za>
Message-ID: <1295445392.48.0.892204236353.issue10896@psf.upfronthosting.co.za>


Vladimir Rutsky <rutsky.vladimir at gmail.com> added the comment:

SilentGhost, thanks for the patch! I can confirm, that adding os.path.normcase fixes issues with different cases of files.

I believe there also may be issue with FAT's long file name mangling, like "C:\PROGRA~1\python26\" instead of "C:\Program Files\python26\". But never experienced such issue with Python.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10896>
_______________________________________

From report at bugs.python.org  Wed Jan 19 15:22:10 2011
From: report at bugs.python.org (Jesse Noller)
Date: Wed, 19 Jan 2011 14:22:10 +0000
Subject: [issue4106] multiprocessing occasionally spits out exception during
	shutdown
In-Reply-To: <1295393003.13.0.986995634168.issue4106@psf.upfronthosting.co.za>
Message-ID: <AANLkTimVnm36dHo2PbmObT7S8+1Mye8_ErsmqvGCewew@mail.gmail.com>


Jesse Noller <jnoller at gmail.com> added the comment:

On Tue, Jan 18, 2011 at 6:23 PM, Brian Thorne <report at bugs.python.org> wrote:
>
> Brian Thorne <hardbyte at gmail.com> added the comment:
>
> With the example script attached I see the exception every time. On Ubuntu 10.10 with Python 2.6
>
> Since the offending line in multiprocesing/queues.py (233) is a debug statement, just commenting it out seems to stop this exception.
>
> Looking at the util file shows the logging functions to be all of the form:
>
> ? ?if _logger:
> ? ? ? ?_logger.log(...
>
> Could it be possible that after the check the _logger global (or the debug function) is destroyed by the exit handler? Can we convince them to stick around until such a time that they cannot be called?
>
> Adding a small delay before joining also seems to work, but is ugly. Why should another Process *have* to have a minimum amount of work to not throw an exception?

See http://bugs.python.org/issue9207 - but yes, the problem is that
the VM is nuking our imported modules before all the processes are
shutdown.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4106>
_______________________________________

From report at bugs.python.org  Wed Jan 19 16:10:13 2011
From: report at bugs.python.org (Vladimir Rutsky)
Date: Wed, 19 Jan 2011 15:10:13 +0000
Subject: [issue10896] trace module compares directories as strings
	(--ignore-dir)
In-Reply-To: <1294843489.43.0.983792093108.issue10896@psf.upfronthosting.co.za>
Message-ID: <1295449813.84.0.226949591751.issue10896@psf.upfronthosting.co.za>


Vladimir Rutsky <rutsky.vladimir at gmail.com> added the comment:

Sorry I was wrong - patch don't fix original issue.

Case should be normalized not only for directories provided through --ignore-dir, but also for directories obtained from __file__. In my tests on Windows Ignore.names(self, filename, modulename) receives `filename''s argument like:
  C:\Python26\Lib\site-packages\shapely\__init__.pyc

Attaching patch fixes this issue for me (for Python 2.7 from http://svn.python.org/projects/python/branches/release27-maint, patch attached by SilentGhost is for 3.X I think).

----------
nosy: +SilentGhost
Added file: http://bugs.python.org/file20452/trace_ignore_case_fix.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10896>
_______________________________________

From report at bugs.python.org  Wed Jan 19 16:28:00 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 19 Jan 2011 15:28:00 +0000
Subject: [issue10898] posixmodule.c redefines FSTAT
In-Reply-To: <1294857148.96.0.548396285489.issue10898@psf.upfronthosting.co.za>
Message-ID: <1295450880.3.0.796671584542.issue10898@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Ok, fixed in r88111 (3.2), r88112 (3.1) and r88113 (2.7).

----------
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10898>
_______________________________________

From report at bugs.python.org  Wed Jan 19 16:28:16 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 19 Jan 2011 15:28:16 +0000
Subject: [issue10945] bdist_wininst depends on MBCS codec,
	unavailable on non-Windows
In-Reply-To: <1295450896.02.0.86964827296.issue10945@psf.upfronthosting.co.za>
Message-ID: <1295450896.02.0.86964827296.issue10945@psf.upfronthosting.co.za>


New submission from ?ric Araujo <merwok at netwok.org>:

If distutils.commands.bdist_wininst.bdist_wininst.get_inidata returns a unicode string (which is always the case in 3.x and can happen in 2.x if if you pass a unicode object as one setup argument), bdist_wininst will try to use the MBCS codec, which is not available on non-Windows OSes (see http://docs.python.org/dev/library/codecs#module-encodings.mbcs).

If someone wants to make a patch, here are some guidelines: http://wiki.python.org/moin/Distutils/FixingBugs

----------
assignee: eric.araujo
components: Distutils, Distutils2
messages: 126528
nosy: eric.araujo, tarek
priority: normal
severity: normal
stage: needs patch
status: open
title: bdist_wininst depends on MBCS codec, unavailable on non-Windows
type: behavior
versions: 3rd party, Python 2.7, Python 3.1, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10945>
_______________________________________

From report at bugs.python.org  Wed Jan 19 16:29:25 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 19 Jan 2011 15:29:25 +0000
Subject: [issue8954] wininst regression: errors when building on linux
In-Reply-To: <1276093244.44.0.895217979727.issue8954@psf.upfronthosting.co.za>
Message-ID: <1295450965.65.0.057589293605.issue8954@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I opened another bug for the MBCS problem which prevents me from testing Anatoly?s patch.

----------
dependencies: +bdist_wininst depends on MBCS codec, unavailable on non-Windows

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8954>
_______________________________________

From report at bugs.python.org  Wed Jan 19 16:32:49 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 19 Jan 2011 15:32:49 +0000
Subject: =?utf-8?q?=5Bissue10946=5D_bdist_doesn=E2=80=99t_pass_--skip-build_on_to_?=
	=?utf-8?q?subcommands?=
In-Reply-To: <1295451169.68.0.9980803941.issue10946@psf.upfronthosting.co.za>
Message-ID: <1295451169.68.0.9980803941.issue10946@psf.upfronthosting.co.za>


New submission from ?ric Araujo <merwok at netwok.org>:

Yannick has found that bdist_* commands don?t get the --skip-build option from bdist.  This should be solved easily thanks to set_undefined_options.

Adding people from #414775 (r25075) to nosy.

----------
assignee: eric.araujo
components: Distutils, Distutils2
keywords: easy
messages: 126530
nosy: eric.araujo, kern, loewis, ygingras
priority: normal
severity: normal
stage: needs patch
status: open
title: bdist doesn?t pass --skip-build on to subcommands
type: behavior
versions: 3rd party, Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10946>
_______________________________________

From report at bugs.python.org  Wed Jan 19 16:33:13 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 19 Jan 2011 15:33:13 +0000
Subject: =?utf-8?q?=5Bissue10946=5D_bdist_doesn=E2=80=99t_pass_--skip-build_on_to_?=
	=?utf-8?q?subcommands?=
In-Reply-To: <1295451169.68.0.9980803941.issue10946@psf.upfronthosting.co.za>
Message-ID: <1295451193.41.0.424845275832.issue10946@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +tarek

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10946>
_______________________________________

From report at bugs.python.org  Wed Jan 19 16:34:36 2011
From: report at bugs.python.org (anatoly techtonik)
Date: Wed, 19 Jan 2011 15:34:36 +0000
Subject: [issue10945] bdist_wininst depends on MBCS codec,
	unavailable on non-Windows
In-Reply-To: <1295450896.02.0.86964827296.issue10945@psf.upfronthosting.co.za>
Message-ID: <1295451276.7.0.0869372727024.issue10945@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

I believe it is better to start and commit a testcase .

----------
nosy: +techtonik

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10945>
_______________________________________

From report at bugs.python.org  Wed Jan 19 16:35:32 2011
From: report at bugs.python.org (Joe Peterson)
Date: Wed, 19 Jan 2011 15:35:32 +0000
Subject: [issue10947] imaplib: Internaldate2tuple and ParseFlags require (and
	latter returns) bytes arrays; should allow/return str
In-Reply-To: <1295451332.43.0.977417439806.issue10947@psf.upfronthosting.co.za>
Message-ID: <1295451332.43.0.977417439806.issue10947@psf.upfronthosting.co.za>


New submission from Joe Peterson <joe at skyrush.com>:

In imaplib, there is currently a mix of bytes array and str use.  Time2Internaldate(), e.g., returns (and accepts) str.  Internaldate2tuple() and ParseFlags() only accept a bytes object, and the latter returns a tuple of bytes objects.  Of course, these were all strings in Python 2.

To regain compatibility with Python 2 behavior and make things more consistent, this patch changes the return type of ParseFlags() to a str tuple, and allow it and Internaldate2tuple() to accept either a bytes object or a str.

The unit test has been expanded to test these.  Note that applying this patch assumes that the the patches from issue 10939 and issue 10941 have been applied.

Also, I am not sure it is proper to accept *both* bytes array and str.  Perhaps only str should be allowed.  Comments?

----------
components: Library (Lib)
files: imaplib_string_compat.patch
keywords: patch
messages: 126532
nosy: lavajoe
priority: normal
severity: normal
status: open
title: imaplib: Internaldate2tuple and ParseFlags require (and latter returns) bytes arrays; should allow/return str
type: behavior
versions: Python 3.2
Added file: http://bugs.python.org/file20453/imaplib_string_compat.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10947>
_______________________________________

From report at bugs.python.org  Wed Jan 19 16:38:46 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 19 Jan 2011 15:38:46 +0000
Subject: [issue10945] bdist_wininst depends on MBCS codec,
	unavailable on non-Windows
In-Reply-To: <1295450896.02.0.86964827296.issue10945@psf.upfronthosting.co.za>
Message-ID: <1295451526.22.0.91924387635.issue10945@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

We don?t commit failing tests :)  If you mean you want to write a test case, please go ahead and attach a patch or changeset URI.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10945>
_______________________________________

From report at bugs.python.org  Wed Jan 19 16:40:16 2011
From: report at bugs.python.org (Joe Peterson)
Date: Wed, 19 Jan 2011 15:40:16 +0000
Subject: [issue10921] imaplib: Internaldate2tuple() string/bytes issues,
	does not handle negative TZ offsets, does not handle DST correctly
In-Reply-To: <1295220756.66.0.509737296044.issue10921@psf.upfronthosting.co.za>
Message-ID: <1295451616.55.0.892544002637.issue10921@psf.upfronthosting.co.za>


Joe Peterson <joe at skyrush.com> added the comment:

This issue has been split, as suggested by Alexander Belopolsky, into separate issues:

issue 10934 - doc change to correctly reflect return of local time vs. UTC
issue 10939 - bytes/str issues
issue 10941 - DST handled incorrectly
issue 10947 - compatibility using str/bytes

Closing this issue (see separate ones above).

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10921>
_______________________________________

From report at bugs.python.org  Wed Jan 19 16:40:47 2011
From: report at bugs.python.org (SilentGhost)
Date: Wed, 19 Jan 2011 15:40:47 +0000
Subject: [issue10896] trace module compares directories as strings
	(--ignore-dir)
In-Reply-To: <1294843489.43.0.983792093108.issue10896@psf.upfronthosting.co.za>
Message-ID: <1295451647.76.0.217113642355.issue10896@psf.upfronthosting.co.za>


SilentGhost <ghost.adh at gmail.com> added the comment:

Vladimir, superseder's patch fixes that too.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10896>
_______________________________________

From report at bugs.python.org  Wed Jan 19 16:44:36 2011
From: report at bugs.python.org (SilentGhost)
Date: Wed, 19 Jan 2011 15:44:36 +0000
Subject: [issue9509] argparse FileType raises ugly exception for missing file
In-Reply-To: <1280927287.23.0.0771144110186.issue9509@psf.upfronthosting.co.za>
Message-ID: <1295451876.41.0.849116815965.issue9509@psf.upfronthosting.co.za>


Changes by SilentGhost <ghost.adh at gmail.com>:


----------
status: open -> languishing

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9509>
_______________________________________

From report at bugs.python.org  Wed Jan 19 17:24:34 2011
From: report at bugs.python.org (anatoly techtonik)
Date: Wed, 19 Jan 2011 16:24:34 +0000
Subject: [issue10945] bdist_wininst depends on MBCS codec,
	unavailable on non-Windows
In-Reply-To: <1295450896.02.0.86964827296.issue10945@psf.upfronthosting.co.za>
Message-ID: <1295454274.5.0.345001878.issue10945@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

Please don't ask me about patches. Core devs won't accept them.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10945>
_______________________________________

From report at bugs.python.org  Wed Jan 19 17:43:31 2011
From: report at bugs.python.org (Phillip J. Eby)
Date: Wed, 19 Jan 2011 16:43:31 +0000
Subject: [issue10935] wsgiref.handlers.BaseHandler and subclasses of str
In-Reply-To: <1295371764.49.0.785710350986.issue10935@psf.upfronthosting.co.za>
Message-ID: <1295455411.46.0.80571657173.issue10935@psf.upfronthosting.co.za>


Phillip J. Eby <pje at telecommunity.com> added the comment:

Doesn't matter how unpythonic it is: the spec calls for exact types and has done so for six years already, so it's a bit late to do anything about it.  (And any version of Python that allowed string subclasses was in violation of the spec and therefore buggy.)

In principle, this class could allow non-str objects if and ONLY if they were converted to actual str objects upon receipt -- but they would have to be the *exact* type after this conversion.

If somebody wants to implement that, I have no objection.  But it MUST reject non-basestring input values and values that don't convert to an exact type str.  (IOW, "type(str(x)) is str" must hold.)

To put it another way, the WSGI protocol requires output headers to be of type 'list' where all elements are type 'tuple' and containing two 'str' entries.  The Headers class cannot fulfill this contract if it allows non-conforming input.  So non-conforming input must either be rejected or made to conform.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10935>
_______________________________________

From report at bugs.python.org  Wed Jan 19 17:52:53 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 19 Jan 2011 16:52:53 +0000
Subject: [issue10935] wsgiref.handlers.BaseHandler and subclasses of str
In-Reply-To: <1295371764.49.0.785710350986.issue10935@psf.upfronthosting.co.za>
Message-ID: <1295455973.84.0.301286307596.issue10935@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> OK.  So he is saying that when the spec says "an object of type str" he 
> means 'type(x) is str' as opposed to 'isinstance(x, str)'.  I would
> naively have expected the latter, as other people clearly do as well.

+1 with RDM here.

> Doesn't matter how unpythonic it is: the spec calls for exact types

Can you clarify why it does?

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10935>
_______________________________________

From report at bugs.python.org  Wed Jan 19 18:07:12 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 19 Jan 2011 17:07:12 +0000
Subject: [issue10945] bdist_wininst depends on MBCS codec,
	unavailable on non-Windows
In-Reply-To: <1295454274.5.0.345001878.issue10945@psf.upfronthosting.co.za>
Message-ID: <4D371A3A.20704@netwok.org>


?ric Araujo <merwok at netwok.org> added the comment:

> Please don't ask me about patches. Core devs won't accept them.

One of your patches for diff has been accepted; some distutils bugs have
patches from you (for which we are grateful) that are in various review
stages.  The only thing preventing acceptance where I?m concerned is
time, nothing else.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10945>
_______________________________________

From report at bugs.python.org  Wed Jan 19 18:07:18 2011
From: report at bugs.python.org (Diego Queiroz)
Date: Wed, 19 Jan 2011 17:07:18 +0000
Subject: [issue10948] Trouble with dir_util created dir cache
In-Reply-To: <1295456838.39.0.734609669589.issue10948@psf.upfronthosting.co.za>
Message-ID: <1295456838.39.0.734609669589.issue10948@psf.upfronthosting.co.za>


New submission from Diego Queiroz <queiroz.diego at gmail.com>:

There is a problem with dir_util cache (defined by "_path_created" global variable).

It appears to be useful but it isn't, just repeat these steps to understand the problem I'm facing:

1) Use mkpath to create any path (eg. /home/user/a/b/c)
2) Open the terminal and manually delete the directory "/home/user/a" and its contents
3) Try to create "/home/user/a/b/c" again using mkpath

Expected behavior:
mkpath should create the folder tree again.

What happens:
Nothing, mkpath "thinks" the folder already exists because its creation was cached. Moreover, if you try to create one more folder level (eg. /home/user/a/b/c/d) it raises an exception because it thinks that part of the tree was already created and fails to create the last folder.


I'm working with parallel applications that deal with files asynchronously, this problem gave me a headache.

Anyway, the solution is easy: remove the cache.

----------
assignee: tarek
components: Distutils
messages: 126540
nosy: diegoqueiroz, eric.araujo, tarek
priority: normal
severity: normal
status: open
title: Trouble with dir_util created dir cache
type: behavior
versions: Python 2.5, Python 2.6, Python 2.7, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10948>
_______________________________________

From report at bugs.python.org  Wed Jan 19 18:11:12 2011
From: report at bugs.python.org (Christophe Kalt)
Date: Wed, 19 Jan 2011 17:11:12 +0000
Subject: [issue10949] logging.RotatingFileHandler not robust enough
In-Reply-To: <1295457072.71.0.821420961283.issue10949@psf.upfronthosting.co.za>
Message-ID: <1295457072.71.0.821420961283.issue10949@psf.upfronthosting.co.za>


New submission from Christophe Kalt <kalt at taranis.org>:

logging.RotatingFileHandler.doRollover() can fail leaving the handler with a closed filehandle, causing all subsequent logging attempts to fail:

>>> import logging
>>> import logging.handlers
>>> logging.getLogger().addHandler(logging.handlers.RotatingFileHandler('testlog', None, 10, 5))
>>> logging.getLogger().setLevel(logging.INFO)
>>> logging.info('qwertyuiop')
>>> os.system('ls -l testlog*')
-rw-r--r-- 1 - - 11 Jan 19 10:02 testlog
-rw-r--r-- 1 - -  0 Jan 19 10:02 testlog.1
0
>>> os.remove('testlog')
>>> logging.info('qwertyuiop')
Traceback (most recent call last):
  File "/home8/taraniso/opt/lib/python2.6/logging/handlers.py", line 72, in emit
    self.doRollover()
  File "/home8/taraniso/opt/lib/python2.6/logging/handlers.py", line 129, in doRollover
    os.rename(self.baseFilename, dfn)
OSError: [Errno 2] No such file or directory
>>> logging.info('qwertyuiop')
Traceback (most recent call last):
  File "/home8/taraniso/opt/lib/python2.6/logging/handlers.py", line 71, in emit
    if self.shouldRollover(record):
  File "/home8/taraniso/opt/lib/python2.6/logging/handlers.py", line 145, in shouldRollover
    self.stream.seek(0, 2)  #due to non-posix-compliant Windows feature
ValueError: I/O operation on closed file
>>> logging.info('qwertyuiop')
Traceback (most recent call last):
  File "/home8/taraniso/opt/lib/python2.6/logging/handlers.py", line 71, in emit
    if self.shouldRollover(record):
  File "/home8/taraniso/opt/lib/python2.6/logging/handlers.py", line 145, in shouldRollover
    self.stream.seek(0, 2)  #due to non-posix-compliant Windows feature
ValueError: I/O operation on closed file

Fix seems trivial enough, attaching.  This is against 2.6.5, browsing subversion online seems to indicate it is needed on the trunk as well, although it won't apply cleanly.

----------
components: Library (Lib)
files: logging.diff
keywords: patch
messages: 126541
nosy: kalt
priority: normal
severity: normal
status: open
title: logging.RotatingFileHandler not robust enough
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1
Added file: http://bugs.python.org/file20454/logging.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10949>
_______________________________________

From report at bugs.python.org  Wed Jan 19 18:12:26 2011
From: report at bugs.python.org (Andrey Popp)
Date: Wed, 19 Jan 2011 17:12:26 +0000
Subject: [issue10935] wsgiref.handlers.BaseHandler and subclasses of str
In-Reply-To: <1295371764.49.0.785710350986.issue10935@psf.upfronthosting.co.za>
Message-ID: <1295457146.91.0.0555593395647.issue10935@psf.upfronthosting.co.za>


Andrey Popp <8mayday at gmail.com> added the comment:

> the spec says "an object of type str" he means 'type(x) is str' as opposed to 'isinstance(x, str)'

-1 Liskov substitution principle states, that every subtype S of type T can be used whenever type T is used.

----------
nosy: +andreypopp

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10935>
_______________________________________

From report at bugs.python.org  Wed Jan 19 18:17:58 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 19 Jan 2011 17:17:58 +0000
Subject: [issue9509] argparse FileType raises ugly exception for missing file
In-Reply-To: <1280927287.23.0.0771144110186.issue9509@psf.upfronthosting.co.za>
Message-ID: <1295457478.54.0.534305126532.issue9509@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

SilentGhost, can you remove old files from the report (or tell which ones I should remove if you can?t do it) and make one patch with code and test changes that apply cleanly to current py3k?  That would make a final review by Steven easier.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9509>
_______________________________________

From report at bugs.python.org  Wed Jan 19 18:24:39 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 19 Jan 2011 17:24:39 +0000
Subject: [issue10887] Add link to development ML
In-Reply-To: <1294745681.16.0.799239354624.issue10887@psf.upfronthosting.co.za>
Message-ID: <1295457879.24.0.524816063127.issue10887@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Done.

----------
assignee: tarek -> eric.araujo
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10887>
_______________________________________

From report at bugs.python.org  Wed Jan 19 18:42:48 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 19 Jan 2011 17:42:48 +0000
Subject: [issue10932] distutils.core.setup - data_files misbehaviour ?
In-Reply-To: <1295353825.23.0.755300594789.issue10932@psf.upfronthosting.co.za>
Message-ID: <1295458968.53.0.953684063866.issue10932@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Thanks for the report.

?No directory information from files is used to determine the final location of the installed file; only the name of the file is used?

I understand this line to mean that only the basename of the file will be used in the target directory, IOW that ('config', ['cfg/data.cfg']) will create a file in config/data.cfg, not config/cfg/data.cfg.  I?m not 100% sure about my reading though, this line is confusing.

Paths starting with '..' are relative, even if they?re not under the top-level directory of the project (do the docs say they should be?), so the ability to give '../../spam/whatever' as data file looks okay.  However, it should not be installed to target_dir/../../spam, that?s definitely a bug (coming from os.path.join in cmd.Command.copy_file, I think).

If you want to write a test and fix, there are some guidelines at http://wiki.python.org/moin/Distutils/FixingBugs

----------
assignee: tarek -> eric.araujo
components: +Distutils2
keywords: +easy
nosy: +fdrake
title: distutils.core.setup - data_files missbehaviour ? -> distutils.core.setup - data_files misbehaviour ?
versions: +3rd party, Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10932>
_______________________________________

From report at bugs.python.org  Wed Jan 19 18:48:58 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 19 Jan 2011 17:48:58 +0000
Subject: [issue10923] Python 2.7 hangs on Unicode+threading
In-Reply-To: <1295230653.16.0.00822246437847.issue10923@psf.upfronthosting.co.za>
Message-ID: <1295459338.1.0.968910846848.issue10923@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

> "import child_directory"
Then it's certainly an effect of the "import lock":
http://docs.python.org/library/threading.html#importing-in-threaded-code

In your case, the first call to encode('utf8') indirectly imports utf8.py, while the import lock is held by 'import child_directory'.
Then the self.loglock is the second resource that closes the deadlock loop.

A workaround is to add some call to encode('utf8') before the thread is created.

----------
nosy: +amaury.forgeotdarc
resolution:  -> works for me

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10923>
_______________________________________

From report at bugs.python.org  Wed Jan 19 18:49:33 2011
From: report at bugs.python.org (Fred L. Drake, Jr.)
Date: Wed, 19 Jan 2011 17:49:33 +0000
Subject: [issue10932] distutils.core.setup - data_files misbehaviour ?
In-Reply-To: <1295458968.53.0.953684063866.issue10932@psf.upfronthosting.co.za>
Message-ID: <AANLkTim30uEdZ=bGfByn43i7amS6QcUuNXdxu2G1Bn=s@mail.gmail.com>


Fred L. Drake, Jr. <fdrake at acm.org> added the comment:

On Wed, Jan 19, 2011 at 12:42 PM, ?ric Araujo <report at bugs.python.org> wrote:
> I understand this line to mean that only the basename of the file will be used
> in the target directory, IOW that ('config', ['cfg/data.cfg']) will create a
> file in config/data.cfg, not config/cfg/data.cfg.
> ?I?m not 100% sure about my reading though, this line is confusing.

This is my reading as well.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10932>
_______________________________________

From report at bugs.python.org  Wed Jan 19 18:50:35 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 19 Jan 2011 17:50:35 +0000
Subject: [issue10948] Trouble with dir_util created dir cache
In-Reply-To: <1295456838.39.0.734609669589.issue10948@psf.upfronthosting.co.za>
Message-ID: <1295459435.59.0.688629078351.issue10948@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Thanks for the report and diagnosis.  Why does your application randomly removes files created by distutils?

----------
assignee: tarek -> eric.araujo
versions: +Python 3.2 -Python 2.5, Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10948>
_______________________________________

From report at bugs.python.org  Wed Jan 19 18:53:12 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 19 Jan 2011 17:53:12 +0000
Subject: [issue10921] imaplib: Internaldate2tuple() string/bytes issues,
	does not handle negative TZ offsets, does not handle DST correctly
In-Reply-To: <1295220756.66.0.509737296044.issue10921@psf.upfronthosting.co.za>
Message-ID: <1295459592.13.0.810821945847.issue10921@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


----------
resolution:  -> duplicate
stage: unit test needed -> committed/rejected
superseder:  -> imaplib: Internaldate2tuple() is documented to return UTC, but it returns local time

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10921>
_______________________________________

From report at bugs.python.org  Wed Jan 19 18:58:59 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 19 Jan 2011 17:58:59 +0000
Subject: [issue1371826] distutils is silent about multiple -I/-L/-R
Message-ID: <1295459939.09.0.032754879605.issue1371826@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
assignee: tarek -> eric.araujo
keywords: +easy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1371826>
_______________________________________

From report at bugs.python.org  Wed Jan 19 19:03:29 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 19 Jan 2011 18:03:29 +0000
Subject: [issue10932] distutils.core.setup - data_files misbehaviour ?
In-Reply-To: <1295353825.23.0.755300594789.issue10932@psf.upfronthosting.co.za>
Message-ID: <1295460209.52.0.0569237075656.issue10932@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

See also #9261.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10932>
_______________________________________

From report at bugs.python.org  Wed Jan 19 19:07:15 2011
From: report at bugs.python.org (Diego Queiroz)
Date: Wed, 19 Jan 2011 18:07:15 +0000
Subject: [issue10948] Trouble with dir_util created dir cache
In-Reply-To: <1295456838.39.0.734609669589.issue10948@psf.upfronthosting.co.za>
Message-ID: <1295460435.54.0.563106506322.issue10948@psf.upfronthosting.co.za>


Diego Queiroz <queiroz.diego at gmail.com> added the comment:

Well. My application does not actually randomly remove the folders, it just can't guarantee for a given process how the folder it created will be deleted.

I have many tasks running on a cluster using the same disk. Some tasks creates the folders/files and some of them remove them after processing. What each task will do depends of the availability of computational resources.

The application is also aware of possible user interaction, that is, I need to be able to manipulate folders manually (adding or removing) without crashing the application or corrupting data.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10948>
_______________________________________

From report at bugs.python.org  Wed Jan 19 19:12:14 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 19 Jan 2011 18:12:14 +0000
Subject: [issue10948] Trouble with dir_util created dir cache
In-Reply-To: <1295456838.39.0.734609669589.issue10948@psf.upfronthosting.co.za>
Message-ID: <1295460734.2.0.662738136056.issue10948@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Maybe I?m tired, but I don?t understand why your application would remove directories that distutils creates.  We?ve fixed a bug related to a race condition when *creating* directories (#9281), but behaving sanely on an unstable tree seems something different to me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10948>
_______________________________________

From report at bugs.python.org  Wed Jan 19 19:19:05 2011
From: report at bugs.python.org (Beau)
Date: Wed, 19 Jan 2011 18:19:05 +0000
Subject: [issue10950] ServerProxy returns bad XML
In-Reply-To: <1295461145.33.0.479841381445.issue10950@psf.upfronthosting.co.za>
Message-ID: <1295461145.33.0.479841381445.issue10950@psf.upfronthosting.co.za>


New submission from Beau <beaumartinez at gmail.com>:

xmlrpc.client.ServerProxy calls that return XML (ie, the a non-marshallable type) give bad XML, with \" (backslash then double quote characters, '\\"'; not escaped double quote) in place of ", and \' in place of '. Ampersands aren't XML-escaped either.

(I have only tested this with Last.fm's API but I have made calls that return marshallable types with no problem, so I'm assuming the issue lies with ServerProxy and not Last.fm's XML-RPC servers.)

The following test code, identical to that in the attached file illustrates the bug; it throws an xml.parsers.expat.ExpatError as the XML is bad:

# Get a Last.fm user's library.
# http://www.last.fm/api/show?service=323

import xmlrpc.client
import xml.etree

server = xmlrpc.client.ServerProxy('http://ws.audioscrobbler.com/2.0/')
parameters = {'api_key': 'b25b959554ed76058ac220b7b2e0a026', 'user': 'joanofarctan', 'page': 1}

tracks = server.library.getTracks(parameters)
tracks_xml = xml.etree.ElementTree.parse(tracks)

# Should get "xml.parsers.expat.ExpatError: XML declaration not well-formed: line 1, column 14".
# (Line 1, column 14 is a backslash: <?xml version=\"1.0\" encoding=\"utf-8\"?>.)

I'm running "Python 3.1.2 (r312:79149, Mar 20 2010, 22:55:39) [MSC v.1500 64 bit (AMD64)] on win32".

----------
components: Library (Lib)
files: serverproxy_test.py
messages: 126552
nosy: beaumartinez
priority: normal
severity: normal
status: open
title: ServerProxy returns bad XML
type: compile error
versions: Python 3.1
Added file: http://bugs.python.org/file20455/serverproxy_test.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10950>
_______________________________________

From report at bugs.python.org  Wed Jan 19 19:28:36 2011
From: report at bugs.python.org (SilentGhost)
Date: Wed, 19 Jan 2011 18:28:36 +0000
Subject: [issue9509] argparse FileType raises ugly exception for missing file
In-Reply-To: <1280927287.23.0.0771144110186.issue9509@psf.upfronthosting.co.za>
Message-ID: <1295461716.58.0.371186067582.issue9509@psf.upfronthosting.co.za>


SilentGhost <ghost.adh at gmail.com> added the comment:

Here is the single patch. All tests pass.

----------
Added file: http://bugs.python.org/file20456/argparse.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9509>
_______________________________________

From report at bugs.python.org  Wed Jan 19 19:28:41 2011
From: report at bugs.python.org (SilentGhost)
Date: Wed, 19 Jan 2011 18:28:41 +0000
Subject: [issue9509] argparse FileType raises ugly exception for missing file
In-Reply-To: <1280927287.23.0.0771144110186.issue9509@psf.upfronthosting.co.za>
Message-ID: <1295461721.54.0.0930729197016.issue9509@psf.upfronthosting.co.za>


Changes by SilentGhost <ghost.adh at gmail.com>:


Removed file: http://bugs.python.org/file19827/test_argparse.py.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9509>
_______________________________________

From report at bugs.python.org  Wed Jan 19 19:28:49 2011
From: report at bugs.python.org (SilentGhost)
Date: Wed, 19 Jan 2011 18:28:49 +0000
Subject: [issue9509] argparse FileType raises ugly exception for missing file
In-Reply-To: <1280927287.23.0.0771144110186.issue9509@psf.upfronthosting.co.za>
Message-ID: <1295461729.29.0.32474905976.issue9509@psf.upfronthosting.co.za>


Changes by SilentGhost <ghost.adh at gmail.com>:


Removed file: http://bugs.python.org/file19805/argparse.py.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9509>
_______________________________________

From report at bugs.python.org  Wed Jan 19 19:31:46 2011
From: report at bugs.python.org (Diego Queiroz)
Date: Wed, 19 Jan 2011 18:31:46 +0000
Subject: [issue10948] Trouble with dir_util created dir cache
In-Reply-To: <1295456838.39.0.734609669589.issue10948@psf.upfronthosting.co.za>
Message-ID: <1295461906.0.0.159076424603.issue10948@psf.upfronthosting.co.za>


Diego Queiroz <queiroz.diego at gmail.com> added the comment:

Suppose the application creates one folder and add some data to it:

- /scratch/a/b/c

While the application is still running (it is not using the folder anymore), you see the data, copy it to somewhere and delete everything manually using the terminal.

After some time, (maybe a week or a month later, it doesn't really matter) the application wants to write again on that folder, but ops, the folder was removed. As application is very well coded :-), it checks for that folder and note that it doesn't exist anymore and needs to be recreated.

But, when the application try to do so, nothing happens, because the cache is not updated. ;/

Maybe distutils package was not designed for the purpose I am using it (I am not using it to install python modules or anything), but this behavior is not well documented anyway.

If you really think the cache is important, two things need to be done:
1) Implement a way to update/clear the cache
2) Include details about the cache and its implications on distutils documentation

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10948>
_______________________________________

From report at bugs.python.org  Wed Jan 19 19:33:51 2011
From: report at bugs.python.org (Phillip J. Eby)
Date: Wed, 19 Jan 2011 18:33:51 +0000
Subject: [issue10935] wsgiref.handlers.BaseHandler and subclasses of str
In-Reply-To: <1295371764.49.0.785710350986.issue10935@psf.upfronthosting.co.za>
Message-ID: <1295462031.44.0.92216053773.issue10935@psf.upfronthosting.co.za>


Phillip J. Eby <pje at telecommunity.com> added the comment:

One of the original reasons was to make it easier for server authors writing C code to interface with WSGI.  C APIs that operate on lists and dicts often do not do what you would expect, when called on a subclass.  Essentially, this could lead to an app that appears 
to work correctly on one server, but breaks strangely when run on another.

(IOW, Python's C API and built-in types often break the Liskov principle: there are C-level operations that don't call back into Python subclass methods, so overriding just a few methods usually doesn't work as expected.)

Another reason was to avoid having to document precisely which methods of a str, list, etc. are required to be implemented.  (This is somewhat easier now that we have abc's, but really, it's still a royal PITA.)

In any event, it's entirely moot now, six years later.  Any change requests should be sent to the Web-SIG for WSGI 2.0 discussion, as changing the existing PEPs is not an option.  (Guido has pronounced that I cannot change PEP 333 in any way, so even if I agreed with the requests in this thread, there is simply no way that wsgiref is changing in 2.x.  PEP 3333 has just been approved as well, so the odds of even a 3.x change are low.  But as I said, I won't object to a Headers patch that *converts* its non-conforming inputs to objects of type str, as long as they were stringlike objects to start with.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10935>
_______________________________________

From report at bugs.python.org  Wed Jan 19 20:28:21 2011
From: report at bugs.python.org (anatoly techtonik)
Date: Wed, 19 Jan 2011 19:28:21 +0000
Subject: [issue10887] Add link to development ML
In-Reply-To: <1294745681.16.0.799239354624.issue10887@psf.upfronthosting.co.za>
Message-ID: <1295465301.14.0.920327930061.issue10887@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

Backlink to project web site won't hurt either. ;)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10887>
_______________________________________

From report at bugs.python.org  Wed Jan 19 20:30:21 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 19 Jan 2011 19:30:21 +0000
Subject: [issue10934] imaplib: Internaldate2tuple() is documented to return
	UTC, but it returns local time
In-Reply-To: <1295358368.86.0.12522725261.issue10934@psf.upfronthosting.co.za>
Message-ID: <1295465421.5.0.0960347448748.issue10934@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

It makes sense that Internaldate2tuple() returns local time because timetuple (with its tm_isdst flag) strongly suggests local time.  (See also issue 9004.)

If UTC or any other timezone time is needed, it would be best to provide a function that would return an aware datetime object.

I made some changes to Joe's patch in attached diff.  I would appreciate another pair of eyes to look at it before I commit.

----------
nosy: +belopolsky
resolution:  -> accepted
stage:  -> commit review
Added file: http://bugs.python.org/file20457/issue10934.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10934>
_______________________________________

From report at bugs.python.org  Wed Jan 19 20:32:07 2011
From: report at bugs.python.org (akira)
Date: Wed, 19 Jan 2011 19:32:07 +0000
Subject: [issue9509] argparse FileType raises ugly exception for missing file
In-Reply-To: <1280927287.23.0.0771144110186.issue9509@psf.upfronthosting.co.za>
Message-ID: <1295465527.43.0.386702605479.issue9509@psf.upfronthosting.co.za>


akira <4kir4.1i at gmail.com> added the comment:

"no such file or directory '%s'" is misleading if you are trying to open a readonly file for writing.

The message might be replace by: "can't open '%s'"

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9509>
_______________________________________

From report at bugs.python.org  Wed Jan 19 20:40:49 2011
From: report at bugs.python.org (SilentGhost)
Date: Wed, 19 Jan 2011 19:40:49 +0000
Subject: [issue9509] argparse FileType raises ugly exception for missing file
In-Reply-To: <1280927287.23.0.0771144110186.issue9509@psf.upfronthosting.co.za>
Message-ID: <1295466049.68.0.525591026362.issue9509@psf.upfronthosting.co.za>


Changes by SilentGhost <ghost.adh at gmail.com>:


Added file: http://bugs.python.org/file20458/argparse.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9509>
_______________________________________

From report at bugs.python.org  Wed Jan 19 20:40:53 2011
From: report at bugs.python.org (SilentGhost)
Date: Wed, 19 Jan 2011 19:40:53 +0000
Subject: [issue9509] argparse FileType raises ugly exception for missing file
In-Reply-To: <1280927287.23.0.0771144110186.issue9509@psf.upfronthosting.co.za>
Message-ID: <1295466053.1.0.494050436903.issue9509@psf.upfronthosting.co.za>


Changes by SilentGhost <ghost.adh at gmail.com>:


Removed file: http://bugs.python.org/file20456/argparse.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9509>
_______________________________________

From report at bugs.python.org  Wed Jan 19 20:45:15 2011
From: report at bugs.python.org (Joe Peterson)
Date: Wed, 19 Jan 2011 19:45:15 +0000
Subject: [issue10934] imaplib: Internaldate2tuple() is documented to return
	UTC, but it returns local time
In-Reply-To: <1295358368.86.0.12522725261.issue10934@psf.upfronthosting.co.za>
Message-ID: <1295466315.69.0.622423149256.issue10934@psf.upfronthosting.co.za>


Joe Peterson <joe at skyrush.com> added the comment:

Hey Alexander,

Looks great.  Just a few small things:

* In hunk 2 of the imaplib.rst file patch section, insert word "to" (i.e. "Convert *date_time* to an IMAP4 ``INTERNALDATE`` representation.")

* Two lines, down there's only one space at end of sentence:  "double-quotes). The" (all other places have 2 spaces).

* In first hunk of imaplib.py patch section, there is a period that does not belong after "tuple":  "time.struct_time tuple. or None"

That's all I saw!  Thanks for expanding on the doc!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10934>
_______________________________________

From report at bugs.python.org  Wed Jan 19 20:54:24 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 19 Jan 2011 19:54:24 +0000
Subject: [issue10934] imaplib: Internaldate2tuple() is documented to return
	UTC, but it returns local time
In-Reply-To: <1295358368.86.0.12522725261.issue10934@psf.upfronthosting.co.za>
Message-ID: <1295466864.27.0.871914841314.issue10934@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Committed in revision 88114.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10934>
_______________________________________

From report at bugs.python.org  Wed Jan 19 20:57:57 2011
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 19 Jan 2011 19:57:57 +0000
Subject: [issue10906] wsgiref should mention that CGI scripts usually expect
	HTTPS variable to be set to 'on'
In-Reply-To: <1295014476.87.0.519263477862.issue10906@psf.upfronthosting.co.za>
Message-ID: <1295467077.21.0.842508849278.issue10906@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

The doc says "1", "yes" or "on".  Looks fine to me.

----------
nosy: +georg.brandl
resolution:  -> works for me
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10906>
_______________________________________

From report at bugs.python.org  Wed Jan 19 21:01:30 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 19 Jan 2011 20:01:30 +0000
Subject: [issue10887] Add link to development ML
In-Reply-To: <1294745681.16.0.799239354624.issue10887@psf.upfronthosting.co.za>
Message-ID: <1295467290.3.0.511440710257.issue10887@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

What?s the project Web site?  In any case, the wiki is open to edition to everyone.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10887>
_______________________________________

From report at bugs.python.org  Wed Jan 19 21:07:15 2011
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 19 Jan 2011 20:07:15 +0000
Subject: [issue10944] ctypes documentation does not mention c_bool in table of
	standard types
In-Reply-To: <1295428553.77.0.0934599344466.issue10944@psf.upfronthosting.co.za>
Message-ID: <1295467635.8.0.570756788418.issue10944@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Fixed in r88115.

----------
nosy: +georg.brandl
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10944>
_______________________________________

From report at bugs.python.org  Wed Jan 19 21:11:17 2011
From: report at bugs.python.org (Beau)
Date: Wed, 19 Jan 2011 20:11:17 +0000
Subject: [issue10950] ServerProxy returns bad XML
In-Reply-To: <1295461145.33.0.479841381445.issue10950@psf.upfronthosting.co.za>
Message-ID: <1295467877.77.0.617508432484.issue10950@psf.upfronthosting.co.za>


Changes by Beau <beaumartinez at gmail.com>:


----------
type: compile error -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10950>
_______________________________________

From report at bugs.python.org  Wed Jan 19 21:20:52 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 19 Jan 2011 20:20:52 +0000
Subject: [issue10948] Trouble with dir_util created dir cache
In-Reply-To: <1295456838.39.0.734609669589.issue10948@psf.upfronthosting.co.za>
Message-ID: <1295468452.25.0.544253824882.issue10948@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

?Maybe distutils package was not designed for the purpose I am using it (I am not using it to install python modules or anything), but this behavior is not well documented anyway.?  Aaaah, I had no idea you were using the function directly for something unrelated to distutils?s purpose.  There is no clear distinction between public and private functions in distutils, so I understand how you could find this seemingly useful function and use it in your code.

The solution is to use a public function like os.makedirs.  For distutils, I don?t think a doc change is needed: the cache is an implementation detail.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10948>
_______________________________________

From report at bugs.python.org  Wed Jan 19 21:41:22 2011
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 19 Jan 2011 20:41:22 +0000
Subject: [issue10950] ServerProxy returns bad XML
In-Reply-To: <1295461145.33.0.479841381445.issue10950@psf.upfronthosting.co.za>
Message-ID: <1295469682.71.0.238163686833.issue10950@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Not sure what you mean by "non-marshallable type".  The Last.fm API returns the XML as an XMLRPC string, including the backslashes.

I tried the same call in Ruby using the script below, and get the backslashes too.  I would say this is a fault of Last.fm's XMLRPC server.

Ruby code:

require 'xmlrpc/client'
cl = XMLRPC::Client.new2 'http://ws.audioscrobbler.com/2.0/'
puts cl.call('library.getTracks', {'api_key' => 'b25b959554ed76058ac220b7b2e0a026', 'user' => 'joanofarctan', 'page' => 1})

----------
nosy: +georg.brandl
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10950>
_______________________________________

From report at bugs.python.org  Wed Jan 19 22:03:08 2011
From: report at bugs.python.org (Beau)
Date: Wed, 19 Jan 2011 21:03:08 +0000
Subject: [issue10950] ServerProxy returns bad XML
In-Reply-To: <1295461145.33.0.479841381445.issue10950@psf.upfronthosting.co.za>
Message-ID: <1295470988.53.0.914201812704.issue10950@psf.upfronthosting.co.za>


Beau <beaumartinez at gmail.com> added the comment:

Thanks for your time, georg.brandl. I'll file a bug report with them.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10950>
_______________________________________

From report at bugs.python.org  Wed Jan 19 22:27:46 2011
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 19 Jan 2011 21:27:46 +0000
Subject: [issue10950] ServerProxy returns bad XML
In-Reply-To: <1295461145.33.0.479841381445.issue10950@psf.upfronthosting.co.za>
Message-ID: <1295472466.05.0.780544000727.issue10950@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

BTW, you might want to exchange your API key since this one is now publicly available forever :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10950>
_______________________________________

From report at bugs.python.org  Wed Jan 19 22:30:18 2011
From: report at bugs.python.org (Diego Queiroz)
Date: Wed, 19 Jan 2011 21:30:18 +0000
Subject: [issue10948] Trouble with dir_util created dir cache
In-Reply-To: <1295456838.39.0.734609669589.issue10948@psf.upfronthosting.co.za>
Message-ID: <1295472618.01.0.686461306888.issue10948@psf.upfronthosting.co.za>


Diego Queiroz <queiroz.diego at gmail.com> added the comment:

You were right, "os.makedirs" fits my needs. :-)

Anyway, I still think the change in the documentation is needed.
This is not an implementation detail, it is part of the way the function works.

The user should be aware of the behavior when he call this function twice. In my opinion, the documentation should be clear about everything. We could call this an implementation detail iff it does not affect anything externally, but this is not the case (it affects subsequent calls).

This function does exactly the same of "os.makedirs" but the why is discribed only in a comment inside the code. We know this is a poor programming style. This information need to be available in the documentation too.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10948>
_______________________________________

From report at bugs.python.org  Wed Jan 19 22:33:38 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 19 Jan 2011 21:33:38 +0000
Subject: [issue10948] Trouble with dir_util created dir cache
In-Reply-To: <1295456838.39.0.734609669589.issue10948@psf.upfronthosting.co.za>
Message-ID: <1295472818.66.0.522954278042.issue10948@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

?This is not an implementation detail, it is part of the way the function works.  The user should be aware of the behavior when [they] call this function twice.?

I would agree if mkpath were a public function.  I think it?s an implementation detail used by other distutils code, especially commands.  Considering that dir_util is gone in distutils2, I see no benefit in editing the doc.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10948>
_______________________________________

From report at bugs.python.org  Wed Jan 19 22:49:10 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 19 Jan 2011 21:49:10 +0000
Subject: [issue10934] imaplib: Internaldate2tuple() is documented to return
	UTC, but it returns local time
In-Reply-To: <1295358368.86.0.12522725261.issue10934@psf.upfronthosting.co.za>
Message-ID: <1295473750.15.0.195623012976.issue10934@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Merged to 2.7 in revision 88116.

----------
stage: commit review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10934>
_______________________________________

From report at bugs.python.org  Wed Jan 19 22:58:38 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 19 Jan 2011 21:58:38 +0000
Subject: [issue10951] gcc 4.6 warnings
In-Reply-To: <1295474318.57.0.129834114348.issue10951@psf.upfronthosting.co.za>
Message-ID: <1295474318.57.0.129834114348.issue10951@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

To analyze #9880, I installed gcc-4.6. It looks like this new gcc version emits new warnings. Here is a report of py3k warnings generated with "gcc-4.6 -O3 -Wall -Wextra -Wstrict-prototypes -Wno-missing-field-initializers -Wno-unused-parameter" on AMD64. I grouped manually  the warnings.

sign-compare:

Parser/node.c: In function 'PyNode_AddChild':
Parser/node.c:94:31: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
Objects/bytesobject.c: In function 'PyBytes_FromStringAndSize':
Objects/bytesobject.c:95:14: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
Objects/floatobject.c: In function 'PyFloat_ClearFreeList':
Objects/floatobject.c:1960:16: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
Objects/floatobject.c:1970:20: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
Objects/floatobject.c: In function 'PyFloat_Fini':
Objects/floatobject.c:2014:20: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
Objects/memoryobject.c: In function '_indirect_copy_nd':
Objects/memoryobject.c:199:20: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
Objects/tupleobject.c: In function 'PyTuple_New':
Objects/tupleobject.c:85:21: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
Objects/typeobject.c: In function 'PyType_FromSpec':
Objects/typeobject.c:2339:17: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
Objects/unicodeobject.c: In function '_PyUnicode_New':
Objects/unicodeobject.c:326:16: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
Objects/unicodeobject.c: In function 'PyUnicodeUCS2_AsWideCharString':
Objects/unicodeobject.c:1288:42: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
Objects/unicodeobject.c: In function 'PyUnicodeUCS2_DecodeFSDefaultAndSize':
Objects/unicodeobject.c:1804:37: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
Objects/unicodeobject.c: In function 'PyUnicodeUCS2_FSConverter':
Objects/unicodeobject.c:1851:14: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
Objects/unicodeobject.c: In function 'PyUnicodeUCS2_FSDecoder':
Objects/unicodeobject.c:1892:14: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
Objects/unicodeobject.c: In function 'PyUnicode_AsUnicodeCopy':
Objects/unicodeobject.c:10336:37: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
Python/asdl.c: In function 'asdl_seq_new':
Python/asdl.c:12:30: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
Python/asdl.c: In function 'asdl_int_seq_new':
Python/asdl.c:43:30: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
Parser/printgrammar.c: In function 'printdfas':
Parser/printgrammar.c:96:23: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
Parser/pgenmain.c: In function 'getgrammar':
Parser/pgenmain.c:102:27: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
Python/bltinmodule.c: In function 'source_as_string':
Python/bltinmodule.c:528:21: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
Python/getargs.c: In function 'convertsimple':
Python/getargs.c:876:28: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
Python/getargs.c:993:43: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
Python/pythonrun.c: In function 'print_error_text':
Python/pythonrun.c:1352:34: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
./Python/sysmodule.c: In function 'svnversion_init':
./Python/sysmodule.c:1367:9: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
Python/traceback.c: In function '_Py_FindSourceFile':
Python/traceback.c:191:29: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
Python/dtoa.c: In function 'Balloc':
Python/dtoa.c:349:56: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
Python/thread_pthread.h: In function 'PyThread_create_key':
Python/thread_pthread.h:592:22: warning: signed and unsigned type in conditional expression [-Wsign-compare]
Python/compile.c: In function 'compiler_import_as':
Python/compile.c:2076:49: warning: signed and unsigned type in conditional expression [-Wsign-compare]
Python/compile.c: In function 'assemble_init':
Python/compile.c:3619:17: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]

unused-but-set-variable:

Parser/parsetok.c: In function 'parsetok':
Parser/parsetok.c:130:43: warning: variable 'handling_with' set but not used [-Wunused-but-set-variable]
Objects/obmalloc.c: In function '_PyObject_DebugMallocStats':
Objects/obmalloc.c:1778:14: warning: variable 'poolsinarena' set but not used [-Wunused-but-set-variable]
Objects/unicodeobject.c: In function 'replace':
Objects/unicodeobject.c:6932:29: warning: variable 'e' set but not used [-Wunused-but-set-variable]
Python/bltinmodule.c: In function 'builtin___build_class__':
Python/bltinmodule.c:40:23: warning: variable 'nbases' set but not used [-Wunused-but-set-variable]
Python/bltinmodule.c: In function 'builtin_exec':
Python/bltinmodule.c:769:9: warning: variable 'plain' set but not used [-Wunused-but-set-variable]
./Python/sysmodule.c: In function 'PySys_AddXOption':
./Python/sysmodule.c:1179:9: warning: variable 'r' set but not used [-Wunused-but-set-variable]
Python/thread_pthread.h: In function 'PyThread_free_lock':
Python/thread_pthread.h:294:17: warning: variable 'error' set but not used [-Wunused-but-set-variable]
Python/thread_pthread.h: In function 'PyThread_acquire_lock_timed':
Python/thread_pthread.h:325:17: warning: variable 'error' set but not used [-Wunused-but-set-variable]
Python/thread_pthread.h: In function 'PyThread_release_lock':
Python/thread_pthread.h:376:17: warning: variable 'error' set but not used [-Wunused-but-set-variable]
./Modules/_sre.c: In function '_validate_inner':
./Modules/_sre.c:2988:42: warning: variable 'prefix_skip' set but not used [-Wunused-but-set-variable]
./Modules/_sre.c:2966:38: warning: variable 'max' set but not used [-Wunused-but-set-variable]
./Modules/_sre.c:2966:33: warning: variable 'min' set but not used [-Wunused-but-set-variable]
./Modules/_io/bytesio.c: In function 'bytesiobuf_getbuffer':
./Modules/_io/bytesio.c:941:11: warning: variable 'ptr' set but not used [-Wunused-but-set-variable]

empty-body:

Parser/pgen.c: In function 'compile_rule':
Parser/pgen.c:174:28: warning: suggest braces around empty body in an 'else' statement [-Wempty-body]
Parser/pgen.c: In function 'compile_rhs':
Parser/pgen.c:195:15: warning: suggest braces around empty body in an 'else' statement [-Wempty-body]
Parser/pgen.c:210:19: warning: suggest braces around empty body in an 'else' statement [-Wempty-body]
Parser/pgen.c: In function 'compile_alt':
Parser/pgen.c:228:15: warning: suggest braces around empty body in an 'else' statement [-Wempty-body]
Parser/pgen.c: In function 'compile_item':
Parser/pgen.c:250:15: warning: suggest braces around empty body in an 'else' statement [-Wempty-body]
Parser/pgen.c:253:19: warning: suggest braces around empty body in an 'else' statement [-Wempty-body]
Parser/pgen.c:262:19: warning: suggest braces around empty body in an 'else' statement [-Wempty-body]
Parser/pgen.c: In function 'compile_atom':
Parser/pgen.c:286:15: warning: suggest braces around empty body in an 'else' statement [-Wempty-body]
Parser/pgen.c:289:19: warning: suggest braces around empty body in an 'else' statement [-Wempty-body]
./Modules/_sre.c: In function '_validate':
./Modules/_sre.c:3194:31: warning: suggest braces around empty body in an 'else' statement [-Wempty-body]

uninitialized:

Objects/setobject.c: In function 'test_c_api':
Objects/setobject.c:2445:11: warning: 'x' may be used uninitialized in this function [-Wuninitialized]
Python/Python-ast.c: In function 'obj2ast_expr':
Python/Python-ast.c:5824:24: warning: 'col_offset' may be used uninitialized in this function [-Wuninitialized]
Python/Python-ast.c:5824:24: warning: 'lineno' may be used uninitialized in this function [-Wuninitialized]
Python/Python-ast.c: In function 'obj2ast_stmt.part.15':
Python/Python-ast.c:4678:24: warning: 'col_offset' may be used uninitialized in this function [-Wuninitialized]
Python/Python-ast.c:4678:24: warning: 'lineno' may be used uninitialized in this function [-Wuninitialized]

(other):

./Python/sysmodule.c: In function 'svnversion_init':
./Python/sysmodule.c:1368:9: warning: offset outside bounds of constant string [enabled by default]
In file included from Python/thread.c:118:0:

----------
messages: 126571
nosy: haypo
priority: normal
severity: normal
status: open
title: gcc 4.6 warnings

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10951>
_______________________________________

From report at bugs.python.org  Wed Jan 19 22:58:50 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 19 Jan 2011 21:58:50 +0000
Subject: [issue10951] gcc 4.6 warnings
In-Reply-To: <1295474318.57.0.129834114348.issue10951@psf.upfronthosting.co.za>
Message-ID: <1295474330.87.0.443690081384.issue10951@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
components: +Build
versions: +Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10951>
_______________________________________

From report at bugs.python.org  Wed Jan 19 23:00:57 2011
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 19 Jan 2011 22:00:57 +0000
Subject: [issue10951] gcc 4.6 warnings
In-Reply-To: <1295474318.57.0.129834114348.issue10951@psf.upfronthosting.co.za>
Message-ID: <1295474457.92.0.310683715518.issue10951@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
nosy: +brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10951>
_______________________________________

From report at bugs.python.org  Wed Jan 19 23:35:13 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 19 Jan 2011 22:35:13 +0000
Subject: [issue10939] imaplib: Internaldate2tuple raises KeyError parsing
	month and does not work with negative TZ offset due to
	bytes/str issues
In-Reply-To: <1295389900.99.0.76199090445.issue10939@psf.upfronthosting.co.za>
Message-ID: <1295476513.39.0.853151016924.issue10939@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Georg,

This is an obvious artifact of an untested py3k port.  Can this go in 3.2?

The patch looks good except for a long line in the test which I can take care of.

----------
assignee:  -> belopolsky
nosy: +belopolsky, georg.brandl
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10939>
_______________________________________

From report at bugs.python.org  Wed Jan 19 23:50:24 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 19 Jan 2011 22:50:24 +0000
Subject: [issue10941] imaplib: Internaldate2tuple produces wrong result if
	date is near a DST change
In-Reply-To: <1295394107.36.0.490316527511.issue10941@psf.upfronthosting.co.za>
Message-ID: <1295477424.39.0.692587805055.issue10941@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

I agree that this is a bug and the solution is right, I am not sure this should be applied during RC period.  The bug has been present and known for a long time, so affected parties probably have a work-around in place already.

----------
nosy: +belopolsky, georg.brandl
stage:  -> patch review
versions: +Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10941>
_______________________________________

From report at bugs.python.org  Thu Jan 20 00:00:48 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 19 Jan 2011 23:00:48 +0000
Subject: [issue10947] imaplib: Internaldate2tuple and ParseFlags require (and
	latter returns) bytes arrays; should allow/return str
In-Reply-To: <1295451332.43.0.977417439806.issue10947@psf.upfronthosting.co.za>
Message-ID: <1295478048.58.0.337818535593.issue10947@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

David,

Can you weigh in on this?

I am -1 on improving Internaldate2tuple(). I think the module should provide a function that would return an aware datetime object instead of a timetuple.

The proposed patch will make error reporting from Internaldate2tuple() inconsistent: invalid bytes result in None return while non-ASCII characters in strings would raise an encoding error.  While I don't like the "if not mo: return None" logic, if compatibility with 2.x is the goal, encoding errors should be caught and converted to return None.

----------
nosy: +belopolsky, r.david.murray
type: behavior -> feature request
versions: +Python 3.3 -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10947>
_______________________________________

From report at bugs.python.org  Thu Jan 20 00:01:32 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 19 Jan 2011 23:01:32 +0000
Subject: [issue10947] imaplib: Internaldate2tuple and ParseFlags require (and
	latter returns) bytes arrays; should allow/return str
In-Reply-To: <1295451332.43.0.977417439806.issue10947@psf.upfronthosting.co.za>
Message-ID: <1295478092.04.0.161063247844.issue10947@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


----------
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10947>
_______________________________________

From report at bugs.python.org  Thu Jan 20 00:29:06 2011
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 19 Jan 2011 23:29:06 +0000
Subject: [issue10923] Python 2.7 hangs on Unicode+threading
In-Reply-To: <1295230653.16.0.00822246437847.issue10923@psf.upfronthosting.co.za>
Message-ID: <1295479746.47.0.469670614167.issue10923@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
nosy: +brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10923>
_______________________________________

From report at bugs.python.org  Thu Jan 20 00:50:39 2011
From: report at bugs.python.org (Beau)
Date: Wed, 19 Jan 2011 23:50:39 +0000
Subject: [issue10950] ServerProxy returns bad XML
In-Reply-To: <1295461145.33.0.479841381445.issue10950@psf.upfronthosting.co.za>
Message-ID: <1295481039.52.0.930085935692.issue10950@psf.upfronthosting.co.za>


Beau <beaumartinez at gmail.com> added the comment:

Use my API key? That would have been telling! Fortunately I used the example API key Last.fm provide on the page I linked ;)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10950>
_______________________________________

From report at bugs.python.org  Thu Jan 20 00:55:10 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 19 Jan 2011 23:55:10 +0000
Subject: [issue10951] gcc 4.6 warnings
In-Reply-To: <1295474318.57.0.129834114348.issue10951@psf.upfronthosting.co.za>
Message-ID: <1295481310.94.0.294323365102.issue10951@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I took a look at an example of each type.

Sign-compare, Parser/node.c, 94
        if (required_capacity > PY_SIZE_MAX / sizeof(node))

I presume PY_SIZE_MAX and sizeof(node) are both unsigned.
So is, conceptually, required_capacity, but it is defined as an int because it is defined with XXXROUNDUP() and hence fancy_roundup(), which returns -1 if n1->n_nchildren is so large that the smallest power of 2 larger is too big for an int.

The comparison is 'OK' in context in that it is preceded by and guarded by
    if (current_capacity < 0 || required_capacity < 0)
        return E_OVERFLOW;

If I had written this, I might have thought about replacing all the comparisons with one check of n1->n_nchildren against some reasonable limit calculated from PY_SIZE_MAX / sizeof(node), and making both capacities unsigned.

---
Unused, Parser/parsetok.c, 130: local vars handling_with and handling_import are both set to 0 both here and again on line 157 and not seen elsewhere in the file. I presume both could just be deleted both places. 

---
Empty body, pgen, multiple places: those I checked are appearances of the REQN() macro. The REQ() macro did not generate a warning. 

#ifdef Py_DEBUG
#define REQN(i, count) \
    if (i < count) { \
        fprintf(stderr, REQNFMT, count); \
        Py_FatalError("REQN"); \
    } else
#else
#define REQN(i, count)  /* empty */
#endif

Since all invocations of REQN look like "     REQN(i, 1);", I presume the 'else' is there to swallow up the ';' which is added to make macro calls look like statements with a function call. I guess this is a style issue. As I remember, the suggestion to simply add '{}' to the macro would make syntax errors.

---
Uninitialized, Objects/setobject.c, 2445, in test_c_api: 
    while (_PySet_NextEntry((PyObject *)dup, &i, &x, &hash)) {
        s = _PyUnicode_AsString(x);

I presume x is set by _PySet... . (If i and hash are also, they are not used). So 'may be' but not actually.

---
Conclusion: the 'fix' is some real cleanup, some warning suppression.

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10951>
_______________________________________

From report at bugs.python.org  Thu Jan 20 02:54:59 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 20 Jan 2011 01:54:59 +0000
Subject: [issue10952] Don't normalize module names to NFKC?
In-Reply-To: <1295488499.02.0.313090900295.issue10952@psf.upfronthosting.co.za>
Message-ID: <1295488499.02.0.313090900295.issue10952@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

The Python 3 parser normalizes all identifiers using NFKC (as described in the PEP 3131). Examples:
 - U+00B5 (?: Micro sign) is normalized to U+03BC (?: Greek small letter mu)
 - U+FB03 (?: Latin small ligature ffi) is normalized to 'ffi'

The problem is that it does also normalize module names, but not the filename.

The module name in the Python source code is written with the keyboard (eg. U+00B5 in my case) and then normalized to NFKC (=> U+03BC). The filename is also written using the keyboard (U+00B5), but it is never normalized.

Attached script tests the current behaviour using "?Torrent" name with U+00B5 and U+03BC: import with U+00B5 or U+03BC use the filename with U+03BC.

The problem is that I'm able to write '?' (U+00B5) with my keyboard, but not U+03BC (?).

----------
components: Interpreter Core, Unicode
files: module_name.py
messages: 126577
nosy: haypo
priority: normal
severity: normal
status: open
title: Don't normalize module names to NFKC?
versions: Python 3.1, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file20459/module_name.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10952>
_______________________________________

From report at bugs.python.org  Thu Jan 20 02:55:04 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 20 Jan 2011 01:55:04 +0000
Subject: =?utf-8?q?=5Bissue10946=5D_bdist_doesn=E2=80=99t_pass_--skip-build_on_to_?=
	=?utf-8?q?subcommands?=
In-Reply-To: <1295451169.68.0.9980803941.issue10946@psf.upfronthosting.co.za>
Message-ID: <1295488504.79.0.411320448442.issue10946@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I added the required calls to pass skip-build from bdist to bdist_* but that isn?t enough to make the test from https://bitbucket.org/ygingras/distutils2/changeset/71f5c39c9100 pass.  build gets somehow called, even though install, install_lib, bdist and bdist_dumb have skip_build set to 0.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10946>
_______________________________________

From report at bugs.python.org  Thu Jan 20 02:56:08 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 20 Jan 2011 01:56:08 +0000
Subject: [issue10952] Don't normalize module names to NFKC?
In-Reply-To: <1295488499.02.0.313090900295.issue10952@psf.upfronthosting.co.za>
Message-ID: <1295488568.85.0.539791854235.issue10952@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


----------
nosy: +belopolsky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10952>
_______________________________________

From report at bugs.python.org  Thu Jan 20 03:00:23 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 20 Jan 2011 02:00:23 +0000
Subject: [issue10952] Don't normalize module names to NFKC?
In-Reply-To: <1295488499.02.0.313090900295.issue10952@psf.upfronthosting.co.za>
Message-ID: <1295488823.25.0.990858475061.issue10952@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

"?Torrent.py" filename example comes from #10754.

This issue is unrelated to the Python parser or the import machinery: it is a surprising behaviour of the MBCS codec which replaces unencodable characters to a similar glyph. I changed the MBCS in Python 3.2 to be strict (it now raises an error on unencodable character).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10952>
_______________________________________

From report at bugs.python.org  Thu Jan 20 03:18:44 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 20 Jan 2011 02:18:44 +0000
Subject: [issue10952] Don't normalize module names to NFKC?
In-Reply-To: <1295488499.02.0.313090900295.issue10952@psf.upfronthosting.co.za>
Message-ID: <1295489924.05.0.981148788417.issue10952@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

This proposal makes sense because it would make

import ?Torrent

behave the same as

?Torrent = __import__('?Torrent')

However, I think this is a feature request and a language change because the current grammar is

import_stmt     ::=  "import" module ..
module          ::=  (identifier ".")* identifier

and in order to implement the proposed feature, "module" will have to become a separate AST node that won't be treated as identifier.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10952>
_______________________________________

From report at bugs.python.org  Thu Jan 20 03:21:42 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 20 Jan 2011 02:21:42 +0000
Subject: [issue10952] Don't normalize module names to NFKC?
In-Reply-To: <1295488499.02.0.313090900295.issue10952@psf.upfronthosting.co.za>
Message-ID: <1295490102.85.0.965951587132.issue10952@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

New problem: if the parser doesn't normalize module names on import, it does still normalize module names on other instructions.

Example: "import \xB5Torrent; del \xB5Torrent" raises an error on del because the parser normalized del identifier (the second module name) => "import \xB5Torrent; del \u03BCTorrent".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10952>
_______________________________________

From report at bugs.python.org  Thu Jan 20 03:22:09 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 20 Jan 2011 02:22:09 +0000
Subject: [issue10952] Don't normalize module names to NFKC?
In-Reply-To: <1295488499.02.0.313090900295.issue10952@psf.upfronthosting.co.za>
Message-ID: <1295490129.01.0.685435800342.issue10952@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

See also #3080 (which is not directly related).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10952>
_______________________________________

From report at bugs.python.org  Thu Jan 20 03:28:31 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Thu, 20 Jan 2011 02:28:31 +0000
Subject: [issue10951] gcc 4.6 warnings
In-Reply-To: <1295474318.57.0.129834114348.issue10951@psf.upfronthosting.co.za>
Message-ID: <1295490511.03.0.313596068957.issue10951@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/issue10951>
_______________________________________

From report at bugs.python.org  Thu Jan 20 03:31:43 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 20 Jan 2011 02:31:43 +0000
Subject: [issue10952] Don't normalize module names to NFKC?
In-Reply-To: <1295490102.85.0.965951587132.issue10952@psf.upfronthosting.co.za>
Message-ID: <AANLkTi=6=vraCBNDFjZkoR8J=PP9sznmZzFEG2bcOVO+@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Wed, Jan 19, 2011 at 9:21 PM, STINNER Victor <report at bugs.python.org> wrote:
..
> New problem: if the parser doesn't normalize module names on import, it does still
> normalize module names on other instructions.
>
> Example: "import \xB5Torrent; del \xB5Torrent" raises an error on del because the parser
> normalized del identifier (the second module name) => "import \xB5Torrent; del \u03BCTorrent".
>

This won't be a problem if you make "import \xB5Torrent" behave as
"\xB5Torrent = __import__('\xB5Torrent')".  The latter is equivalent
to "\u03BCTorrent =  __import__('\xB5Torrent')".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10952>
_______________________________________

From report at bugs.python.org  Thu Jan 20 04:02:22 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 20 Jan 2011 03:02:22 +0000
Subject: [issue10952] Don't normalize module names to NFKC?
In-Reply-To: <1295488499.02.0.313090900295.issue10952@psf.upfronthosting.co.za>
Message-ID: <1295492542.64.0.331169275347.issue10952@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> This won't be a problem if you make 
> "import \xB5Torrent" 
> behave as (...)
> "\u03BCTorrent =  __import__('\xB5Torrent')"

"import name" is compiled to "IMPORT_NAME(name); STORE_NAME(name)" bytecode instructions. So you proposed to compile it to "IMPORT_NAME(name); STORE_NAME(normalized_name)" if name is different than the normalized name. Ok, I think that it is possible.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10952>
_______________________________________

From report at bugs.python.org  Thu Jan 20 04:07:28 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 20 Jan 2011 03:07:28 +0000
Subject: [issue10923] Deadlock because of the import lock when loading the
	utf8 codec
In-Reply-To: <1295230653.16.0.00822246437847.issue10923@psf.upfronthosting.co.za>
Message-ID: <1295492848.62.0.87574534133.issue10923@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
title: Python 2.7 hangs on Unicode+threading -> Deadlock because of the import lock when loading the utf8 codec

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10923>
_______________________________________

From report at bugs.python.org  Thu Jan 20 04:13:27 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 20 Jan 2011 03:13:27 +0000
Subject: [issue10923] Deadlock because of the import lock when loading the
	utf8 codec
In-Reply-To: <1295230653.16.0.00822246437847.issue10923@psf.upfronthosting.co.za>
Message-ID: <1295493207.57.0.67513030095.issue10923@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Dummy question: can't we raise a RuntimeError on a deadlock?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10923>
_______________________________________

From report at bugs.python.org  Thu Jan 20 04:29:35 2011
From: report at bugs.python.org (kai zhu)
Date: Thu, 20 Jan 2011 03:29:35 +0000
Subject: [issue10953] safely eval serialized dict/list data from arbitrary
	string over web with no side effects
In-Reply-To: <1295494175.9.0.514806108432.issue10953@psf.upfronthosting.co.za>
Message-ID: <1295494175.9.0.514806108432.issue10953@psf.upfronthosting.co.za>


New submission from kai zhu <kaizhu at ugcs.caltech.edu>:

rather than serialize python dicts & list to json / xml / protocol buffer for web use, its more efficient to just serialize w/ repr() & then use eval(), if only there was a way to guarantee arbitrary code can't b executed.

this is a very simple proposed method for the latter.  b4 eval(), it compiles string to python code object & checks for:
1. co_names list can only contain 'False', 'None', 'True'
   -this ensures no function call can b made
2. co_consts list cannot contain code objects
   -embedded lambda's r forbidden.
3. grave accents are explicitly forbidden.

here is the code for both python2.5 (intended for google appengine) & python 3k:

## safe_eval.py
import sys, types

if sys.version_info[0] == 2: ## py2x
  _co_safe = 'co_argcount co_nlocals co_varnames co_filename co_freevars co_cellvars'.split(' ')
else: ## py3k
  _co_safe = 'co_argcount co_kwonlyargcount co_nlocals co_names co_varnames co_filename co_freevars co_cellvars'.split(' ')

## safely eval string with no side-effects
def safe_eval(ss):
  if not ss: return None
  if '`' in ss: raise ValueError('grave accent "`" forbidden')
  cc = compile(ss, '', 'eval')
  for aa in _co_safe:
    if getattr(cc, aa): raise ValueError(aa + ' must be empty / none / zero')
  for aa in cc.co_names:
    if aa not in ['False', 'None', 'True']: raise ValueError('co_names can only contain False, None, True')
  for aa in cc.co_consts:
    if isinstance(aa, types.CodeType): raise TypeError('code objects not allowed in co_consts')
  return eval(cc, {})



python2.5
Python 2.5.5 (r255:77872, Nov 28 2010, 19:00:19) 
[GCC 4.4.5] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from safe_eval import safe_eval

>>> safe_eval('[False, None, True, {1:2}]')
[False, None, True, {1: 2}]

>>> safe_eval('[None, False, True, {1:2}, evil_code()]')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "safe_eval.py", line 19, in safe_eval
    if aa not in ['False', 'None', 'True']: raise ValueError('co_names can only contain False, None, True')
ValueError: co_names can only contain False, None, True

>>> safe_eval('[None, False, True, {1:2}, `evil_code()`]')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "safe_eval.py", line 14, in safe_eval
    if '`' in ss: raise ValueError('grave accent "`" forbidden')
ValueError: grave accent "`" forbidden

>>> safe_eval('[None, False, True, {1:2}, lambda: evil_code()]')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "safe_eval.py", line 21, in safe_eval
    if isinstance(aa, types.CodeType): raise TypeError('code objects not allowed in co_consts')
TypeError: code objects not allowed in co_consts

----------
components: Library (Lib)
messages: 126586
nosy: kaizhu
priority: normal
severity: normal
status: open
title: safely eval serialized dict/list data from arbitrary string over web with no side effects
type: feature request
versions: Python 2.5, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10953>
_______________________________________

From report at bugs.python.org  Thu Jan 20 05:11:46 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 20 Jan 2011 04:11:46 +0000
Subject: [issue10952] Don't normalize module names to NFKC?
In-Reply-To: <1295488499.02.0.313090900295.issue10952@psf.upfronthosting.co.za>
Message-ID: <1295496706.47.0.958787509809.issue10952@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Victor> Ok, I think that it is possible.

While it is possible, I am not sure it is a good idea.  For example, if a filesystem uses encoding that is capable of distinguishing between "\xB5Torrent.py" and "\u03BCTorrent.py", should "import \xB5Torrent" and "import \u03BCTorrent" import different modules?

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10952>
_______________________________________

From report at bugs.python.org  Thu Jan 20 05:20:32 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 20 Jan 2011 04:20:32 +0000
Subject: [issue3080] Full unicode import system
In-Reply-To: <1213208697.49.0.984990811807.issue3080@psf.upfronthosting.co.za>
Message-ID: <1295497232.65.0.283533757293.issue3080@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


----------
nosy: +belopolsky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3080>
_______________________________________

From report at bugs.python.org  Thu Jan 20 06:23:29 2011
From: report at bugs.python.org (Ross Lagerwall)
Date: Thu, 20 Jan 2011 05:23:29 +0000
Subject: [issue6059] uuid.uuid4 cause segfault in emesene
In-Reply-To: <1242699417.24.0.211949858612.issue6059@psf.upfronthosting.co.za>
Message-ID: <1295501009.51.0.916305891839.issue6059@psf.upfronthosting.co.za>


Ross Lagerwall <rosslagerwall at gmail.com> added the comment:

I tried to reproduce the bug on 2.7 & 3.2 using libuuid version 2.17.2 and up to 100 threads but couldn't.

Perhaps there was an issue with the uuid library function that he was using and threading?

----------
nosy: +rosslagerwall

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6059>
_______________________________________

From report at bugs.python.org  Thu Jan 20 07:03:42 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 20 Jan 2011 06:03:42 +0000
Subject: [issue10953] safely eval serialized dict/list data from arbitrary
	string over web with no side effects
In-Reply-To: <1295494175.9.0.514806108432.issue10953@psf.upfronthosting.co.za>
Message-ID: <1295503422.79.0.507817918657.issue10953@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

> rather than serialize python dicts & list to json ...
> its more efficient to just serialize w/ repr() & then use eval()

Do you have benchmarks that support this claim?

----------
nosy: +belopolsky
versions:  -Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10953>
_______________________________________

From report at bugs.python.org  Thu Jan 20 07:19:05 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 20 Jan 2011 06:19:05 +0000
Subject: [issue10952] Don't normalize module names to NFKC?
In-Reply-To: <1295488499.02.0.313090900295.issue10952@psf.upfronthosting.co.za>
Message-ID: <1295504345.52.0.340096637702.issue10952@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

I think this issue falls into a similar category as support for case-insensitive but case-preserving file systems. Python uses regular file system lookups, but then may need to verify whether it got the right one.

I'd like to request that PEP 3131 is followed as it stands: identifier lookup uses NFKC, period. This gives two issues: a) how can users make sure that they name the files correctly? and b) what if the file system implementation mangles file names.

For b), I'd use the same approach as with case-insensitive lookups: verify that the file we read is really the one we want. For a), wrt. "I'm not able to write U+03BC with my keyboard", I say "tough luck - don't use that character in a module name, then". Somebody with a Greek keyboard will have no problems doing that. This is really the same as any other non-ASCII character which you are unable to type: it just means that you can't conveniently enter the respective Python identifier. Just try importing "????", for example. Get a different keyboard.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10952>
_______________________________________

From report at bugs.python.org  Thu Jan 20 07:19:13 2011
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 20 Jan 2011 06:19:13 +0000
Subject: [issue10953] safely eval serialized dict/list data from arbitrary
	string over web with no side effects
In-Reply-To: <1295494175.9.0.514806108432.issue10953@psf.upfronthosting.co.za>
Message-ID: <1295504353.79.0.918175266575.issue10953@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Have a look at ast.literal_eval().

----------
nosy: +georg.brandl
resolution:  -> works for me
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10953>
_______________________________________

From report at bugs.python.org  Thu Jan 20 07:40:27 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 20 Jan 2011 06:40:27 +0000
Subject: [issue10952] Don't normalize module names to NFKC?
In-Reply-To: <1295504345.52.0.340096637702.issue10952@psf.upfronthosting.co.za>
Message-ID: <AANLkTi=Q5ZK4iG2nMgic50fMLCqWDEiDVQgKTripr+bX@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Thu, Jan 20, 2011 at 1:19 AM, Martin v. L?wis <report at bugs.python.org> wrote:
..
> I'd like to request that PEP 3131 is followed as it stands: identifier lookup uses NFKC,
> period. This gives two issues: a) how can users make sure that they name the files
> correctly? and b) what if the file system implementation mangles file names.
>

There is also issue c) what if the filesystem encoding can only
represent a compatibility character, say U+00B5, but not its NFKC
equivalent, U+03BC?  Suppose you have a system with both locale and FS
encodings being Latin-1.  You can write Python code using Latin-1 and
the following is valid bytestream:

b'# encoding: latin-1\nimport \xB5Torrent\n"

However, this code will always fail because '\xB5Torrent' will be
normalized into '\u03BCTorrent' and a file named '\u03BCTorrent.py'
cannot be created on a filesystem with Latin-1 encoding.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10952>
_______________________________________

From report at bugs.python.org  Thu Jan 20 07:43:39 2011
From: report at bugs.python.org (John Machin)
Date: Thu, 20 Jan 2011 06:43:39 +0000
Subject: [issue7198] Extraneous newlines with csv.writer on Windows
In-Reply-To: <1256422121.38.0.499052368843.issue7198@psf.upfronthosting.co.za>
Message-ID: <1295505819.38.0.863088601853.issue7198@psf.upfronthosting.co.za>


John Machin <sjmachin at lexicon.net> added the comment:

"docpatch" for 3.x csv docs:

In the csv.writer docs, insert the sentence "If csvfile is a file object, it should be opened with newline=''." immediately after the sentence "csvfile can be any object with a write() method."

In the closely-following example, change the open call from "open('eggs.csv', 'w')" to "open('eggs.csv', 'w', newline='')".

In section 13.1.5 Examples, there are 2 reader cases and 1 writer case that likewise need inserting ", newline=''" in the open call.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7198>
_______________________________________

From report at bugs.python.org  Thu Jan 20 09:38:07 2011
From: report at bugs.python.org (Ross Lagerwall)
Date: Thu, 20 Jan 2011 08:38:07 +0000
Subject: [issue4761] create Python wrappers for openat() and others
In-Reply-To: <1230476318.95.0.898909480668.issue4761@psf.upfronthosting.co.za>
Message-ID: <1295512687.53.0.377050611376.issue4761@psf.upfronthosting.co.za>


Ross Lagerwall <rosslagerwall at gmail.com> added the comment:

Fixed small #ifdef error with fstatat.

----------
Added file: http://bugs.python.org/file20460/i4761_v6.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4761>
_______________________________________

From report at bugs.python.org  Thu Jan 20 10:49:49 2011
From: report at bugs.python.org (Matt Joiner)
Date: Thu, 20 Jan 2011 09:49:49 +0000
Subject: [issue2987] RFC2732 support for urlparse (IPv6 addresses)
In-Reply-To: <1211920837.73.0.839643919886.issue2987@psf.upfronthosting.co.za>
Message-ID: <1295516989.34.0.41519527693.issue2987@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/issue2987>
_______________________________________

From report at bugs.python.org  Thu Jan 20 10:51:04 2011
From: report at bugs.python.org (Denis S. Otkidach)
Date: Thu, 20 Jan 2011 09:51:04 +0000
Subject: [issue10935] wsgiref.handlers.BaseHandler and subclasses of str
In-Reply-To: <1295371764.49.0.785710350986.issue10935@psf.upfronthosting.co.za>
Message-ID: <1295517064.24.0.161047745592.issue10935@psf.upfronthosting.co.za>


Denis S. Otkidach <denis.otkidach at gmail.com> added the comment:

Phillip, your argument about interfacing with code written in C doesn't work for built-in immutable types like str. Any subclass of str must call str.__new__ thus keeping proper internal state.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10935>
_______________________________________

From report at bugs.python.org  Thu Jan 20 11:32:28 2011
From: report at bugs.python.org (Lennart Regebro)
Date: Thu, 20 Jan 2011 10:32:28 +0000
Subject: [issue10954] No warning for csv.writer API change
In-Reply-To: <1295519548.77.0.698015070506.issue10954@psf.upfronthosting.co.za>
Message-ID: <1295519548.77.0.698015070506.issue10954@psf.upfronthosting.co.za>


New submission from Lennart Regebro <regebro at gmail.com>:

In Python 2 the file used for csv.writer() should be opened in binary mode, while in Python 3 is should be opened in text mode but with newlines set to ''.

This change is neither warned for by python -3, nor is there a fixer for it (and making a fixer would be tricky), thus it provides a surprising API change.

I think that csv.writer() should warn or even fail if the file is opened in binary mode under Python 3. Failing is a god option, as a binary file is likely to be a port from Python 2, and you are likely to get the less useful message "must be bytes or buffer, not str". Even if you understand that message, you will then probably just change the file mode from binary to text, but you will not add the lineendings='' parameter, and thusly you might cause subtle error on windows.

----------
components: 2to3 (2.x to 3.0 conversion tool), Library (Lib)
messages: 126596
nosy: lregebro
priority: normal
severity: normal
status: open
title: No warning for csv.writer API change
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/issue10954>
_______________________________________

From report at bugs.python.org  Thu Jan 20 12:07:24 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 20 Jan 2011 11:07:24 +0000
Subject: [issue10952] Don't normalize module names to NFKC?
In-Reply-To: <1295504345.52.0.340096637702.issue10952@psf.upfronthosting.co.za>
Message-ID: <1295521633.2016.80.camel@marge>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> b) what if the file system implementation mangles file names.
> 
> I'd use the same approach as with case-insensitive lookups: verify
> that the file we read is really the one we want.

Only Mac OS X and the HFS+ filesystem normalize filenames (to a variant
of NFD). But such normalization is a good thing! I mean that I don't
think that we have anything to do for that.

---
The user creates caf?.py file, name written with the keyboard in NFD:
cafe\u0301 (this is very unlikely, all operating systems prefer NFC for
the keyboard, but it's just to give an example). Mac OS X normalizes the
filename to NFD: cafe\u0301.py is created in the filesystem.

Then (s)he tries to import the caf? module: write "import caf?" with
his/her NFD keyboard. Python normalizes caf? to NFKC (caf\xe9) and then
tries to read caf\xe9.py. Mac OS X normalizes the filename to NFD: cafe
\u0301.py, and this file, so it works as expected.
---

I suppose that any filesystem normalization is good, because it avoids
surprising behaviours (eg. having two files cafe\u0301 and caf\xe9 with
names rendered exactly the same on screen). We should maybe patch
Windows, Mac OS, Linux & co to normalize to NFKC :-)

> a) how can users make sure that they name the files correctly?
>
>  For a), wrt. "I'm not able to write U+03BC with my keyboard", I say
> "tough luck - don't use that character in a module name, then".
> Somebody with a Greek keyboard will have no problems doing that. 

Even if I try to agree with "don't use that character in a module name":
it can be surprising for an English who would like to use ?Torrent (U
+00B5) module name in his/her project. She/He can creates ?Torrent.py
with his non-Greek keyboard (\xb5Torrent.py), but than import ?Torrent
(import \xb5Torrent) fails: "ImportError: No module named ?Torrent". The
error message is "ImportError: No module named \u03BCTorrent": the
identifier is normalized, but remember that ? (U+00B5) and ? (U+03BC)
are rendered exactly the same by most fonts.

We should at least document this surprising behaviour in the import
documentation. Something like:

<< WARNING: Non-ASCII characters in module names are normalized to NFKC
by the Python parser ([PEP 3131]). For example, import ?Torrent (?: U
+00B5) is normalized to import ?Torrent (?: U+03BC): Python will try to
open "\u03BCTorrent.py" (or "\u03BCTorrent/__init__.py"), and not
"\xB5Torrent.py" (or "\xB5Torrent/__init__.py"). >>

> This is really the same as any other non-ASCII character which you are
> unable to type: it just means that you can't conveniently enter the
> respective Python identifier. Just try importing "????", for example.
> Get a different keyboard.

I disagree. For identifiers in the source code, it works (transparently)
as expected.

A Greek starts a project using ?Torrent (\u03BCTorrent) identifier in
its source code (a variable name, not a module name). An English writes
a patch using ?Torrent written with \xB5Torrent: both forms are accepted
by Python, and it works.

"exec"))
it works

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10952>
_______________________________________

From report at bugs.python.org  Thu Jan 20 12:35:15 2011
From: report at bugs.python.org (Ross Lagerwall)
Date: Thu, 20 Jan 2011 11:35:15 +0000
Subject: [issue10812] Add some posix functions
In-Reply-To: <1294058752.01.0.285856626146.issue10812@psf.upfronthosting.co.za>
Message-ID: <1295523315.06.0.466185820526.issue10812@psf.upfronthosting.co.za>


Ross Lagerwall <rosslagerwall at gmail.com> added the comment:

A few small fixes for OS X:
It has no return value for sethostid() and sets different errno if permission denied,
waitid() is broken - so its disabled,
the timeval struct used in futimes and lutimes is defined slightly differently.

----------
Added file: http://bugs.python.org/file20461/10812_v6.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10812>
_______________________________________

From report at bugs.python.org  Thu Jan 20 13:05:00 2011
From: report at bugs.python.org (Lennart Regebro)
Date: Thu, 20 Jan 2011 12:05:00 +0000
Subject: [issue10954] No warning for csv.writer API change
In-Reply-To: <1295519548.77.0.698015070506.issue10954@psf.upfronthosting.co.za>
Message-ID: <1295525100.12.0.496993929873.issue10954@psf.upfronthosting.co.za>


Changes by Lennart Regebro <regebro at gmail.com>:


----------
nosy: +sjmachin

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10954>
_______________________________________

From report at bugs.python.org  Thu Jan 20 13:13:39 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 20 Jan 2011 12:13:39 +0000
Subject: [issue10923] Deadlock because of the import lock when loading the
	utf8 codec
In-Reply-To: <1295230653.16.0.00822246437847.issue10923@psf.upfronthosting.co.za>
Message-ID: <1295525619.69.0.608420528641.issue10923@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

> can't we raise a RuntimeError on a deadlock?

Deadlock detection is difficult, and probably impossible if the involved locks don't use the same underlying mechanism. (A lock can be a pthread object, a file opened with os.O_EXCL, and even a loop that tests some atomic variable)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10923>
_______________________________________

From report at bugs.python.org  Thu Jan 20 13:18:32 2011
From: report at bugs.python.org (John Machin)
Date: Thu, 20 Jan 2011 12:18:32 +0000
Subject: [issue10954] No warning for csv.writer API change
In-Reply-To: <1295519548.77.0.698015070506.issue10954@psf.upfronthosting.co.za>
Message-ID: <1295525912.6.0.0299367791467.issue10954@psf.upfronthosting.co.za>


John Machin <sjmachin at lexicon.net> added the comment:

I believe that both csv.reader and csv.writer should fail with a meaningful message if mode is binary or newline is not ''

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10954>
_______________________________________

From report at bugs.python.org  Thu Jan 20 13:35:06 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 20 Jan 2011 12:35:06 +0000
Subject: [issue10923] Deadlock because of the import lock when loading the
	utf8 codec
In-Reply-To: <1295230653.16.0.00822246437847.issue10923@psf.upfronthosting.co.za>
Message-ID: <1295526906.22.0.258909344564.issue10923@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> > can't we raise a RuntimeError on a deadlock?

(I mean: deadlock on the import lock)

> Deadlock detection is difficult, and probably impossible if the
> involved locks don't use the same underlying mechanism

If it is impossible to detect deadlocks, can't we raise an exception if two threads try to import a module at the same time? (change completly how the import "lock" is handled)

Antoine changed recently the io module to raise a RuntimeError on reentrant calls in the io module (io.Buffered*.*()): #10478.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10923>
_______________________________________

From report at bugs.python.org  Thu Jan 20 13:56:50 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 20 Jan 2011 12:56:50 +0000
Subject: [issue10451] memoryview can be used to write into readonly buffer
In-Reply-To: <1290064697.49.0.308725501485.issue10451@psf.upfronthosting.co.za>
Message-ID: <1295528210.53.0.37095470256.issue10451@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/issue10451>
_______________________________________

From report at bugs.python.org  Thu Jan 20 14:06:44 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 20 Jan 2011 13:06:44 +0000
Subject: [issue10952] Don't normalize module names to NFKC?
In-Reply-To: <1295488499.02.0.313090900295.issue10952@psf.upfronthosting.co.za>
Message-ID: <1295528804.55.0.872945297923.issue10952@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> There is also issue c) what if the filesystem encoding can only
> represent a compatibility character, say U+00B5, but not its NFKC
> equivalent, U+03BC?

It is the same problem than not being able to write U+03BC with a keyboard: in this setup, don't use U+00B5 or U+03BC. More generally: don't use non-ASCII characters if your setup is not fully Unicode compliant, or fix your setup :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10952>
_______________________________________

From report at bugs.python.org  Thu Jan 20 14:07:41 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 20 Jan 2011 13:07:41 +0000
Subject: [issue10923] Deadlock because of the import lock when loading the
	utf8 codec
In-Reply-To: <1295526906.22.0.258909344564.issue10923@psf.upfronthosting.co.za>
Message-ID: <1295528856.3705.13.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> If it is impossible to detect deadlocks, can't we raise an exception
> if two threads try to import a module at the same time? (change
> completly how the import "lock" is handled)
> 
> Antoine changed recently the io module to raise a RuntimeError on
> reentrant calls in the io module (io.Buffered*.*()): #10478.

Reentrant calls and concurrent calls are not the same. If the import
lock is changed to raise an exception, heaps of multi-threaded software
will be broken.

What we could do is set a timeout on the import lock, but then we need
to choose a rather large one (e.g. 5 minutes), and who will wait 5
minutes before killing the process?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10923>
_______________________________________

From report at bugs.python.org  Thu Jan 20 14:14:24 2011
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Thu, 20 Jan 2011 13:14:24 +0000
Subject: [issue10935] wsgiref.handlers.BaseHandler and subclasses of str
In-Reply-To: <1295371764.49.0.785710350986.issue10935@psf.upfronthosting.co.za>
Message-ID: <1295529264.67.0.533573923426.issue10935@psf.upfronthosting.co.za>


Jean-Paul Calderone <invalid at example.invalid> added the comment:

> Phillip, your argument about interfacing with code written in C doesn't work for built-in immutable types like str.

Sure it does.  Definitely-str is easier to handle in C than maybe-str-subclass.  It doesn't matter that str.__new__ gets called.  Other things might get called too, with who-knows-what side-effects.

wsgi is right to demand str and only str and exactly str.

----------
nosy: +exarkun

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10935>
_______________________________________

From report at bugs.python.org  Thu Jan 20 14:16:56 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 20 Jan 2011 13:16:56 +0000
Subject: [issue10935] wsgiref.handlers.BaseHandler and subclasses of str
In-Reply-To: <1295529264.67.0.533573923426.issue10935@psf.upfronthosting.co.za>
Message-ID: <1295529391.3705.15.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Jean-Paul Calderone <invalid at example.invalid> added the comment:
> 
> > Phillip, your argument about interfacing with code written in C
> doesn't work for built-in immutable types like str.
> 
> Sure it does.  Definitely-str is easier to handle in C than
> maybe-str-subclass.

Well, PyString_AsString() works on subclasses as well as on str itself.
I'm not sure what operations you're thinking about here.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10935>
_______________________________________

From report at bugs.python.org  Thu Jan 20 14:22:47 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 20 Jan 2011 13:22:47 +0000
Subject: [issue3080] Full unicode import system
In-Reply-To: <1213208697.49.0.984990811807.issue3080@psf.upfronthosting.co.za>
Message-ID: <1295529767.05.0.480399604068.issue3080@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Victor, could you please create a Reitveld review for this? The auto-review creator can't cope with the Git diffs.

----------
nosy: +ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3080>
_______________________________________

From report at bugs.python.org  Thu Jan 20 14:24:23 2011
From: report at bugs.python.org (Andrey Popp)
Date: Thu, 20 Jan 2011 13:24:23 +0000
Subject: [issue10935] wsgiref.handlers.BaseHandler and subclasses of str
In-Reply-To: <1295371764.49.0.785710350986.issue10935@psf.upfronthosting.co.za>
Message-ID: <1295529863.25.0.938052251183.issue10935@psf.upfronthosting.co.za>


Andrey Popp <8mayday at gmail.com> added the comment:

I've also sent message[1] to web-sig about this issue.

[1]: http://mail.python.org/pipermail/web-sig/2011-January/004986.html

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10935>
_______________________________________

From report at bugs.python.org  Thu Jan 20 14:24:31 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 20 Jan 2011 13:24:31 +0000
Subject: [issue3080] Full unicode import system
In-Reply-To: <1213208697.49.0.984990811807.issue3080@psf.upfronthosting.co.za>
Message-ID: <1295529871.45.0.168178020403.issue3080@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> Victor, could you please create a Reitveld review for this?

Yes, but not yet. I have first to cleanup the patch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3080>
_______________________________________

From report at bugs.python.org  Thu Jan 20 14:30:04 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 20 Jan 2011 13:30:04 +0000
Subject: [issue10923] Deadlock because of the import lock when loading the
	utf8 codec
In-Reply-To: <1295230653.16.0.00822246437847.issue10923@psf.upfronthosting.co.za>
Message-ID: <1295530204.55.0.882947664757.issue10923@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> If the import lock is changed to raise an exception, 
> heaps of multi-threaded software will be broken.

You are right. It has done so for 12 years already (10011), so it's a bit late to do anything about it. And backward compatibility is very important, so I close this issue.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10923>
_______________________________________

From report at bugs.python.org  Thu Jan 20 14:31:53 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 20 Jan 2011 13:31:53 +0000
Subject: [issue10923] Deadlock because of the import lock when loading the
	utf8 codec
In-Reply-To: <1295230653.16.0.00822246437847.issue10923@psf.upfronthosting.co.za>
Message-ID: <1295530313.04.0.621500360076.issue10923@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> for 12 years already (10011)

Oops, it's r10011 (to get a nice URL on the commit).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10923>
_______________________________________

From report at bugs.python.org  Thu Jan 20 14:34:34 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 20 Jan 2011 13:34:34 +0000
Subject: [issue10923] Deadlock because of the import lock when loading the
	utf8 codec
In-Reply-To: <1295230653.16.0.00822246437847.issue10923@psf.upfronthosting.co.za>
Message-ID: <1295530474.77.0.374907634879.issue10923@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

See also issue?#9260 for a possible improvment.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10923>
_______________________________________

From report at bugs.python.org  Thu Jan 20 14:35:21 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 20 Jan 2011 13:35:21 +0000
Subject: [issue3080] Full unicode import system
In-Reply-To: <1213208697.49.0.984990811807.issue3080@psf.upfronthosting.co.za>
Message-ID: <1295530521.77.0.582949501529.issue3080@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

OK - I'll wait until that is ready before digging into this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3080>
_______________________________________

From report at bugs.python.org  Thu Jan 20 14:46:11 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 20 Jan 2011 13:46:11 +0000
Subject: [issue9260] A finer grained import lock
In-Reply-To: <1279118663.3.0.514954672422.issue9260@psf.upfronthosting.co.za>
Message-ID: <1295531171.3.0.393774427937.issue9260@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/issue9260>
_______________________________________

From report at bugs.python.org  Thu Jan 20 14:52:14 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 20 Jan 2011 13:52:14 +0000
Subject: [issue3080] Full unicode import system
In-Reply-To: <1213208697.49.0.984990811807.issue3080@psf.upfronthosting.co.za>
Message-ID: <1295531534.54.0.609348665275.issue3080@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> Use "U" format to parse a module name, and "%R" to format a module name
> (to escape surrogates characters and add quotes, instead of 
> "... '%.200s' ...").

See also #8754: repr() is better than str() for other reasons, eg. to see a space at the end of a module name (__import__('space ')) thanks to the quotes.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3080>
_______________________________________

From report at bugs.python.org  Thu Jan 20 14:52:20 2011
From: report at bugs.python.org (Ronald Oussoren)
Date: Thu, 20 Jan 2011 13:52:20 +0000
Subject: [issue10955] Possible regression with stdlib in zipfile
In-Reply-To: <1295531540.01.0.823019908764.issue10955@psf.upfronthosting.co.za>
Message-ID: <1295531540.01.0.823019908764.issue10955@psf.upfronthosting.co.za>


New submission from Ronald Oussoren <ronaldoussoren at mac.com>:

I ran into this issue while debugging why py2app doesn't work with python 3.2rc2. The reason seems to be a regression w.r.t. having the stdlib inside a zipfile.

Note that I haven't tested this without going through py2app yet.

py2app basicly recreates a minimal sys.prefix that contains just the application python files and a minimal selection of files from the stdlib.

The file structure in the app bundle contains (for python3.2):

    .../Resources/
            lib/
               python32.zip   # Most compiled python files
               python3.2/     # Files that cannot be in the zip
                  lib-dynload # Extensions

This structure works fine with python2.7 (and earlier) and python3.1, with python 3.2rc2 I get a bootstrap error because the filesystem encoding codec cannot be located.

This can be worked around by moving the encodings package and the codecs module from the zipfile to the python3.2 directory. 

That however is not good enough, I also have to change the default search-path using Py_SetPath. The default path has python32.zip before the python3.2 directory, only when I switch those around the application loads fine.

All of this is on MacOSX 10.6.6 (where the filesystem encoding is UTF-8).

This is a regression because it is no longer possible to have a packaged python application where all python code is inside a zipfile. Some files must be outside of the file to bootstrap the interpreter.

----------
messages: 126614
nosy: ronaldoussoren
priority: normal
severity: normal
stage: unit test needed
status: open
title: Possible regression with stdlib in zipfile
type: behavior
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10955>
_______________________________________

From report at bugs.python.org  Thu Jan 20 14:54:32 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 20 Jan 2011 13:54:32 +0000
Subject: [issue10955] Possible regression with stdlib in zipfile
In-Reply-To: <1295531540.01.0.823019908764.issue10955@psf.upfronthosting.co.za>
Message-ID: <1295531672.65.0.305216028325.issue10955@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

It should be a regression introduced by?#8611 or #9425.

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10955>
_______________________________________

From report at bugs.python.org  Thu Jan 20 14:54:40 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 20 Jan 2011 13:54:40 +0000
Subject: [issue10955] Possible regression with stdlib in zipfile
In-Reply-To: <1295531540.01.0.823019908764.issue10955@psf.upfronthosting.co.za>
Message-ID: <1295531680.02.0.660299831475.issue10955@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
nosy: +georg.brandl
priority: normal -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10955>
_______________________________________

From report at bugs.python.org  Thu Jan 20 15:12:31 2011
From: report at bugs.python.org (Mark Florisson)
Date: Thu, 20 Jan 2011 14:12:31 +0000
Subject: [issue10956] file.write and file.read don't handle EINTR
In-Reply-To: <1295532751.32.0.53142512873.issue10956@psf.upfronthosting.co.za>
Message-ID: <1295532751.32.0.53142512873.issue10956@psf.upfronthosting.co.za>


New submission from Mark Florisson <markflorisson88 at gmail.com>:

In both Python versions EINTR is not handled properly in the file.write and file.read methods. 

------------------------- file.write -------------------------
In Python 2, file.write can write a short amount of
bytes, and when it is interrupted there is no way to tell how many bytes it
actually wrote. In Python 2 it raises an IOError with EINTR, whereas in Python 3 it
simply stops writing and returns the amount of bytes written.

Here is the output of fwrite with Python 2.7 (see attached files). Note also how inconsistent the IOError vs OSError difference is:

python2.7 fwrite.py
Writing 100000 bytes, interrupt me with SIGQUIT (^\)
^\^\(3, <frame object at 0x9535ab4>)
Traceback (most recent call last):
  File "fwrite.py", line 16, in <module>
    print(write_file.write(b'a' * 100000))
IOError: [Errno 4] Interrupted system call
read 65536 bytes
^\(3, <frame object at 0x9535ab4>)
Traceback (most recent call last):
  File "fwrite.py", line 21, in <module>
    print('read %d bytes' % len(os.read(r, 100000)))
OSError: [Errno 4] Interrupted system call

Because os.read blocks on the second call to read, we know that only 65536 of
the 100000 bytes were written.

------------------------- file.read -------------------------
When interrupting file.read in Python 3, it may have read bytes that are inaccessible. 
In Python 2 it returns the bytes, whereas in Python 3 it
raises an IOError with EINTR.

A demonstration:

$ python3.2 fread.py
Writing 7 bytes
Reading 20 bytes... interrupt me with SIGQUIT (^\)
^\(3, <frame object at 0x8e1d2d4>)
Traceback (most recent call last):
  File "fread.py", line 18, in <module>
    print('Read %d bytes using file.read' % len(read_file.read(20)))
IOError: [Errno 4] Interrupted system call
Reading any remaining bytes...
^\(3, <frame object at 0x8e1d2d4>)
Traceback (most recent call last):
  File "fread.py", line 23, in <module>
    print('reading: %r' % os.read(r, 4096))
OSError: [Errno 4] Interrupted system call

Note how in Python 2 it stops reading when interrupted and it returns our
bytes, but in Python 3 it raises IOError while there is no way to access the
bytes that it read.

So basically, this behaviour is just plain wrong as EINTR is not an error, and
this behaviour makes it impossible for the caller to handle the situation
correctly.

Here is how I think Python should behave. I think that it should be possible to 
interrupt both read and write calls, however, it should also be possible for the user to handle these cases. 

file.write, on EINTR, could decide to continue writing if no Python signal handler raised an exception.
Analogously, file.read could decide to keep on reading on EINTR if no Python signal handler raised an exception.

This way, it is possible for the programmer to write interruptable code while
at the same time having proper file.write and file.read behaviour in case code
should not be interrupted.
KeyboardInterrupt would still interrupt read and write calls, because it
raises an exception. If the programmer decided that writes should finish
before allowing such an exception, the programmer could replace the default
signal handler for SIGINT. 

So, in pseudo-code:
    
    bytes_written = 0

    while bytes_written < len(buf):
        result = write(buf)
        
        if result < 0:
            if errno == EINTR 
                if PyErr_CheckSignals() < 0:
                    /* Propagate exception from signal handler */
                    return NULL
                continue
            else:
                PyErr_SetFromErrno(PyExc_IOError)
                return NULL
        
        buf += result
        bytes_written += result

    return bytes_written

Similar code could be used for file.read with the obvious adjustments.

However, in case of an error (either from the write call or from a Python signal handler), 
it would still be unclear how many bytes were actually written. Maybe (I think
this part would be bonus points) we could put the number of bytes written on the exception object in this case, or make it retrievable in some other thread-safe way.

For files with file descriptors in nonblocking mode (and maybe other cases) it will still return a short amount of bytes.

----------
components: IO
files: fwrite.py
messages: 126616
nosy: eggy
priority: normal
severity: normal
status: open
title: file.write and file.read don't handle EINTR
type: behavior
versions: Python 2.5, Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file20462/fwrite.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10956>
_______________________________________

From report at bugs.python.org  Thu Jan 20 15:13:12 2011
From: report at bugs.python.org (Mark Florisson)
Date: Thu, 20 Jan 2011 14:13:12 +0000
Subject: [issue10956] file.write and file.read don't handle EINTR
In-Reply-To: <1295532751.32.0.53142512873.issue10956@psf.upfronthosting.co.za>
Message-ID: <1295532792.97.0.524322009451.issue10956@psf.upfronthosting.co.za>


Mark Florisson <markflorisson88 at gmail.com> added the comment:

Here is fread.py (why can you only attach one file at a time? :P)

----------
Added file: http://bugs.python.org/file20463/fread.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10956>
_______________________________________

From report at bugs.python.org  Thu Jan 20 15:30:07 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 20 Jan 2011 14:30:07 +0000
Subject: [issue10955] Possible regression with stdlib in zipfile
In-Reply-To: <1295531540.01.0.823019908764.issue10955@psf.upfronthosting.co.za>
Message-ID: <1295533807.91.0.981261875637.issue10955@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

zipimport decodes filenames of the archive from cp437 or UTF-8 (depending on a flag in each file entry). Python has a builtin UTF-8 codec, but no cp437 builtin codec. You should try to add encodings/cp437.py to your python3.2/ directory, or to build a ZIP archive with unicode filenames (I don't know how to do that).

Call trace:
 - Load the codec of the filesystem encoding
 - Initialize the codec registry
 - Load the codec from python32.zip
 - Load cp437 or UTF-8 codec to decode python32.zip filenames
 - *Bootstrap failure*

Detailed call trace to initialize the codec registry:
 - import encodings (Lib/encodings/__init__.py)
 - import codecs (Load Lib/codecs.py)
 - import encodings.aliases (Load Lib/encodings/aliases.py)

And then the call trace to load UTF-8 codec:
 - import encodings.utf_8 (Lib/encodings/utf_8.py)

Later, initstdio() loads also Latin1 codec (import encodings.latin_1, Lib/encodings/latin_1.py).

Python has builtin codecs for MBCS (filesystem encoding on Windows) and UTF-8 (filesystem encodings on Mac OS X and many other OSes) encodings, but the codec lookup loads the encodings module (encodings/xxx.py).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10955>
_______________________________________

From report at bugs.python.org  Thu Jan 20 15:31:07 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 20 Jan 2011 14:31:07 +0000
Subject: [issue10955] Possible regression with stdlib in zipfile
In-Reply-To: <1295531540.01.0.823019908764.issue10955@psf.upfronthosting.co.za>
Message-ID: <1295533867.86.0.577011459526.issue10955@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Restore priority to normal: this is a workaround, and a better fix cannot be done before 3.2 final.

----------
priority: release blocker -> normal

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10955>
_______________________________________

From report at bugs.python.org  Thu Jan 20 15:55:29 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 20 Jan 2011 14:55:29 +0000
Subject: [issue10956] file.write and file.read don't handle EINTR
In-Reply-To: <1295532751.32.0.53142512873.issue10956@psf.upfronthosting.co.za>
Message-ID: <1295535329.96.0.592324116683.issue10956@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

What behaviour would you expect instead?

----------
nosy: +pitrou
versions:  -Python 2.5, Python 2.6, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10956>
_______________________________________

From report at bugs.python.org  Thu Jan 20 15:57:00 2011
From: report at bugs.python.org (Mark Florisson)
Date: Thu, 20 Jan 2011 14:57:00 +0000
Subject: [issue10956] file.write and file.read don't handle EINTR
In-Reply-To: <1295532751.32.0.53142512873.issue10956@psf.upfronthosting.co.za>
Message-ID: <1295535420.44.0.0697813208013.issue10956@psf.upfronthosting.co.za>


Mark Florisson <markflorisson88 at gmail.com> added the comment:

I think this sums it up: 
file.write, on EINTR, could decide to continue writing if no Python signal handler raised an exception.
Analogously, file.read could decide to keep on reading on EINTR if no Python signal handler raised an exception.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10956>
_______________________________________

From report at bugs.python.org  Thu Jan 20 15:59:55 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 20 Jan 2011 14:59:55 +0000
Subject: [issue10956] file.write and file.read don't handle EINTR
In-Reply-To: <1295532751.32.0.53142512873.issue10956@psf.upfronthosting.co.za>
Message-ID: <1295535595.89.0.106370634135.issue10956@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Oops, sorry, had missed the relevant part in your original message.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10956>
_______________________________________

From report at bugs.python.org  Thu Jan 20 16:03:10 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 20 Jan 2011 15:03:10 +0000
Subject: [issue10956] file.write and file.read don't handle EINTR
In-Reply-To: <1295532751.32.0.53142512873.issue10956@psf.upfronthosting.co.za>
Message-ID: <1295535790.75.0.294653219276.issue10956@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> file.write, on EINTR, could decide to continue writing if no Python
> signal handler raised an exception.
> Analogously, file.read could decide to keep on reading on EINTR if no
> Python signal handler raised an exception.

Ok. This would only be done in buffered mode, though, so your fwrite.py example would have to be changed slightly (drop the ",0" in fdopen()).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10956>
_______________________________________

From report at bugs.python.org  Thu Jan 20 16:08:04 2011
From: report at bugs.python.org (Mark Florisson)
Date: Thu, 20 Jan 2011 15:08:04 +0000
Subject: [issue10956] file.write and file.read don't handle EINTR
In-Reply-To: <1295532751.32.0.53142512873.issue10956@psf.upfronthosting.co.za>
Message-ID: <1295536084.89.0.370809856024.issue10956@psf.upfronthosting.co.za>


Mark Florisson <markflorisson88 at gmail.com> added the comment:

> Ok. This would only be done in buffered mode, though, so your fwrite.py example would have to be changed slightly (drop the ",0" in fdopen()).

Indeed, good catch. So apparently file.write (in buffered mode) is also "incorrect" in Python 3.

----------
Added file: http://bugs.python.org/file20464/fwrite.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10956>
_______________________________________

From report at bugs.python.org  Thu Jan 20 16:44:44 2011
From: report at bugs.python.org (Diego Queiroz)
Date: Thu, 20 Jan 2011 15:44:44 +0000
Subject: [issue10948] Trouble with dir_util created dir cache
In-Reply-To: <1295456838.39.0.734609669589.issue10948@psf.upfronthosting.co.za>
Message-ID: <1295538284.83.0.627636765537.issue10948@psf.upfronthosting.co.za>


Diego Queiroz <queiroz.diego at gmail.com> added the comment:

"I would agree if mkpath were a public function."
So It is better to define what a "public function" is. Any function in any module of any project, if it is indented to be used by other modules, it is public by definition.

If new people get involved in distutils development they will need to read all the code, line by line and every comment, because the old developers decided not to document the inner workings of its functions.

"Considering that dir_util is gone in distutils2, I see no benefit in editing the doc."
Well, I know nothing about this. However, if you tell me that distutils2 will replace distutils, I may agree with you and distutils just needs to be deprecated. Otherwise, I keep my opinion.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10948>
_______________________________________

From report at bugs.python.org  Thu Jan 20 17:34:15 2011
From: report at bugs.python.org (Jerry Seutter)
Date: Thu, 20 Jan 2011 16:34:15 +0000
Subject: [issue10957] Python FAQ grammar error
In-Reply-To: <1295541255.37.0.868919325173.issue10957@psf.upfronthosting.co.za>
Message-ID: <1295541255.37.0.868919325173.issue10957@psf.upfronthosting.co.za>


New submission from Jerry Seutter <jseutter at gmail.com>:

Section 4.1 of the Python FAQ (http://www.python.org/dev/faq/) contains a grammar error:

The sentence I am referring to says: "If you are developing on OS X for Python 2.x and will not be working with the OS X-specific modules from the standard library, then consider using the --without-toolbox-glue flag to faster compilation time."

How about instead: "If you are developing on OS X for Python 2.x and will not be working with the OS X-specific modules from the standard library, then consider using the --without-toolbox-glue flag for a faster compile."

(Note: Taken from the FAQ as of Jan 20, 2011)

----------
assignee: docs at python
components: Documentation
keywords: easy
messages: 126626
nosy: docs at python, jerry.seutter
priority: normal
severity: normal
status: open
title: Python FAQ grammar error
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10957>
_______________________________________

From report at bugs.python.org  Thu Jan 20 17:53:07 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 20 Jan 2011 16:53:07 +0000
Subject: [issue10955] Possible regression with stdlib in zipfile
In-Reply-To: <1295531540.01.0.823019908764.issue10955@psf.upfronthosting.co.za>
Message-ID: <1295542387.74.0.73327642648.issue10955@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

The regression was introduced in r85690: use the correct encoding to decode the filename from the ZIP file. Attached patch fixes the bootstrap issue.

----------
keywords: +patch
Added file: http://bugs.python.org/file20465/issue10955.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10955>
_______________________________________

From report at bugs.python.org  Thu Jan 20 18:00:04 2011
From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=)
Date: Thu, 20 Jan 2011 17:00:04 +0000
Subject: [issue10958] stat.S_ISLNK() does not wok!
In-Reply-To: <1295542804.63.0.323986582337.issue10958@psf.upfronthosting.co.za>
Message-ID: <1295542804.63.0.323986582337.issue10958@psf.upfronthosting.co.za>


New submission from ???? ????????? <socketpair at gmail.com>:

ipython session:

In [48]: qwe=os.stat('/usr/lib/libstdc++.so.6')
In [49]: qwe.st_mode
Out[49]: 33188
In [50]: stat.S_ISLNK(qwe.st_mode)
Out[50]: False
In [51]: stat.S_IFLNK & qwe.st_mode
Out[51]: 32768

'/usr/lib/libstdc++.so.6' is really symlink !!!

python in ubuntu 10.10 and RHEL 6.0. All the same.

----------
components: Library (Lib)
messages: 126628
nosy: mmarkk
priority: normal
severity: normal
status: open
title: stat.S_ISLNK() does not wok!
type: behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10958>
_______________________________________

From report at bugs.python.org  Thu Jan 20 18:00:35 2011
From: report at bugs.python.org (Ross Lagerwall)
Date: Thu, 20 Jan 2011 17:00:35 +0000
Subject: [issue10959] mmap crash
In-Reply-To: <1295542835.78.0.12155244599.issue10959@psf.upfronthosting.co.za>
Message-ID: <1295542835.78.0.12155244599.issue10959@psf.upfronthosting.co.za>


New submission from Ross Lagerwall <rosslagerwall at gmail.com>:

The fix for issue10916 commited in r88022 introduces this line:

map_size = st.st_size - offset;

If offset > st.st_size, map_size is negative. This should cause the mmap system call to return -1 and set errno.

However, given a certain size of offset, since map_size is unsigned it will give a very large map_size and access the resultant mmap object results in a bus error crash. It also gives bogus len(mmap) values.

Eg (crashes on a 32bit system):
import os, mmap

with open("/tmp/rnd", "wb") as f:
    f.write(b"X" * 115699)

with open("/tmp/rnd", "w+b") as f:
    with mmap.mmap(f.fileno(), 0, offset=2147479552) as m:
        print(len(m))
        for i in m:
            print(m[i])

Attached is a patch which should fix this issue by raising a value error if offset > st.st_size.

----------
files: mmap_issue.patch
keywords: patch
messages: 126629
nosy: amaury.forgeotdarc, pitrou, rosslagerwall
priority: normal
severity: normal
status: open
title: mmap crash
type: crash
versions: Python 2.7, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file20466/mmap_issue.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10959>
_______________________________________

From report at bugs.python.org  Thu Jan 20 18:10:44 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 20 Jan 2011 17:10:44 +0000
Subject: [issue10958] stat.S_ISLNK() does not wok!
In-Reply-To: <1295542804.63.0.323986582337.issue10958@psf.upfronthosting.co.za>
Message-ID: <1295543444.1.0.195728855431.issue10958@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

os.stat() follows symbolic links. You probably want to use os.lstat() instead: http://docs.python.org/library/os.html#os.lstat

----------
nosy: +amaury.forgeotdarc
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10958>
_______________________________________

From report at bugs.python.org  Thu Jan 20 18:28:06 2011
From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=)
Date: Thu, 20 Jan 2011 17:28:06 +0000
Subject: [issue10960] os.stat() does not mention that it follow symlinks by
	default
In-Reply-To: <1295544486.66.0.118119387237.issue10960@psf.upfronthosting.co.za>
Message-ID: <1295544486.66.0.118119387237.issue10960@psf.upfronthosting.co.za>


New submission from ???? ????????? <socketpair at gmail.com>:

Documentation should say about 'following symlink' in this function. Documentation should advice to use os.lstat() in case when it needed.

----------
assignee: docs at python
components: Documentation
messages: 126631
nosy: docs at python, mmarkk
priority: normal
severity: normal
status: open
title: os.stat() does not mention that it follow symlinks by default
type: behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10960>
_______________________________________

From report at bugs.python.org  Thu Jan 20 18:47:48 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 20 Jan 2011 17:47:48 +0000
Subject: [issue10952] Don't normalize module names to NFKC?
In-Reply-To: <1295528804.55.0.872945297923.issue10952@psf.upfronthosting.co.za>
Message-ID: <AANLkTim0POiAYAH8e0gxTSqAmFuPNvhf7j8P2P3+dufm@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Thu, Jan 20, 2011 at 8:06 AM, STINNER Victor <report at bugs.python.org> wrote:
..
>> There is also issue c) what if the filesystem encoding can only
>> represent a compatibility character, say U+00B5, but not its NFKC
>> equivalent, U+03BC?
>
> It is the same problem than not being able to write U+03BC with a keyboard:

No.  This is a different problem and I agree with Martin that keyboard
limitations are not an issue.  With proper tools one can create
'\u03BCTorrent.py" file even if the keyboard does not have a '\u03BC'
key as long as the filesystem is capable of storing such file.  Python
itself is one such tool:

>>> with open('\u03BCTorrent.py'.encode(fsencoding), 'w') as f: ...

However, if fsencoding = 'latin-1', the code above will fail.

One possible solution to this problem is to define a 'compat' error
handler that would detect unencodable strings with encodable
compatibility equivalents and produce encoding of an NFKC equivalent
string instead of raising an error.  ISTM, that in the Latin-1
encoding, there are only five affected characters:

...     dec = decomposition(chr(i))
...     if dec and dec.startswith('<compat>'):
...        print("U+00%02X '%s' (%s): %s" %(i, chr(i), name(chr(i)), dec))
...
U+00A8 '?' (DIAERESIS): <compat> 0020 0308
U+00AF '?' (MACRON): <compat> 0020 0304
U+00B4 '?' (ACUTE ACCENT): <compat> 0020 0301
U+00B5 '?' (MICRO SIGN): <compat> 03BC
U+00B8 '?' (CEDILLA): <compat> 0020 0327

I suspect that the number of affected characters in the other
encodings is similarly small.  If we further limit special handling to
characters that are valid in identifiers, U+00B5 will end up being the
only such character in Latin-1.

An import mechanism using encode(fsencoding, 'compat') will, when
given either "import \u00B5Torrent" or  "import \u03BCTorrent" in
source file, open  "\u03BCTorrent.py" when fsencoding='utf-8'  and
"\u00B5Torrent.py" if fsencoding='latin-1'.   A packaging mechanism
that prepares code developed on a Latin-1 filesystem for distribution,
would have to NFKC-normalize filenames before encoding them using
UTF-8.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10952>
_______________________________________

From report at bugs.python.org  Thu Jan 20 18:48:58 2011
From: report at bugs.python.org (Ron Adam)
Date: Thu, 20 Jan 2011 17:48:58 +0000
Subject: [issue10961] Pydoc touchups in new browser for 3.2
In-Reply-To: <1295545738.06.0.604274599052.issue10961@psf.upfronthosting.co.za>
Message-ID: <1295545738.06.0.604274599052.issue10961@psf.upfronthosting.co.za>


New submission from Ron Adam <ron_adam at users.sourceforge.net>:

A collection of small fix's that only effect the new browser mode.

* Change title of html pages from "Python ..." to "PyDoc ...".
    
* Fixed unterminated div float for items returned without a header.
     example: str, None, True, False
    
* Added "topic?key=..." url command to explicitly get topics.  This is to avoid the shadowing when an object has the same name as a topic.

* Nicer parsing and error handling in the url handler.

----------
components: Library (Lib)
files: pydoc_misc_fix.diff
keywords: patch
messages: 126633
nosy: georg.brandl, ron_adam
priority: normal
severity: normal
status: open
title: Pydoc touchups in new browser for 3.2
type: behavior
versions: Python 3.2
Added file: http://bugs.python.org/file20467/pydoc_misc_fix.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10961>
_______________________________________

From report at bugs.python.org  Thu Jan 20 19:01:11 2011
From: report at bugs.python.org (Ron Adam)
Date: Thu, 20 Jan 2011 18:01:11 +0000
Subject: [issue10961] Pydoc touchups in new browser for 3.2
In-Reply-To: <1295545738.06.0.604274599052.issue10961@psf.upfronthosting.co.za>
Message-ID: <1295546471.99.0.281258909588.issue10961@psf.upfronthosting.co.za>


Ron Adam <ron_adam at users.sourceforge.net> added the comment:

new patch...

Adjusted a comment in the _gettopic method.

Everything else the same.

----------
Added file: http://bugs.python.org/file20468/pydoc_misc_fix.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10961>
_______________________________________

From report at bugs.python.org  Thu Jan 20 19:01:28 2011
From: report at bugs.python.org (Ron Adam)
Date: Thu, 20 Jan 2011 18:01:28 +0000
Subject: [issue10961] Pydoc touchups in new browser for 3.2
In-Reply-To: <1295545738.06.0.604274599052.issue10961@psf.upfronthosting.co.za>
Message-ID: <1295546488.3.0.619925358655.issue10961@psf.upfronthosting.co.za>


Changes by Ron Adam <ron_adam at users.sourceforge.net>:


Removed file: http://bugs.python.org/file20467/pydoc_misc_fix.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10961>
_______________________________________

From report at bugs.python.org  Thu Jan 20 19:15:38 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 20 Jan 2011 18:15:38 +0000
Subject: [issue10955] Possible regression with stdlib in zipfile
In-Reply-To: <1295531540.01.0.823019908764.issue10955@psf.upfronthosting.co.za>
Message-ID: <1295547338.27.0.21082027523.issue10955@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

About the patch: """Break out of this dependency by assuming that the path to the encodings module is ASCII-only."""

The 'path' here is the entry inside the zip file (and does not include the location of the zip file itself), so the comment is right as long as the Python stdlib only contains ascii names.

But if the zip file contains the stdlib *and* some other custom modules with cp437 names, the whole operation will fail; it can be the case with py2exe applications.

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10955>
_______________________________________

From report at bugs.python.org  Thu Jan 20 19:39:48 2011
From: report at bugs.python.org (Phillip J. Eby)
Date: Thu, 20 Jan 2011 18:39:48 +0000
Subject: [issue10935] wsgiref.handlers.BaseHandler and subclasses of str
In-Reply-To: <1295371764.49.0.785710350986.issue10935@psf.upfronthosting.co.za>
Message-ID: <1295548788.39.0.0946761340099.issue10935@psf.upfronthosting.co.za>


Phillip J. Eby <pje at telecommunity.com> added the comment:

PyString_AsString() only "works on subclasses" if their internal representation is the same as type str.  So we can't say "subclass of str" without *also* specifying that the subclass store its contents in exactly the same way as an object of type str...  which means all we've really done is to make the specification longer and more complicated.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10935>
_______________________________________

From report at bugs.python.org  Thu Jan 20 20:31:11 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 20 Jan 2011 19:31:11 +0000
Subject: [issue10935] wsgiref.handlers.BaseHandler and subclasses of str
In-Reply-To: <1295548788.39.0.0946761340099.issue10935@psf.upfronthosting.co.za>
Message-ID: <1295551853.3705.18.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> PyString_AsString() only "works on subclasses" if their internal
> representation is the same as type str.  So we can't say "subclass of
> str" without *also* specifying that the subclass store its contents in
> exactly the same way as an object of type str...

There's no point in subclassing str if you're using a different
representation. You're not only wasting space, but some things will
behave badly (precisely because of lot of C functions will call
PyString_Check() and then PyString_AsString()).
So, what you call a limitation isn't really one.

> which means all we've really done is to make the specification longer
> and more complicated

That doesn't follow from the above.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10935>
_______________________________________

From report at bugs.python.org  Thu Jan 20 21:03:20 2011
From: report at bugs.python.org (Ned Deily)
Date: Thu, 20 Jan 2011 20:03:20 +0000
Subject: [issue10812] Add some posix functions
In-Reply-To: <1294058752.01.0.285856626146.issue10812@psf.upfronthosting.co.za>
Message-ID: <1295553800.27.0.0915898419466.issue10812@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


----------
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10812>
_______________________________________

From report at bugs.python.org  Thu Jan 20 21:03:24 2011
From: report at bugs.python.org (Skip Montanaro)
Date: Thu, 20 Jan 2011 20:03:24 +0000
Subject: [issue10953] safely eval serialized dict/list data from arbitrary
	string over web with no side effects
In-Reply-To: <1295494175.9.0.514806108432.issue10953@psf.upfronthosting.co.za>
Message-ID: <1295553804.71.0.333840380161.issue10953@psf.upfronthosting.co.za>


Skip Montanaro <skip at pobox.com> added the comment:

If you intend this to be "safe" in the security sense of the word, I
suggest you release it in PyPI and post a note on comp.lang.python
(a.k.a. python-list at python.org) asking people to try and break it.

----------
nosy: +skip.montanaro

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10953>
_______________________________________

From report at bugs.python.org  Thu Jan 20 21:04:20 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 20 Jan 2011 20:04:20 +0000
Subject: [issue10962] gdb support broken
In-Reply-To: <1295553859.97.0.683428660139.issue10962@psf.upfronthosting.co.za>
Message-ID: <1295553859.97.0.683428660139.issue10962@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

This happens when I try to debug a Python process (py3k HEAD in pydebug mode):

Traceback (most recent call last):
  File "/home/antoine/py3k/__svn__/python-gdb.py", line 52, in <module>
    _type_size_t = gdb.lookup_type('size_t')
RuntimeError: No type named size_t.

----------
assignee: dmalcolm
components: Demos and Tools
messages: 126639
nosy: dmalcolm, georg.brandl, pitrou
priority: critical
severity: normal
status: open
title: gdb support broken
type: behavior
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10962>
_______________________________________

From report at bugs.python.org  Thu Jan 20 21:04:38 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 20 Jan 2011 20:04:38 +0000
Subject: [issue10962] gdb support broken
In-Reply-To: <1295553859.97.0.683428660139.issue10962@psf.upfronthosting.co.za>
Message-ID: <1295553878.61.0.862829947572.issue10962@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

$ gdb --version
GNU gdb (GDB) 7.1-1mdv2010.1 (Mandriva Linux release 2010.1)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10962>
_______________________________________

From report at bugs.python.org  Thu Jan 20 21:09:47 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 20 Jan 2011 20:09:47 +0000
Subject: [issue10962] gdb support broken
In-Reply-To: <1295553859.97.0.683428660139.issue10962@psf.upfronthosting.co.za>
Message-ID: <1295554187.54.0.102112100854.issue10962@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

And bizarrely, test_gdb runs fine.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10962>
_______________________________________

From report at bugs.python.org  Thu Jan 20 21:12:45 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 20 Jan 2011 20:12:45 +0000
Subject: [issue10962] gdb support broken
In-Reply-To: <1295553859.97.0.683428660139.issue10962@psf.upfronthosting.co.za>
Message-ID: <1295554365.83.0.153995984967.issue10962@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Er, for some reason it seems to have just stopped happening.

----------
resolution:  -> works for me
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10962>
_______________________________________

From report at bugs.python.org  Thu Jan 20 21:19:14 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 20 Jan 2011 20:19:14 +0000
Subject: [issue10962] gdb support broken
In-Reply-To: <1295553859.97.0.683428660139.issue10962@psf.upfronthosting.co.za>
Message-ID: <1295554754.93.0.294483703113.issue10962@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10962>
_______________________________________

From report at bugs.python.org  Thu Jan 20 21:23:34 2011
From: report at bugs.python.org (Dave Malcolm)
Date: Thu, 20 Jan 2011 20:23:34 +0000
Subject: [issue10963] "subprocess" can raise OSError (EPIPE) when
	communicating with short-lived processes
In-Reply-To: <1295555014.31.0.879687826689.issue10963@psf.upfronthosting.co.za>
Message-ID: <1295555014.31.0.879687826689.issue10963@psf.upfronthosting.co.za>


New submission from Dave Malcolm <dmalcolm at redhat.com>:

If we start a short-lived process which finishes before we begin communicating with it (e.g. by crashing), we can receive a SIGPIPE due to the receiving process no longer existing.  This becomes an EPIPE, which becomes an:
  OSError: [Errno 32] Broken pipe

Arguably this is a bug; if the subprocess could crash, the user currently has to check for it by both monitoring the returncode _and_ catching OSError (then examining for this specific errno), which seems ugly to me.

I'm attaching a patch for subprocess which handles this case, masking the OSError within the Popen implementation, so that you have to test for it within the returncode, in one place, rather than wrap every call with a try/except.

It could be argued that this is incorrect, as it masks under-reads of stdin by the subprocess.  However I believe a sanely-written subprocess ought to indicate success/failure back with its return code.

This was originally filed downstream within the Red Hat bugzilla instance as:
  https://bugzilla.redhat.com/show_bug.cgi?id=667431

The handler part of the patch is based on a patch attached there by Federico Simoncelli; I don't know if he has signed a PSF contributor agreement, however the size of the patch is sufficiently small that I suspect it's not copyrightable, and I've somewhat rewritten it since; I wrote the unit test.

----------
components: Library (Lib)
files: py3k-handle-EPIPE-for-short-lived-subprocesses-2011-01-20-001.patch
keywords: patch
messages: 126643
nosy: dmalcolm
priority: normal
severity: normal
stage: patch review
status: open
title: "subprocess" can raise OSError (EPIPE) when communicating with short-lived processes
versions: Python 3.3
Added file: http://bugs.python.org/file20469/py3k-handle-EPIPE-for-short-lived-subprocesses-2011-01-20-001.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10963>
_______________________________________

From report at bugs.python.org  Thu Jan 20 21:27:00 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 20 Jan 2011 20:27:00 +0000
Subject: [issue10963] "subprocess" can raise OSError (EPIPE) when
	communicating with short-lived processes
In-Reply-To: <1295555014.31.0.879687826689.issue10963@psf.upfronthosting.co.za>
Message-ID: <1295555220.1.0.737843737875.issue10963@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> It could be argued that this is incorrect, as it masks under-reads of
> stdin by the subprocess.  However I believe a sanely-written subprocess 
> ought to indicate success/failure back with its return code.

It seems quite orthogonal. The subprocess could have terminated successfully while not all of the stdin bytes were consumed; EPIPE informs you of the latter.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10963>
_______________________________________

From report at bugs.python.org  Thu Jan 20 21:27:11 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 20 Jan 2011 20:27:11 +0000
Subject: [issue10959] mmap crash
In-Reply-To: <1295542835.78.0.12155244599.issue10959@psf.upfronthosting.co.za>
Message-ID: <1295555231.49.0.878814526549.issue10959@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +georg.brandl
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10959>
_______________________________________

From report at bugs.python.org  Thu Jan 20 21:50:22 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 20 Jan 2011 20:50:22 +0000
Subject: [issue10959] mmap crash
In-Reply-To: <1295542835.78.0.12155244599.issue10959@psf.upfronthosting.co.za>
Message-ID: <1295556622.59.0.870247241882.issue10959@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Here is an updated patch which also caters to the Windows side of things.

----------
Added file: http://bugs.python.org/file20470/mmap_10959.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10959>
_______________________________________

From report at bugs.python.org  Thu Jan 20 22:00:19 2011
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 20 Jan 2011 21:00:19 +0000
Subject: [issue10845] test_multiprocessing failure under Windows
In-Reply-To: <1294309581.41.0.731804987161.issue10845@psf.upfronthosting.co.za>
Message-ID: <1295557219.05.0.0815644526462.issue10845@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
priority: normal -> critical

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10845>
_______________________________________

From report at bugs.python.org  Thu Jan 20 22:21:01 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 20 Jan 2011 21:21:01 +0000
Subject: [issue10959] mmap crash
In-Reply-To: <1295542835.78.0.12155244599.issue10959@psf.upfronthosting.co.za>
Message-ID: <1295558461.05.0.489027838271.issue10959@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Fixed in r88131 (3.2), r88132 (3.1) and r88133 (2.7). Thank you!

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10959>
_______________________________________

From report at bugs.python.org  Thu Jan 20 22:25:44 2011
From: report at bugs.python.org (Giampaolo Rodola')
Date: Thu, 20 Jan 2011 21:25:44 +0000
Subject: [issue4761] create Python wrappers for openat() and others
In-Reply-To: <1230476318.95.0.898909480668.issue4761@psf.upfronthosting.co.za>
Message-ID: <1295558744.14.0.82426520804.issue4761@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/issue4761>
_______________________________________

From report at bugs.python.org  Thu Jan 20 22:27:51 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 20 Jan 2011 21:27:51 +0000
Subject: [issue4819] Misc/cheatsheet needs updating
In-Reply-To: <1230988594.32.0.497089911482.issue4819@psf.upfronthosting.co.za>
Message-ID: <1295558871.45.0.593486822904.issue4819@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Misc/cheatsheet has been removed in r88127.  Should this be closed?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4819>
_______________________________________

From report at bugs.python.org  Thu Jan 20 22:29:07 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 20 Jan 2011 21:29:07 +0000
Subject: [issue4819] Misc/cheatsheet needs updating
In-Reply-To: <1230988594.32.0.497089911482.issue4819@psf.upfronthosting.co.za>
Message-ID: <1295558947.63.0.252619655866.issue4819@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Well, perhaps Marc-Andr? wants to revive it. Otherwise, suggest closing indeed.

----------
assignee: docs at python -> 
nosy: +lemburg
stage:  -> needs patch
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4819>
_______________________________________

From report at bugs.python.org  Thu Jan 20 22:37:10 2011
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Thu, 20 Jan 2011 21:37:10 +0000
Subject: [issue4819] Misc/cheatsheet needs updating
In-Reply-To: <1230988594.32.0.497089911482.issue4819@psf.upfronthosting.co.za>
Message-ID: <1295559430.64.0.123296456822.issue4819@psf.upfronthosting.co.za>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Updating the cheat sheet would be a great summer of code like project. We are considering using the cheat sheet as basis for a flyer in the PSF marketing material project.

Please add it back and add a note to it, that it currently is missing a few language features (e.g. add Alexanders list to it).

Thanks.

----------
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4819>
_______________________________________

From report at bugs.python.org  Thu Jan 20 22:43:03 2011
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 20 Jan 2011 21:43:03 +0000
Subject: [issue10238] ctypes not building under OS X 10.6 with LLVM/Clang 2.8
In-Reply-To: <1288391275.39.0.918201255477.issue10238@psf.upfronthosting.co.za>
Message-ID: <1295559783.7.0.144089557029.issue10238@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Filed a bug with LLVM/Clang: http://llvm.org/bugs/show_bug.cgi?id=9014

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10238>
_______________________________________

From report at bugs.python.org  Thu Jan 20 22:47:03 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 20 Jan 2011 21:47:03 +0000
Subject: [issue4819] Misc/cheatsheet needs updating
In-Reply-To: <1295559430.64.0.123296456822.issue4819@psf.upfronthosting.co.za>
Message-ID: <1295560009.3705.25.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Updating the cheat sheet would be a great summer of code like project.
> We are considering using the cheat sheet as basis for a flyer in the
> PSF marketing material project.

IMO it's not only about updating. It's about converting it to some
proper markup format, and being able to generate nicely laid out
versions of it. See examples of nice non-Python cheat sheets:
http://javascript-reference.info/
http://www.gscottolson.com/weblog/2008/01/11/jquery-cheat-sheet/

By the way the Python 3 transition means that it not only misses some
features, but probably has lots of bogus constructs and examples, so
putting it back as-is would do users a disservice.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4819>
_______________________________________

From report at bugs.python.org  Thu Jan 20 23:02:10 2011
From: report at bugs.python.org (anatoly techtonik)
Date: Thu, 20 Jan 2011 22:02:10 +0000
Subject: [issue10887] Add link to development ML
In-Reply-To: <1294745681.16.0.799239354624.issue10887@psf.upfronthosting.co.za>
Message-ID: <1295560930.9.0.783826185595.issue10887@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

Link on group description page to FOTP project site. I thought that https://bitbucket.org/tarek/distutils2/wiki/Home is that site.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10887>
_______________________________________

From report at bugs.python.org  Thu Jan 20 23:08:29 2011
From: report at bugs.python.org (anatoly techtonik)
Date: Thu, 20 Jan 2011 22:08:29 +0000
Subject: [issue10906] wsgiref should mention that CGI scripts usually expect
	HTTPS variable to be set to 'on'
In-Reply-To: <1295014476.87.0.519263477862.issue10906@psf.upfronthosting.co.za>
Message-ID: <1295561309.88.0.0259500667172.issue10906@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

The problem that most scripts check for 'on', and not for '1'.

http://www.cgi101.com/book/ch3/text.html

More than that - I don't know any servers that set this to '1', except mod_wsgi, and perhaps other implementations that follow this wsgiref. mod_wsgi even changes value of Apache2 environment to '1'

For existing CGI scripts (that rely on HTTPS parameter being 'on') and that are ported to WSGI, this creates additional issues with HTTPS, and wastes people time.

----------
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10906>
_______________________________________

From report at bugs.python.org  Thu Jan 20 23:10:48 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 20 Jan 2011 22:10:48 +0000
Subject: [issue10955] Possible regression with stdlib in zipfile
In-Reply-To: <1295547338.27.0.21082027523.issue10955@psf.upfronthosting.co.za>
Message-ID: <1295561440.29835.4.camel@marge>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Le jeudi 20 janvier 2011 ? 18:15 +0000, Amaury Forgeot d'Arc a ?crit :
> But if the zip file contains the stdlib *and* some other custom
> modules with cp437 names, the whole operation will fail; it can be the
> case with py2exe applications.

The ASCII fallback is only used before the codec registry is loaded. I
suppose that you can use non-ASCII module names in the same ZIP file: if
you load them after that the codec registry is ready, it should work.

I copied the fix from Objects/unicodeobject.c which has also a similar
bootstrap "hack" to encode/decode filenames.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10955>
_______________________________________

From report at bugs.python.org  Thu Jan 20 23:21:04 2011
From: report at bugs.python.org (Graham Dumpleton)
Date: Thu, 20 Jan 2011 22:21:04 +0000
Subject: [issue10906] wsgiref should mention that CGI scripts usually expect
	HTTPS variable to be set to 'on'
In-Reply-To: <1295014476.87.0.519263477862.issue10906@psf.upfronthosting.co.za>
Message-ID: <1295562064.68.0.847810528359.issue10906@psf.upfronthosting.co.za>


Graham Dumpleton <Graham.Dumpleton at gmail.com> added the comment:

As has been pointed out to you already in other forums, the correct way of detecting in a compliant WSGI application that a SSL connection was used is to check the value of the wsgi.url_scheme variable. If your code does not do this then it is not a compliant WSGI application and you have no guarantee that it will work portably across different WSGI hosting mechanisms. This is because a WSGI server/adapter is not obligated to set the HTTPS variable in the WSGI environment dictionary.

So, the correct thing to do, which for some reasons you don't want to, is to fix your code when it is being ported to adhere to the WSGI specification and what it dictates as the way of detecting a SSL connection.

FWIW, the HTTPS variable will no longer be set from mod_wsgi version 4.0 to enforce the point that it is not the correct way of detecting that an SSL connection and that wsgi.url_scheme should be used. The HTTPS variable was only being set at all and with that value because older versions of Django weren't doing what you also refuse to do, which is check for wsgi.url_scheme instead of the HTTPS variable. Django did the right thing and fixed their code to be compliant. Why you can't and want to keep arguing this point in three different forums is beyond me. You have spent way much more time arguing the point than it would take to fix your code to be compliant.

----------
nosy: +grahamd

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10906>
_______________________________________

From report at bugs.python.org  Thu Jan 20 23:23:22 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 20 Jan 2011 22:23:22 +0000
Subject: [issue10952] Don't normalize module names to NFKC?
In-Reply-To: <AANLkTim0POiAYAH8e0gxTSqAmFuPNvhf7j8P2P3+dufm@mail.gmail.com>
Message-ID: <1295562193.29835.15.camel@marge>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> A packaging mechanism that prepares code developed on a Latin-1
> filesystem for distribution, would have to NFKC-normalize 
> filenames before encoding them using UTF-8.

It causes portability issues: if you copy a non-ASCII module on a new
host, the program will work or not depending on the filesystem encoding.
Having to transform the filename when you copy a file, just to fix a
corner case, is a pain.

> One possible solution to this problem is to define a 'compat' error
> handler that would detect unencodable strings with encodable
> compatibility equivalents and produce encoding of an NFKC equivalent
> string instead of raising an error.

Only few people use non-ASCII module names and most operating systems
are able to store all Unicode characters, so I don't think that we need
to support U+00B5 in a module name with Latin1 filesystem at all. If you
use an old system using Latin1 filesystem, you have to limit your
expectation on Python unicode support :-)

os.fsencode() and os.fsdecode() already use a custom error handler:
surrogateescape. compat will conflict with surrogateescape. Loading a
module concatenates two parts: a path from sys.path (decoded from the
filesystem encoding and surrogateescape error handler) and a module
name. If custom is used to encode the filename, the module name will be
encoded correctly, but not the path.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10952>
_______________________________________

From report at bugs.python.org  Thu Jan 20 23:31:50 2011
From: report at bugs.python.org (Sam Bull)
Date: Thu, 20 Jan 2011 22:31:50 +0000
Subject: [issue8797] urllib2 basicauth broken in 2.6.5: RuntimeError: maximum
	recursion depth exceeded in cmp
In-Reply-To: <1274665334.09.0.561782804312.issue8797@psf.upfronthosting.co.za>
Message-ID: <1295562710.2.0.00463186153939.issue8797@psf.upfronthosting.co.za>


Sam Bull <sam at pocketuniverse.ca> added the comment:

I think there's a much simpler solution to this ticket than the retry logic that's currently in place.

The code originally avoided the infinite recursion by checking to see if the previous request had already submitted the auth credentials that would be used in the retry. If it had, it would return None. If it hadn't, it would add the auth credentials to the request header and the request again:

            if req.headers.get(self.auth_header, None) == auth:
                return None
            req.add_header(self.auth_header, auth)

Then, to fix #3819, it was changed. Instead of calling add_header, it called add_unredirected_header:

            if req.headers.get(self.auth_header, None) == auth:
                return None
            req.add_unredirected_header(self.auth_header, auth)

This caused the loop because the auth creds were going into unredirected_hdrs instead of the headers dict.

But I think the original logic is sound. The code just wasn't checking in all the headers. Luckily there's a get_header method that checks both for you. This one-line change should fix the issue:


            if req.get_header(self.auth_header, None) == auth:
                return None
            req.add_unredirected_header(self.auth_header, auth)

I think this fix is cleaner and makes more sense, but I'm worried I might be missing something. I don't fully understand the distinction between headers and unredirected headers. Maybe there's a reason why the code isn't checking in unredirected headers for the auth header.

I'm attaching a patch. I'm new to contributing to python so I apologize if the format is wrong.

----------
nosy: +sambull
versions: +Python 2.7
Added file: http://bugs.python.org/file20471/simpler_fix.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8797>
_______________________________________

From report at bugs.python.org  Thu Jan 20 23:39:21 2011
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 20 Jan 2011 22:39:21 +0000
Subject: [issue10238] ctypes not building under OS X 10.6 with LLVM/Clang 2.8
In-Reply-To: <1288391275.39.0.918201255477.issue10238@psf.upfronthosting.co.za>
Message-ID: <1295563161.55.0.0122347890903.issue10238@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Chris Lattner from LLVM says that this has been fixed in their mainline and that to work around it in LLVM 2.8 one should build with the -no-integrated-as flag.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10238>
_______________________________________

From report at bugs.python.org  Fri Jan 21 00:00:45 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 20 Jan 2011 23:00:45 +0000
Subject: [issue4819] Misc/cheatsheet needs updating
In-Reply-To: <1230988594.32.0.497089911482.issue4819@psf.upfronthosting.co.za>
Message-ID: <1295564445.08.0.827216744442.issue4819@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Perhaps the cheatsheet can be transferred to a wiki page and we can put out a comp.lang.python call for updates.

Also, +1 on the summer of code idea.

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4819>
_______________________________________

From report at bugs.python.org  Fri Jan 21 00:21:43 2011
From: report at bugs.python.org (anatoly techtonik)
Date: Thu, 20 Jan 2011 23:21:43 +0000
Subject: [issue3341] "Suggest a change" link
In-Reply-To: <1215774609.12.0.768814080421.issue3341@psf.upfronthosting.co.za>
Message-ID: <1295565703.57.0.481963688546.issue3341@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

Still actual, esp. with this - http://google-opensource.blogspot.com/2011/01/make-quick-fixes-quicker-on-google.html and this http://codemirror.net/

----------
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3341>
_______________________________________

From report at bugs.python.org  Fri Jan 21 00:30:33 2011
From: report at bugs.python.org (Russell Owen)
Date: Thu, 20 Jan 2011 23:30:33 +0000
Subject: [issue10964] Mac installer need not add things to /usr/local
In-Reply-To: <1295566233.42.0.612397787907.issue10964@psf.upfronthosting.co.za>
Message-ID: <1295566233.42.0.612397787907.issue10964@psf.upfronthosting.co.za>


New submission from Russell Owen <reowen at users.sourceforge.net>:

The Mac installer alters the user's $PATH to put /Library/Frameworks/Python.Framework/Versions/Current/bin on the $PATH before /usr/local/bin and /usr/bin. This is a good idea in my opinion.

But the installer *also* installs numerous symlinks in /usr/local/bin. These symlinks are redundant with altering the $PATH. Thus they are redundant. They are also make it difficult to switch versions of python because it's tricky to know which symlinks should be deleted (and the list may depend on the current version of python).

This is problem for me because I often have to switch versions of Python while building binary installers for packages such as matplotlib.

My request is for the Mac python installer to leave /usr/local/bin alone.

For if there is a need to add symlinks to /usr/local/bin that I'm not seeing then my request is for an easy way to switch versions of python or at least get rid of the symlinks, e.g. a python version switcher script or symlink deletion script.

----------
assignee: ronaldoussoren
components: Macintosh
messages: 126661
nosy: reowen, ronaldoussoren
priority: normal
severity: normal
status: open
title: Mac installer need not add things to /usr/local
type: feature request
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10964>
_______________________________________

From report at bugs.python.org  Fri Jan 21 00:33:43 2011
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 20 Jan 2011 23:33:43 +0000
Subject: [issue10965] dev task of documenting undocumented APIs
In-Reply-To: <1295566423.14.0.859020697485.issue10965@psf.upfronthosting.co.za>
Message-ID: <1295566423.14.0.859020697485.issue10965@psf.upfronthosting.co.za>


New submission from Brett Cannon <brett at python.org>:

Once the docs are built using Python 3, then the coverage results can be used by people wanting to contribute as something to do. Should also mention in the task that some APIs should probably be private: http://mail.python.org/pipermail/python-dev/2010-November/105476.html .

----------
assignee: brett.cannon
components: Documentation
messages: 126662
nosy: brett.cannon
priority: low
severity: normal
stage: needs patch
status: open
title: dev task of documenting undocumented APIs
type: feature request
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10965>
_______________________________________

From report at bugs.python.org  Fri Jan 21 00:34:37 2011
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 20 Jan 2011 23:34:37 +0000
Subject: [issue10965] dev task of documenting undocumented APIs
In-Reply-To: <1295566423.14.0.859020697485.issue10965@psf.upfronthosting.co.za>
Message-ID: <1295566477.31.0.903494641715.issue10965@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
dependencies: +Build 3.x documentation using python3.x

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10965>
_______________________________________

From report at bugs.python.org  Fri Jan 21 00:40:30 2011
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 20 Jan 2011 23:40:30 +0000
Subject: [issue10966] eliminate use of ImportError implicitly representing
	TestSkipped
In-Reply-To: <1295566830.75.0.786153857799.issue10966@psf.upfronthosting.co.za>
Message-ID: <1295566830.75.0.786153857799.issue10966@psf.upfronthosting.co.za>


New submission from Brett Cannon <brett at python.org>:

test.regrtest considers an ImportError to be a test to skip. It then uses this info to decide what skipped tests were expected (or not) based on a list kepted in regrtest.py.

For detecting compiler failures, an ImportError should be a test error or failure. Tests for optional modules should instead raise TestSkipped directly if an import fails. Something like test.support.optional_import() should be created which raises TestSkipped if the requested module could not be imported. It could also be made optional based on the OS (not sure if it should be inclusive, exclusive, or either). That way the list of expected skips in regrtest.py can be moved into the individual test modules where it belongs.

----------
components: Tests
messages: 126663
nosy: brett.cannon
priority: normal
severity: normal
stage: needs patch
status: open
title: eliminate use of ImportError implicitly representing TestSkipped
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10966>
_______________________________________

From report at bugs.python.org  Fri Jan 21 00:41:54 2011
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 20 Jan 2011 23:41:54 +0000
Subject: [issue10966] eliminate use of ImportError implicitly representing
	TestSkipped
In-Reply-To: <1295566830.75.0.786153857799.issue10966@psf.upfronthosting.co.za>
Message-ID: <1295566914.8.0.596311756971.issue10966@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Once the proper function in test.support comes about then a dev task to help move everything over can be created. And then once all needed test modules have been switched over the ImportError try/except statement in regrtest can be removed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10966>
_______________________________________

From report at bugs.python.org  Fri Jan 21 00:45:45 2011
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 20 Jan 2011 23:45:45 +0000
Subject: [issue10967] move regrtest over to using more unittest infrastructure
In-Reply-To: <1295567145.8.0.568957178125.issue10967@psf.upfronthosting.co.za>
Message-ID: <1295567145.8.0.568957178125.issue10967@psf.upfronthosting.co.za>


New submission from Brett Cannon <brett at python.org>:

test.regrtest is rather old and has not been updated to take advantage of all the latest features in unittest (e.g., test discovery). It might be a rather large undertaking with various bits requiring some changes (e.g., getting away from raising exceptions for skipped tests and instead using unittest.skipIf), but for maintainability it might be good to try to use as much unittest code in regrtest as possible.

----------
components: Tests
messages: 126665
nosy: brett.cannon
priority: low
severity: normal
stage: unit test needed
status: open
title: move regrtest over to using more unittest infrastructure
type: feature request
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10967>
_______________________________________

From report at bugs.python.org  Fri Jan 21 01:02:08 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Fri, 21 Jan 2011 00:02:08 +0000
Subject: [issue10952] Don't normalize module names to NFKC?
In-Reply-To: <AANLkTi=Q5ZK4iG2nMgic50fMLCqWDEiDVQgKTripr+bX@mail.gmail.com>
Message-ID: <4D38CCFA.9060903@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> There is also issue c) what if the filesystem encoding can only
> represent a compatibility character, say U+00B5, but not its NFKC
> equivalent, U+03BC?

That should be considered as similar to file systems that just cannot
represent certain characters at all - e.g. many of the non-ASCII
characters, or no upper-case letters. If you have such a file system,
you just cannot use these characters in a module name. Rename your
modules, then, or put the modules in a zipfile (or use some other
import hook).

> However, this code will always fail because '\xB5Torrent' will be
> normalized into '\u03BCTorrent' and a file named '\u03BCTorrent.py'
> cannot be created on a filesystem with Latin-1 encoding.

Tough luck. The filesystem just doesn't support GREEK SMALL LETTER MU,
just as it doesn't support all the other greek characters.

It may be fun coming up with these border cases. But I really don't
see a need to support them. If you really need to have that letter
in a module name, reformat your disk with a better file system.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10952>
_______________________________________

From report at bugs.python.org  Fri Jan 21 01:05:41 2011
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 21 Jan 2011 00:05:41 +0000
Subject: [issue10238] ctypes not building under OS X 10.6 with LLVM/Clang 2.8
In-Reply-To: <1288391275.39.0.918201255477.issue10238@psf.upfronthosting.co.za>
Message-ID: <1295568341.66.0.655412820348.issue10238@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

I have verified that if you add -no-integrated-as as a flag (e.g., through CFLAGS) then ctypes will build.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10238>
_______________________________________

From report at bugs.python.org  Fri Jan 21 01:06:31 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 21 Jan 2011 00:06:31 +0000
Subject: [issue10956] file.write and file.read don't handle EINTR
In-Reply-To: <1295532751.32.0.53142512873.issue10956@psf.upfronthosting.co.za>
Message-ID: <1295568391.63.0.682733967618.issue10956@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Here is a patch for Python 3.2+.

----------
keywords: +patch
nosy: +amaury.forgeotdarc
stage:  -> patch review
Added file: http://bugs.python.org/file20472/eintr_io.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10956>
_______________________________________

From report at bugs.python.org  Fri Jan 21 01:08:02 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Fri, 21 Jan 2011 00:08:02 +0000
Subject: [issue10952] Don't normalize module names to NFKC?
In-Reply-To: <1295521633.2016.80.camel@marge>
Message-ID: <4D38CE5D.20405@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> Only Mac OS X and the HFS+ filesystem normalize filenames (to a variant
> of NFD). But such normalization is a good thing! I mean that I don't
> think that we have anything to do for that.

That may well be - I don't have a case where this would cause problems,
either.

> We should at least document this surprising behaviour in the import
> documentation.

There are also are better ways to support the user than mere
documentation. For example,, the exception message could be more
helpful, and IDLE could warn the user when saving the file in the
first place.

> << WARNING: Non-ASCII characters in module names are normalized to NFKC
> by the Python parser ([PEP 3131]). For example, import ?Torrent (?: U
> +00B5) is normalized to import ?Torrent (?: U+03BC): Python will try to
> open "\u03BCTorrent.py" (or "\u03BCTorrent/__init__.py"), and not
> "\xB5Torrent.py" (or "\xB5Torrent/__init__.py"). >>

I can't believe this is a real problem. I'd defer warning about made-up
problems until real users report them as a real problem.

> I disagree.

If you disagree strongly, please write a PEP.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10952>
_______________________________________

From report at bugs.python.org  Fri Jan 21 01:38:38 2011
From: report at bugs.python.org (Ron Adam)
Date: Fri, 21 Jan 2011 00:38:38 +0000
Subject: [issue10961] Pydoc touchups in new browser for 3.2
In-Reply-To: <1295545738.06.0.604274599052.issue10961@psf.upfronthosting.co.za>
Message-ID: <1295570318.23.0.298328979651.issue10961@psf.upfronthosting.co.za>


Ron Adam <ron_adam at users.sourceforge.net> added the comment:

A few last minute changes.. I think this will be all.

Run topic contents through html.markup.  That makes ref:, pep:, and html: links if they exist.  (I meant to this earlier.)

Fix case where topic reference links are to objects rather than another topic.  (applies to keywords also.)

Skips making an empty reference section if there are no references with a topic.

These are all small changes, and nothing should be controversial in this as everything changed only effects the new html browser mode.

----------
Added file: http://bugs.python.org/file20473/pydoc_misc_fix_c.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10961>
_______________________________________

From report at bugs.python.org  Fri Jan 21 01:39:44 2011
From: report at bugs.python.org (Ron Adam)
Date: Fri, 21 Jan 2011 00:39:44 +0000
Subject: [issue10961] Pydoc touchups in new browser for 3.2
In-Reply-To: <1295545738.06.0.604274599052.issue10961@psf.upfronthosting.co.za>
Message-ID: <1295570384.26.0.444229264563.issue10961@psf.upfronthosting.co.za>


Changes by Ron Adam <ron_adam at users.sourceforge.net>:


Removed file: http://bugs.python.org/file20468/pydoc_misc_fix.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10961>
_______________________________________

From report at bugs.python.org  Fri Jan 21 01:44:17 2011
From: report at bugs.python.org (Ron Adam)
Date: Fri, 21 Jan 2011 00:44:17 +0000
Subject: [issue10961] Pydoc touchups in new browser for 3.2
In-Reply-To: <1295545738.06.0.604274599052.issue10961@psf.upfronthosting.co.za>
Message-ID: <1295570657.31.0.119720742276.issue10961@psf.upfronthosting.co.za>


Changes by Ron Adam <ron_adam at users.sourceforge.net>:


----------
nosy: +eric.araujo, rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10961>
_______________________________________

From report at bugs.python.org  Fri Jan 21 02:15:35 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 21 Jan 2011 01:15:35 +0000
Subject: [issue4819] Misc/cheatsheet needs updating
In-Reply-To: <1230988594.32.0.497089911482.issue4819@psf.upfronthosting.co.za>
Message-ID: <1295572535.45.0.0140187093103.issue4819@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

I agree that it would be nice to have a cheatsheet somewhere, possibly in the official doc and not as a plain txt file in Misc/.
FWIW another cheatsheet updated to 2.6 can be found here: http://rgruet.free.fr/PQR26/PQR2.6.html

----------
keywords: +gsoc
nosy: +ezio.melotti
type:  -> feature request

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4819>
_______________________________________

From report at bugs.python.org  Fri Jan 21 02:21:25 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 21 Jan 2011 01:21:25 +0000
Subject: [issue3080] Full unicode import system
In-Reply-To: <1213208697.49.0.984990811807.issue3080@psf.upfronthosting.co.za>
Message-ID: <1295572885.65.0.196151674291.issue3080@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Version 4 of the patch.

----------
Added file: http://bugs.python.org/file20474/issue3080-4.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3080>
_______________________________________

From report at bugs.python.org  Fri Jan 21 02:21:32 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 21 Jan 2011 01:21:32 +0000
Subject: [issue3080] Full unicode import system
In-Reply-To: <1213208697.49.0.984990811807.issue3080@psf.upfronthosting.co.za>
Message-ID: <1295572892.1.0.264234245101.issue3080@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Removed file: http://bugs.python.org/file20448/issue3080-3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3080>
_______________________________________

From report at bugs.python.org  Fri Jan 21 02:25:30 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 21 Jan 2011 01:25:30 +0000
Subject: [issue3080] Full unicode import system
In-Reply-To: <1213208697.49.0.984990811807.issue3080@psf.upfronthosting.co.za>
Message-ID: <1295573130.48.0.277145892361.issue3080@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Same patch (version 4) generated by svn.

----------
Added file: http://bugs.python.org/file20475/issue3080-4-svn.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3080>
_______________________________________

From report at bugs.python.org  Fri Jan 21 02:32:45 2011
From: report at bugs.python.org (Matt Joiner)
Date: Fri, 21 Jan 2011 01:32:45 +0000
Subject: [issue9723] pipes.quote() needs to be documented
In-Reply-To: <1283262014.72.0.527039259842.issue9723@psf.upfronthosting.co.za>
Message-ID: <1295573565.63.0.643471073151.issue9723@psf.upfronthosting.co.za>


Matt Joiner <anacrolix at gmail.com> added the comment:

I agree, I discovered this function (pipes.quote) only through recommendation here:

http://stackoverflow.com/questions/4748344/whats-the-reverse-of-shlex-split

I suggest that it be added to shlex, perhaps as shlex.quote. While the quoting style it performs, and the module it's found in are specific to Unix tools, the shlex module is available on non-Unix platforms. To this end, adding the function to shlex would make it available elsewhere, as well as be appropriately shell-related.

----------
nosy: +anacrolix

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9723>
_______________________________________

From report at bugs.python.org  Fri Jan 21 02:34:24 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 21 Jan 2011 01:34:24 +0000
Subject: [issue4819] Misc/cheatsheet needs updating
In-Reply-To: <1230988594.32.0.497089911482.issue4819@psf.upfronthosting.co.za>
Message-ID: <1295573664.21.0.895730755097.issue4819@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

FWIW, I updated the first couple of pages.  If anyone finds my changes useful, here they are in issue4819.diff.

----------
keywords: +patch
Added file: http://bugs.python.org/file20476/issue4819.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4819>
_______________________________________

From report at bugs.python.org  Fri Jan 21 02:37:14 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 21 Jan 2011 01:37:14 +0000
Subject: [issue3080] Full unicode import system
In-Reply-To: <1213208697.49.0.984990811807.issue3080@psf.upfronthosting.co.za>
Message-ID: <1295573834.58.0.255743017544.issue3080@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

You can review the patch with Rietveld:
http://codereview.appspot.com/3972045

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3080>
_______________________________________

From report at bugs.python.org  Fri Jan 21 02:44:59 2011
From: report at bugs.python.org (Benjamin VENELLE)
Date: Fri, 21 Jan 2011 01:44:59 +0000
Subject: [issue10968] Timer class inheritance issue
Message-ID: <1295574299.43.0.018764263809.issue10968@psf.upfronthosting.co.za>


Changes by Benjamin VENELLE <gu0sur20 at gmail.com>:


----------
assignee: collinwinter
components: Benchmarks
nosy: Kain94, collinwinter
priority: normal
severity: normal
status: open
title: Timer class inheritance issue
type: behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10968>
_______________________________________

From report at bugs.python.org  Fri Jan 21 02:48:21 2011
From: report at bugs.python.org (Benjamin VENELLE)
Date: Fri, 21 Jan 2011 01:48:21 +0000
Subject: [issue10968] Timer class inheritance issue
In-Reply-To: <1295574501.95.0.0935688829986.issue10968@psf.upfronthosting.co.za>
Message-ID: <1295574501.95.0.0935688829986.issue10968@psf.upfronthosting.co.za>


New submission from Benjamin VENELLE <gu0sur20 at gmail.com>:

Hi,

Due to Timer's object creation behavior, it is impossible to subclass it. This kind of declaration will result to an exception raising:

class A(Timer): pass

----------
components: +Library (Lib) -Benchmarks
versions: +Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10968>
_______________________________________

From report at bugs.python.org  Fri Jan 21 03:08:22 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 21 Jan 2011 02:08:22 +0000
Subject: [issue3080] Full unicode import system
In-Reply-To: <1213208697.49.0.984990811807.issue3080@psf.upfronthosting.co.za>
Message-ID: <1295575702.65.0.558339942422.issue3080@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Oops, there is a dummy typo in imp_init_builtin() that makes test_importlib to crash (which proves that importlib has a good coverage :-)): replace "s:" by "U:" in if (!PyArg_ParseTuple(args, "s:init_builtin", &name)).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3080>
_______________________________________

From report at bugs.python.org  Fri Jan 21 03:12:37 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 21 Jan 2011 02:12:37 +0000
Subject: [issue4819] Misc/cheatsheet needs updating
In-Reply-To: <1230988594.32.0.497089911482.issue4819@psf.upfronthosting.co.za>
Message-ID: <1295575957.51.0.733024471931.issue4819@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Past experience has shown that a cheatsheet in the main repository gets neglected.  How about we open it up via a wiki or somesuch so that the community if free to update it?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4819>
_______________________________________

From report at bugs.python.org  Fri Jan 21 03:13:45 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 21 Jan 2011 02:13:45 +0000
Subject: [issue3080] Full unicode import system
In-Reply-To: <1213208697.49.0.984990811807.issue3080@psf.upfronthosting.co.za>
Message-ID: <1295576025.96.0.420029004627.issue3080@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

test_reprlib fails on Windows, because '\' in quoted '\\' in the filename on repr(module). Workaround:

*******
index b0dc4d7..e476941 100644
--- a/Lib/test/test_reprlib.py
+++ b/Lib/test/test_reprlib.py
@@ -234,7 +234,7 @@ class LongReprTest(unittest.TestCase):
         touch(os.path.join(self.subpkgname, self.pkgname + '.py'))
         from areallylongpackageandmodulenametotestreprtruncation.areallylongpackageandmodulenametotestreprtruncation import areallylongpackageandmodulenametotestreprtruncation
         eq(repr(areallylongpackageandmodulenametotestreprtruncation),
-           "<module '%s' from '%s'>" % (areallylongpackageandmodulenametotestreprtruncation.__name__, areallylongpackageandmodulenametotestreprtruncation.__file__))
+           "<module %r from %r>" % (areallylongpackageandmodulenametotestreprtruncation.__name__, areallylongpackageandmodulenametotestreprtruncation.__file__))
         eq(repr(sys), "<module 'sys' (built-in)>")
 
     def test_type(self):
*******

It is maybe not a good idea to use %R to format the filename in module.__repr__().

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3080>
_______________________________________

From report at bugs.python.org  Fri Jan 21 03:18:04 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 21 Jan 2011 02:18:04 +0000
Subject: [issue3080] Full unicode import system
In-Reply-To: <1213208697.49.0.984990811807.issue3080@psf.upfronthosting.co.za>
Message-ID: <1295576284.2.0.837828307805.issue3080@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

test_runpy fails on Windows on make_legacy_pyc() (of test.support), I don't know why.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3080>
_______________________________________

From report at bugs.python.org  Fri Jan 21 03:26:36 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 21 Jan 2011 02:26:36 +0000
Subject: [issue4819] Misc/cheatsheet needs updating
In-Reply-To: <1230988594.32.0.497089911482.issue4819@psf.upfronthosting.co.za>
Message-ID: <1295576796.27.0.342788103761.issue4819@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Leaving it in the wiki for a while so that the community can update and improve it might be a good idea, but ultimately I think it should go in the doc.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4819>
_______________________________________

From report at bugs.python.org  Fri Jan 21 03:28:31 2011
From: report at bugs.python.org (Zac Medico)
Date: Fri, 21 Jan 2011 02:28:31 +0000
Subject: [issue5380] pty.read raises IOError when slave pty device is closed
In-Reply-To: <1235721814.23.0.522352333065.issue5380@psf.upfronthosting.co.za>
Message-ID: <1295576911.53.0.375988343922.issue5380@psf.upfronthosting.co.za>


Zac Medico <zmedico at gentoo.org> added the comment:

This issue no longer appears to be a problem for my purposes, since it seems that array.fromfile() does not lose any data as long as the input file is opened in unbuffered mode (I use fdopen with 0 for the bufsize argument).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5380>
_______________________________________

From report at bugs.python.org  Fri Jan 21 03:28:51 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 21 Jan 2011 02:28:51 +0000
Subject: [issue10968] Timer class inheritance issue
In-Reply-To: <1295574501.95.0.0935688829986.issue10968@psf.upfronthosting.co.za>
Message-ID: <1295576931.6.0.107343321249.issue10968@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Works for me:

>>> from timeit import Timer
>>> class A(Timer): pass
... 

(Tested with Python 3.1 and 3.2 on OSX.)

----------
nosy: +belopolsky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10968>
_______________________________________

From report at bugs.python.org  Fri Jan 21 03:58:01 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 21 Jan 2011 02:58:01 +0000
Subject: [issue10936] Simple CSS fix for left margin at docs.python.org
In-Reply-To: <1295377924.0.0.902429691003.issue10936@psf.upfronthosting.co.za>
Message-ID: <1295578681.83.0.748624907845.issue10936@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

If the width is specified with a percentage, a min-width should be specified too.
In the py3k doc the sidebar can be collapsed though, so I'm not sure it's worth changing this. Georg?

----------
keywords: +easy
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10936>
_______________________________________

From report at bugs.python.org  Fri Jan 21 04:07:57 2011
From: report at bugs.python.org (Christoph Gohlke)
Date: Fri, 21 Jan 2011 03:07:57 +0000
Subject: [issue8275] callback function on win64 results in bad behavior. mem
	corruption?
In-Reply-To: <1270061625.47.0.601780173179.issue8275@psf.upfronthosting.co.za>
Message-ID: <1295579277.04.0.642312083371.issue8275@psf.upfronthosting.co.za>


Changes by Christoph Gohlke <cgohlke at uci.edu>:


----------
nosy: +cgohlke

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8275>
_______________________________________

From report at bugs.python.org  Fri Jan 21 04:08:50 2011
From: report at bugs.python.org (R. David Murray)
Date: Fri, 21 Jan 2011 03:08:50 +0000
Subject: [issue10947] imaplib: Internaldate2tuple and ParseFlags require (and
	latter returns) bytes arrays; should allow/return str
In-Reply-To: <1295451332.43.0.977417439806.issue10947@psf.upfronthosting.co.za>
Message-ID: <1295579330.73.0.262015665188.issue10947@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I think the module should be reviewed and made consistent, as Antoine did for nntplib.  I don't know enough about the IMAP protocol to do such a review, or even weigh in meaningfully on the immediate question, nor am I likely to have time to learn enough before 3.2, even assuming we wanted to make such changes at this point in the release cycle.  Putting changes off to 3.3 makes backward compatibility more important, so we may wind up stuck with warts.

Yes a function that returns a datetime would probably make sense.  That would be one way to clear up the warts: introduce a new function and deprecate the old.

A relatively uniformed opinion: it sounds like Internaldate2tuple should take bytes (since it sounds like Internaldate is most likely to be manipulated as a wire-protocol level object), and that Time2Internaldate should correspondingly return bytes(*).  What ParseFlags should return I couldn't guess without learning how the returned result is used in a typical program.

(*) The asymetry in the names of these two functions is already a wart.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10947>
_______________________________________

From report at bugs.python.org  Fri Jan 21 04:21:09 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 21 Jan 2011 03:21:09 +0000
Subject: [issue10947] imaplib: Internaldate2tuple and ParseFlags require (and
	latter returns) bytes arrays; should allow/return str
In-Reply-To: <1295579330.73.0.262015665188.issue10947@psf.upfronthosting.co.za>
Message-ID: <AANLkTinxsp3TVnuJnR0sK9MUaBCb=vdsfvYvCGahPTKJ@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Thu, Jan 20, 2011 at 10:08 PM, R. David Murray
<report at bugs.python.org> wrote:
..
> (*) The asymetry in the names of these two functions is already a wart.

Not to mention the use of CamelCase.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10947>
_______________________________________

From report at bugs.python.org  Fri Jan 21 04:47:32 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 21 Jan 2011 03:47:32 +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: <1295581652.3.0.230339429083.issue9196@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Python 3 checks the return types of __bytes__ and __str__, raising an error if it's not bytes and str respectively:
>>> str(C())
TypeError: __str__ returned non-string (type bytes)
>>> bytes(C())
TypeError: __bytes__ returned non-bytes (type str)

The Python 2 doc for unicode() says[0]:
"""
For objects which provide a __unicode__() method, it will call this method without arguments to create a Unicode string. For all other objects, the 8-bit string version or representation is requested and then converted to a Unicode string using the codec for the default encoding in 'strict' mode.
"""

The doc for .__unicode__() says[1]:
"""
Called to implement unicode() built-in; should return a Unicode object. When this method is not defined, string conversion is attempted, and the result of string conversion is converted to Unicode using the system default encoding.
"""
This is consistent with unicode() doc (but it doesn't mention that 'strict' is used).  It also says that the method *should* return unicode, but it can also returns a str that gets coerced by unicode().

The doc for .__str__() says[2]:
"""
Called by the str() built-in function and by the print statement to compute the ?informal? string representation of an object. [...] The return value must be a string object.
"""
This is wrong because the return value can be unicode too (this has been changed at some point, it used to be true on older versions).

That said, some of the behaviors described by Craig (e.g. __str__ that returns unicode) are not documented and documenting them might save some confusion. However these "weird" behaviors are most likely errors and the fact that there are no exception is just because Python 2 is not strict with str/unicode.

I think a better way to solve the problem is to document clearly how these methods should be used (i.e. if __unicode__ should be preferred over __str__, if it's necessary to implement both, what they should return, etc.).

[0]: http://docs.python.org/library/functions.html#unicode
[1]: http://docs.python.org/reference/datamodel.html#object.__unicode__
[2]: http://docs.python.org/reference/datamodel.html#object.__str__

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9196>
_______________________________________

From report at bugs.python.org  Fri Jan 21 04:55:19 2011
From: report at bugs.python.org (Christoph Gohlke)
Date: Fri, 21 Jan 2011 03:55:19 +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: <1295582119.16.0.927371083524.issue10854@psf.upfronthosting.co.za>


Changes by Christoph Gohlke <cgohlke at uci.edu>:


----------
nosy: +cgohlke

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10854>
_______________________________________

From report at bugs.python.org  Fri Jan 21 05:00:33 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 21 Jan 2011 04:00:33 +0000
Subject: [issue10573] Consistency in unittest assert methods: order of actual, 
	expected
In-Reply-To: <1290992159.72.0.107137027413.issue10573@psf.upfronthosting.co.za>
Message-ID: <1295582433.97.0.68829240021.issue10573@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Not all the arg names in the doc match with the actual name of the args (probably because the methods are expected to be used with positional args only), that's why the changes affects only the doc.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10573>
_______________________________________

From report at bugs.python.org  Fri Jan 21 05:03:37 2011
From: report at bugs.python.org (Fred L. Drake, Jr.)
Date: Fri, 21 Jan 2011 04:03:37 +0000
Subject: [issue10936] Simple CSS fix for left margin at docs.python.org
In-Reply-To: <1295578681.83.0.748624907845.issue10936@psf.upfronthosting.co.za>
Message-ID: <AANLkTimQDpBf3BxXXuKwGxmNLnTaow_=BY4OCPX3FF7j@mail.gmail.com>


Fred L. Drake, Jr. <fdrake at acm.org> added the comment:

As Ezio noted, the coming versions of the Python 3 documentation
provide a way to collapse the sidebar completely.  Perhaps a min-width
should be specified, but I'm not convinced that's a good idea.

The sidebar problem is fairly significant, and the collapsing sidebar
alone isn't sufficient.  The sidebar is useful since it's the only
overall navigation structure (as opposed to the direct links embedded
in the content), but there's no real need to ensure it gets "enough"
width.  I'd rather see a simple adjustment as recommended by
Christopher Dunn.

I appreciate Ezio's in making the sidebar collapsible, but I think
that's just the first step.  The sidebar is certainly the most
contentious element of the new design, and the most difficult to get
right.

----------
nosy: +fdrake

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10936>
_______________________________________

From report at bugs.python.org  Fri Jan 21 05:18:35 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 21 Jan 2011 04:18:35 +0000
Subject: [issue10936] Simple CSS fix for left margin at docs.python.org
In-Reply-To: <1295377924.0.0.902429691003.issue10936@psf.upfronthosting.co.za>
Message-ID: <1295583515.01.0.722282435317.issue10936@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

The min-width is necessary in case the CSS is changed to resize the sidebar dynamically. If it gets too narrow it would start getting unusable and the text will start overflowing.

Possible alternatives are:
1) use a percentage and min-width;
2) like 1) but also collapse the sidebar automatically when its width gets smaller than the min-width;
3) leave a fixed width but make the sidebar mouse-resizable (that will conflict with the collapsibility though and is less trivial to do);

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10936>
_______________________________________

From report at bugs.python.org  Fri Jan 21 05:45:40 2011
From: report at bugs.python.org (Fred L. Drake, Jr.)
Date: Fri, 21 Jan 2011 04:45:40 +0000
Subject: [issue10936] Simple CSS fix for left margin at docs.python.org
In-Reply-To: <1295583515.01.0.722282435317.issue10936@psf.upfronthosting.co.za>
Message-ID: <AANLkTim1Gv4=rK_xJwu65pitdmn0mRYshTCGoLobvLtu@mail.gmail.com>


Fred L. Drake, Jr. <fdrake at acm.org> added the comment:

On Thu, Jan 20, 2011 at 11:18 PM, Ezio Melotti <report at bugs.python.org> wrote:
> If it gets too narrow it would start getting unusable and the text will start overflowing.

If someone is zooming that much, it's because they really need the
size of the text more than anything (trust me; I've tried to work
while my eyes were dilated; size is *everything* at that point).  The
worst thing to do in such situations is to get in the way of the
browser's normal behavior.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10936>
_______________________________________

From report at bugs.python.org  Fri Jan 21 06:11:23 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 21 Jan 2011 05:11:23 +0000
Subject: [issue10936] Simple CSS fix for left margin at docs.python.org
In-Reply-To: <1295377924.0.0.902429691003.issue10936@psf.upfronthosting.co.za>
Message-ID: <1295586683.36.0.220929359845.issue10936@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

I did some tests using 20% instead of 230px and found the following problems:
1) while zooming, even if the width of the sidebar doesn't change, the font size does, overflowing from the sidebar;
2) min-width can't be used because the width of the sidebar is given by the margin-left of the bodywrapper, and there's no min-margin-left property that can be used instead;

The font size can probably be changed to fit the width of the sidebar, but the min-width problem remains (I'm thinking about small screens -- e.g. smartphones -- where the sidebar would end up having a width of ~130-160px (I haven't (yet) tested it there though)).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10936>
_______________________________________

From report at bugs.python.org  Fri Jan 21 06:22:16 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 21 Jan 2011 05:22:16 +0000
Subject: [issue10775] assertRaises as a context manager should accept a 'msg'
	keyword argument.
In-Reply-To: <1293391143.22.0.15906903458.issue10775@psf.upfronthosting.co.za>
Message-ID: <1295587336.3.0.710143472788.issue10775@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/issue10775>
_______________________________________

From report at bugs.python.org  Fri Jan 21 06:23:32 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 21 Jan 2011 05:23:32 +0000
Subject: [issue10675] unittest should have an assertChanges context manager
In-Reply-To: <1292011116.36.0.95630190465.issue10675@psf.upfronthosting.co.za>
Message-ID: <1295587412.59.0.305559720312.issue10675@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
components: +Tests
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10675>
_______________________________________

From report at bugs.python.org  Fri Jan 21 06:28:19 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 21 Jan 2011 05:28:19 +0000
Subject: [issue10969] Make Tcl recommendation more prominent
In-Reply-To: <1295587699.83.0.103417791423.issue10969@psf.upfronthosting.co.za>
Message-ID: <1295587699.83.0.103417791423.issue10969@psf.upfronthosting.co.za>


New submission from Raymond Hettinger <rhettinger at users.sourceforge.net>:

On the releases page at http://www.python.org/download/releases/3.2/ the  note about Tcl needs to be made more prominent for the 32/64 bit Mac OS installer.  Right now, it's buried in another page referenced in a footnote at the bottom of the release.  I think it is too easy to miss and it is essential for users if they want IDLE or tkinter to work.

Recommend adding a link immediately below the 64-bit installer.  See below:




-------------------------------------------------

We currently support these formats for download:

Bzipped source tar ball (3.2rc1) (sig), ~ 11 MB
XZ compressed source tar ball (3.2rc1) (sig), ~ 8.5 MB
Gzipped source tar ball (3.2rc1) (sig), ~ 13 MB
Windows x86 MSI Installer (3.2rc1) (sig) and Visual Studio debug information files (sig)
Windows X86-64 MSI Installer (3.2rc1) [1] (sig) and Visual Studio debug information files (sig)
Mac OS X 32-bit i386/PPC Installer (3.2rc1) for OS X 10.3 through 10.6 [2] (sig)
Mac OS X 64-bit/32-bit Installer (3.2rc1) for Mac OS X 10.6 [2] (sig)
 (needs ActiveState Tcl 8.5.9 to run IDLE or use Tkinter).

----------
assignee: georg.brandl
components: Installation
messages: 126694
nosy: georg.brandl, rhettinger
priority: normal
severity: normal
status: open
title: Make Tcl recommendation more prominent
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10969>
_______________________________________

From report at bugs.python.org  Fri Jan 21 07:10:34 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Fri, 21 Jan 2011 06:10:34 +0000
Subject: [issue10967] move regrtest over to using more unittest infrastructure
In-Reply-To: <1295567145.8.0.568957178125.issue10967@psf.upfronthosting.co.za>
Message-ID: <1295590234.57.0.625286124499.issue10967@psf.upfronthosting.co.za>


Changes by Sandro Tosi <sandro.tosi at gmail.com>:


----------
nosy: +sandro.tosi

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10967>
_______________________________________

From report at bugs.python.org  Fri Jan 21 07:14:21 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 21 Jan 2011 06:14:21 +0000
Subject: [issue3080] Full unicode import system
In-Reply-To: <1213208697.49.0.984990811807.issue3080@psf.upfronthosting.co.za>
Message-ID: <1295590461.43.0.26786896095.issue3080@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

After applying the patch, doing a make clean and rebuild, I found that test_importlib fails with a segmentation fault, but the default test suite otherwise runs without error (that's on Linux with a UTF-8 filesystem, though).

I'll see how a -uall run fares.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3080>
_______________________________________

From report at bugs.python.org  Fri Jan 21 07:25:16 2011
From: report at bugs.python.org (Mahmoud Abdelkader)
Date: Fri, 21 Jan 2011 06:25:16 +0000
Subject: [issue10970] "string".encode('base64') is not the same as
	base64.b64encode("string")
In-Reply-To: <1295591116.22.0.262504941667.issue10970@psf.upfronthosting.co.za>
Message-ID: <1295591116.22.0.262504941667.issue10970@psf.upfronthosting.co.za>


New submission from Mahmoud Abdelkader <mabdelkader at gmail.com>:

Given a string, encoding it with .encode('base64') is not the same as using base64's b64encode function. I think this is very unclear and unintuitive. 

Here's some example code to demonstrate the problem. Before I attempt to submit a patch, is this done for legacy reasons? Are there any reasons to use one over the other?

import hmac
import hashlib
import base64


signature = hmac.new('secret', 'url', hashlib.sha512).digest()
assert signature.encode('base64') == base64.b64encode(signature)

----------
components: Library (Lib)
messages: 126696
nosy: mahmoudimus
priority: normal
severity: normal
status: open
title: "string".encode('base64') is not the same as base64.b64encode("string")
versions: Python 2.5, Python 2.6, Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10970>
_______________________________________

From report at bugs.python.org  Fri Jan 21 07:32:24 2011
From: report at bugs.python.org (Joe Peterson)
Date: Fri, 21 Jan 2011 06:32:24 +0000
Subject: [issue10947] imaplib: Internaldate2tuple and ParseFlags require (and
	latter returns) bytes arrays; should allow/return str
In-Reply-To: <1295451332.43.0.977417439806.issue10947@psf.upfronthosting.co.za>
Message-ID: <1295591544.41.0.221722239607.issue10947@psf.upfronthosting.co.za>


Joe Peterson <joe at skyrush.com> added the comment:

These are all good comments.  And I agree that the naming of the functions is not good (and the CamelCase).

Overall, yes, it should be made consistent and the types returned and passed in should be appropriate.  I did a little experimenting, using more imaplib functions in Python3, and I found the following...

In the case of Internaldate2tuple(), I use it as follows (and I suspect most would do the same):

    typ, data = src_box.fetch(src_msg, '(INTERNALDATE)')
    ...check typ here for error...
    src_internal_date = data[0]
    src_date_tuple = myInternaldate2tuple(src_internal_date)

So data[0] is a bytes array, returned by the fetch() method, and it is indeed therefore compatible with Internaldate2tuple().

In fact, it seems that the data, in general, is returned as bytes arrays in imaplib.  Given that we are dealing with raw email headers and bodies, this is perhaps exactly what should be done.  There is some grey area here.  For example, for headers, RFC 2047 discusses using special 'encoded-words' that are regular ASCII in, e.g., subjects (but I've encountered a few cases of UTF-8 in headers, even though this is a dubious practice).  IMAP flags are ASCII as well.

On the other hand, what you get from fetching pieces of emails are thing that you usually want to deal with as strings (e.g., you will want to do find() and startswith(), etc. on them).  But I guess it depends on what is really proper to use for email data.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10947>
_______________________________________

From report at bugs.python.org  Fri Jan 21 07:46:34 2011
From: report at bugs.python.org (Owen)
Date: Fri, 21 Jan 2011 06:46:34 +0000
Subject: [issue9884] The 4th parameter of method always None or 0 on x64
	Windows.
In-Reply-To: <1284714742.48.0.856656538994.issue9884@psf.upfronthosting.co.za>
Message-ID: <1295592394.0.0.319711907059.issue9884@psf.upfronthosting.co.za>


Owen <j2.nete at gmail.com> added the comment:

I tested this issue in Python2.7.1, Python3.1.3 and Python 3.2rc1. It's still can reproduce. Would you please check this "Callback functions" issue?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9884>
_______________________________________

From report at bugs.python.org  Fri Jan 21 08:07:27 2011
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 21 Jan 2011 07:07:27 +0000
Subject: [issue3341] "Suggest a change" link
In-Reply-To: <1215774609.12.0.768814080421.issue3341@psf.upfronthosting.co.za>
Message-ID: <1295593647.4.0.482636318572.issue3341@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

And still this is a thing that Sphinx needs to do (already does, but needs to be finalized.)

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3341>
_______________________________________

From report at bugs.python.org  Fri Jan 21 08:09:04 2011
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 21 Jan 2011 07:09:04 +0000
Subject: [issue10906] wsgiref should mention that CGI scripts usually expect
	HTTPS variable to be set to 'on'
In-Reply-To: <1295014476.87.0.519263477862.issue10906@psf.upfronthosting.co.za>
Message-ID: <1295593744.51.0.529881064335.issue10906@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

The doc for this function is not a place to discuss what CGI scripts do.  It describes what guess_scheme() does, and it does so sufficiently.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10906>
_______________________________________

From report at bugs.python.org  Fri Jan 21 08:10:20 2011
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 21 Jan 2011 07:10:20 +0000
Subject: [issue10961] Pydoc touchups in new browser for 3.2
In-Reply-To: <1295545738.06.0.604274599052.issue10961@psf.upfronthosting.co.za>
Message-ID: <1295593820.97.0.134804819774.issue10961@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Sigh... that might have come a little earlier.

As it is, I'll review it before rc2.

----------
assignee:  -> georg.brandl
priority: normal -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10961>
_______________________________________

From report at bugs.python.org  Fri Jan 21 08:53:16 2011
From: report at bugs.python.org (Ned Deily)
Date: Fri, 21 Jan 2011 07:53:16 +0000
Subject: [issue10964] Mac installer need not add things to /usr/local
In-Reply-To: <1295566233.42.0.612397787907.issue10964@psf.upfronthosting.co.za>
Message-ID: <1295596396.74.0.795221593719.issue10964@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Adding the symlinks to /usr/local is an option in the OS X installer.  Although it is enabled by default, you can easily disable it in Installer.app by selecting "Customize" and then unchecking the install of the "UNIX command-line tools" package.

The main reason for installing the symlinks by default is, I believe, a historical one.  Using /usr/local/bin/ to refer to an alternate Python is an established custom.  On the other hand, as you point out, adding the OS X framework bin directory to the path is accomplishes the same thing and is more robust and, in fact, necessary if packages are installed that add console scripts (unless a symlink is manually created in /usr/local/bin for the console script).

With the likely ongoing requirement for multiple Python versions for many users, it would be good to have a better way to manage versions than the current rather simplistic approach, i.e. the installer supplied 'Update Shell Profile.command'.

----------
nosy: +ned.deily
versions: +Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10964>
_______________________________________

From report at bugs.python.org  Fri Jan 21 08:53:18 2011
From: report at bugs.python.org (Christopher Dunn)
Date: Fri, 21 Jan 2011 07:53:18 +0000
Subject: [issue10936] Simple CSS fix for left margin at docs.python.org
In-Reply-To: <1295377924.0.0.902429691003.issue10936@psf.upfronthosting.co.za>
Message-ID: <1295596398.63.0.0437921219805.issue10936@psf.upfronthosting.co.za>


Christopher Dunn <cdunn2001 at gmail.com> added the comment:

I see what @ezio means about the apparent overflow when the bodywrapper left margin is at 20%. (It's not really overflow, since the sidebar is actually the width of the screen.) How about this change to basic.css?

 44 div.sphinxsidebar {
 45     float: left;
 46     width: 20%; /* was 230px */
 47     margin-left: -100%;
 48     font-size: 90%;
 49 }

It looks pretty good to me. The only thing that overflows is the search-input box. CSS for that is set in both basic.css and default.css (which takes precedence) as:

104 div.sphinxsidebar input {
105     border: 1px solid #98dbcc;
106     font-family: sans-serif;
107     font-size: 1em;
108     max-width: 100%;
109 }

I added line 108 (max-width). And now everything looks decent when zoomed in.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10936>
_______________________________________

From report at bugs.python.org  Fri Jan 21 08:58:36 2011
From: report at bugs.python.org (Christopher Dunn)
Date: Fri, 21 Jan 2011 07:58:36 +0000
Subject: [issue10936] Simple CSS fix for left margin at docs.python.org
In-Reply-To: <1295377924.0.0.902429691003.issue10936@psf.upfronthosting.co.za>
Message-ID: <1295596716.59.0.130601233551.issue10936@psf.upfronthosting.co.za>


Christopher Dunn <cdunn2001 at gmail.com> added the comment:

For narrow-width screens, there really shouldn't be a sidebar. Maybe a dynamic element would be better. Could it unhide and overlap the main body with a click or mouse-over? Then the main body could take the full screen width. Just an idea.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10936>
_______________________________________

From report at bugs.python.org  Fri Jan 21 08:59:49 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 21 Jan 2011 07:59:49 +0000
Subject: [issue3080] Full unicode import system
In-Reply-To: <1213208697.49.0.984990811807.issue3080@psf.upfronthosting.co.za>
Message-ID: <1295596789.34.0.83548536367.issue3080@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

As for the more limited run, I get a clean run with -uall except for the segfault in test_importlib.

I'll switch to a pydebug build and see how a verbose run of that test fares.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3080>
_______________________________________

From report at bugs.python.org  Fri Jan 21 09:19:16 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 21 Jan 2011 08:19:16 +0000
Subject: [issue3080] Full unicode import system
In-Reply-To: <1213208697.49.0.984990811807.issue3080@psf.upfronthosting.co.za>
Message-ID: <1295597956.86.0.970530709516.issue3080@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

I haven't investigated in detail yet, but this is the final line showing the failing test:

test_module (importlib.test.builtin.test_loader.LoaderTests) ... Segmentation fault

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3080>
_______________________________________

From report at bugs.python.org  Fri Jan 21 09:33:43 2011
From: report at bugs.python.org (Daniel Urban)
Date: Fri, 21 Jan 2011 08:33:43 +0000
Subject: [issue10775] assertRaises as a context manager should accept a 'msg'
	keyword argument.
In-Reply-To: <1293391143.22.0.15906903458.issue10775@psf.upfronthosting.co.za>
Message-ID: <1295598823.37.0.699044054388.issue10775@psf.upfronthosting.co.za>


Changes by Daniel Urban <urban.dani+py at gmail.com>:


----------
nosy: +durban

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10775>
_______________________________________

From report at bugs.python.org  Fri Jan 21 09:38:09 2011
From: report at bugs.python.org (Ned Deily)
Date: Fri, 21 Jan 2011 08:38:09 +0000
Subject: [issue10969] Make Tcl recommendation more prominent
In-Reply-To: <1295587699.83.0.103417791423.issue10969@psf.upfronthosting.co.za>
Message-ID: <1295599089.13.0.292818153339.issue10969@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

I'm a little concerned about that wording change. I proposed the current wording and footnote because the situation is dynamic and is not so cut and dried.  For one, Apple could at anytime fix their Tcl/Tk.  Another, ActiveState could issue a new (and presumably better) patchlevel of 8.5 (rather than 8.5.9).  Third, users need to be aware that ActiveState Tcl/Tk comes with its own license which may not be compatible with their usage (a warning to be added in a forthcoming update to the mac/tcltk web page).  As it stands, the Download page, the Installer Welcome message, the Installer readme, and the last ditch IDLE warning message all point the user to one place for current information.  Yes, the download page can be easily updated but I could see a duplicated but distilled recommendation taking on a life of its own.  But I concede that my concern may be misplaced.

----------
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10969>
_______________________________________

From report at bugs.python.org  Fri Jan 21 10:19:31 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 21 Jan 2011 09:19:31 +0000
Subject: [issue3080] Full unicode import system
In-Reply-To: <1213208697.49.0.984990811807.issue3080@psf.upfronthosting.co.za>
Message-ID: <1295601571.39.0.113864797805.issue3080@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> except for the segfault in test_importlib.

Yes, as reported in my previous comment :-) Let's update the patch for practical reasons. But I don't want to touch http://codereview.appspot.com/1874048 (based on patch version 4).

----------
Added file: http://bugs.python.org/file20477/issue3080-5.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3080>
_______________________________________

From report at bugs.python.org  Fri Jan 21 10:19:47 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 21 Jan 2011 09:19:47 +0000
Subject: [issue3080] Full unicode import system
In-Reply-To: <1213208697.49.0.984990811807.issue3080@psf.upfronthosting.co.za>
Message-ID: <1295601587.21.0.00937466668801.issue3080@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Removed file: http://bugs.python.org/file20474/issue3080-4.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3080>
_______________________________________

From report at bugs.python.org  Fri Jan 21 10:19:50 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 21 Jan 2011 09:19:50 +0000
Subject: [issue3080] Full unicode import system
In-Reply-To: <1213208697.49.0.984990811807.issue3080@psf.upfronthosting.co.za>
Message-ID: <1295601590.51.0.397770514166.issue3080@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Removed file: http://bugs.python.org/file20475/issue3080-4-svn.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3080>
_______________________________________

From report at bugs.python.org  Fri Jan 21 10:27:52 2011
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Fri, 21 Jan 2011 09:27:52 +0000
Subject: [issue4819] Misc/cheatsheet needs updating
In-Reply-To: <1295564445.08.0.827216744442.issue4819@psf.upfronthosting.co.za>
Message-ID: <4D395189.70403@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Raymond Hettinger wrote:
> 
> Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:
> 
> Perhaps the cheatsheet can be transferred to a wiki page and we can put out a comp.lang.python call for updates.

Good idea.

I just want to prevent the text from being lost in SVN
history somewhere... one of the things I liked about CVS was the Attic.
With Subversion deleted files are simply gone and unless someone remembers
them, they are lost.

> Also, +1 on the summer of code idea.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4819>
_______________________________________

From report at bugs.python.org  Fri Jan 21 10:34:51 2011
From: report at bugs.python.org (Christoph Gohlke)
Date: Fri, 21 Jan 2011 09:34:51 +0000
Subject: [issue9884] The 4th parameter of method always None or 0 on x64
	Windows.
In-Reply-To: <1284714742.48.0.856656538994.issue9884@psf.upfronthosting.co.za>
Message-ID: <1295602491.05.0.0397671131867.issue9884@psf.upfronthosting.co.za>


Christoph Gohlke <cgohlke at uci.edu> added the comment:

The provided example has two problems: The DLL should be loaded as cdll, not windll. C_METHOD_TYPE4 uses c_int32 as parameter type while pyFunc4Type in testPy2.cpp uses LPVOID (64 bit on win-amd64). Even with those corrections the issue remains.

----------
nosy: +cgohlke

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9884>
_______________________________________

From report at bugs.python.org  Fri Jan 21 10:58:01 2011
From: report at bugs.python.org (Owen)
Date: Fri, 21 Jan 2011 09:58:01 +0000
Subject: [issue9884] The 4th parameter of method always None or 0 on x64
	Windows.
In-Reply-To: <1284714742.48.0.856656538994.issue9884@psf.upfronthosting.co.za>
Message-ID: <1295603881.82.0.781621726765.issue9884@psf.upfronthosting.co.za>


Owen <j2.nete at gmail.com> added the comment:

yes, I tried lots of types. The issue still happens. The same case in Ubuntu and Mac were works well.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9884>
_______________________________________

From report at bugs.python.org  Fri Jan 21 11:01:42 2011
From: report at bugs.python.org (Christoph Gohlke)
Date: Fri, 21 Jan 2011 10:01:42 +0000
Subject: [issue9884] The 4th parameter of method always None or 0 on x64
	Windows.
In-Reply-To: <1284714742.48.0.856656538994.issue9884@psf.upfronthosting.co.za>
Message-ID: <1295604102.96.0.404384995529.issue9884@psf.upfronthosting.co.za>


Christoph Gohlke <cgohlke at uci.edu> added the comment:

The patch attached to #8275 fixes this issue and possibly also #9266.

Tested with Python 2.7.1 64 bit on Windows 7.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9884>
_______________________________________

From report at bugs.python.org  Fri Jan 21 11:04:18 2011
From: report at bugs.python.org (Christoph Gohlke)
Date: Fri, 21 Jan 2011 10:04:18 +0000
Subject: [issue8275] callback function on win64 results in bad behavior. mem
	corruption?
In-Reply-To: <1270061625.47.0.601780173179.issue8275@psf.upfronthosting.co.za>
Message-ID: <1295604258.17.0.571674733574.issue8275@psf.upfronthosting.co.za>


Christoph Gohlke <cgohlke at uci.edu> added the comment:

This patch fixes issue #9884 and possibly #9266.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8275>
_______________________________________

From report at bugs.python.org  Fri Jan 21 11:37:37 2011
From: report at bugs.python.org (Owen)
Date: Fri, 21 Jan 2011 10:37:37 +0000
Subject: [issue9884] The 4th parameter of method always None or 0 on x64
	Windows.
In-Reply-To: <1284714742.48.0.856656538994.issue9884@psf.upfronthosting.co.za>
Message-ID: <1295606257.72.0.729551159048.issue9884@psf.upfronthosting.co.za>


Owen <j2.nete at gmail.com> added the comment:

wow~~~ It works on my PC too (Windows 2003 STD x64). Thanks.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9884>
_______________________________________

From report at bugs.python.org  Fri Jan 21 11:54:00 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 21 Jan 2011 10:54:00 +0000
Subject: [issue10955] Possible regression with stdlib in zipfile
In-Reply-To: <1295531540.01.0.823019908764.issue10955@psf.upfronthosting.co.za>
Message-ID: <1295607240.52.0.0283641372402.issue10955@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

No, your change is in the read_directory() function, which reads the whole archive the first time it's used.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10955>
_______________________________________

From report at bugs.python.org  Fri Jan 21 11:59:00 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 21 Jan 2011 10:59:00 +0000
Subject: [issue10955] Possible regression with stdlib in zipfile
In-Reply-To: <1295531540.01.0.823019908764.issue10955@psf.upfronthosting.co.za>
Message-ID: <1295607540.9.0.595475908116.issue10955@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> No, your change is in the read_directory() function, 
> which reads the whole archive the first time it's used.

Oh, I though that read_directory() only reads files one by one.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10955>
_______________________________________

From report at bugs.python.org  Fri Jan 21 12:08:24 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 21 Jan 2011 11:08:24 +0000
Subject: [issue10955] Possible regression with stdlib in zipfile
In-Reply-To: <1295531540.01.0.823019908764.issue10955@psf.upfronthosting.co.za>
Message-ID: <1295608104.48.0.695311537372.issue10955@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Ronald Oussoren and Amaury Forgeot d'Arc: do you think that it is an acceptable limitation to only accept ASCII filenames in python32.zip? (not in all ZIP files, just in the file loaded at startup)

All possible solutions:

 a) Only accept ASCII filenames in python32.zip
 b) Only accept ZIP archive using UTF-8 filenames (unicode flag set for all files in the archive). On Linux, I don't know how to create such archive. I suppose that most ZIP archivers prefer the legacy format (unicode flag unset). But few people produce python32.zip files, maybe only py2exe / pyfreeze developers.
 c) Add encodings/cp437.py to your python3.2/ directory (outside the ZIP file), which can be a problem :-/
 d) Implement cp437 in C

I dislike (c) and (d), but I cannot say if (a) or (b) is better.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10955>
_______________________________________

From report at bugs.python.org  Fri Jan 21 12:14:50 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 21 Jan 2011 11:14:50 +0000
Subject: [issue10971] python Lib/test/regrtest.py -R 3:3:
	test_zipimport_support fails
In-Reply-To: <1295608490.51.0.226657873121.issue10971@psf.upfronthosting.co.za>
Message-ID: <1295608490.51.0.226657873121.issue10971@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

"./python Lib/test/regrtest.py test_zipimport_support" pass, but not with the -R option.

----
$ ./python Lib/test/regrtest.py -R 3:3: test_zipimport_support
[1/1] test_zipimport_support
beginning 6 repetitions
123456
test test_zipimport_support failed -- Traceback (most recent call last):
  File "/home/haypo/prog/SVN/py3k/Lib/test/test_zipimport_support.py", line 96, in test_inspect_getsource_issue4223
    self.assertEqual(inspect.getsource(zip_pkg.foo), test_src)
  File "/home/haypo/prog/SVN/py3k/Lib/inspect.py", line 693, in getsource
    lines, lnum = getsourcelines(object)
  File "/home/haypo/prog/SVN/py3k/Lib/inspect.py", line 682, in getsourcelines
    lines, lnum = findsource(object)
  File "/home/haypo/prog/SVN/py3k/Lib/inspect.py", line 530, in findsource
    raise IOError('could not get source code')
IOError: could not get source code

1 test failed:
    test_zipimport_support
----

----------
components: Tests
messages: 126718
nosy: haypo
priority: normal
severity: normal
status: open
title: python Lib/test/regrtest.py -R 3:3: test_zipimport_support fails
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10971>
_______________________________________

From report at bugs.python.org  Fri Jan 21 12:38:43 2011
From: report at bugs.python.org (Benjamin VENELLE)
Date: Fri, 21 Jan 2011 11:38:43 +0000
Subject: [issue10968] Timer class inheritance issue
In-Reply-To: <1295574501.95.0.0935688829986.issue10968@psf.upfronthosting.co.za>
Message-ID: <1295609923.71.0.0600582484334.issue10968@psf.upfronthosting.co.za>


Benjamin VENELLE <gu0sur20 at gmail.com> added the comment:

I've tested it with Python 3.1.2 under Windows 7 32 bits. It raises the following TypeError exception "function() argument 1 must be code, not str"

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10968>
_______________________________________

From report at bugs.python.org  Fri Jan 21 12:50:28 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 21 Jan 2011 11:50:28 +0000
Subject: [issue10955] Possible regression with stdlib in zipfile
In-Reply-To: <1295531540.01.0.823019908764.issue10955@psf.upfronthosting.co.za>
Message-ID: <1295610628.31.0.775947865731.issue10955@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

What about tools that builds one .zip file for all modules, like py2exe?

A cp437 decoder is not so ugly to implement in C. It's just a charmap.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10955>
_______________________________________

From report at bugs.python.org  Fri Jan 21 12:53:49 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 21 Jan 2011 11:53:49 +0000
Subject: [issue10955] Possible regression with stdlib in zipfile
In-Reply-To: <1295531540.01.0.823019908764.issue10955@psf.upfronthosting.co.za>
Message-ID: <1295610829.8.0.458297802128.issue10955@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Oh, py2app is implemented in Python and use the zipfile module. So if we can control how the filename is encoded, we can fix py2app to workaround this limitation :-)

7zip and WinRAR uses the same algorithm than ZipFile._encodeFilename(): try cp437 or use UTF-8. Eg. if a filename contains ? (U+221E), it is encoded to UTF-8.

WinZIP encodes all filenames to cp437: ? (U+221E) is replaced by 8 (U+0038), ? (U+263A) is replaced by... U+0001 !

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10955>
_______________________________________

From report at bugs.python.org  Fri Jan 21 12:54:25 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 21 Jan 2011 11:54:25 +0000
Subject: [issue10968] Timer class inheritance issue
In-Reply-To: <1295574501.95.0.0935688829986.issue10968@psf.upfronthosting.co.za>
Message-ID: <1295610865.4.0.770464897077.issue10968@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

I can't reproduce the error. Do you have a script that shows the issue?
What is the complete traceback?

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10968>
_______________________________________

From report at bugs.python.org  Fri Jan 21 12:57:45 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 21 Jan 2011 11:57:45 +0000
Subject: [issue10968] Timer class inheritance issue
In-Reply-To: <1295574501.95.0.0935688829986.issue10968@psf.upfronthosting.co.za>
Message-ID: <1295611065.22.0.437780105982.issue10968@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Ah, got it. It's about threading.Timer, which looks like a class, but is actually a function.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10968>
_______________________________________

From report at bugs.python.org  Fri Jan 21 13:00:45 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 21 Jan 2011 12:00:45 +0000
Subject: [issue10972] zipfile: add unicode option to the choose filename
	encoding
In-Reply-To: <1295611245.09.0.199855932712.issue10972@psf.upfronthosting.co.za>
Message-ID: <1295611245.09.0.199855932712.issue10972@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

ZipInfo._encodeFilename() tries cp437 encoding or use UTF-8. It is not possible to decide the encoding.

To workaround #10955 (bootstrap issue with python32.zip), it would be nice to be able to create a ZIP file using only UTF-8 filenames.

Attached patch adds unicode parameter to ZipFile.write(), ZipFile.writestr() and ZipInfo constructor.

----------
components: Library (Lib), Unicode
files: zipfile_unicode.patch
keywords: patch
messages: 126724
nosy: haypo
priority: normal
severity: normal
status: open
title: zipfile: add unicode option to the choose filename encoding
versions: Python 3.2, Python 3.3
Added file: http://bugs.python.org/file20478/zipfile_unicode.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10972>
_______________________________________

From report at bugs.python.org  Fri Jan 21 13:03:08 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 21 Jan 2011 12:03:08 +0000
Subject: [issue10972] zipfile: add unicode option to the choose filename
	encoding
In-Reply-To: <1295611245.09.0.199855932712.issue10972@psf.upfronthosting.co.za>
Message-ID: <1295611388.3.0.711513532641.issue10972@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Oh, this patch fixes also a bug: ZipFile._RealGetContents() doesn't keep the unicode flag, so open a ZIP file and then write it somewhere else may change the unicode flag if unicode flag was set but the filename is also encodable to UTF-8 (eg. ASCII filename).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10972>
_______________________________________

From report at bugs.python.org  Fri Jan 21 13:04:51 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 21 Jan 2011 12:04:51 +0000
Subject: [issue10955] Possible regression with stdlib in zipfile
In-Reply-To: <1295531540.01.0.823019908764.issue10955@psf.upfronthosting.co.za>
Message-ID: <1295611491.73.0.253958941103.issue10955@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

#10972 has a patch for zipfile to set the filename encoding if a ZipInfo object (to force the encoding to UTF-8).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10955>
_______________________________________

From report at bugs.python.org  Fri Jan 21 13:07:09 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 21 Jan 2011 12:07:09 +0000
Subject: [issue10972] zipfile: add unicode option to the choose filename
	encoding
In-Reply-To: <1295611245.09.0.199855932712.issue10972@psf.upfronthosting.co.za>
Message-ID: <1295611629.36.0.303977621119.issue10972@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

7zip and WinRAR uses the same algorithm than ZipFile._encodeFilename(): try cp437 or use UTF-8. Eg. if a filename contains ? (U+221E), it is encoded to UTF-8.

WinZIP encodes all filenames to cp437: ? (U+221E) is replaced by 8 (U+0038), ? (U+263A) is replaced by... U+0001!

7zip, WinRAR and WinZIP are able to decode UTF-8 filenames (handle correctly the unicode flag).

----------
nosy: +alanmcintyre

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10972>
_______________________________________

From report at bugs.python.org  Fri Jan 21 13:07:38 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 21 Jan 2011 12:07:38 +0000
Subject: [issue10972] zipfile: add "unicode" option to the force the filename
	encoding to UTF-8
In-Reply-To: <1295611245.09.0.199855932712.issue10972@psf.upfronthosting.co.za>
Message-ID: <1295611658.55.0.973149879628.issue10972@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
title: zipfile: add unicode option to the choose filename encoding -> zipfile: add "unicode" option to the force the filename encoding to UTF-8

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10972>
_______________________________________

From report at bugs.python.org  Fri Jan 21 13:10:37 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 21 Jan 2011 12:10:37 +0000
Subject: [issue10968] Timer class inheritance issue
In-Reply-To: <1295574501.95.0.0935688829986.issue10968@psf.upfronthosting.co.za>
Message-ID: <1295611837.03.0.38999807955.issue10968@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

It seems to be by design: from the documentation:
http://docs.python.org/py3k/library/threading.html
"Timer is a subclass of Thread", and a Thread subclass should "only override the __init__() and run() methods".

What are you trying to do here? overriding run() is probably wrong; and overriding __init__ is better done by passing the correct parameters to threading.Timer().

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10968>
_______________________________________

From report at bugs.python.org  Fri Jan 21 13:11:57 2011
From: report at bugs.python.org (Lennart Regebro)
Date: Fri, 21 Jan 2011 12:11:57 +0000
Subject: [issue10042] total_ordering stack overflow
In-Reply-To: <1286440012.74.0.624864175042.issue10042@psf.upfronthosting.co.za>
Message-ID: <1295611917.4.0.661274493271.issue10042@psf.upfronthosting.co.za>


Lennart Regebro <regebro at gmail.com> added the comment:

This also affects Python 2.7, where it hasn't been fixed. Maybe reopen it?

----------
nosy: +lregebro

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10042>
_______________________________________

From report at bugs.python.org  Fri Jan 21 13:13:17 2011
From: report at bugs.python.org (Benjamin VENELLE)
Date: Fri, 21 Jan 2011 12:13:17 +0000
Subject: [issue10968] Timer class inheritance issue
In-Reply-To: <1295574501.95.0.0935688829986.issue10968@psf.upfronthosting.co.za>
Message-ID: <1295611997.92.0.588874391821.issue10968@psf.upfronthosting.co.za>


Benjamin VENELLE <gu0sur20 at gmail.com> added the comment:

Yes that's it. I Should precise it. I've taken a screenshot from my python's interpreter to spot it.

----------
Added file: http://bugs.python.org/file20479/issue10968.png

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10968>
_______________________________________

From report at bugs.python.org  Fri Jan 21 13:18:53 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 21 Jan 2011 12:18:53 +0000
Subject: [issue10972] zipfile: add "unicode" option to the force the filename
	encoding to UTF-8
In-Reply-To: <1295611245.09.0.199855932712.issue10972@psf.upfronthosting.co.za>
Message-ID: <1295612333.1.0.796731669457.issue10972@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

What kind of problem are you trying to solve?

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10972>
_______________________________________

From report at bugs.python.org  Fri Jan 21 13:21:11 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 21 Jan 2011 12:21:11 +0000
Subject: [issue10968] Timer should be a class so that it can be derived
In-Reply-To: <1295574501.95.0.0935688829986.issue10968@psf.upfronthosting.co.za>
Message-ID: <1295612471.7.0.568688563032.issue10968@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

AFAIK this is by design. Not that I agree with this decision anyway.

----------
assignee: collinwinter -> 
nosy: +pitrou
title: Timer class inheritance issue -> Timer should be a class so that it can be derived
type: behavior -> feature request
versions: +Python 3.3 -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10968>
_______________________________________

From report at bugs.python.org  Fri Jan 21 13:45:07 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 21 Jan 2011 12:45:07 +0000
Subject: [issue10955] Possible regression with stdlib in zipfile
In-Reply-To: <1295531540.01.0.823019908764.issue10955@psf.upfronthosting.co.za>
Message-ID: <1295613907.36.0.308392411682.issue10955@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

On Linux, the "zip" command line program (InfoZIP zip program) only sets the unicode flag if it is able to set the locale to "en_US.UTF-8". It can do better: check if the locale encoding is UTF-8, and only "en_US.UTF-8" locale if the encoding was not UTF-8.

The conclusion is today, it is very hard to create archives using only UTF-8 names (unicode flag set): only the zip program can do that on Linux.

With issue10955.patch (#10972): py2app and py2exe will only support ASCII filenames, but at least it fixes this issue :-)

With issue10955.patch + zipfile_unicode.patch (#10972): py2app will support non-ASCII filenames, but py2exe will only support ASCII filenames.

We can fix the bootstrap issue today, and improve zipfile later to support non-ASCII filenames. Anyway, Python 3.2 doesn't support non-ASCII filenames on Windows (#3080), and I plan to fix this in Python 3.3.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10955>
_______________________________________

From report at bugs.python.org  Fri Jan 21 14:00:54 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 21 Jan 2011 13:00:54 +0000
Subject: [issue10972] zipfile: add "unicode" option to the force the filename
	encoding to UTF-8
In-Reply-To: <1295611245.09.0.199855932712.issue10972@psf.upfronthosting.co.za>
Message-ID: <1295614854.1.0.783391940785.issue10972@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> What kind of problem are you trying to solve?

Support non-ASCII filenames in python32.zip (#10955): at bootstrap, Python 3.2 can only use UTF-8 codec (not cp437).

But I suppose also that forcing the encoding to UTF-8 gives a better Unicode support (when you decompress the archive).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10972>
_______________________________________

From report at bugs.python.org  Fri Jan 21 14:03:43 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 21 Jan 2011 13:03:43 +0000
Subject: [issue10972] zipfile: add "unicode" option to the force the filename
	encoding to UTF-8
In-Reply-To: <1295614854.1.0.783391940785.issue10972@psf.upfronthosting.co.za>
Message-ID: <1295615019.3681.0.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Support non-ASCII filenames in python32.zip (#10955): at bootstrap,
> Python 3.2 can only use UTF-8 codec (not cp437).
> 
> But I suppose also that forcing the encoding to UTF-8 gives a better
> Unicode support (when you decompress the archive).

The question is, rather, why you need an external flag for that.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10972>
_______________________________________

From report at bugs.python.org  Fri Jan 21 14:04:46 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 21 Jan 2011 13:04:46 +0000
Subject: [issue10955] Possible regression with stdlib in zipfile
In-Reply-To: <1295531540.01.0.823019908764.issue10955@psf.upfronthosting.co.za>
Message-ID: <1295615086.15.0.614636452002.issue10955@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Patch version 2: display a more useful error message:

$ python
Fatal Python error: Py_Initialize: Unable to get the locale encoding
NotImplementedError: bootstrap issue: python32.zip contains non-ASCII filenames without the unicode flag
Aborted

Instead of (message without the patch):

$ python
Fatal Python error: Py_Initialize: Unable to get the locale encoding
LookupError: no codec search functions registered: can't find encoding
Aborted

----------
Added file: http://bugs.python.org/file20480/issue10955-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10955>
_______________________________________

From report at bugs.python.org  Fri Jan 21 14:18:53 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 21 Jan 2011 13:18:53 +0000
Subject: [issue10955] Possible regression with stdlib in zipfile
In-Reply-To: <1295531540.01.0.823019908764.issue10955@psf.upfronthosting.co.za>
Message-ID: <1295615933.66.0.298728860329.issue10955@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Victor's second patch looks good to me. Georg, is this a release blocker?

----------
nosy: +pitrou
stage: unit test needed -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10955>
_______________________________________

From report at bugs.python.org  Fri Jan 21 14:42:01 2011
From: report at bugs.python.org (Fred L. Drake, Jr.)
Date: Fri, 21 Jan 2011 13:42:01 +0000
Subject: [issue10936] Simple CSS fix for left margin at docs.python.org
In-Reply-To: <1295596716.59.0.130601233551.issue10936@psf.upfronthosting.co.za>
Message-ID: <AANLkTi=b5XqqLUTr5H7NkCW725w382_Fh6bdH35VA6eL@mail.gmail.com>


Fred L. Drake, Jr. <fdrake at acm.org> added the comment:

On Fri, Jan 21, 2011 at 2:58 AM, Christopher Dunn
<report at bugs.python.org> wrote:
> For narrow-width screens, there really shouldn't be a sidebar. Maybe a dynamic element would be better.

Right.  I'd be in favor of removing the sidebar and having a pop-out
ToC navigator of some sort.  Most of the time, most of us are looking
at the content, not at how to navigate the content.  Spending so much
screen real-estate on navigation is painful.  Large, hi-res screens
just aren't *that* cheap yet.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10936>
_______________________________________

From report at bugs.python.org  Fri Jan 21 14:57:21 2011
From: report at bugs.python.org (Eric Smith)
Date: Fri, 21 Jan 2011 13:57:21 +0000
Subject: [issue10968] threading.Timer should be a class so that it can be
	derived
In-Reply-To: <1295574501.95.0.0935688829986.issue10968@psf.upfronthosting.co.za>
Message-ID: <1295618241.86.0.292222399034.issue10968@psf.upfronthosting.co.za>


Changes by Eric Smith <eric at trueblade.com>:


----------
nosy: +eric.smith
title: Timer should be a class so that it can be derived -> threading.Timer should be a class so that it can be derived

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10968>
_______________________________________

From report at bugs.python.org  Fri Jan 21 15:27:41 2011
From: report at bugs.python.org (Nestor Aguilera)
Date: Fri, 21 Jan 2011 14:27:41 +0000
Subject: =?utf-8?q?=5Bissue10973=5D_=27=C3=B1=27_not_working_with_IDLE_3=2E2rc1_-_?=
	=?utf-8?q?OSX_10=2E6=2E6?=
In-Reply-To: <1295620061.05.0.0288010484186.issue10973@psf.upfronthosting.co.za>
Message-ID: <1295620061.05.0.0288010484186.issue10973@psf.upfronthosting.co.za>


New submission from Nestor Aguilera <aguilera at santafe-conicet.gov.ar>:

When trying to type '?' in idle 3.2 (no problem in terminal), python "quits unexpectedly" when started from terminal:

$ idle3
2011-01-21 11:21:55.883 Python[5228:a07] setCanCycle: is deprecated.  Please use setCollectionBehavior instead
2011-01-21 11:21:55.890 Python[5228:a07] setCanCycle: is deprecated.  Please use setCollectionBehavior instead
2011-01-21 11:21:55.891 Python[5228:a07] setCanCycle: is deprecated.  Please use setCollectionBehavior instead
2011-01-21 11:22:08.777 Python[5228:a07] An uncaught exception was raised
2011-01-21 11:22:08.779 Python[5228:a07] *** -[NSCFString characterAtIndex:]: Range or index out of bounds
2011-01-21 11:22:08.781 Python[5228:a07] *** Terminating app due to uncaught exception 'NSRangeException', reason: '*** -[NSCFString characterAtIndex:]: Range or index out of bounds'
*** Call stack at first throw:
(
	0   CoreFoundation                      0x00007fff829c47b4 __exceptionPreprocess + 180
	1   libobjc.A.dylib                     0x00007fff816300f3 objc_exception_throw + 45
	2   CoreFoundation                      0x00007fff829c45d7 +[NSException raise:format:arguments:] + 103
	3   CoreFoundation                      0x00007fff829c4564 +[NSException raise:format:] + 148
	4   Foundation                          0x00007fff839c15e1 -[NSCFString characterAtIndex:] + 97
	5   Tk                                  0x00000001012ba035 -[TKApplication(TKKeyEvent) tkProcessKeyEvent:] + 664
	6   Tk                                  0x00000001012c0b38 TkMacOSXEventsCheckProc + 349
	7   Tcl                                 0x0000000101175667 Tcl_DoOneEvent + 316
	8   _tkinter.so                         0x000000010077d801 Tkapp_MainLoop + 177
	9   Python                              0x00000001000b2b62 PyEval_EvalFrameEx + 30530
	10  Python                              0x00000001000b34ca PyEval_EvalCodeEx + 1770
	11  Python                              0x00000001000b19e3 PyEval_EvalFrameEx + 26051
	12  Python                              0x00000001000b1bfd PyEval_EvalFrameEx + 26589
	13  Python                              0x00000001000b34ca PyEval_EvalCodeEx + 1770
	14  Python                              0x00000001000b37df PyEval_EvalCode + 63
	15  Python                              0x00000001000da19b PyRun_FileExFlags + 187
	16  Python                              0x00000001000da469 PyRun_SimpleFileExFlags + 521
	17  Python                              0x00000001000ef253 Py_Main + 3059
	18  Python                              0x0000000100000e5f 0x0 + 4294970975
	19  Python                              0x0000000100000d04 0x0 + 4294970628
)
terminate called after throwing an instance of 'NSException'
Abort trap
 
#----------------------------------------------
The welcome in idle 3.2 is:

Python 3.2rc1 (r32rc1:88040, Jan 15 2011, 13:31:22) 
[GCC 4.2.1 (Apple Inc. build 5664)] on darwin
Type "copyright", "credits" or "license()" for more information.

#----------------------------------------------
I cannot start IDLE by double-clicking its icon in the Finder.

Best,

N?stor Aguilera

----------
components: IDLE
messages: 126739
nosy: naguilera
priority: normal
severity: normal
status: open
title: '?' not working with IDLE 3.2rc1 - OSX 10.6.6
type: crash
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10973>
_______________________________________

From report at bugs.python.org  Fri Jan 21 15:30:40 2011
From: report at bugs.python.org (Ronald Oussoren)
Date: Fri, 21 Jan 2011 14:30:40 +0000
Subject: [issue10955] Possible regression with stdlib in zipfile
In-Reply-To: <1295531540.01.0.823019908764.issue10955@psf.upfronthosting.co.za>
Message-ID: <1295620240.78.0.690979723917.issue10955@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

The python32.zip file generated by py2app contains both files from the stdlib and application files.  I cannot avoid haveing non-ascii filenames when a python package contains data files that have such names.

The patch in Issue10972 would be nice to have, that way py2app can enforce that the zipfile uses UTF-8 names.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10955>
_______________________________________

From report at bugs.python.org  Fri Jan 21 15:31:39 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 21 Jan 2011 14:31:39 +0000
Subject: =?utf-8?q?=5Bissue10973=5D_=27=C3=B1=27_not_working_with_IDLE_3=2E2rc1_-_?=
	=?utf-8?q?OSX_10=2E6=2E6?=
In-Reply-To: <1295620061.05.0.0288010484186.issue10973@psf.upfronthosting.co.za>
Message-ID: <1295620299.52.0.207831823553.issue10973@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/issue10973>
_______________________________________

From report at bugs.python.org  Fri Jan 21 15:32:33 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 21 Jan 2011 14:32:33 +0000
Subject: [issue10955] Possible regression with stdlib in zipfile
In-Reply-To: <1295620240.78.0.690979723917.issue10955@psf.upfronthosting.co.za>
Message-ID: <1295620341.3681.1.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> The python32.zip file generated by py2app contains both files from the
> stdlib and application files.  I cannot avoid haveing non-ascii
> filenames when a python package contains data files that have such
> names.

I don't think this is a problem. We are only talking about
bootstrap-time importing of encodings modules. Once the encodings
machinery is initialized, importing non-ascii files should work fine.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10955>
_______________________________________

From report at bugs.python.org  Fri Jan 21 15:36:28 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 21 Jan 2011 14:36:28 +0000
Subject: =?utf-8?q?=5Bissue10973=5D_=27=C3=B1=27_not_working_with_IDLE_3=2E2rc1_-_?=
	=?utf-8?q?OSX_10=2E6=2E6?=
In-Reply-To: <1295620061.05.0.0288010484186.issue10973@psf.upfronthosting.co.za>
Message-ID: <1295620588.13.0.292382123892.issue10973@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10973>
_______________________________________

From report at bugs.python.org  Fri Jan 21 15:36:29 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 21 Jan 2011 14:36:29 +0000
Subject: [issue10955] Possible regression with stdlib in zipfile
In-Reply-To: <1295531540.01.0.823019908764.issue10955@psf.upfronthosting.co.za>
Message-ID: <1295620589.4.0.608924387274.issue10955@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

> We are only talking about bootstrap-time importing of encodings modules.
Again, the whole zip central directory is loaded on first import. If the zip file contains non-ascii filenames, nothing can be imported.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10955>
_______________________________________

From report at bugs.python.org  Fri Jan 21 15:46:11 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 21 Jan 2011 14:46:11 +0000
Subject: [issue10955] Possible regression with stdlib in zipfile
In-Reply-To: <1295620589.4.0.608924387274.issue10955@psf.upfronthosting.co.za>
Message-ID: <1295621137.3681.2.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Again, the whole zip central directory is loaded on first import. If
> the zip file contains non-ascii filenames, nothing can be imported.

Does it have to be decoded eagerly, though?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10955>
_______________________________________

From report at bugs.python.org  Fri Jan 21 15:58:09 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 21 Jan 2011 14:58:09 +0000
Subject: [issue10955] Possible regression with stdlib in zipfile
In-Reply-To: <1295531540.01.0.823019908764.issue10955@psf.upfronthosting.co.za>
Message-ID: <1295621889.47.0.00815297203964.issue10955@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> I cannot avoid haveing non-ascii filenames when a python package
> contains data files that have such names.

Are "data files" Python modules (.py files)? Or can it be anything?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10955>
_______________________________________

From report at bugs.python.org  Fri Jan 21 16:02:11 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 21 Jan 2011 15:02:11 +0000
Subject: [issue10972] zipfile: add "unicode" option to the force the filename
	encoding to UTF-8
In-Reply-To: <1295611245.09.0.199855932712.issue10972@psf.upfronthosting.co.za>
Message-ID: <1295622131.04.0.935095915103.issue10972@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> The question is, rather, why you need an external flag for that.

Because I don't want to change the default encoding. I am not sure that all applications support UTF-8 encodings.

But if you control your environment, force UTF-8 encoding should improve your Unicode support.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10972>
_______________________________________

From report at bugs.python.org  Fri Jan 21 16:12:25 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 21 Jan 2011 15:12:25 +0000
Subject: [issue10972] zipfile: add "unicode" option to the force the filename
	encoding to UTF-8
In-Reply-To: <1295622131.04.0.935095915103.issue10972@psf.upfronthosting.co.za>
Message-ID: <1295622740.3681.10.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> > The question is, rather, why you need an external flag for that.
> 
> Because I don't want to change the default encoding. I am not sure
> that all applications support UTF-8 encodings.

If this is a ZIP standard flag, why should we care about applications
which don't support it? Should we add other flags to disable other
features out of fear that other applications might not support them
either?

> But if you control your environment, force UTF-8 encoding should
> improve your Unicode support.

How is a random user supposed to know if their tools support UTF-8
encoding? It's not like everyone is an expert in ZIP files. This is the
kind of situation where asking the user to make a choice is more
confusing than helpful. When adding the flag, not only you complicate
the API, but you have to support this flag for the rest of your life
(well, almost :-)).

We could instead use utf-8 by default for all non-ascii filenames (and
*perhaps* have a separate force_cp437 flag, but default it to False).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10972>
_______________________________________

From report at bugs.python.org  Fri Jan 21 16:16:13 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 21 Jan 2011 15:16:13 +0000
Subject: [issue10972] zipfile: add "unicode" option to the force the filename
	encoding to UTF-8
In-Reply-To: <1295611245.09.0.199855932712.issue10972@psf.upfronthosting.co.za>
Message-ID: <1295622973.23.0.473771401165.issue10972@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10972>
_______________________________________

From report at bugs.python.org  Fri Jan 21 16:17:41 2011
From: report at bugs.python.org (R. David Murray)
Date: Fri, 21 Jan 2011 15:17:41 +0000
Subject: [issue10947] imaplib: Internaldate2tuple and ParseFlags require (and
	latter returns) bytes arrays; should allow/return str
In-Reply-To: <1295451332.43.0.977417439806.issue10947@psf.upfronthosting.co.za>
Message-ID: <1295623061.61.0.941149278437.issue10947@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Well, we recently added support for parsing binary data streams to the email module (or added back, if you are looking at it from a python2 perspective), exactly because "in the wild" headers are not always RFC compliant ASCII, and because bodies often are RFC *compliant* 8bit.  So yes, the appropriate type for imaplib to be returning is bytes, and the application has to figure out how to decode it to string using the information contained internally in the email message.  The email package is the obvious way to do this, and if there are helper routines that an imaplib programmer would want in order to make that job easier, those would be very legitimate feature requests (but most of what one needs should already be there; specifically decode_header and friends, although there's an outstanding feature request for a convenience wrapper around that).

----------
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10947>
_______________________________________

From report at bugs.python.org  Fri Jan 21 16:31:21 2011
From: report at bugs.python.org (dholth)
Date: Fri, 21 Jan 2011 15:31:21 +0000
Subject: [issue8713] multiprocessing needs option to eschew fork() under Linux
In-Reply-To: <1273853591.12.0.245920632829.issue8713@psf.upfronthosting.co.za>
Message-ID: <1295623881.19.0.4956675741.issue8713@psf.upfronthosting.co.za>


dholth <dholth at fastmail.fm> added the comment:

+1

----------
nosy: +dholth

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8713>
_______________________________________

From report at bugs.python.org  Fri Jan 21 16:40:06 2011
From: report at bugs.python.org (Phillip J. Eby)
Date: Fri, 21 Jan 2011 15:40:06 +0000
Subject: [issue10935] wsgiref.handlers.BaseHandler and subclasses of str
In-Reply-To: <1295371764.49.0.785710350986.issue10935@psf.upfronthosting.co.za>
Message-ID: <1295624406.9.0.0482119953271.issue10935@psf.upfronthosting.co.za>


Phillip J. Eby <pje at telecommunity.com> added the comment:

Implicit knowledge in your own head about what might or might not be a good idea to program is not the same thing as a specification.  "type(x) is str" is a good specification in this context, while "string subclasses, but only if they're really str" does not.

And the reason why that is, is because the first specification allows server implementers to say, "your type is not str, so you are not conformant; go fix your code."   The second "specification" is just an invitation to (number of server implementations)*(number of string implementations) arguments about what conformance is.

That makes the latter an objectively worse specification than the first, even if EVERYONE would prefer to be able to use their own string type.  Practicality beats purity, and explicit is better than implicit.  These principles are doubly true where interop protocol definitions are concerned.

To put it another way, the greater the social separation between parties, the more explicit and specific a contract between those two parties has to be in order to co-ordinate their actions, because they can't rely on having the same operating assumptions as the other party.  This situation is a terrific example of that principle in action.  ;-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10935>
_______________________________________

From report at bugs.python.org  Fri Jan 21 16:43:35 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 21 Jan 2011 15:43:35 +0000
Subject: [issue8713] multiprocessing needs option to eschew fork() under Linux
In-Reply-To: <1273853591.12.0.245920632829.issue8713@psf.upfronthosting.co.za>
Message-ID: <1295624615.85.0.618578209607.issue8713@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +asksol
stage:  -> needs patch
versions: +Python 3.3 -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8713>
_______________________________________

From report at bugs.python.org  Fri Jan 21 16:49:02 2011
From: report at bugs.python.org (Joe Peterson)
Date: Fri, 21 Jan 2011 15:49:02 +0000
Subject: [issue10947] imaplib: Internaldate2tuple and ParseFlags require (and
	latter returns) bytes arrays; should allow/return str
In-Reply-To: <1295451332.43.0.977417439806.issue10947@psf.upfronthosting.co.za>
Message-ID: <1295624942.74.0.351513152862.issue10947@psf.upfronthosting.co.za>


Joe Peterson <joe at skyrush.com> added the comment:

Yep, I agree, and in light of this, we should probably just close this issue and work toward reviewing/improving imaplib in the ways you are suggesting.

As I migrate my imap stuff more to Python3, I'll see if I run into any problems with using bytes throughout (beyond what is addressed in issue 10939).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10947>
_______________________________________

From report at bugs.python.org  Fri Jan 21 16:53:37 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 21 Jan 2011 15:53:37 +0000
Subject: [issue10935] wsgiref.handlers.BaseHandler and subclasses of str
In-Reply-To: <1295624406.9.0.0482119953271.issue10935@psf.upfronthosting.co.za>
Message-ID: <1295625211.3681.15.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Implicit knowledge in your own head about what might or might not be a
> good idea to program is not the same thing as a specification.
> "type(x) is str" is a good specification in this context, while
> "string subclasses, but only if they're really str" does not.
> 
> And the reason why that is, is because the first specification allows
> server implementers to say, "your type is not str, so you are not
> conformant; go fix your code."   The second "specification" is just an
> invitation to (number of server implementations)*(number of string
> implementations) arguments about what conformance is.

You might argue about this all the way you want, but let me repeat it:
the interpreter already, implicitly, uses the "second specification" in
many of its internal routines (e.g. C implementations of stdlib
functions and types). Why do you think what is fine for the interpreter
and its stdlib is not fine for WSGI?

> Practicality beats purity, and explicit is better than implicit. 

And, ironically, you are arguing for a pure specification at the expense
of practicality. As for explicit/implicit, it isn't involved here: an
isinstance() test is as explicit as a type() equality test.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10935>
_______________________________________

From report at bugs.python.org  Fri Jan 21 17:43:19 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 21 Jan 2011 16:43:19 +0000
Subject: [issue3080] Full unicode import system
In-Reply-To: <1213208697.49.0.984990811807.issue3080@psf.upfronthosting.co.za>
Message-ID: <1295628199.42.0.402148936012.issue3080@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Oops, missed that post - that was indeed the problem. With that fixed, tests are all good on this system. I'll give the patch a look anyway, but I'm going to have trouble diagnosing things that don't fail on my development machine.

As far as the test_reprlib failure goes, I seem to recall addressing a similar problem elsewhere in the standard lib by replace a "%r" code with "'%s'" to get the single quotes without the backslash escaping. A similar change should probably do the trick here.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3080>
_______________________________________

From report at bugs.python.org  Fri Jan 21 17:59:36 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 21 Jan 2011 16:59:36 +0000
Subject: =?utf-8?q?=5Bissue10973=5D_=27=C3=B1=27_not_working_with_IDLE_3=2E2rc1_-_?=
	=?utf-8?q?OSX_10=2E6=2E6?=
In-Reply-To: <1295620061.05.0.0288010484186.issue10973@psf.upfronthosting.co.za>
Message-ID: <1295629176.44.0.801003859445.issue10973@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

No problem on Linux (Debian Sid): I tried "???=1" in IDLE interpreter (written using the compose key).

It looks like the bug is specific to Mac OS X and comes from Tk directly:
http://sourceforge.net/tracker/index.php?func=detail&aid=2907388&group_id=12997&atid=112997
"(...)  this crash happens for [all] composite characters. (...) the crash is caused by the "sticky" modifier key and not by the accented character itself."

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10973>
_______________________________________

From report at bugs.python.org  Fri Jan 21 18:00:21 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 21 Jan 2011 17:00:21 +0000
Subject: =?utf-8?q?=5Bissue10973=5D_=27=C3=B1=27_not_working_with_IDLE_3=2E2rc1_-_?=
	=?utf-8?q?OSX_10=2E6=2E6?=
In-Reply-To: <1295620061.05.0.0288010484186.issue10973@psf.upfronthosting.co.za>
Message-ID: <1295629221.3.0.679545955597.issue10973@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> I cannot start IDLE by double-clicking its icon in the Finder.

You may open a new issue for this proble.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10973>
_______________________________________

From report at bugs.python.org  Fri Jan 21 18:06:55 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 21 Jan 2011 17:06:55 +0000
Subject: [issue3080] Full unicode import system
In-Reply-To: <1213208697.49.0.984990811807.issue3080@psf.upfronthosting.co.za>
Message-ID: <1295629615.09.0.951590822577.issue3080@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> but I'm going to have trouble diagnosing things that don't fail 
> on my development machine.

On Windows, try any character not encodable into your ANSI code page (eg. ? with cp1252) in the module path and non-ASCII characters in the module name.

On Mac OS X, sorry, it already works.

On other OSes, set the locale to something else than UTF-8 (and than ASCII because ASCII is not very interesting) and try non-ASCII module names. The patch includes issue3080.py: set the locale to fr_FR.iso88591 to have ISO-8859-1 as locale encoding and try to load a module called 'issue3080\xE4'. U+00E4 is encoded to b'\xE4' in ISO-8859-1 and b'\xC3\xA4' to UTF-8.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3080>
_______________________________________

From report at bugs.python.org  Fri Jan 21 18:08:45 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 21 Jan 2011 17:08:45 +0000
Subject: [issue3080] Full unicode import system
In-Reply-To: <1213208697.49.0.984990811807.issue3080@psf.upfronthosting.co.za>
Message-ID: <1295629725.81.0.474049512742.issue3080@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

I tried issue3080-5.patch. The whole test suite pass on Windows. It pass also on Linux with "-Wd -Werror -R 3:3:" (except #10971 which is unrelated to this issue).

I should maybe add some unit tests for non-ASCII module paths and non-ASCII module names :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3080>
_______________________________________

From report at bugs.python.org  Fri Jan 21 18:10:02 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 21 Jan 2011 17:10:02 +0000
Subject: [issue8754] ImportError: quote bad module name in message
In-Reply-To: <1274202200.16.0.392487565261.issue8754@psf.upfronthosting.co.za>
Message-ID: <1295629802.25.0.278237772232.issue8754@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

My patch for #3080 uses repr() to format module name in all error messages.

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8754>
_______________________________________

From report at bugs.python.org  Fri Jan 21 18:18:11 2011
From: report at bugs.python.org (Ned Deily)
Date: Fri, 21 Jan 2011 17:18:11 +0000
Subject: =?utf-8?q?=5Bissue10973=5D_=27=C3=B1=27_not_working_with_IDLE_3=2E2rc1_-_?=
	=?utf-8?q?OSX_10=2E6=2E6?=
In-Reply-To: <1295620061.05.0.0288010484186.issue10973@psf.upfronthosting.co.za>
Message-ID: <1295630291.11.0.327211751805.issue10973@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

(Regarding the second problem: if IDLE does not launch when you double-click on it, please check for and report any error messages from /var/log/system.log at the time. You can use /Applications/Utilities/Console.app to view system.log.)

----------
assignee:  -> ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10973>
_______________________________________

From report at bugs.python.org  Fri Jan 21 19:00:06 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 21 Jan 2011 18:00:06 +0000
Subject: [issue10972] zipfile: add "unicode" option to the force the filename
	encoding to UTF-8
In-Reply-To: <1295611245.09.0.199855932712.issue10972@psf.upfronthosting.co.za>
Message-ID: <1295632806.53.0.861037021617.issue10972@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

This looks similar to issue10614

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10972>
_______________________________________

From report at bugs.python.org  Fri Jan 21 19:13:29 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 21 Jan 2011 18:13:29 +0000
Subject: [issue3080] Full unicode import system
In-Reply-To: <1295629725.81.0.474049512742.issue3080@psf.upfronthosting.co.za>
Message-ID: <AANLkTi=Tc6DaNy1rC6tfRDsusYc6p=0e5oW2AqOXJ7q+@mail.gmail.com>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

On Sat, Jan 22, 2011 at 3:08 AM, STINNER Victor <report at bugs.python.org> wrote:
> I should maybe add some unit tests for non-ASCII module paths and non-ASCII module names :-)

Indeed. There are a few tests in test_runpy that could be adapted to
that task fairly easily (it creates the test packages at run time in a
temporary directory, so copying that to make a non-ASCII path and
module name test should be too difficult).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3080>
_______________________________________

From report at bugs.python.org  Fri Jan 21 19:19:54 2011
From: report at bugs.python.org (Phillip J. Eby)
Date: Fri, 21 Jan 2011 18:19:54 +0000
Subject: [issue10935] wsgiref.handlers.BaseHandler and subclasses of str
In-Reply-To: <1295371764.49.0.785710350986.issue10935@psf.upfronthosting.co.za>
Message-ID: <1295633994.15.0.250728025678.issue10935@psf.upfronthosting.co.za>


Phillip J. Eby <pje at telecommunity.com> added the comment:

1. WSGI is a *Python* spec, not a *CPython* spec, so CPython implementation details have little bearing on how the spec should work.

Most non-CPython implementations have a native string type optimized for their runtime or VM (i.e. Jython and IronPython), and thus have *different* implementation-dependent details of what constitutes a "native" string, other than that it has type 'str' as seen by Python code.  (See my previous point about people bringing these sorts of implicit assumptions to the table!)

(Also, as you may or may not be aware, WSGI supports Python 2.1, mainly for Jython's sake at the time, and in Python 2.1 there was *no such thing* as a subclass of 'str' to begin with.)

2. The specific practical goal of WSGI is interoperability, *not* programmer convenience.  (Says so right in the PEP.)

3. You are free to patch wsgiref's Headers class to *accept* non-str values (as long as they are converted to conforming strings in the process) and to make any proposals you like for future versions of WSGI or another interop protocol via the Web-SIG, so this entire discussion has been moot for some time now.

4. The explicit-vs-implicit is about the contract defined in the spec (making explicit what, precisely, is required of both parties), not the type test.

5. Since this discussion is moot (see point 3), we'll have to agree to disagree here.  Whether you (or I!) like what the spec says is not what matters: wsgiref is the *reference library* for the specification, and therefore must conform to the actual spec, not what any of us would like the spec to be.

Heck, I tried to add some *much* more minor amendments to PEP 333 than this about three or four months ago, and Guido said he'd reject the whole PEP if I tried!  That's why we have PEP 3333 instead of a slightly-amended PEP 333.  This particular bikeshed was painted six years ago, so let's get on with the actual bicycling already.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10935>
_______________________________________

From report at bugs.python.org  Fri Jan 21 19:26:32 2011
From: report at bugs.python.org (Nestor Aguilera)
Date: Fri, 21 Jan 2011 18:26:32 +0000
Subject: =?utf-8?q?=5Bissue10973=5D_=27=C3=B1=27_not_working_with_IDLE_3=2E2rc1_-_?=
	=?utf-8?q?OSX_10=2E6=2E6?=
In-Reply-To: <1295630291.11.0.327211751805.issue10973@psf.upfronthosting.co.za>
Message-ID: <1E34ACCF-6E58-4317-A0F2-558FB0DD8BCC@santafe-conicet.gov.ar>


Nestor Aguilera <aguilera at santafe-conicet.gov.ar> added the comment:

Thanks Victor and Ned, I'll send a report on the second issue as well (I thought it was known).

N?stor Aguilera

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10973>
_______________________________________

From report at bugs.python.org  Fri Jan 21 19:36:13 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 21 Jan 2011 18:36:13 +0000
Subject: [issue10968] threading.Timer should be a class so that it can be
	derived
In-Reply-To: <1295574501.95.0.0935688829986.issue10968@psf.upfronthosting.co.za>
Message-ID: <1295634973.39.0.282747822816.issue10968@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Adding Guido, who checked the module in, to nosy.

Guido: Could you tell us whether the fake classes in threading.py should stay as is or can be fixed?  The whole _Verbose business and Thing/_Thing indirection seem a bit outdated and unneeded.

----------
nosy: +eric.araujo, gvanrossum

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10968>
_______________________________________

From report at bugs.python.org  Fri Jan 21 19:40:55 2011
From: report at bugs.python.org (Nestor Aguilera)
Date: Fri, 21 Jan 2011 18:40:55 +0000
Subject: [issue10974] IDLE 3.2 not loading on double-click in Finder, OSX 10.6
In-Reply-To: <1295635255.29.0.478257321345.issue10974@psf.upfronthosting.co.za>
Message-ID: <1295635255.29.0.478257321345.issue10974@psf.upfronthosting.co.za>


New submission from Nestor Aguilera <aguilera at santafe-conicet.gov.ar>:

Here is the report from "Console" (date/time removed):

[0x0-0x1a11a1].org.python.IDLE[5541]	Traceback (most recent call last):
[0x0-0x1a11a1].org.python.IDLE[5541]	  File "/Applications/Python 3.2/IDLE.app/Contents/Resources/idlemain.py", line 73, in <module>
[0x0-0x1a11a1].org.python.IDLE[5541]	    main()
[0x0-0x1a11a1].org.python.IDLE[5541]	  File "/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/idlelib/PyShell.py", line 1388, in main
[0x0-0x1a11a1].org.python.IDLE[5541]	    shell = flist.open_shell()
[0x0-0x1a11a1].org.python.IDLE[5541]	  File "/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/idlelib/PyShell.py", line 277, in open_shell
[0x0-0x1a11a1].org.python.IDLE[5541]	    self.pyshell = PyShell(self)
[0x0-0x1a11a1].org.python.IDLE[5541]	  File "/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/idlelib/PyShell.py", line 813, in __init__
[0x0-0x1a11a1].org.python.IDLE[5541]	    OutputWindow.__init__(self, flist, None, None)
[0x0-0x1a11a1].org.python.IDLE[5541]	  File "/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/idlelib/OutputWindow.py", line 16, in __init__
[0x0-0x1a11a1].org.python.IDLE[5541]	    EditorWindow.__init__(self, *args)
[0x0-0x1a11a1].org.python.IDLE[5541]	  File "/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/idlelib/EditorWindow.py", line 267, in __init__
[0x0-0x1a11a1].org.python.IDLE[5541]	    self.update_recent_files_list()
[0x0-0x1a11a1].org.python.IDLE[5541]	  File "/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/idlelib/EditorWindow.py", line 777, in update_recent_files_list
[0x0-0x1a11a1].org.python.IDLE[5541]	    rf_list = rf_list_file.readlines()
[0x0-0x1a11a1].org.python.IDLE[5541]	  File "/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/encodings/ascii.py", line 26, in decode
[0x0-0x1a11a1].org.python.IDLE[5541]	    return codecs.ascii_decode(input, self.errors)[0]
[0x0-0x1a11a1].org.python.IDLE[5541]	UnicodeDecodeError: 'ascii' codec can't decode byte 0xcc in position 55: ordinal not in range(128)
com.apple.launchd.peruser.501[168]	([0x0-0x1a11a1].org.python.IDLE[5541]) Exited with exit code: 1

Thanks,

N?stor Aguilera

----------
components: IDLE
messages: 126764
nosy: naguilera
priority: normal
severity: normal
status: open
title: IDLE 3.2 not loading on double-click in Finder, OSX 10.6
type: crash
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10974>
_______________________________________

From report at bugs.python.org  Fri Jan 21 19:46:05 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 21 Jan 2011 18:46:05 +0000
Subject: [issue10975] #10961: Pydoc touchups in new 3.2 Web server
	(issue4090042)
In-Reply-To: <00221532cc70620113049a5fa977@google.com>
Message-ID: <00221532cc70620113049a5fa977@google.com>


New submission from ?ric Araujo <merwok at netwok.org>:

Some comments.  Haven?t tested the patch yet.

http://codereview.appspot.com/4090042/diff/1/Lib/pydoc.py
File Lib/pydoc.py (right):

http://codereview.appspot.com/4090042/diff/1/Lib/pydoc.py#newcode2507
Lib/pydoc.py:2507: <div style='overflow:auto'>
Does this work fine with common Web browsers, including not-most-recent
versions, and various resolutions?  (?fine? being defined as ?not worse
than before the patch?)

http://codereview.appspot.com/4090042/diff/1/Lib/pydoc.py#newcode2591
Lib/pydoc.py:2591: return '<a href="topic?key=%s.html">%s</a>' % (name,
name)
I see no reason for polluting the key value with ?.html?

http://codereview.appspot.com/4090042/diff/1/Lib/pydoc.py#newcode2713
Lib/pydoc.py:2713: raise TypeError('unknown content type %r' % ([url,
content_type]))
You can remove the extraneous parens around the list.

http://codereview.appspot.com/4090042/diff/1/Lib/test/test_pydoc.py
File Lib/test/test_pydoc.py (right):

http://codereview.appspot.com/4090042/diff/1/Lib/test/test_pydoc.py#newcode431
Lib/test/test_pydoc.py:431: ("", "PyDoc: Index of Modules"),
I?m not sure ?PyDoc? is better than ?Python?.  What about ?Python Doc??
Very clear and still short.

http://codereview.appspot.com/4090042/

----------
messages: 126765
nosy: eric.araujo
priority: normal
severity: normal
status: open
title: #10961: Pydoc touchups in new 3.2 Web server (issue4090042)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10975>
_______________________________________

From report at bugs.python.org  Fri Jan 21 19:48:34 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 21 Jan 2011 18:48:34 +0000
Subject: [issue10975] #10961: Pydoc touchups in new 3.2 Web server
	(issue4090042)
In-Reply-To: <00221532cc70620113049a5fa977@google.com>
Message-ID: <1295635714.68.0.00631985112688.issue10975@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

One day, email from rietveld will go to the right roundup report.

----------
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10975>
_______________________________________

From report at bugs.python.org  Fri Jan 21 19:49:32 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 21 Jan 2011 18:49:32 +0000
Subject: [issue10961] Pydoc touchups in new browser for 3.2
In-Reply-To: <1295545738.06.0.604274599052.issue10961@psf.upfronthosting.co.za>
Message-ID: <1295635772.89.0.555632103451.issue10961@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Some comments on http://codereview.appspot.com/4090042

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10961>
_______________________________________

From report at bugs.python.org  Fri Jan 21 19:51:11 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 21 Jan 2011 18:51:11 +0000
Subject: [issue9723] pipes.quote() needs to be documented
In-Reply-To: <1283262014.72.0.527039259842.issue9723@psf.upfronthosting.co.za>
Message-ID: <1295635871.51.0.598749848186.issue9723@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Why do you want to move quote from pipes to shlex?  The function is available, the issue here is lack of documentation.

----------
stage:  -> unit test needed
type: feature request -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9723>
_______________________________________

From report at bugs.python.org  Fri Jan 21 19:52:28 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 21 Jan 2011 18:52:28 +0000
Subject: [issue10936] Simple CSS fix for left margin at docs.python.org
In-Reply-To: <1295377924.0.0.902429691003.issue10936@psf.upfronthosting.co.za>
Message-ID: <1295635948.06.0.148770025422.issue10936@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Also, laptops and handheld devices have a limited screen size.

-1 on a pop-up, for obvious usability reasons.

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10936>
_______________________________________

From report at bugs.python.org  Fri Jan 21 19:52:38 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 21 Jan 2011 18:52:38 +0000
Subject: [issue9723] pipes.quote() needs to be documented
In-Reply-To: <1283262014.72.0.527039259842.issue9723@psf.upfronthosting.co.za>
Message-ID: <1295635958.27.0.67729297689.issue9723@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
stage: unit test needed -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9723>
_______________________________________

From report at bugs.python.org  Fri Jan 21 19:57:46 2011
From: report at bugs.python.org (Christopher Dunn)
Date: Fri, 21 Jan 2011 18:57:46 +0000
Subject: [issue10936] Simple CSS fix for left margin at docs.python.org
In-Reply-To: <1295377924.0.0.902429691003.issue10936@psf.upfronthosting.co.za>
Message-ID: <1295636266.22.0.446066441019.issue10936@psf.upfronthosting.co.za>


Christopher Dunn <cdunn2001 at gmail.com> added the comment:

@eric.araujo:

Not a 'pop-up', that you would have to click to close. But something dynamic, based on mouse location.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10936>
_______________________________________

From report at bugs.python.org  Fri Jan 21 19:59:49 2011
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 21 Jan 2011 18:59:49 +0000
Subject: [issue10968] threading.Timer should be a class so that it can be
	derived
In-Reply-To: <1295574501.95.0.0935688829986.issue10968@psf.upfronthosting.co.za>
Message-ID: <1295636389.38.0.725041872975.issue10968@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

IIRC:

The design started out this way because it predates new-style classes. When this was put in one couldn't subclass extension types, and there were plans/hopes to replace some of the lock types with platform-specific built-in versions on some platforms.

Since it is now possible to write subclassable extension types the Thing/_Thing design is no longer needed.

I'm not sure about the _Verbose hacks, if it is deemed not useful I'm fine with letting it go.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10968>
_______________________________________

From report at bugs.python.org  Fri Jan 21 20:01:49 2011
From: report at bugs.python.org (hhas)
Date: Fri, 21 Jan 2011 19:01:49 +0000
Subject: [issue10976] json.loads() throws TypeError on bytes object
In-Reply-To: <1295636509.41.0.0138366952356.issue10976@psf.upfronthosting.co.za>
Message-ID: <1295636509.41.0.0138366952356.issue10976@psf.upfronthosting.co.za>


New submission from hhas <hhas at users.sourceforge.net>:

json.loads() accepts strings but errors on bytes objects. Documentation and API indicate that both should work. Review of json/__init__.py code shows that the loads() function's 'encoding' arg is ignored and no decoding takes place before the object is passed to JSONDecoder.decode()

Tested on Python 3.1.2 and Python 3.2rc1; fails on both. 

Example:

#################################################

#!/usr/local/bin/python3.2

import json

print(json.loads('123'))
# 123

print(json.loads(b'123'))
# /Library/Frameworks/Python.framework/Versions/3.1/lib/python3.1/json/decoder.py:325:  
#   TypeError: can't use a string pattern on a bytes-like object

print(json.loads(b'123', encoding='utf-8'))
# /Library/Frameworks/Python.framework/Versions/3.1/lib/python3.1/json/decoder.py:325:  
#   TypeError: can't use a string pattern on a bytes-like object

#################################################

Patch attached.

----------
components: Library (Lib)
files: json.diff
keywords: patch
messages: 126772
nosy: hhas
priority: normal
severity: normal
status: open
title: json.loads() throws TypeError on bytes object
type: behavior
versions: Python 3.1, Python 3.2
Added file: http://bugs.python.org/file20481/json.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10976>
_______________________________________

From report at bugs.python.org  Fri Jan 21 20:14:53 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 21 Jan 2011 19:14:53 +0000
Subject: [issue10948] Trouble with dir_util created dir cache
In-Reply-To: <1295456838.39.0.734609669589.issue10948@psf.upfronthosting.co.za>
Message-ID: <1295637293.34.0.490467024714.issue10948@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> So It is better to define what a "public function" is.
That is no easy task.  See #10894 for a general discussion.  For the particular case of distutils, there is no distinction between internal helpers that we should be free to change and public functions provided to third-party code.  That?s one of the reasons we had to fork under a new name to have a chance to clean things up (i.e. make nearly everything private).

> If new people get involved in distutils development they will need to
> read all the code, line by line and every comment, because the old
> developers decided not to document the inner workings of its functions.
A lot of people have bee learning distutils internals in recent years: Tarek, the current maintainer; hackers from Montreal; Google Summer of Code students like me.  So it is possible to get involved with distutils, starting with one area (network code, or versions and dependencies, or commands, or compilers...).  That said, I agree the doc is very lacking, and improving it is one of my big goals for distutils2 in Python 3.3.  (I will give priority to important user-facing functions and classes over helpers like mkpath, however.)

> Well, I know nothing about this. However, if you tell me that
> distutils2 will replace distutils, I may agree with you and distutils
> just needs to be deprecated. Otherwise, I keep my opinion.
distutils is frozen and only gets bug fixes; distutils2 is a fork where we can break compatibility to fix the design and behavior.  More information on http://tarekziade.wordpress.com/2010/03/03/the-fate-of-distutils-pycon-summit-packaging-sprint-detailed-report/

I am now closing this issue.  If I have misunderstood your last message and you?re not satisfied with that, please reopen.  Thanks again for your report, and don?t hesitate to report any bug you may find in the future.

----------
resolution:  -> works for me
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10948>
_______________________________________

From report at bugs.python.org  Fri Jan 21 20:15:29 2011
From: report at bugs.python.org (Christopher Dunn)
Date: Fri, 21 Jan 2011 19:15:29 +0000
Subject: [issue10936] Simple CSS fix for left margin at docs.python.org
In-Reply-To: <1295377924.0.0.902429691003.issue10936@psf.upfronthosting.co.za>
Message-ID: <1295637329.42.0.373580467958.issue10936@psf.upfronthosting.co.za>


Christopher Dunn <cdunn2001 at gmail.com> added the comment:

I was just trying to help fix the CSS, and I think I've done that.

If we're reconsidering the behavior of the nav sidebar, then I'd like to point out that if you're far down the page, the sidebar is blank to your right. From a usability point of view, it's already broken. It was a neat idea, but a ToC for the page would serve the purpose better.

My monitor is quite large, and rotated 90 degrees, so it's narrow and tall. A web-page can be infinitely long, but its practical width is limited to the user's screen, which is different for every user. That's why HTML was designed the way it is, with auto-word-wrap.

When you have a bunch of stuff that you want to fit within a window, a sidebar makes more sense. For Python docs, I'd vote to drop it altogether, as attractive-looking as it is.

But if you really want it, give it its own vertical scrollbar, so that a relevant portion is always visible. Then people can talk about dynamic controls.

That's just my opinion. I created this bug because, when I zoon, the sidebar consumes most of my screen with no visible text. It's such a huge problem that I was afraid someone had already submitted this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10936>
_______________________________________

From report at bugs.python.org  Fri Jan 21 20:34:01 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Fri, 21 Jan 2011 19:34:01 +0000
Subject: [issue10822] test_getgroups failure under Solaris
In-Reply-To: <1294139319.03.0.190267830849.issue10822@psf.upfronthosting.co.za>
Message-ID: <1295638441.59.0.926608986229.issue10822@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

Antoine, can you confirm that the problem is solved, and mark this issue as closed/fixed?.

Thanks.

----------
nosy:  -rosslagerwall
resolution: fixed -> 
stage: committed/rejected -> needs patch
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10822>
_______________________________________

From report at bugs.python.org  Fri Jan 21 20:34:23 2011
From: report at bugs.python.org (R. David Murray)
Date: Fri, 21 Jan 2011 19:34:23 +0000
Subject: [issue10935] wsgiref.handlers.BaseHandler and subclasses of str
In-Reply-To: <1295371764.49.0.785710350986.issue10935@psf.upfronthosting.co.za>
Message-ID: <1295638463.11.0.0235683942534.issue10935@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

> 4. The explicit-vs-implicit is about the contract defined in the spec (making explicit what, precisely, is required of both parties), not the type test.

Perhaps a clarification in the (3333) spec that 'type str' means "type(s) is str" would be in order, then, since this discussion makes it clear that "type str" in English can also mean "isinstance(s, str)".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10935>
_______________________________________

From report at bugs.python.org  Fri Jan 21 20:38:19 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Fri, 21 Jan 2011 19:38:19 +0000
Subject: [issue10822] test_getgroups failure under Solaris
In-Reply-To: <1294139319.03.0.190267830849.issue10822@psf.upfronthosting.co.za>
Message-ID: <1295638699.38.0.726366089739.issue10822@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

Sorry, Firefox insists in cache-ing the tracker, with bad results.

I beg your pardon.

----------
nosy: +rosslagerwall
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10822>
_______________________________________

From report at bugs.python.org  Fri Jan 21 21:07:38 2011
From: report at bugs.python.org (R. David Murray)
Date: Fri, 21 Jan 2011 20:07:38 +0000
Subject: [issue10966] eliminate use of ImportError implicitly representing
	TestSkipped
In-Reply-To: <1295566830.75.0.786153857799.issue10966@psf.upfronthosting.co.za>
Message-ID: <1295640458.24.0.648768796039.issue10966@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

How is this different from issue 2409?

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10966>
_______________________________________

From report at bugs.python.org  Fri Jan 21 21:12:18 2011
From: report at bugs.python.org (R. David Murray)
Date: Fri, 21 Jan 2011 20:12:18 +0000
Subject: [issue10966] eliminate use of ImportError implicitly representing
	TestSkipped
In-Reply-To: <1295566830.75.0.786153857799.issue10966@psf.upfronthosting.co.za>
Message-ID: <1295640738.44.0.805689863391.issue10966@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

On second reading I see one way it is different: you suggest to move the list of expected skips out of regrtest.  So, are you suggesting, essentially, that support.import_module be replaced by an optional_import that takes arguments to indicate on which platforms the skip is expected?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10966>
_______________________________________

From report at bugs.python.org  Fri Jan 21 21:20:23 2011
From: report at bugs.python.org (R. David Murray)
Date: Fri, 21 Jan 2011 20:20:23 +0000
Subject: [issue10967] move regrtest over to using more unittest infrastructure
In-Reply-To: <1295567145.8.0.568957178125.issue10967@psf.upfronthosting.co.za>
Message-ID: <1295641223.21.0.481577217315.issue10967@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I think we have already been moving in this director for quite some time.  Past policy is to only change things when we are working on that area of code anyway.  If someone wants to make some specific proposals to simplify regrtest by doing a wholesale move of test code away from a regrtest supported infrastructure to a unittest supported infrastructure, I think that's worth considering, but I think it should be done bit by bit with specific proposals to replace specific regrtest features.

Extending regrtest to support unittest test discovery directly is also a worthwhile specific proposal.

Do you intend this issue to be an "index issue" that links to issues with specific proposals?

(Note: see also the closely related issue 8273).

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10967>
_______________________________________

From report at bugs.python.org  Fri Jan 21 21:21:45 2011
From: report at bugs.python.org (R. David Murray)
Date: Fri, 21 Jan 2011 20:21:45 +0000
Subject: [issue10967] move regrtest over to using more unittest infrastructure
In-Reply-To: <1295567145.8.0.568957178125.issue10967@psf.upfronthosting.co.za>
Message-ID: <1295641305.1.0.886105935555.issue10967@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I think we have already been moving in this direction for quite some time.  Past policy is to only change things when we are working on that area of code anyway.  If someone wants to make some specific proposals to simplify regrtest by doing a wholesale move of test code away from a regrtest supported infrastructure to a unittest supported infrastructure, I think that's worth considering, but I think it should be done bit by bit with specific proposals to replace specific regrtest features.

Extending regrtest to support unittest test discovery directly is also a worthwhile specific proposal.

Do you intend this issue to be an "index issue" that links to issues with specific proposals?

(Note: see also the closely related issue 8273).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10967>
_______________________________________

From report at bugs.python.org  Fri Jan 21 21:21:50 2011
From: report at bugs.python.org (R. David Murray)
Date: Fri, 21 Jan 2011 20:21:50 +0000
Subject: [issue10967] move regrtest over to using more unittest infrastructure
In-Reply-To: <1295567145.8.0.568957178125.issue10967@psf.upfronthosting.co.za>
Message-ID: <1295641310.7.0.94936476686.issue10967@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
Removed message: http://bugs.python.org/msg126780

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10967>
_______________________________________

From report at bugs.python.org  Fri Jan 21 21:35:34 2011
From: report at bugs.python.org (R. David Murray)
Date: Fri, 21 Jan 2011 20:35:34 +0000
Subject: [issue10976] json.loads() throws TypeError on bytes object
In-Reply-To: <1295636509.41.0.0138366952356.issue10976@psf.upfronthosting.co.za>
Message-ID: <1295642134.19.0.557682115632.issue10976@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Hmm.  According to issue 4136, all bytes support was supposed to have been removed.

----------
nosy: +pitrou, r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10976>
_______________________________________

From report at bugs.python.org  Fri Jan 21 21:37:39 2011
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 21 Jan 2011 20:37:39 +0000
Subject: [issue10966] eliminate use of ImportError implicitly representing
	TestSkipped
In-Reply-To: <1295566830.75.0.786153857799.issue10966@psf.upfronthosting.co.za>
Message-ID: <1295642259.69.0.0852497793818.issue10966@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Yes. So for _winreg (if we even have tests) it would be skipped on all OSs other than Windows, on on Windows it would be a test failure if it didn't work as it is expected to exist.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10966>
_______________________________________

From report at bugs.python.org  Fri Jan 21 21:39:54 2011
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 21 Jan 2011 20:39:54 +0000
Subject: [issue10967] move regrtest over to using more unittest infrastructure
In-Reply-To: <1295567145.8.0.568957178125.issue10967@psf.upfronthosting.co.za>
Message-ID: <1295642394.71.0.608168893336.issue10967@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Yes, I somewhat view this as an index issue. I don't expect a wholesale move but a more step-by-step move.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10967>
_______________________________________

From report at bugs.python.org  Fri Jan 21 21:45:30 2011
From: report at bugs.python.org (Forest Wilkinson)
Date: Fri, 21 Jan 2011 20:45:30 +0000
Subject: [issue3831] Multiprocessing: Expose underlying pipe in queues
In-Reply-To: <1221095639.45.0.136100950642.issue3831@psf.upfronthosting.co.za>
Message-ID: <1295642730.17.0.452982998866.issue3831@psf.upfronthosting.co.za>


Changes by Forest Wilkinson <python1 at tibit.com>:


----------
nosy: +forest

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3831>
_______________________________________

From report at bugs.python.org  Fri Jan 21 21:46:51 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 21 Jan 2011 20:46:51 +0000
Subject: [issue10976] json.loads() throws TypeError on bytes object
In-Reply-To: <1295636509.41.0.0138366952356.issue10976@psf.upfronthosting.co.za>
Message-ID: <1295642811.72.0.661510305904.issue10976@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Indeed, the documentation (and function docstring) needs fixing instead. It's a pity we didn't remove the useless `encoding` parameter.

----------
assignee:  -> docs at python
components: +Documentation -Library (Lib)
nosy: +docs at python

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10976>
_______________________________________

From report at bugs.python.org  Fri Jan 21 21:54:36 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 21 Jan 2011 20:54:36 +0000
Subject: [issue10976] json.loads() throws TypeError on bytes object
In-Reply-To: <1295636509.41.0.0138366952356.issue10976@psf.upfronthosting.co.za>
Message-ID: <1295643276.8.0.909709903601.issue10976@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Georg: Is it still time to deprecate the encoding parameter in 3.2?

----------
nosy: +eric.araujo, georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10976>
_______________________________________

From report at bugs.python.org  Fri Jan 21 21:58:07 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 21 Jan 2011 20:58:07 +0000
Subject: [issue10042] total_ordering stack overflow
In-Reply-To: <1286440012.74.0.624864175042.issue10042@psf.upfronthosting.co.za>
Message-ID: <1295643487.05.0.192917156449.issue10042@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
status: closed -> open
versions: +Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10042>
_______________________________________

From report at bugs.python.org  Fri Jan 21 22:27:14 2011
From: report at bugs.python.org (R. David Murray)
Date: Fri, 21 Jan 2011 21:27:14 +0000
Subject: [issue10966] eliminate use of ImportError implicitly representing
	TestSkipped
In-Reply-To: <1295566830.75.0.786153857799.issue10966@psf.upfronthosting.co.za>
Message-ID: <1295645234.66.0.42559490766.issue10966@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Ah, I see what you are getting at now.  I was confused by the "raise SkipTest directly" part, since the test suite currently does raise SkipTest instead of ImportError.  So the key change here is to make the test show as a *failure* on those platforms where it is currently reported as an unexpected skip.  We can then eliminate the whole "these skips are expected" bit from regrtest.  That would be a very nice cleanup.

I'm going to mark this as easy, since it is basically a mechanical transformation from the expected skip list in regrtest to calls to a fairly simple new test.support function, and then ripping the obsolete code out of regrtest.  Tedious, but doable in a day.

----------
keywords: +easy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10966>
_______________________________________

From report at bugs.python.org  Fri Jan 21 22:38:08 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 21 Jan 2011 21:38:08 +0000
Subject: [issue10976] json.loads() throws TypeError on bytes object
In-Reply-To: <1295636509.41.0.0138366952356.issue10976@psf.upfronthosting.co.za>
Message-ID: <1295645888.73.0.507443717354.issue10976@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I've committed a doc fix in r88137.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10976>
_______________________________________

From report at bugs.python.org  Fri Jan 21 22:43:11 2011
From: report at bugs.python.org (R. David Murray)
Date: Fri, 21 Jan 2011 21:43:11 +0000
Subject: [issue10943] abitype: Need better support to port C extension modules
	to the stable C API
In-Reply-To: <1295426330.25.0.635363870245.issue10943@psf.upfronthosting.co.za>
Message-ID: <1295646191.16.0.352893643324.issue10943@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10943>
_______________________________________

From report at bugs.python.org  Fri Jan 21 22:48:44 2011
From: report at bugs.python.org (R. David Murray)
Date: Fri, 21 Jan 2011 21:48:44 +0000
Subject: [issue10949] logging.RotatingFileHandler not robust enough
In-Reply-To: <1295457072.71.0.821420961283.issue10949@psf.upfronthosting.co.za>
Message-ID: <1295646524.32.0.375279538591.issue10949@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
nosy: +vinay.sajip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10949>
_______________________________________

From report at bugs.python.org  Fri Jan 21 23:08:43 2011
From: report at bugs.python.org (R. David Murray)
Date: Fri, 21 Jan 2011 22:08:43 +0000
Subject: [issue10960] os.stat() does not mention that it follow symlinks by
	default
In-Reply-To: <1295544486.66.0.118119387237.issue10960@psf.upfronthosting.co.za>
Message-ID: <1295647723.11.0.479553810917.issue10960@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I almost closed this as invalid, since the name is, after all 'os.stat' and the docs clearly say that it calls the 'stat' system call.  However, I see that our docs do not contain the more explicit language used by the 'stat' system call docs: "stats the file pointed to by path".  Although even that isn't crystal clear unless you also read the definition of 'lstat' right below it.  If you read our docs for lstat it does become clear even as things stand, but lstat isn't right below stat in our docs.

So on reflection I think the docs could use improvement in this area.

----------
nosy: +r.david.murray
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10960>
_______________________________________

From report at bugs.python.org  Fri Jan 21 23:34:51 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 21 Jan 2011 22:34:51 +0000
Subject: [issue10909] thread hang, possibly related to print
In-Reply-To: <1295026647.31.0.671636636712.issue10909@psf.upfronthosting.co.za>
Message-ID: <1295649291.37.0.925154383957.issue10909@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

What happens if you run your program without IDLE? 
(either with right-click and run or run from Command Prompt window?) 

I would not be surprised if your problems go away. IDLE runs a saved file in a separate pythonw process. Printing (or writing) to stdout requires sending output back to the IDLE process. I can imagine that doing that from 2 subthreads could lead to conflicts.

If the problems do go away, then we should probably close this as won't fix. IDLE is a development environment, not a production running environment

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10909>
_______________________________________

From report at bugs.python.org  Fri Jan 21 23:39:18 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 21 Jan 2011 22:39:18 +0000
Subject: [issue10614] ZipFile and CP932 encoding
In-Reply-To: <1291362121.18.0.976785403189.issue10614@psf.upfronthosting.co.za>
Message-ID: <1295649558.2.0.915282022743.issue10614@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

In #10972, I propose to add an option for the filename encoding to UTF-8. But I would like to force UTF-8 to create a ZIP file, it doesn't concern the decompression of a ZIP file.

Proposal of a specification to fix both issues at the same time.


"default_encoding" name is confusing because it doesn't specify if it is the encoding of (text?) file content or the encoding the filename. Why not simply "filename_encoding"?

The option can be added in multiple places:
 - argument to ZipFile constructor: this is needed to decompress
 - argument to ZipFile.write() and ZipInfo, because they are 3 different manners to add files

ZipFile.filename_encoding (and ZipInfo.filename_encoding) will be None by default: in this case, use the current algorithm (try cp437 or use UTF-8). Otherwise, use the encoding. If the encoding is UTF-8: set unicode flag.

Examples:
---
zipfile.ZipFile("non-ascii-cp932.zip", filename_encoding="cp932")

f = zipfile.ZipFile("test.zip", "w")
f.write(filename, filename_encoding="UTF-8")
info = ZipInfo(filename, filename_encoding="UTF-8")
f.writestr(info, b'data')
---

Don't add filename_encoding argument to ZipFile.writestr(), because it may conflict if a ZipInfo is passed and ZipInfo.filename_encoding and filename_encoding are different.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10614>
_______________________________________

From report at bugs.python.org  Fri Jan 21 23:54:48 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 21 Jan 2011 22:54:48 +0000
Subject: [issue10922] Unexpected exception when calling
	function_proxy.__class__.__call__(function_proxy)
In-Reply-To: <1295230218.02.0.641570555776.issue10922@psf.upfronthosting.co.za>
Message-ID: <1295650488.19.0.294726136155.issue10922@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
versions:  -Python 2.5, Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10922>
_______________________________________

From report at bugs.python.org  Sat Jan 22 00:06:40 2011
From: report at bugs.python.org (Scott M)
Date: Fri, 21 Jan 2011 23:06:40 +0000
Subject: [issue10909] thread hang, possibly related to print
In-Reply-To: <1295649291.37.0.925154383957.issue10909@psf.upfronthosting.co.za>
Message-ID: <000001cbb9bf$d5a2cee0$80e86ca0$@mayo@comcast.net>


Scott M <scott.mayo at comcast.net> added the comment:

It hasn't failed yet when run "straight".

Here's the issue, though. I'm going to be introducing Python as the scripting language of choice, to a bunch of people who are less than fluent in programming. Because debugging is not an obvious concept to them, they are going to hunt for problems by sticking in print statements everywhere, and the environment is inherently multithreaded, so it's hard for me to imagine they won't experience this bug. I hit it in my very first multithreaded experiment. And I can't possibly ask them not to use IDLE - without syntax coloring and a friendly editor to show them which line is wrong, they will never get off the ground.

It would be tolerable if there was at least a traceback, but if threads vanish silently, they will not realize it's a environment problem; they will either assume that they did something inexplicably wrong and that "scripting is too hard", or it will get around that I provided a "broken" solution.

So even if it's "just the IDE", it's still life and death for this project. "Won't fix" probably means I have to abandon Python.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10909>
_______________________________________

From report at bugs.python.org  Sat Jan 22 00:18:37 2011
From: report at bugs.python.org (Ron Adam)
Date: Fri, 21 Jan 2011 23:18:37 +0000
Subject: [issue10961] Pydoc touchups in new browser for 3.2
In-Reply-To: <1295545738.06.0.604274599052.issue10961@psf.upfronthosting.co.za>
Message-ID: <1295651917.59.0.898420353309.issue10961@psf.upfronthosting.co.za>


Ron Adam <ron_adam at users.sourceforge.net> added the comment:

George, My apologies to you for the late corrections.  And thanks for doing this.

Eric, I replied to your comments on Rietveld.  Thanks for taking a look.

I'll wait until you have a chance to reply and test it, then upload a new patch with any needed changes.

Ron

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10961>
_______________________________________

From report at bugs.python.org  Sat Jan 22 00:28:51 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 21 Jan 2011 23:28:51 +0000
Subject: [issue10925] Document pure Python version of integer-to-float
	correctly-rounded conversion
In-Reply-To: <1295269244.12.0.126728941356.issue10925@psf.upfronthosting.co.za>
Message-ID: <1295652531.26.0.3174804999.issue10925@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I see there is already something similar for true division.

I find
+    q_max, shift_max = 1 << sig_bits, sys.float_info.max_exp - sig_bits
easier to read as two lines
+    q_max = 1 << sig_bits
+    shift_max = sys.float_info.max_exp - sig_bits

Not having precedence memorized, I prefer added parens here:
+ ...  (n >> shift) | bool(n & (1 << shift) - 1)

I presume that for normal production testing, you would comment out
+       float = long_to_float

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10925>
_______________________________________

From report at bugs.python.org  Sat Jan 22 00:37:26 2011
From: report at bugs.python.org (Rafe Kettler)
Date: Fri, 21 Jan 2011 23:37:26 +0000
Subject: [issue10957] Python FAQ grammar error
In-Reply-To: <1295541255.37.0.868919325173.issue10957@psf.upfronthosting.co.za>
Message-ID: <1295653046.34.0.476784132024.issue10957@psf.upfronthosting.co.za>


Rafe Kettler <rafe.kettler at gmail.com> added the comment:

>for a faster compile
Compile isn't a noun; the most grammatically correct sentences would be "for faster compilation."

----------
nosy: +rafe.kettler

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10957>
_______________________________________

From report at bugs.python.org  Sat Jan 22 00:38:03 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Fri, 21 Jan 2011 23:38:03 +0000
Subject: [issue10949] logging.RotatingFileHandler not robust enough
In-Reply-To: <1295457072.71.0.821420961283.issue10949@psf.upfronthosting.co.za>
Message-ID: <1295653083.29.0.690234502642.issue10949@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

Fix checked into py3k, release27-maint, release31-maint (r88139). The 2.6 branch is closed for changes other than security fixes.

----------
assignee:  -> vinay.sajip
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10949>
_______________________________________

From report at bugs.python.org  Sat Jan 22 00:39:13 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Fri, 21 Jan 2011 23:39:13 +0000
Subject: =?utf-8?q?=5Bissue10973=5D_=27=C3=B1=27_not_working_with_IDLE_3=2E2rc1_-_?=
	=?utf-8?q?OSX_10=2E6=2E6?=
In-Reply-To: <1295620061.05.0.0288010484186.issue10973@psf.upfronthosting.co.za>
Message-ID: <1295653153.48.0.457535818806.issue10973@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

As this clearly seems to be a Tk bug, I suggest to close this report as "won't fix - 3rd party".

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10973>
_______________________________________

From report at bugs.python.org  Sat Jan 22 00:42:09 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Fri, 21 Jan 2011 23:42:09 +0000
Subject: [issue10943] abitype: Need better support to port C extension modules
	to the stable C API
In-Reply-To: <1295426330.25.0.635363870245.issue10943@psf.upfronthosting.co.za>
Message-ID: <1295653329.81.0.670716187676.issue10943@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Notice that a boilerplate module is already available: xxlimited.c.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10943>
_______________________________________

From report at bugs.python.org  Sat Jan 22 00:42:48 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 21 Jan 2011 23:42:48 +0000
Subject: [issue10909] thread hang, possibly related to print
In-Reply-To: <1295026647.31.0.671636636712.issue10909@psf.upfronthosting.co.za>
Message-ID: <1295653368.64.0.962577224605.issue10909@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

FWIW, I downloaded, edited for 3.2, and ran. 45 minutes later, with counter in box near 16000, and output sequence looking about the same as initially, I killed with Task Manager (also on winxp). You might try same on your system.

----------
Added file: http://bugs.python.org/file20482/e10909.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10909>
_______________________________________

From report at bugs.python.org  Sat Jan 22 00:49:39 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 21 Jan 2011 23:49:39 +0000
Subject: [issue10977] Concrete object C API needs abstract path for subclasses
	of builtin types
In-Reply-To: <1295653779.62.0.836506069174.issue10977@psf.upfronthosting.co.za>
Message-ID: <1295653779.62.0.836506069174.issue10977@psf.upfronthosting.co.za>


New submission from Raymond Hettinger <rhettinger at users.sourceforge.net>:

Currently, the concrete object C API bypasses any methods defined on subclasses of builtin types.  

It has long been accepted that subclasses of builtin types need to override many methods rather than just a few because the type itself was implemented with direct internal calls.  This work-around requires extra work but still makes it possible to create a consistent subclass (a case-insensitive dictionary for example).

However, there is another problem with this workaround.  Any subclassed builtin may still be bypassed by other functions and methods using the concrete C API.

For example, the OrderedDict class overrides enough dict methods to make itself internally consistent and fully usable by all pure python code.  However, any builtin or extension using PyDict_SetItem() or PyDict_DelItem() will update the OrderedDict's internal unordered dict
and bypass all the logic keeping dict ordering invariants intact.  Note, this problem would still impact OrderedDict even if it were rewritten in C.  The concrete calls would directly access the original dict structure and ignore any of the logic implemented in the subclass (whether coded in pure python or in C).

Since OrderedDict is written in pure python, the consequence of having its invariants violated would result in disorganization, but not in a crash.  However if OrderedDict were rewritten in C, augmenting the inherited data structure with its own extra state, then this problem could result in seg-faulting.

Note this is only one example.  Pretty much any subclass of a builtin type that adds additional state is vulnerable to a concrete C API that updates only part of the state while leaving the extra state information in an inconsistent state.

Another example would be a list subclass that kept extra state tracking the number of None objects contained within.  There is no way to implement that subclass, either in C or pure python, even if every method were overridden, that wouldn't be rendered inconsistent by an external tool using PyList_SetItem().

My recommendation is to find all of the mutating methods for the concrete C API and add an alternate path for subclasses.  The alternate path should use the abstract API.

Pseudo-code for PyList_SetItem():

   if type(obj) is list:
      # proceed as currently implemented
   else:
      # use PyObject_SetItem() adapting the 
      # function parameters and return values if necessary
      # to match the API for PyList_SetItem().
   else:
      raise BadInternalCall('object should be a list')

----------
components: Interpreter Core
messages: 126800
nosy: rhettinger
priority: normal
severity: normal
status: open
title: Concrete object C API needs abstract path for subclasses of builtin  types
type: behavior
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10977>
_______________________________________

From report at bugs.python.org  Sat Jan 22 00:56:57 2011
From: report at bugs.python.org (Nestor Aguilera)
Date: Fri, 21 Jan 2011 23:56:57 +0000
Subject: =?utf-8?q?=5Bissue10973=5D_=27=C3=B1=27_not_working_with_IDLE_3=2E2rc1_-_?=
	=?utf-8?q?OSX_10=2E6=2E6?=
In-Reply-To: <1295653153.48.0.457535818806.issue10973@psf.upfronthosting.co.za>
Message-ID: <FF00CEDE-D3B0-4793-B8B1-D895587A695C@gmail.com>


Nestor Aguilera <aguilera at santafe-conicet.gov.ar> added the comment:

On 21 Jan 2011, at 20:39, Martin v. L?wis wrote:

> Martin v. L?wis <martin at v.loewis.de> added the comment:
> 
> As this clearly seems to be a Tk bug, I suggest to close this report as "won't fix - 3rd party".

I see your point. The problem is that IDLE is somewhat included with Python (so in a sense it is not "3rd party"), and seems like a good tool for learning Python: my concern is similar to that in message 126276 <http://bugs.python.org/msg126276>.

All the best,

Nestor

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10973>
_______________________________________

From report at bugs.python.org  Sat Jan 22 01:01:50 2011
From: report at bugs.python.org (Jerry Seutter)
Date: Sat, 22 Jan 2011 00:01:50 +0000
Subject: [issue10957] Python FAQ grammar error
In-Reply-To: <1295541255.37.0.868919325173.issue10957@psf.upfronthosting.co.za>
Message-ID: <1295654510.6.0.823665297867.issue10957@psf.upfronthosting.co.za>


Jerry Seutter <jseutter at gmail.com> added the comment:

I agree with what Rafe said.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10957>
_______________________________________

From report at bugs.python.org  Sat Jan 22 01:12:48 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sat, 22 Jan 2011 00:12:48 +0000
Subject: =?utf-8?q?=5Bissue10973=5D_=27=C3=B1=27_not_working_with_IDLE_3=2E2rc1_-_?=
	=?utf-8?q?OSX_10=2E6=2E6?=
In-Reply-To: <FF00CEDE-D3B0-4793-B8B1-D895587A695C@gmail.com>
Message-ID: <4D3A20FD.80309@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> I see your point. The problem is that IDLE is somewhat included with
> Python (so in a sense it is not "3rd party"), and seems like a good
> tool for learning Python: my concern is similar to that in message
> 126276 <http://bugs.python.org/msg126276>.

Unfortunately, there is little we can do about this (IIUC). One option
would be to include a fixed Tk version, but there is none to include
(IIUC). The only real solution to "fix" both the reported problem and
the problem of msg126276 would be to stop including IDLE with the MacOS
distributions, and asking users who want to use IDLE to switch to
Linux or Windows.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10973>
_______________________________________

From report at bugs.python.org  Sat Jan 22 01:15:36 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 22 Jan 2011 00:15:36 +0000
Subject: [issue10978] Add optional argument to Semaphore.release for releasing
	multiple threads
In-Reply-To: <1295655336.58.0.55708711889.issue10978@psf.upfronthosting.co.za>
Message-ID: <1295655336.58.0.55708711889.issue10978@psf.upfronthosting.co.za>


New submission from Raymond Hettinger <rhettinger at users.sourceforge.net>:

Call sem.release(5) would have the same effect as:

with lock:
    for i in range(5):
         sem.release()

The use case is when a single semaphore is holding up multiple threads and needs to release them all.  According to "The Little Book of Semaphores <http://greenteapress.com/semaphores/>", this is a common design pattern.

Basic patch attached.  If the proposal meets with acceptance, will add tests and a doc update.

----------
components: Library (Lib)
files: sem.diff
keywords: patch
messages: 126804
nosy: rhettinger
priority: normal
severity: normal
status: open
title: Add optional argument to Semaphore.release for releasing multiple threads
type: behavior
versions: Python 3.3
Added file: http://bugs.python.org/file20483/sem.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10978>
_______________________________________

From report at bugs.python.org  Sat Jan 22 01:19:20 2011
From: report at bugs.python.org (Jerry Seutter)
Date: Sat, 22 Jan 2011 00:19:20 +0000
Subject: [issue10957] Python developer FAQ grammar error
In-Reply-To: <1295541255.37.0.868919325173.issue10957@psf.upfronthosting.co.za>
Message-ID: <1295655560.86.0.188632469355.issue10957@psf.upfronthosting.co.za>


Changes by Jerry Seutter <jseutter at gmail.com>:


----------
title: Python FAQ grammar error -> Python developer FAQ grammar error

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10957>
_______________________________________

From report at bugs.python.org  Sat Jan 22 01:19:23 2011
From: report at bugs.python.org (Nestor Aguilera)
Date: Sat, 22 Jan 2011 00:19:23 +0000
Subject: =?utf-8?q?=5Bissue10973=5D_=27=C3=B1=27_not_working_with_IDLE_3=2E2rc1_-_?=
	=?utf-8?q?OSX_10=2E6=2E6?=
In-Reply-To: <4D3A20FD.80309@v.loewis.de>
Message-ID: <75320CFE-DC98-4581-8E05-0E3E52093882@santafe-conicet.gov.ar>


Nestor Aguilera <aguilera at santafe-conicet.gov.ar> added the comment:

On 21 Jan 2011, at 21:12, Martin v. L?wis wrote:

> 
> Martin v. L?wis <martin at v.loewis.de> added the comment:
> 
>> I see your point. The problem is that IDLE is somewhat included with
>> Python (so in a sense it is not "3rd party"), and seems like a good
>> tool for learning Python: my concern is similar to that in message
>> 126276 <http://bugs.python.org/msg126276>.
> 
> Unfortunately, there is little we can do about this (IIUC). One option
> would be to include a fixed Tk version, but there is none to include
> (IIUC). The only real solution to "fix" both the reported problem and
> the problem of msg126276 would be to stop including IDLE with the MacOS
> distributions, and asking users who want to use IDLE to switch to
> Linux or Windows.

(:-)

I hope you will not consider to also stop including tkinter!

Nestor

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10973>
_______________________________________

From report at bugs.python.org  Sat Jan 22 01:30:53 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 22 Jan 2011 00:30:53 +0000
Subject: [issue10957] Python developer FAQ grammar error
In-Reply-To: <1295541255.37.0.868919325173.issue10957@psf.upfronthosting.co.za>
Message-ID: <1295656253.79.0.966893591178.issue10957@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

In general, the website is separate from Python code and documentation and website issues should be sent to webmaster at python.org, not here, as code/doc committers cannot change web pages.

However, this particular page (dev/faq) has being pulled into the (hg) repository as part of expanded docs for developers. It is possible that 'to faster compilation time' has already been corrected. Brett? (and will the web page go away or be replaced?)

----------
nosy: +brett.cannon, terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10957>
_______________________________________

From report at bugs.python.org  Sat Jan 22 01:49:19 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Sat, 22 Jan 2011 00:49:19 +0000
Subject: [issue5863] bz2.BZ2File should accept other file-like objects.
In-Reply-To: <1240898269.47.0.592056792771.issue5863@psf.upfronthosting.co.za>
Message-ID: <1295657359.57.0.620635465813.issue5863@psf.upfronthosting.co.za>


Nadeem Vawda <nadeem.vawda at gmail.com> added the comment:

I have been working on a patch for this issue. I've implemented everything except for readline(), readlines() and the iterator protocol.

In the existing implementation, the reading methods seem to interact weirdly - iternext() uses a readahead buffer, while none of the other methods do. Does anyone know if there's a reason for this? I was planning on having all the reading methods use a common buffer, which should allow free mixing of read methods and iteration.

Looking at issue8397, I'm guessing it would be fine, but I wanted to double-check in case there's a quirk of the iteration protocol that I've overlooked, or something like that.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5863>
_______________________________________

From report at bugs.python.org  Sat Jan 22 01:57:00 2011
From: report at bugs.python.org (R. David Murray)
Date: Sat, 22 Jan 2011 00:57:00 +0000
Subject: [issue10968] threading.Timer should be a class so that it can be
	derived
In-Reply-To: <1295574501.95.0.0935688829986.issue10968@psf.upfronthosting.co.za>
Message-ID: <1295657820.81.0.00784928078854.issue10968@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

See also issue 5831.  That should probably be closed as a dup of this since this has an explanation.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10968>
_______________________________________

From report at bugs.python.org  Sat Jan 22 02:04:39 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 22 Jan 2011 01:04:39 +0000
Subject: [issue10954] No warning for csv.writer API change
In-Reply-To: <1295519548.77.0.698015070506.issue10954@psf.upfronthosting.co.za>
Message-ID: <1295658279.99.0.603845654096.issue10954@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Failing when passed a bytesIO object seems reasonable.
I question the bit about newlines though. The doc does not specify that newlines='' is needed on output. While is says it is needed for input, why? Why is a mix of '\n', '\r\n', and '\r' better than always '\n'?
It is not clear to me that the information is available to csv anyway.

----------
nosy: +terry.reedy
versions:  -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10954>
_______________________________________

From report at bugs.python.org  Sat Jan 22 02:15:18 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 22 Jan 2011 01:15:18 +0000
Subject: [issue10954] No warning for csv.writer API change
In-Reply-To: <1295519548.77.0.698015070506.issue10954@psf.upfronthosting.co.za>
Message-ID: <1295658918.16.0.943506261157.issue10954@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Changing csv api is a feature request that could only happen in 3.3.

----------
nosy: +skip.montanaro
type: behavior -> feature request
versions: +Python 3.3 -Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10954>
_______________________________________

From report at bugs.python.org  Sat Jan 22 02:45:27 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 22 Jan 2011 01:45:27 +0000
Subject: [issue10970] "string".encode('base64') is not the same as
	base64.b64encode("string")
In-Reply-To: <1295591116.22.0.262504941667.issue10970@psf.upfronthosting.co.za>
Message-ID: <1295660727.62.0.521131034258.issue10970@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Questions should generally be asked on python-list or its mirrors.

The docs do not say that the result should be exactly, byte-for-byte, the same. base64 module refers to RFC 3548. Both our doc and the RFC describe variations. The base64 codec does 'Mime base64' (7.8.3. Standard Encodings). The RFC says things like "MIME does not define "base 64" per se, but rather a "base 64 Content-Transfer-Encoding" for use within MIME." It also mentions 'line-break issues'.

You neglected to identify and post what the difference is ;-).

>>> import base64
>>> s='I am a string'
>>> s.encode('base64')
'SSBhbSBhIHN0cmluZw==\n'
>>> base64.b64encode(s)
'SSBhbSBhIHN0cmluZw=='
>>> s.encode('base64')== base64.b64encode(s)+'\n'
True

The addition of '\n' for the Mime version looks to be intentional, and will not be changed for 2.7.

(2.5 and 2.6 only get security patches now.)

----------
nosy: +terry.reedy
resolution:  -> invalid
status: open -> closed
versions:  -Python 2.5, Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10970>
_______________________________________

From report at bugs.python.org  Sat Jan 22 03:56:09 2011
From: report at bugs.python.org (R. David Murray)
Date: Sat, 22 Jan 2011 02:56:09 +0000
Subject: [issue10954] No warning for csv.writer API change
In-Reply-To: <1295519548.77.0.698015070506.issue10954@psf.upfronthosting.co.za>
Message-ID: <1295664969.07.0.116525980026.issue10954@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Newline='' is indeed needed. It preserves the newlines so that the csv module can correctly parse them according to the weird csv quoting roles.  And for output, the fact that it isn't documented there is a an issue that was only noticed recently.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10954>
_______________________________________

From report at bugs.python.org  Sat Jan 22 04:05:57 2011
From: report at bugs.python.org (Brett Cannon)
Date: Sat, 22 Jan 2011 03:05:57 +0000
Subject: [issue10957] Python developer FAQ grammar error
In-Reply-To: <1295541255.37.0.868919325173.issue10957@psf.upfronthosting.co.za>
Message-ID: <1295665557.5.0.0872846565212.issue10957@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

That entire portion of the FAQ has been removed as it was redundant compared to other parts of the devguide.

Closing as out of date.

----------
resolution:  -> out of date
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10957>
_______________________________________

From report at bugs.python.org  Sat Jan 22 04:39:28 2011
From: report at bugs.python.org (Mahmoud Abdelkader)
Date: Sat, 22 Jan 2011 03:39:28 +0000
Subject: [issue10970] "string".encode('base64') is not the same as
	base64.b64encode("string")
In-Reply-To: <1295591116.22.0.262504941667.issue10970@psf.upfronthosting.co.za>
Message-ID: <1295667568.0.0.845178915547.issue10970@psf.upfronthosting.co.za>


Mahmoud Abdelkader <mabdelkader at gmail.com> added the comment:

Thanks for the clarification Terry. This is indeed not a bug. For reference, the pieces of code I pasted line-wrapped after the 76th character, which was my main source of confusion.

After reading RFC3548, I am now informed that the behavior of string.encode is the correct and expected result, as the documentation per 7.8.3 state that it's MIME 64.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10970>
_______________________________________

From report at bugs.python.org  Sat Jan 22 04:42:40 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 22 Jan 2011 03:42:40 +0000
Subject: [issue10967] move regrtest over to using more unittest infrastructure
In-Reply-To: <1295567145.8.0.568957178125.issue10967@psf.upfronthosting.co.za>
Message-ID: <1295667760.08.0.219149424087.issue10967@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
keywords: +gsoc
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10967>
_______________________________________

From report at bugs.python.org  Sat Jan 22 04:43:17 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 22 Jan 2011 03:43:17 +0000
Subject: [issue10909] thread hang, possibly related to print
In-Reply-To: <1295026647.31.0.671636636712.issue10909@psf.upfronthosting.co.za>
Message-ID: <1295667797.82.0.939393478038.issue10909@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I ran the 2.7 file (on 2.7) and after several minutes, threadA stopped printing, but no error message.

Antoine, could improvement from 2.7 to 3.2 have anything to new with the new implementation of the Global Interpreter Lock?

Scott, if you can do your project with 3.2, I strongly recommend it. Even with 2.7, one can run files outside of IDLE even though you edit with IDLE. You just give up the F5 convenience. Or, I believe there are other editors without a shell which do so directly. Or, you could write a dp() (debug print) function that writes to a scrolled window in your toplevel app window (where running numbers appear now.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10909>
_______________________________________

From report at bugs.python.org  Sat Jan 22 05:13:32 2011
From: report at bugs.python.org (Brandon Craig Rhodes)
Date: Sat, 22 Jan 2011 04:13:32 +0000
Subject: [issue10979] setUpClass exception causes explosion with "-b"
In-Reply-To: <1295669611.84.0.453494131357.issue10979@psf.upfronthosting.co.za>
Message-ID: <1295669611.84.0.453494131357.issue10979@psf.upfronthosting.co.za>


New submission from Brandon Craig Rhodes <brandon at rhodesmill.org>:

Normally, unittest cleanly reports an exception in a setUpClass method. But if I place the attached test in a directory by itself and then run "python -m unittest discover -b" from inside of the same directory, then instead of being shown the setUpClass exception I am instead shown a long traceback because unittest seems to think that it has put a stringIO in place of sys.stdout but a file is there instead.

----------
components: Library (Lib)
files: test_example.py
messages: 126816
nosy: brandon-rhodes
priority: normal
severity: normal
status: open
title: setUpClass exception causes explosion with "-b"
type: crash
versions: Python 2.7
Added file: http://bugs.python.org/file20484/test_example.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10979>
_______________________________________

From report at bugs.python.org  Sat Jan 22 05:42:07 2011
From: report at bugs.python.org (Ross Lagerwall)
Date: Sat, 22 Jan 2011 04:42:07 +0000
Subject: [issue4216] subprocess.Popen hangs at communicate() when child exits
In-Reply-To: <1225151867.64.0.844146967045.issue4216@psf.upfronthosting.co.za>
Message-ID: <1295671327.55.0.905816117994.issue4216@psf.upfronthosting.co.za>


Ross Lagerwall <rosslagerwall at gmail.com> added the comment:

Yes I think subprocess is working correctly.

Since this feature request is 2 years old now without any interest, I think it should be closed. If the functionality is needed, it can always be programmed by the user when needed.

----------
nosy: +rosslagerwall

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4216>
_______________________________________

From report at bugs.python.org  Sat Jan 22 05:55:35 2011
From: report at bugs.python.org (R. David Murray)
Date: Sat, 22 Jan 2011 04:55:35 +0000
Subject: [issue10979] setUpClass exception causes explosion with "-b"
In-Reply-To: <1295669611.84.0.453494131357.issue10979@psf.upfronthosting.co.za>
Message-ID: <1295672135.82.0.895381659168.issue10979@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
nosy: +michael.foord
type: crash -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10979>
_______________________________________

From report at bugs.python.org  Sat Jan 22 08:37:23 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 22 Jan 2011 07:37:23 +0000
Subject: [issue10967] move regrtest over to using more unittest infrastructure
In-Reply-To: <1295567145.8.0.568957178125.issue10967@psf.upfronthosting.co.za>
Message-ID: <1295681843.25.0.248233441151.issue10967@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Wouldn't the time be better spent factoring the test suite or improving coverage?  I'm not sure how simply rearranging the tests makes us better-off.

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10967>
_______________________________________

From report at bugs.python.org  Sat Jan 22 08:44:49 2011
From: report at bugs.python.org (Pierre Quentel)
Date: Sat, 22 Jan 2011 07:44:49 +0000
Subject: [issue10911] cgi: add more tests
In-Reply-To: <1295040877.8.0.0807786274615.issue10911@psf.upfronthosting.co.za>
Message-ID: <1295682289.98.0.811258985172.issue10911@psf.upfronthosting.co.za>


Pierre Quentel <pierre.quentel at gmail.com> added the comment:

Hi,

I have written more tests, but also propose changes to cgi.py : 
- rewrite the parse_qs() and parse_multipart() functions so that they use FieldStorage methods instead of duplicating them
- add a function set_stdout_encoding(encoding), using the IOMix class proposed by Glen Linderman in issue #4953

Should I post the new version of test_cgi.py here and open another issue for the other proposed changes to cgi.py, or use this issue to discuss both ?

----------
nosy: +quentel

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10911>
_______________________________________

From report at bugs.python.org  Sat Jan 22 08:45:42 2011
From: report at bugs.python.org (Ned Deily)
Date: Sat, 22 Jan 2011 07:45:42 +0000
Subject: [issue10974] IDLE 3.2 not loading on double-click in Finder, OSX 10.6
In-Reply-To: <1295635255.29.0.478257321345.issue10974@psf.upfronthosting.co.za>
Message-ID: <1295682342.15.0.426740191888.issue10974@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

>From the traceback, IDLE is crashing on a decode error when trying to process the list of recently used files which is used to populate its recent files menu.  That list of files is saved in ~/.idlerc/recent-file.lst so an easy workaround is to delete the file before launching IDLE.app.  IDLE appears to be dependent on locale LANG settings.  When launched by double-clicking, like all Mac GUI apps IDLE.app does not inherited environment variables set in shell profiles, as in a terminal session.  The problem can be easily reproduced with bin/idle which is started from a shell environment:

$ echo $LANG
en_US.UTF-8
$ echo "/Users/nad/Documents/test_?.py" > ~/.idlerc/recent-files.lst
nad at fimt:~$ /usr/local/bin/idle3.2
# idle starts normally with the umlauted file name in the recent files menu
$ unset LANG
$ /usr/local/bin/idle3.2
Traceback (most recent call last):
  File "/usr/local/bin/idle3.2", line 5, in <module>
    main()
  File "/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/idlelib/PyShell.py", line 1388, in main
    shell = flist.open_shell()
  File "/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/idlelib/PyShell.py", line 277, in open_shell
    self.pyshell = PyShell(self)
  File "/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/idlelib/PyShell.py", line 813, in __init__
    OutputWindow.__init__(self, flist, None, None)
  File "/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/idlelib/OutputWindow.py", line 16, in __init__
    EditorWindow.__init__(self, *args)
  File "/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/idlelib/EditorWindow.py", line 267, in __init__
    self.update_recent_files_list()
  File "/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/idlelib/EditorWindow.py", line 777, in update_recent_files_list
    rf_list = rf_list_file.readlines()
  File "/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/encodings/ascii.py", line 26, in decode
    return codecs.ascii_decode(input, self.errors)[0]
UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 26: ordinal not in range(128)

A similar exception occurs (without a crash) when saving a file to a non-ASCII file name and LANG is not properly set:

Exception in Tkinter callback
Traceback (most recent call last):
  File "/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/tkinter/__init__.py", line 1399, in __call__
    return self.func(*args)
  File "/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/idlelib/MultiCall.py", line 166, in handler
    r = l[i](event)
  File "/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/idlelib/IOBinding.py", line 328, in save
    self.save_as(event)
  File "/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/idlelib/IOBinding.py", line 350, in save_as
    self.updaterecentfileslist(filename)
  File "/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/idlelib/IOBinding.py", line 515, in updaterecentfileslist
    self.editwin.update_recent_files_list(filename)
  File "/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/idlelib/EditorWindow.py", line 795, in update_recent_files_list
    rf_file.writelines(rf_list)
UnicodeEncodeError: 'ascii' codec can't encode character '\xe4' in position 16: ordinal not in range(128)

----------
assignee:  -> ned.deily
nosy: +ned.deily
priority: normal -> high
stage:  -> needs patch
versions: +Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10974>
_______________________________________

From report at bugs.python.org  Sat Jan 22 08:50:04 2011
From: report at bugs.python.org (Ned Deily)
Date: Sat, 22 Jan 2011 07:50:04 +0000
Subject: [issue10974] IDLE 3.2 not loading on double-click in Finder, OSX 10.6
In-Reply-To: <1295635255.29.0.478257321345.issue10974@psf.upfronthosting.co.za>
Message-ID: <1295682604.31.0.887060902448.issue10974@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

>From the traceback, IDLE is crashing on a decode error when trying to process the list of recently used files which is used to populate its recent files menu.  That list of files is saved in ~/.idlerc/recent-file.lst so an easy workaround is to delete the file before launching IDLE.app.  Most likely, the list of files contains at least one path name with a non-ASCII character.  IDLE appears to be dependent here on locale LANG settings.  When launched by double-clicking, like all Mac GUI apps IDLE.app does not inherited environment variables set in shell profiles, as in a terminal session.  The problem can be easily reproduced with bin/idle which is started from a shell environment:

$ echo $LANG
en_US.UTF-8
$ echo "/Users/nad/Documents/test_?.py" > ~/.idlerc/recent-files.lst
$ /usr/local/bin/idle3.2
# with UTF-8 locale, idle starts normally with the umlauted file name in the recent files menu
$ unset LANG
$ /usr/local/bin/idle3.2
Traceback (most recent call last):
  File "/usr/local/bin/idle3.2", line 5, in <module>
    main()
  File "/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/idlelib/PyShell.py", line 1388, in main
    shell = flist.open_shell()
  File "/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/idlelib/PyShell.py", line 277, in open_shell
    self.pyshell = PyShell(self)
  File "/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/idlelib/PyShell.py", line 813, in __init__
    OutputWindow.__init__(self, flist, None, None)
  File "/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/idlelib/OutputWindow.py", line 16, in __init__
    EditorWindow.__init__(self, *args)
  File "/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/idlelib/EditorWindow.py", line 267, in __init__
    self.update_recent_files_list()
  File "/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/idlelib/EditorWindow.py", line 777, in update_recent_files_list
    rf_list = rf_list_file.readlines()
  File "/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/encodings/ascii.py", line 26, in decode
    return codecs.ascii_decode(input, self.errors)[0]
UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 26: ordinal not in range(128)

A similar exception occurs (without a crash) when saving a file to a non-ASCII file name and LANG is not properly set:

Exception in Tkinter callback
Traceback (most recent call last):
  File "/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/tkinter/__init__.py", line 1399, in __call__
    return self.func(*args)
  File "/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/idlelib/MultiCall.py", line 166, in handler
    r = l[i](event)
  File "/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/idlelib/IOBinding.py", line 328, in save
    self.save_as(event)
  File "/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/idlelib/IOBinding.py", line 350, in save_as
    self.updaterecentfileslist(filename)
  File "/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/idlelib/IOBinding.py", line 515, in updaterecentfileslist
    self.editwin.update_recent_files_list(filename)
  File "/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/idlelib/EditorWindow.py", line 795, in update_recent_files_list
    rf_file.writelines(rf_list)
UnicodeEncodeError: 'ascii' codec can't encode character '\xe4' in position 16: ordinal not in range(128)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10974>
_______________________________________

From report at bugs.python.org  Sat Jan 22 08:50:11 2011
From: report at bugs.python.org (Ned Deily)
Date: Sat, 22 Jan 2011 07:50:11 +0000
Subject: [issue10974] IDLE 3.2 not loading on double-click in Finder, OSX 10.6
In-Reply-To: <1295635255.29.0.478257321345.issue10974@psf.upfronthosting.co.za>
Message-ID: <1295682611.76.0.175324156641.issue10974@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


----------
Removed message: http://bugs.python.org/msg126820

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10974>
_______________________________________

From report at bugs.python.org  Sat Jan 22 09:02:53 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 22 Jan 2011 08:02:53 +0000
Subject: [issue10969] Make Tcl recommendation more prominent
In-Reply-To: <1295587699.83.0.103417791423.issue10969@psf.upfronthosting.co.za>
Message-ID: <1295683373.73.0.886903417056.issue10969@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

If you want to be less specific making recommendations for getting it to work, at least have a prominent disclosure of some sort:

Mac OS X 32-bit i386/PPC Installer (3.2rc1) for OS X 10.3 through 10.6 [2] (sig)
Mac OS X 64-bit/32-bit Installer (3.2rc1) for Mac OS X 10.6 [2] (sig)
 (may need an updated Tcl/Tk install to run IDLE or use Tkinter, see note 2 for instructions).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10969>
_______________________________________

From report at bugs.python.org  Sat Jan 22 09:52:32 2011
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 22 Jan 2011 08:52:32 +0000
Subject: [issue10955] Possible regression with stdlib in zipfile
In-Reply-To: <1295531540.01.0.823019908764.issue10955@psf.upfronthosting.co.za>
Message-ID: <1295686352.08.0.992594013614.issue10955@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Patch #2 looks innocent enough to me, and is clearly an improvement.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10955>
_______________________________________

From report at bugs.python.org  Sat Jan 22 09:53:54 2011
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 22 Jan 2011 08:53:54 +0000
Subject: [issue10955] Possible regression with stdlib in zipfile
In-Reply-To: <1295531540.01.0.823019908764.issue10955@psf.upfronthosting.co.za>
Message-ID: <1295686434.26.0.723091662655.issue10955@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

For 3.3, we might want to consider implementing cp437 in C, as a necessary consequence of supporting import from zipfiles.  Shouldn't be so hard, I guess.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10955>
_______________________________________

From report at bugs.python.org  Sat Jan 22 09:56:20 2011
From: report at bugs.python.org (Ross Lagerwall)
Date: Sat, 22 Jan 2011 08:56:20 +0000
Subject: [issue5885] uuid.uuid1() is too slow
In-Reply-To: <1241086416.5.0.850110966894.issue5885@psf.upfronthosting.co.za>
Message-ID: <1295686580.27.0.93011099263.issue5885@psf.upfronthosting.co.za>


Ross Lagerwall <rosslagerwall at gmail.com> added the comment:

Attached is a patch based on the original patch, meant to have better performance.

On my PC, this:

import sys, time, uuid

def uu(n):
    t = time.time()
    for x in range(n):
        uuid.uuid1()
    print('%.3f microseconds' % ((time.time() - t) * 1000000.0 / n))

uu(50000)

records a time of 38.5 microseconds unpatched (still using ctypes/libuuid) and a time of 16.5 microseconds afterwards.
uuid4() results in an improvement from 30 microseconds to 9 microseconds. From what I could see, what took the most time was the call to UUID() with a bytes object. That's why this patch passes in the uuid as a long.

It also fixes setup.py to check for the uuid.h header.

----------
nosy: +rosslagerwall
Added file: http://bugs.python.org/file20485/issue_5885.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5885>
_______________________________________

From report at bugs.python.org  Sat Jan 22 10:50:38 2011
From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=)
Date: Sat, 22 Jan 2011 09:50:38 +0000
Subject: [issue10960] os.stat() does not mention that it follow symlinks by
	default
In-Reply-To: <1295544486.66.0.118119387237.issue10960@psf.upfronthosting.co.za>
Message-ID: <1295689838.16.0.564885089054.issue10960@psf.upfronthosting.co.za>


???? ????????? <socketpair at gmail.com> added the comment:

Yes, os.stat and os.lstat should be one after next in docs. Also IMHO, they should have cross-references. See excellent php docs for example.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10960>
_______________________________________

From report at bugs.python.org  Sat Jan 22 11:14:27 2011
From: report at bugs.python.org (Michael Foord)
Date: Sat, 22 Jan 2011 10:14:27 +0000
Subject: [issue10969] Make Tcl recommendation more prominent
In-Reply-To: <1295587699.83.0.103417791423.issue10969@psf.upfronthosting.co.za>
Message-ID: <1295691267.48.0.0697444365273.issue10969@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

For what it's worth I prefer Raymond's original wording. Installing the Activestate Tcl/Tk will never be a *bad* thing to do for using Python, so I don't see a problem with stating it as a requirement. Users are unlikely to see the current warning when they download and a "broken IDLE" by default is a bad situation.

----------
nosy: +michael.foord

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10969>
_______________________________________

From report at bugs.python.org  Sat Jan 22 11:23:41 2011
From: report at bugs.python.org (Nestor Aguilera)
Date: Sat, 22 Jan 2011 10:23:41 +0000
Subject: [issue10974] IDLE 3.2 not loading on double-click in Finder, OSX 10.6
In-Reply-To: <1295682611.79.0.0953873711894.issue10974@psf.upfronthosting.co.za>
Message-ID: <E9BD9890-A06B-4233-9323-5B1EBE303E38@gmail.com>


Nestor Aguilera <aguilera at santafe-conicet.gov.ar> added the comment:

Ned: thanks for the explanation.

Nestor

=======================================================================

On 22 Jan 2011, at 04:50, Ned Deily wrote:

> 
> Changes by Ned Deily <nad at acm.org>:
> 
> 
> ----------
> Removed message: http://bugs.python.org/msg126820
> 
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue10974>
> _______________________________________

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10974>
_______________________________________

From report at bugs.python.org  Sat Jan 22 11:35:41 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 22 Jan 2011 10:35:41 +0000
Subject: [issue10955] Possible regression with stdlib in zipfile
In-Reply-To: <1295531540.01.0.823019908764.issue10955@psf.upfronthosting.co.za>
Message-ID: <1295692541.66.0.606714400161.issue10955@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

georg.brandl> Patch #2 looks innocent enough to me, 
georg.brandl> and is clearly an improvement.

Ok, issue fixed by r88140 (+r88141):

Issue #10955: zipimport uses ASCII encoding instead of cp497 to decode
filenames, at bootstrap, if the codec registry is not ready yet. It is
still possible to have non-ASCII filenames using the Unicode flag
(UTF-8 encoding) for all file entries in the ZIP file.

Oh, by the way, using ASCII at bootstrap is not a regression of Python 3.2: Python 3.1 used the wrong encoding (UTF-8) to decode filenames encoded to cp437. Raise a UnicodeDecodeError is better than decoding with the wrong encoding.

> For 3.3, we might want to consider implementing cp437 in C, ...

Since, I don't like this solution, I will not open a new issue for that. Feel free to open a new issue if you consider that we need that in Python 3.3.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10955>
_______________________________________

From report at bugs.python.org  Sat Jan 22 12:01:38 2011
From: report at bugs.python.org (Matt Joiner)
Date: Sat, 22 Jan 2011 11:01:38 +0000
Subject: [issue9723] pipes.quote() needs to be documented
In-Reply-To: <1283262014.72.0.527039259842.issue9723@psf.upfronthosting.co.za>
Message-ID: <1295694098.84.0.680552076754.issue9723@psf.upfronthosting.co.za>


Matt Joiner <anacrolix at gmail.com> added the comment:

Two reasons: The pipes module is Unix only, but pipes.quote is useful on all platforms. Secondly pipes.quote pertains to shell command-lines, this is also the domain of shlex which already cross platform. In pipes, an import shlex.quote would more than sufficient.

If this belongs in another separate bug I shall submit one. Please advise.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9723>
_______________________________________

From report at bugs.python.org  Sat Jan 22 13:28:37 2011
From: report at bugs.python.org (hhas)
Date: Sat, 22 Jan 2011 12:28:37 +0000
Subject: [issue10976] json.loads() throws TypeError on bytes object
In-Reply-To: <1295636509.41.0.0138366952356.issue10976@psf.upfronthosting.co.za>
Message-ID: <1295699317.74.0.671235162686.issue10976@psf.upfronthosting.co.za>


hhas <hhas at users.sourceforge.net> added the comment:

Doc fix works for me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10976>
_______________________________________

From report at bugs.python.org  Sat Jan 22 13:45:54 2011
From: report at bugs.python.org (Armin Ronacher)
Date: Sat, 22 Jan 2011 12:45:54 +0000
Subject: [issue10980] http.server Header Unicode Bug
In-Reply-To: <1295700354.03.0.333269896981.issue10980@psf.upfronthosting.co.za>
Message-ID: <1295700354.03.0.333269896981.issue10980@psf.upfronthosting.co.za>


New submission from Armin Ronacher <armin.ronacher at active-4.com>:

I have a critical bugfix that should make it into Python 3.2 even when it's in release candidate state.  Currently http.server.BaseHTTPServer encodes headers with ASCII charset.  This is at least in violation with PEP 3333 which demands that latin1 is used.

Because HTTP itself suggests latin1 (iso-8859-1) I strongly recommend changing this in BaseHTTPServer and not wsgiref.

The attached patch fixes that in a backwards compatible fashion.

----------
assignee: georg.brandl
components: Library (Lib)
files: http-server-unicode.patch
keywords: patch
messages: 126832
nosy: aronacher, georg.brandl
priority: normal
severity: normal
stage: patch review
status: open
title: http.server Header Unicode Bug
type: behavior
Added file: http://bugs.python.org/file20486/http-server-unicode.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10980>
_______________________________________

From report at bugs.python.org  Sat Jan 22 13:49:12 2011
From: report at bugs.python.org (David Caro)
Date: Sat, 22 Jan 2011 12:49:12 +0000
Subject: [issue10981] options starting with -- match substrings
In-Reply-To: <1295700552.8.0.933174530734.issue10981@psf.upfronthosting.co.za>
Message-ID: <1295700552.8.0.933174530734.issue10981@psf.upfronthosting.co.za>


New submission from David Caro <david.caro.estevez at gmail.com>:

When parsing option like --optionname, --option will match it too

example:

>>> import argparse
>>>  parser = argparse.ArgumentParser()
>>> parser = argparse.ArgumentParser()
>>> parser.add_argument('--superstring')
_StoreAction(option_strings=['--superstring'], dest='superstring', nargs=None, const=None, default=None, type=None, choices=None, help=None, metavar=None)
>>> parser.parse_args(['--super','value'])
Namespace(superstring='value')

I'm using argparse 1.1 with python 2.6.6 (r266:84292, Sep 15 2010, 15:52:39), on ubuntu 10.10 32bit

----------
messages: 126833
nosy: David.Caro
priority: normal
severity: normal
status: open
title: options starting with -- match substrings

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10981>
_______________________________________

From report at bugs.python.org  Sat Jan 22 13:51:01 2011
From: report at bugs.python.org (David Caro)
Date: Sat, 22 Jan 2011 12:51:01 +0000
Subject: [issue10981] options starting with -- match substrings
In-Reply-To: <1295700552.8.0.933174530734.issue10981@psf.upfronthosting.co.za>
Message-ID: <1295700661.05.0.145875908351.issue10981@psf.upfronthosting.co.za>


Changes by David Caro <david.caro.estevez at gmail.com>:


----------
components: +Extension Modules
versions: +Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10981>
_______________________________________

From report at bugs.python.org  Sat Jan 22 13:53:12 2011
From: report at bugs.python.org (David Caro)
Date: Sat, 22 Jan 2011 12:53:12 +0000
Subject: [issue10981] argparse: options starting with -- match substrings
In-Reply-To: <1295700552.8.0.933174530734.issue10981@psf.upfronthosting.co.za>
Message-ID: <1295700792.54.0.422977767351.issue10981@psf.upfronthosting.co.za>


Changes by David Caro <david.caro.estevez at gmail.com>:


----------
title: options starting with -- match substrings -> argparse: options starting with -- match substrings

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10981>
_______________________________________

From report at bugs.python.org  Sat Jan 22 14:04:30 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 22 Jan 2011 13:04:30 +0000
Subject: [issue10980] http.server Header Unicode Bug
In-Reply-To: <1295700354.03.0.333269896981.issue10980@psf.upfronthosting.co.za>
Message-ID: <1295701470.34.0.613555869801.issue10980@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Extract of PEP 3333: << Note also that strings passed to start_response() as a status or as response headers must follow RFC 2616 with respect to encoding. That is, they must either be ISO-8859-1 characters, or use RFC 2047 MIME encoding. >>

What is the best choice for portability (HTTP servers and web browsers): latin1 or MIME encoding? Latin1 is a small subset of Unicode: only U+0000..U+00FF.

We should maybe give the choice to the user between Latin1, MIME, or maybe something else (eg. UTF-8, cp1252, ...). Or at least, you should try something like:

try:
   bytes = text.encode('latin1')
except UnicodeEncodeError:
   bytes = encodeMIME(text, 'utf-8')

Would it be a good idea to accept raw bytes headers? HTTP is *supposed* to be correctly encoded using different RFC, but in practical, anyone is free to do whateven he wants.

Sentence extracted randomly from the WWW (dec. 2008): "it seems that neither Tomcat 5.5 or 6 properly decodes HTTP headers as per RFC 2047! The Tomcat code assumes everywhere that header values use ISO-8859-1."

Finally, why do you consider that this issue have to be fixed before Python 3.2?

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10980>
_______________________________________

From report at bugs.python.org  Sat Jan 22 14:14:17 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 22 Jan 2011 13:14:17 +0000
Subject: [issue10980] http.server Header Unicode Bug
In-Reply-To: <1295700354.03.0.333269896981.issue10980@psf.upfronthosting.co.za>
Message-ID: <1295702057.43.0.910932691547.issue10980@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

RFC 5987 (Character Set and Language Encoding for Hypertext Transfer Protocol (HTTP) Header Field Parameters), August 2010:
http://greenbytes.de/tech/webdav/rfc5987.html#language.specification.in.encoded.words

<< 3.3 Language Specification in Encoded Words

Section 5 of [RFC2231] extends the encoding defined in [RFC2047] to also support language specification in encoded words. Although the HTTP/1.1 specification does refer to RFC 2047 ([RFC2616], Section 2.2), it's not clear to which header field exactly it applies, and whether it is implemented in practice (see <http://tools.ietf.org/wg/httpbis/trac/ticket/111> for details).

Thus, this specification does not include this feature. >>

Hum ok, Latin1 looks safe and enough.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10980>
_______________________________________

From report at bugs.python.org  Sat Jan 22 14:16:37 2011
From: report at bugs.python.org (Armin Ronacher)
Date: Sat, 22 Jan 2011 13:16:37 +0000
Subject: [issue10980] http.server Header Unicode Bug
In-Reply-To: <1295700354.03.0.333269896981.issue10980@psf.upfronthosting.co.za>
Message-ID: <1295702197.68.0.499770194651.issue10980@psf.upfronthosting.co.za>


Armin Ronacher <armin.ronacher at active-4.com> added the comment:

Georg Brandl signed off the commit and Python 3.2 will ship with the HTTP server accepting latin1 bytes.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10980>
_______________________________________

From report at bugs.python.org  Sat Jan 22 14:25:32 2011
From: report at bugs.python.org (Scott M)
Date: Sat, 22 Jan 2011 13:25:32 +0000
Subject: [issue10909] thread hang, possibly related to print
In-Reply-To: <1295667797.82.0.939393478038.issue10909@psf.upfronthosting.co.za>
Message-ID: <000001cbba37$d03ae780$70b0b680$@mayo@comcast.net>


Scott M <scott.mayo at comcast.net> added the comment:

Moving to 3.x means redoing large swaths of the extension I just wrote. It's only a couple thousand lines, but it was my first extension and it cost me a week of my life in Google, and it does a lot with strings.

I haven't pulled down the source code for Python's internals yet, but from the one trace back I did get in the failing thread test app, the problem was inside print and it looked like it was inside the mechanism where print gets redirected. I hope the problem isn't anything as fundamental as the GIL, because that throws the stability of all of 2.7 into question (and it's been solid in all my tests; I do a lot with threads in my extension, all going after the GIL and diving into Python code.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10909>
_______________________________________

From report at bugs.python.org  Sat Jan 22 15:32:10 2011
From: report at bugs.python.org (Roy Hyunjin Han)
Date: Sat, 22 Jan 2011 14:32:10 +0000
Subject: [issue10574] email.header.decode_header fails if the string contains
	multiple directives
In-Reply-To: <1291136757.37.0.0353161103665.issue10574@psf.upfronthosting.co.za>
Message-ID: <AANLkTim4qSbW6863RCCQVK9iqhPDNMEg20DiUttifUb1@mail.gmail.com>


Roy Hyunjin Han <starsareblueandfaraway at gmail.com> added the comment:

2010/11/30 R. David Murray <report at bugs.python.org>:
> Out of curiosity, which email program is it that is producing these invalid headers?

I lost the headers for the original email, so I don't know which email
program created the invalid headers.

On searching for messages from the same address, it seems most of the
messages originate from a marketing company called informz.net, but in
rare instances there is a non-standard X-Mailer header:
- ColdFusion 8 Application Server (via JavaMail)
- IBM Lotus Domino Access for MS Outlook (2003) Release 7.0.2 September 26, 2006

Messages sent via informz.net generally parse correctly, so I am
guessing it might have been one of the X-Mailers above.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10574>
_______________________________________

From report at bugs.python.org  Sat Jan 22 15:40:01 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 22 Jan 2011 14:40:01 +0000
Subject: [issue10909] thread hang, possibly related to print
In-Reply-To: <1295026647.31.0.671636636712.issue10909@psf.upfronthosting.co.za>
Message-ID: <1295707201.75.0.831940979141.issue10909@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Antoine, could improvement from 2.7 to 3.2 have anything to new with
> the new implementation of the Global Interpreter Lock?

Perhaps, but then it's pure luck. 
Looking at the traceback, IDLE seems to replace sys.stdout with its own thingie when spawning a separate Python program. Perhaps that thingie isn't thread-safe.

----------
components: +IDLE -Interpreter Core

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10909>
_______________________________________

From report at bugs.python.org  Sat Jan 22 15:41:47 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 22 Jan 2011 14:41:47 +0000
Subject: [issue10909] thread hang, possibly related to print
In-Reply-To: <1295026647.31.0.671636636712.issue10909@psf.upfronthosting.co.za>
Message-ID: <1295707307.4.0.484470183537.issue10909@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +kbk

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10909>
_______________________________________

From report at bugs.python.org  Sat Jan 22 15:50:24 2011
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 22 Jan 2011 14:50:24 +0000
Subject: [issue10980] http.server Header Unicode Bug
In-Reply-To: <1295700354.03.0.333269896981.issue10980@psf.upfronthosting.co.za>
Message-ID: <1295707824.26.0.907910041855.issue10980@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Armin committed the patch in r88142 and followed up with r88143 for the http.client library.

Needs backporting?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10980>
_______________________________________

From report at bugs.python.org  Sat Jan 22 16:02:53 2011
From: report at bugs.python.org (David Caro)
Date: Sat, 22 Jan 2011 15:02:53 +0000
Subject: [issue10981] argparse: options starting with -- match substrings
In-Reply-To: <1295700552.8.0.933174530734.issue10981@psf.upfronthosting.co.za>
Message-ID: <1295708573.96.0.520368257819.issue10981@psf.upfronthosting.co.za>


David Caro <david.caro.estevez at gmail.com> added the comment:

It is not an issue, it will try to match all the optional parameters, and if only one matches, then it will use it:

2110                 elif option_string.startswith(option_prefix):
2111                     action = self._option_string_actions[option_string]
2112                     tup = action, option_string, explicit_arg
2113                     result.append(tup)

and

2057         # if exactly one action matched, this segmentation is good,
2058         # so return the parsed action
2059         elif len(option_tuples) == 1:
2060             option_tuple, = option_tuples
2061             return option_tuple


if you try to add more than one optional parameter that matches the substring, it will complain:

>>> import argparse
>>> parser = argparse.ArgumentParser()
>>> parser.add_argument('--superstring')
_StoreAction(option_strings=['--superstring'], dest='superstring', nargs=None, const=None, default=None, type=None, choices=None, help=None, metavar=None)
>>> parser.parse_args(['--super','value'])
Namespace(superstring='value')
>>> parser.add_argument('--superstring2')
_StoreAction(option_strings=['--superstring'], dest='superstring', nargs=None, const=None, default=None, type=None, choices=None, help=None, metavar=None)
>>> parser.parse_args(['--super','value'])
usage: [-h] [--superstring SUPERSTRING] [--superstring2 SUPERSTRING2]
: error: ambiguous option: --super could match --superstring, --superstring2

----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10981>
_______________________________________

From report at bugs.python.org  Sat Jan 22 17:46:09 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 22 Jan 2011 16:46:09 +0000
Subject: [issue10977] Concrete object C API needs abstract path for subclasses
	of builtin types
In-Reply-To: <1295653779.62.0.836506069174.issue10977@psf.upfronthosting.co.za>
Message-ID: <1295714769.09.0.702485963344.issue10977@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +eric.araujo
title: Concrete object C API needs abstract path for subclasses of builtin  types -> Concrete object C API needs abstract path for subclasses of builtin types

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10977>
_______________________________________

From report at bugs.python.org  Sat Jan 22 17:48:20 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 22 Jan 2011 16:48:20 +0000
Subject: [issue10935] wsgiref.handlers.BaseHandler and subclasses of str
In-Reply-To: <1295371764.49.0.785710350986.issue10935@psf.upfronthosting.co.za>
Message-ID: <1295714900.17.0.924355084893.issue10935@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

FYI, #10977 has been opened to tackle the general subclasses problem.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10935>
_______________________________________

From report at bugs.python.org  Sat Jan 22 18:35:16 2011
From: report at bugs.python.org (R. David Murray)
Date: Sat, 22 Jan 2011 17:35:16 +0000
Subject: [issue10967] move regrtest over to using more unittest infrastructure
In-Reply-To: <1295567145.8.0.568957178125.issue10967@psf.upfronthosting.co.za>
Message-ID: <1295717716.03.0.563550447925.issue10967@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I also would put increasing test coverage at a higher priority, but this sort of refactoring can be a good step in the development path of new contributors, and doing it does decrease the future maintenance burden.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10967>
_______________________________________

From report at bugs.python.org  Sat Jan 22 18:35:54 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 22 Jan 2011 17:35:54 +0000
Subject: [issue10980] http.server Header Unicode Bug
In-Reply-To: <1295700354.03.0.333269896981.issue10980@psf.upfronthosting.co.za>
Message-ID: <1295717754.1.0.357252538971.issue10980@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I think so.

----------
nosy: +benjamin.peterson, eric.araujo, orsenthil
resolution:  -> accepted
stage: patch review -> commit review
versions: +Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10980>
_______________________________________

From report at bugs.python.org  Sat Jan 22 19:03:06 2011
From: report at bugs.python.org (k1h)
Date: Sat, 22 Jan 2011 18:03:06 +0000
Subject: [issue10982] asyncore timeouts do not work correctly
In-Reply-To: <1295719386.38.0.705218895334.issue10982@psf.upfronthosting.co.za>
Message-ID: <1295719386.38.0.705218895334.issue10982@psf.upfronthosting.co.za>


New submission from k1h <k1h1861 at gmail.com>:

Asyncore for the versions of Python examined do not check for the empty sequences select.select returns to indicate a timeout.  The attached patch served my immediate needs, but no effort was made to verify that all scenarios were covered or that other issues weren't introduced.

----------
components: Library (Lib)
files: asyncore_timeout_patch_with_example.txt
messages: 126846
nosy: k1h
priority: normal
severity: normal
status: open
title: asyncore timeouts do not work correctly
versions: Python 2.5, Python 2.6, Python 2.7, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file20487/asyncore_timeout_patch_with_example.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10982>
_______________________________________

From report at bugs.python.org  Sat Jan 22 19:05:03 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 22 Jan 2011 18:05:03 +0000
Subject: [issue10982] asyncore timeouts do not work correctly
In-Reply-To: <1295719386.38.0.705218895334.issue10982@psf.upfronthosting.co.za>
Message-ID: <1295719503.44.0.639734660564.issue10982@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +giampaolo.rodola
type:  -> behavior
versions:  -Python 2.5, Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10982>
_______________________________________

From report at bugs.python.org  Sat Jan 22 19:29:50 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 22 Jan 2011 18:29:50 +0000
Subject: [issue10975] #10961: Pydoc touchups in new 3.2 Web server
	(issue4090042)
In-Reply-To: <00221532cc70620113049a5fa977@google.com>
Message-ID: <20cf30549e1f0d124c049a738d68@google.com>


?ric Araujo <merwok at netwok.org> added the comment:

not-most-recent
>> versions, and various resolutions?  (?fine? being defined as ?not
worse than
>> before the patch?)
> Works with ie, firefox and chromium. If you have something else,
please test it,
> and let me know.

What versions did you test with?  (I don?t have other browsers.)

changed
> in 3.3 if it's desirable to do so.

Okay.

Doc??  Very
>> clear and still short.
> "Python" and "Python Docs" is too general.  PyDoc is instantly
recognizable for
> what it is.

If you already know what it is.

Keep in
> mind pydoc may also be used to generate third party documentation, not
just
> python documentation.

Ah, good argument.  +0 for PyDoc then, +0.1 for Pydoc.

http://codereview.appspot.com/4090042/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10975>
_______________________________________

From report at bugs.python.org  Sat Jan 22 19:32:35 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 22 Jan 2011 18:32:35 +0000
Subject: [issue5831] Doc mistake : threading.Timer is *not* a class
In-Reply-To: <1240580557.82.0.551397939271.issue5831@psf.upfronthosting.co.za>
Message-ID: <1295721155.5.0.449276458507.issue5831@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Explanation has been provided on #10968, and hopefully the code will be cleaned up.  Closing as superseded.

----------
resolution:  -> duplicate
stage:  -> committed/rejected
status: open -> closed
superseder:  -> threading.Timer should be a class so that it can be derived

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5831>
_______________________________________

From report at bugs.python.org  Sat Jan 22 19:41:20 2011
From: report at bugs.python.org (Sean Reifschneider)
Date: Sat, 22 Jan 2011 18:41:20 +0000
Subject: [issue10924] Adding salt and Modular Crypt Format to crypt library.
In-Reply-To: <1295247997.49.0.7150272714.issue10924@psf.upfronthosting.co.za>
Message-ID: <1295721680.64.0.834910709888.issue10924@psf.upfronthosting.co.za>


Sean Reifschneider <jafo at tummy.com> added the comment:

At this point I'm going to consider this good to go, and will commit it after the 3.2 final release.  Thanks for the review everyone.  Of course, I'm open to further suggestions until then, just not expecting any...

----------
assignee:  -> jafo
keywords:  -needs review
resolution:  -> later
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10924>
_______________________________________

From report at bugs.python.org  Sat Jan 22 19:42:12 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 22 Jan 2011 18:42:12 +0000
Subject: [issue9723] Add shlex.quote
In-Reply-To: <1283262014.72.0.527039259842.issue9723@psf.upfronthosting.co.za>
Message-ID: <1295721732.05.0.296456484667.issue9723@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Even if quote does not start with an underscore, its absence from the docs and from the module?s __all__ make it a private function.

I propose to make it public as shlex.quote in 3.3 and deprecate pipes.quote for people that relied on it (i.e. move code from pipes/test_pipes to shlex/test_shlex, add doc, write a pipes.quote function that sends a DeprecationWarning and calls shlex.quote).

----------
assignee: docs at python -> 
components: +Library (Lib) -Documentation
nosy:  -docs at python
title: pipes.quote() needs to be documented -> Add shlex.quote
type:  -> feature request
versions: +Python 3.3 -Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9723>
_______________________________________

From report at bugs.python.org  Sat Jan 22 19:43:44 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 22 Jan 2011 18:43:44 +0000
Subject: [issue10924] Adding salt and Modular Crypt Format to crypt library.
In-Reply-To: <1295247997.49.0.7150272714.issue10924@psf.upfronthosting.co.za>
Message-ID: <1295721824.6.0.813119599554.issue10924@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Actually, the "pending" stage is only for when things have been committed :)
See http://docs.python.org/devguide/triaging.html#triaging

----------
resolution: later -> accepted
stage: patch review -> commit review
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10924>
_______________________________________

From report at bugs.python.org  Sat Jan 22 19:48:39 2011
From: report at bugs.python.org (Giampaolo Rodola')
Date: Sat, 22 Jan 2011 18:48:39 +0000
Subject: [issue10982] asyncore timeouts do not work correctly
In-Reply-To: <1295719386.38.0.705218895334.issue10982@psf.upfronthosting.co.za>
Message-ID: <1295722119.13.0.748608949506.issue10982@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

You have misinterpreted the purpose of timeout argument.
"timeout" argument tells select() or poll() how long they have to wait before returning in case no file descriptors are ready.
This has nothing to do with asyncore.loop() which is supposed to keep running except when:

- all file descriptors have been closed/extinguished
- the count argument is provided

...in which case it finally returns.
Closing out as invalid.

----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10982>
_______________________________________

From report at bugs.python.org  Sat Jan 22 20:00:15 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 22 Jan 2011 19:00:15 +0000
Subject: [issue10975] #10961: Pydoc touchups in new 3.2 Web server
	(issue4090042)
In-Reply-To: <00221532cc70620113049a5fa977@google.com>
Message-ID: <1295722815.46.0.295227514826.issue10975@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
Removed message: http://bugs.python.org/msg126847

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10975>
_______________________________________

From report at bugs.python.org  Sat Jan 22 20:04:29 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 22 Jan 2011 19:04:29 +0000
Subject: [issue10949] logging.RotatingFileHandler not robust enough
In-Reply-To: <1295457072.71.0.821420961283.issue10949@psf.upfronthosting.co.za>
Message-ID: <1295723069.61.0.542368131085.issue10949@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Is it okay that there is no test?

----------
nosy: +eric.araujo
stage:  -> committed/rejected
versions: +Python 3.2 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10949>
_______________________________________

From report at bugs.python.org  Sat Jan 22 20:07:57 2011
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 22 Jan 2011 19:07:57 +0000
Subject: [issue10949] logging.RotatingFileHandler not robust enough
In-Reply-To: <1295457072.71.0.821420961283.issue10949@psf.upfronthosting.co.za>
Message-ID: <1295723277.19.0.681126606957.issue10949@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

You could have said that the py3k branch is closed for changes without tests or review...

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10949>
_______________________________________

From report at bugs.python.org  Sat Jan 22 21:23:21 2011
From: report at bugs.python.org (Giampaolo Rodola')
Date: Sat, 22 Jan 2011 20:23:21 +0000
Subject: [issue10968] threading.Timer should be a class so that it can be
	derived
In-Reply-To: <1295574501.95.0.0935688829986.issue10968@psf.upfronthosting.co.za>
Message-ID: <1295727801.85.0.966154364785.issue10968@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/issue10968>
_______________________________________

From report at bugs.python.org  Sat Jan 22 22:03:39 2011
From: report at bugs.python.org (Ned Deily)
Date: Sat, 22 Jan 2011 21:03:39 +0000
Subject: [issue10973] OS X 10.6 IDLE,
	tkinter: Cocoa Tk 8.5 crash when composite character typed in text
	field
In-Reply-To: <1295620061.05.0.0288010484186.issue10973@psf.upfronthosting.co.za>
Message-ID: <1295730219.85.0.393859175147.issue10973@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

This seems to me to be a nasty release blocker. As documented in the Tk bug that Victor cited (thanks!), the crash occurs in Cocoa Tk when an input method prefix "dead key" combining character is typed in a Tk text field. So, for example, with the US Extended input method on a US keyboard, to type ?, you can type the two keystrokes: Option-n n.  Or for an ?: Option-u a. Typing the leading dead key causes Tk to crash with the "index out of bounds" exception, bringing down tkinter and IDLE with it (and users losing their edits).  There is a workaround for users to enter these characters without a crash.  OS X also supports a postfix "dead key" combining sequence; ? -> n Shift-Option-n and ? -> a Shift-Option-u.  The postfix forms do not cause a crash with Cocoa Tk 8.5 and the expected character is stored in the field, although the screen may not get properly updated.  But, I suspect of the two, the prefix method is much more commonly used and, in any case, it is not reasonable to warn users that they risk a crash if they enter a common keyboard sequence.  (The other common method to enter characters not available on the keyboard is to use the system Character Viewer which gives access to all Unicode code points.  Unfortunately, Character Viewer input doesn't seem to work with Cocoa Tk 8.5.  That would seem to be a major deficiency in Cocoa Tk's support for full Unicode input.)

This problem is exhibited in the Apple-supplied Cocoa Tk 8.5 shipped with OS X 10.6 and the Apple-supplied IDLEs (/usr/bin/idle2.6 and /usr/bin/idle2.5) suffer from the same vulnerability.  So this is not a new problem in the ActiveState Tk 8.5.9.  The Tk bug report on the SourceForge tracker was opened and accepted nearly a year ago and, although subsequent comments and activity have raised the priority to 9 (critical), there is no indication that a fix is forthcoming soon.  I am pinging both at the SF tracker and on the Tcl Mac list and will propose some alternatives for 3.2 here shortly.

----------
components: +Tkinter
nosy: +benjamin.peterson, georg.brandl
priority: normal -> release blocker
title: '?' not working with IDLE 3.2rc1 - OSX 10.6.6 -> OS X 10.6 IDLE, tkinter: Cocoa Tk 8.5 crash when composite character typed in text field
versions: +Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10973>
_______________________________________

From report at bugs.python.org  Sat Jan 22 22:30:12 2011
From: report at bugs.python.org (nooB)
Date: Sat, 22 Jan 2011 21:30:12 +0000
Subject: [issue10684] Folders get deleted when trying to change case with
	shutil.move (Windows)
In-Reply-To: <1292149124.13.0.45494559671.issue10684@psf.upfronthosting.co.za>
Message-ID: <1295731812.7.0.264572602786.issue10684@psf.upfronthosting.co.za>


nooB <nsharish.mit at gmail.com> added the comment:

Sorry, for the wrong info. The issues exists only for folder renaming in windows.
try this,

>> import os, shutil
>> os.mkdir('test')
>> shutil.move('test', 'TEST')

poof. The folder is gone.
Shouldn't the path case be checked for file operations?

----------
title: Shutil.move deletes file/folder in windows while renaming -> Folders get deleted when trying to change case with shutil.move (Windows)
versions: +Python 2.5, Python 2.6, Python 2.7, Python 3.1, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10684>
_______________________________________

From report at bugs.python.org  Sat Jan 22 22:32:18 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 22 Jan 2011 21:32:18 +0000
Subject: [issue10684] Folders get deleted when trying to change case with
	shutil.move (Windows)
In-Reply-To: <1292149124.13.0.45494559671.issue10684@psf.upfronthosting.co.za>
Message-ID: <1295731938.97.0.977766110331.issue10684@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
priority: normal -> high
stage:  -> needs patch
versions:  -Python 2.5, Python 2.6, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10684>
_______________________________________

From report at bugs.python.org  Sat Jan 22 22:49:21 2011
From: report at bugs.python.org (nooB)
Date: Sat, 22 Jan 2011 21:49:21 +0000
Subject: [issue10983] Errors in http.client.HTTPConnection class (python3)
In-Reply-To: <1295732961.38.0.859825723182.issue10983@psf.upfronthosting.co.za>
Message-ID: <1295732961.38.0.859825723182.issue10983@psf.upfronthosting.co.za>


New submission from nooB <nsharish.mit at gmail.com>:

In python 3.x http.client.HTTPConnection class, I saw few problems.

1) `_tunnel_headers` not initialized in the __init__ method. This causes `set_tunnel` method to raise `AttributeError` when called without `headers` keyword argument.

2) In `_tunnel` method, `self._tunnel_headers.iteritems()` has been used instead of `self._tunnel_headers.items()`, which caused AttributeError.

3) In `_tunnel` method, the CONNECT request is incomplete and hangs.
self.send(b'\r\n') is missing after sending the headers.

----------
messages: 126857
nosy: nooB
priority: normal
severity: normal
status: open
title: Errors in http.client.HTTPConnection class (python3)
versions: Python 3.1, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10983>
_______________________________________

From report at bugs.python.org  Sat Jan 22 22:52:20 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 22 Jan 2011 21:52:20 +0000
Subject: [issue10983] Errors in http.client.HTTPConnection class (python3)
In-Reply-To: <1295732961.38.0.859825723182.issue10983@psf.upfronthosting.co.za>
Message-ID: <1295733140.2.0.656575965077.issue10983@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
components: +Library (Lib)
nosy: +orsenthil
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10983>
_______________________________________

From report at bugs.python.org  Sat Jan 22 22:54:22 2011
From: report at bugs.python.org (nooB)
Date: Sat, 22 Jan 2011 21:54:22 +0000
Subject: [issue10983] Errors in http.client.HTTPConnection class (python3)
In-Reply-To: <1295732961.38.0.859825723182.issue10983@psf.upfronthosting.co.za>
Message-ID: <1295733262.83.0.487699447079.issue10983@psf.upfronthosting.co.za>


Changes by nooB <nsharish.mit at gmail.com>:


----------
versions:  -Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10983>
_______________________________________

From report at bugs.python.org  Sat Jan 22 23:06:35 2011
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 22 Jan 2011 22:06:35 +0000
Subject: [issue10983] Errors in http.client.HTTPConnection class (python3)
In-Reply-To: <1295732961.38.0.859825723182.issue10983@psf.upfronthosting.co.za>
Message-ID: <1295733995.34.0.344696103126.issue10983@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

All your points make sense and I fixed them in r88144.

Leaving this open for somebody to add a unittest that actually exercises these tunnel features.

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10983>
_______________________________________

From report at bugs.python.org  Sat Jan 22 23:20:32 2011
From: report at bugs.python.org (Ned Deily)
Date: Sat, 22 Jan 2011 22:20:32 +0000
Subject: [issue10973] OS X 10.6 IDLE,
	tkinter: Cocoa Tk 8.5 crash when composite character typed in text
	field
In-Reply-To: <1295620061.05.0.0288010484186.issue10973@psf.upfronthosting.co.za>
Message-ID: <1295734832.93.0.204795204665.issue10973@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Here's a brain dump of possible options I see for 3.2rc2:

    1. document and do nothing
        -> IDLE (and other tkinter program) crashes whenever a user types a composing character (like Option u in US layout for an umlaut) when the 64-/32-bit installer is used

    2. don't ship the OS X 64-bit installer, only the traditional 32-bit one
        
    3a. don't ship IDLE.app and bin/idle with 64-bit installer
        
    3b. don't ship tkinter, IDLE.app, and bin/idle with 64-bit installer
        
    4. for 64-bit installer, link tkinter with Aqua Tk 8.4, like 32-bit installer
        -> no tkinter available in (default) 64-bit mode, users would need to force 32-bit execution
        -> need to fix IDLE to only run in 32-bit mode
        
    5a. for 64-bit installer, link tkinter with a third-party X11 Tk 8.5, most likely MacPorts
        -> X11 version works in both 64- and 32- and is likely more widely tested (on Unixes). MacPorts for example currently supplies an X11 Tk by default.
        -> non-native look and feel
        -> is X11 installed by default on 10.6? (check and document)
        -> MacPorts currently does not supply binary packages so users would need to install Xcode developer tools

    5b. for 64-bit installer, have the installer build an X11 Tk 8.5 (using the installer's existing third-party lib infrastructure) and ship with the 64-bit installer
        -> same as 5a except that IDLE and tkinter would now work out of the box but at the cost of the additional unknown development and testing work to get Tk built with the installer

At the moment, for 3.2rc2 my inclination is to pursue option 4 and at least explore the feasibility of option 5b with a fallback to option 3a while encouraging (but not depending) on a future fix for Cocoa Tk. Again, this applies only to the 64-/32-bit installer; the traditional 32-bit installer is linked with Carbon Tk 8.4 which does not have this problem.

Post 3.2, I think it makes sense to pursue a previously-discussed option to support multiple Tk versions with one release so users can choose.  That would also have the potential benefit of making Tk 8.5 available in one form or another for users of earlier OS X releases.  But that's a matter for later exploration.

----------
nosy: +michael.foord, rhettinger, ronaldoussoren
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10973>
_______________________________________

From report at bugs.python.org  Sat Jan 22 23:29:56 2011
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 22 Jan 2011 22:29:56 +0000
Subject: [issue10973] OS X 10.6 IDLE,
	tkinter: Cocoa Tk 8.5 crash when composite character typed in text
	field
In-Reply-To: <1295620061.05.0.0288010484186.issue10973@psf.upfronthosting.co.za>
Message-ID: <1295735396.78.0.871019955973.issue10973@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Hmm.  It seems better to me to accept this bug (and document it, and point out that it isn't Python's fault) than depriving 64-bit users of IDLE, or (even worse) of tkinter.

If you can manage a solution that doesn't remove IDLE, I'm in favor, but otherwise option 1. is my favorite.  I trust there is no possibility of a workaround from the Python or _tkinter side of things?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10973>
_______________________________________

From report at bugs.python.org  Sat Jan 22 23:54:56 2011
From: report at bugs.python.org (Ned Deily)
Date: Sat, 22 Jan 2011 22:54:56 +0000
Subject: [issue10973] OS X 10.6 IDLE,
	tkinter: Cocoa Tk 8.5 crash when composite character typed in text
	field
In-Reply-To: <1295620061.05.0.0288010484186.issue10973@psf.upfronthosting.co.za>
Message-ID: <1295736896.6.0.482728980156.issue10973@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Since the key strokes are captured directly by Tk, I doubt that anything could be worked around on the Python side unless there was some Tk option to disable a class of input characters or something. Seems unlikely but I can check with the tcl-mac list.

I should point out regarding 5a and 5b that with the X11 option (as with MacPorts today) using the Apple X11 Quartz window manager server (the default option) is a relatively seemless experience for the user. Clicking on IDLE.app or executing bin/idle in a shell causes the Apple X11.app to launch automatically and the expected IDLE windows appear alongside the user's existing (non-X11) windows.  The main difference is that there is the look of the windows and that the menu bars are in the X windows rather than in the normal OS X menu bar at the top of the screen (that menu bar is for X11.app).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10973>
_______________________________________

From report at bugs.python.org  Sun Jan 23 00:02:00 2011
From: report at bugs.python.org (Chris Lasher)
Date: Sat, 22 Jan 2011 23:02:00 +0000
Subject: [issue10984] argparse add_mutually_exclusive_group should accept
	existing arguments to register conflicts
In-Reply-To: <1295737320.83.0.942830837874.issue10984@psf.upfronthosting.co.za>
Message-ID: <1295737320.83.0.942830837874.issue10984@psf.upfronthosting.co.za>


New submission from Chris Lasher <chris.lasher at gmail.com>:

argparse supports registering conflicting arguments, however, it does so in a way that an argument may belong to at most one group of conflicting arguments. The inspiration for this bug is Stack Overflow question #4770576.
http://stackoverflow.com/questions/4770576/does-argparse-python-support-mutually-exclusive-groups-of-arguments

The most straightforward use case argparse can not accommodate is the following: the user has three flags, '-a', '-b', and '-c'. The flag '-b' is incompatible with both '-a' and with '-c', however, '-a' and '-c' are compatible with each other.

Current practice is to register a conflict by first defining a conflict group with parser.add_mutually_exclusive_group(), and then create new arguments within that group using group.add_argument(). Because the programmer is not allowed to create the argument prior to creating the group, an argument cannot be registered in two exclusive groups.

I feel it would be much more useful to be given the option to create exclusive groups after the programmer has defined and created the options, as is the design for ConflictsOptionParser
http://pypi.python.org/pypi/ConflictsOptionParser/

----------
components: Library (Lib)
messages: 126862
nosy: gotgenes
priority: normal
severity: normal
status: open
title: argparse add_mutually_exclusive_group should accept existing arguments to register conflicts
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10984>
_______________________________________

From report at bugs.python.org  Sun Jan 23 00:03:24 2011
From: report at bugs.python.org (R. David Murray)
Date: Sat, 22 Jan 2011 23:03:24 +0000
Subject: [issue9723] Add shlex.quote
In-Reply-To: <1283262014.72.0.527039259842.issue9723@psf.upfronthosting.co.za>
Message-ID: <1295737404.04.0.683369841747.issue9723@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Rather than doing a code deprecation you can just do 'from shlex import quote' in pipes (with a comment about backward compatibility).  I don't think there is any real harm in leaving that kind of backward compatibility in place indefinitely.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9723>
_______________________________________

From report at bugs.python.org  Sun Jan 23 00:46:02 2011
From: report at bugs.python.org (Brett Cannon)
Date: Sat, 22 Jan 2011 23:46:02 +0000
Subject: [issue10541] regrtest.py -T broken
In-Reply-To: <1290787334.28.0.0735858321707.issue10541@psf.upfronthosting.co.za>
Message-ID: <1295739962.36.0.504538987578.issue10541@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

At least the test_trace fix for preventing the complete destruction of any preset trace should be looked at and possibly applied separately (prevents coverage.py from covering the entire test suite as well). Should probably add a test to regrtest to make sure that the trace function is not mutated after a test file runs.

----------
nosy: +brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10541>
_______________________________________

From report at bugs.python.org  Sun Jan 23 01:18:09 2011
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 23 Jan 2011 00:18:09 +0000
Subject: [issue10985] test_sys triggers a fatal python error when run under
	coverage.py
In-Reply-To: <1295741889.19.0.432522991902.issue10985@psf.upfronthosting.co.za>
Message-ID: <1295741889.19.0.432522991902.issue10985@psf.upfronthosting.co.za>


New submission from Brett Cannon <brett at python.org>:

If you run test_sys under coverage.py with ``./python.exe -m coverage run --pylib Lib/test/regrtest.py test_sys`` you get::

  Fatal Python error: Cannot recover from stack overflow

Have not taken the time to try to figure out exactly what code is triggering the recursion, but coverage.py is being used w/o its extension coverage support. Could be caused by coverage.py, but I'm a bit surprised that it's a fatal error instead of a recursion limit exception.

----------
messages: 126865
nosy: brett.cannon
priority: normal
severity: normal
stage: unit test needed
status: open
title: test_sys triggers a fatal python error when run under coverage.py
type: crash
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10985>
_______________________________________

From report at bugs.python.org  Sun Jan 23 01:28:19 2011
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 23 Jan 2011 00:28:19 +0000
Subject: [issue10985] test_sys triggers a fatal python error when run under
	coverage.py
In-Reply-To: <1295741889.19.0.432522991902.issue10985@psf.upfronthosting.co.za>
Message-ID: <1295742499.21.0.128103525423.issue10985@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Ran the test under verbose mode at Antoine's suggestion; test triggering the failure is test_recursionlimit_recovery

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10985>
_______________________________________

From report at bugs.python.org  Sun Jan 23 01:34:59 2011
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 23 Jan 2011 00:34:59 +0000
Subject: [issue10985] test_sys triggers a fatal python error when run under
	coverage.py
In-Reply-To: <1295741889.19.0.432522991902.issue10985@psf.upfronthosting.co.za>
Message-ID: <1295742899.8.0.37524178274.issue10985@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

The comment on the test says its brittle and sensitive to nothing mucking around with recursion depth, so the test probably need a unittest.skipIf check for a trace function.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10985>
_______________________________________

From report at bugs.python.org  Sun Jan 23 01:38:50 2011
From: report at bugs.python.org (R. David Murray)
Date: Sun, 23 Jan 2011 00:38:50 +0000
Subject: [issue10984] argparse add_mutually_exclusive_group should accept
	existing arguments to register conflicts
In-Reply-To: <1295737320.83.0.942830837874.issue10984@psf.upfronthosting.co.za>
Message-ID: <1295743130.85.0.658592750461.issue10984@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
nosy: +bethard

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10984>
_______________________________________

From report at bugs.python.org  Sun Jan 23 02:10:09 2011
From: report at bugs.python.org (Nestor Aguilera)
Date: Sun, 23 Jan 2011 01:10:09 +0000
Subject: [issue10973] OS X 10.6 IDLE,
	tkinter: Cocoa Tk 8.5 crash when composite character typed in text
	field
In-Reply-To: <1295735396.78.0.871019955973.issue10973@psf.upfronthosting.co.za>
Message-ID: <01D58F80-5837-4BD0-86D1-15C2B87C884D@gmail.com>


Nestor Aguilera <aguilera at santafe-conicet.gov.ar> added the comment:

Thanks Ned for thinking of ways out.

- If I had a choice, I would agree with Georg's choice (Ned's option 1): most users will not use the composite characters and need not go through complications, or worse, cannibalization of the distribution (3a and 3b are unacceptable).

Perhaps the existence of the bug could be documented together with the need of a proper Tcl/Tk version.

- My experience with python 3.1.3 with OS 10.6 is that when starting IDLE I always get several messages of the sort:

      Python(1305,0xa0a5c540) malloc: *** error for object
      0x1a277738: pointer being freed was not allocated
      *** set a breakpoint in malloc_error_break to debug

possibly leading to memory leaks. Thus, I am not happy with 4.

- As for 5a, perhaps with the warnings of Tcl/Tk and composite crashes, one could announce this alternative installation. 5b doesn't seem to be worth the trouble, given the existence of the MacPorts version.

My 2 cents.

N?stor

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10973>
_______________________________________

From report at bugs.python.org  Sun Jan 23 02:41:38 2011
From: report at bugs.python.org (Sean Reifschneider)
Date: Sun, 23 Jan 2011 01:41:38 +0000
Subject: [issue8591] update mkpkg to latest coding standards
In-Reply-To: <1272727331.63.0.427295643421.issue8591@psf.upfronthosting.co.za>
Message-ID: <1295746898.93.0.80646986451.issue8591@psf.upfronthosting.co.za>


Changes by Sean Reifschneider <jafo at tummy.com>:


----------
nosy:  -jafo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8591>
_______________________________________

From report at bugs.python.org  Sun Jan 23 02:41:58 2011
From: report at bugs.python.org (Ned Deily)
Date: Sun, 23 Jan 2011 01:41:58 +0000
Subject: [issue10940] IDLE 3.2 hangs with Cmd-M hotkey on OS X 10.6 with
	64-bit installer and A/S Tk 8.5
In-Reply-To: <1295391844.43.0.912463306116.issue10940@psf.upfronthosting.co.za>
Message-ID: <1295746918.1.0.339770373247.issue10940@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

It appears that the Cocoa Tk 8.5 added support for the Apple convention using Cmd-M as the window minimize menu item (collapses the window into the dock) and that conflicts with IDLE's use of the Cmd-M as the shortcut for the Open Module menu item.  I'll see if Tk can be persuaded to not use that shortcut, otherwise it will probably be necessary to use a new shortcut for Open Module on OS X.

----------
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10940>
_______________________________________

From report at bugs.python.org  Sun Jan 23 02:59:40 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 23 Jan 2011 01:59:40 +0000
Subject: [issue10973] OS X 10.6 IDLE,
	tkinter: Cocoa Tk 8.5 crash when composite character typed in
	text	field
In-Reply-To: <1295735396.78.0.871019955973.issue10973@psf.upfronthosting.co.za>
Message-ID: <4D3B8B82.7060500@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> Hmm.  It seems better to me to accept this bug (and document it, and
> point out that it isn't Python's fault) than depriving 64-bit users
> of IDLE, or (even worse) of tkinter.

I disagree. There aren't really "64-bit users" on OSX, thanks to fat
binaries. So if starting IDLE would start a 32-bit interpreter, users
likely won't even notice. If they do notice, they can still run in
64-bit mode from the command line.

In my experience with fat python builds on OSX, it's typically better
to prefer 32-bit mode, anyway, as extension modules often don't come
in a fat version, but often in 32-bit mode only.

----------
title: OS X 10.6 IDLE, tkinter: Cocoa Tk 8.5 crash when composite character typed in text field -> OS X 10.6 IDLE,	tkinter: Cocoa Tk 8.5 crash when composite character typed in text	field

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10973>
_______________________________________

From report at bugs.python.org  Sun Jan 23 03:47:00 2011
From: report at bugs.python.org (Benjamin VENELLE)
Date: Sun, 23 Jan 2011 02:47:00 +0000
Subject: [issue10986] traceback's rendering behavior while throwing custom
	exception
In-Reply-To: <1295750820.31.0.636288532577.issue10986@psf.upfronthosting.co.za>
Message-ID: <1295750820.31.0.636288532577.issue10986@psf.upfronthosting.co.za>


New submission from Benjamin VENELLE <gu0sur20 at gmail.com>:

Hi,

>From few days, I've acknowledge when throwing an exception, the last traceback entry is always related to the raise statement. This is ok when the exception takes source from a non fail-safe code. But when an exception is raised due to a function's inputs sanity check (like an assertion error) the last traceback entry is non-sense. I've done a script to spot this behavior.

Is there a way to prevent last traceback rendering (not suppressing) while exception is displayed without explicit call to traceback.print_exception ? If not, it would be useful to have a boolean declared in Exception's classes which will allow last traceback entry rendering or not.

----------
components: Interpreter Core
files: traceback_rendering.py
messages: 126871
nosy: Kain94
priority: normal
severity: normal
status: open
title: traceback's rendering behavior while throwing custom exception
type: feature request
versions: Python 3.1
Added file: http://bugs.python.org/file20488/traceback_rendering.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10986>
_______________________________________

From report at bugs.python.org  Sun Jan 23 03:58:15 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 23 Jan 2011 02:58:15 +0000
Subject: [issue10541] regrtest.py -T broken
In-Reply-To: <1290787334.28.0.0735858321707.issue10541@psf.upfronthosting.co.za>
Message-ID: <1295751495.57.0.917948478761.issue10541@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/issue10541>
_______________________________________

From report at bugs.python.org  Sun Jan 23 05:04:32 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 23 Jan 2011 04:04:32 +0000
Subject: [issue10986] traceback's rendering behavior while throwing custom
	exception
In-Reply-To: <1295750820.31.0.636288532577.issue10986@psf.upfronthosting.co.za>
Message-ID: <1295755472.79.0.172645249833.issue10986@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Please see python-ideas list.

----------
nosy: +benjamin.peterson
resolution:  -> rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10986>
_______________________________________

From report at bugs.python.org  Sun Jan 23 06:46:52 2011
From: report at bugs.python.org (John Machin)
Date: Sun, 23 Jan 2011 05:46:52 +0000
Subject: [issue10954] No warning for csv.writer API change
In-Reply-To: <1295519548.77.0.698015070506.issue10954@psf.upfronthosting.co.za>
Message-ID: <1295761612.5.0.772503030463.issue10954@psf.upfronthosting.co.za>


John Machin <sjmachin at lexicon.net> added the comment:

I don't understand "Changing csv api is a feature request that could only happen in 3.3". This is NOT a request for an API change. Lennert's point is that an API change was made in 3.0 as compared with 2.6 but there is no fixer in 2to3. What is requested is for csv.reader/writer to give more meaningful error messages for valid 2.x code that has been put through fixer-less 2to3.

The name of the arg is "newline". "newlines" is an attribute that stores what was actually found in "universal newlines" mode.

newline='' is needed on input for the same reason that binary mode is required in 2.x: \r and \n may quite validly appear in data, inside a quoted field, and must not be treated as part of a row separator.

newline='' is needed on output for the same reason that binary mode is required in 2.x: any \n in the data and any \n in the caller's chosen "line" terminator must be preserved from being changed to os.linesep (e.g. \r\n).

"newline" is not available as an attribute of the _io.TextIOWrapper object created by open('xxx.csv', 'w', newline=''); is exposing this possible?

----------
versions: +Python 3.2 -Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10954>
_______________________________________

From report at bugs.python.org  Sun Jan 23 07:06:10 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 23 Jan 2011 06:06:10 +0000
Subject: [issue10987] Bizarre pickle -- exception interaction bug
In-Reply-To: <1295762770.11.0.0669999171717.issue10987@psf.upfronthosting.co.za>
Message-ID: <1295762770.11.0.0669999171717.issue10987@psf.upfronthosting.co.za>


New submission from Terry J. Reedy <tjreedy at udel.edu>:

Tool/scripts/find_recursionlimit.py includes test_cpickle() which, like the other test_xxx functions, is supposed to raise a RuntimeError when the recursion limit is reached. It appears to work correctly on 3.1 and I presume previously. On 3.2, test_cpickle() hangs. Here is much reduced code that shows the behavior:

import itertools
import io
import _pickle

# extracted from 'def test_cpickle' and condensed:
l = None
for n in itertools.count():
    try:
        raise KeyError
    except KeyError:
        for i in range(100):
            l = [l]
        print(n,i)
    _pickle.Pickler(io.BytesIO(), protocol=-1).dump(l)

The added print line prints 0,99 1,99, ... indefinitely. If the recursive list l is added to the print function, the attempt to create repr(l) raises a runtime error at n = 9. If we remove the try-except part:

l = None
for n in itertools.count():
    for i in range(100):
        l = [l]
    print(n,i)
    _pickle.Pickler(io.BytesIO(), protocol=-1).dump(l)

*pickle* now raises a RuntimeError, as expected in the original context, at n=4!

1. I do not actually know which behavior is buggy. I suppose the next step would be to capture and not toss the pickle output to see what is the difference.

2. At least for the present, I think the call to test_cpickle should be commented out in find_recursionlimit.py.

There seems to be other pickle and recursive structure issues, like #9269, but I did not see any the same as this.

----------
files: frl_pickle1.py
messages: 126874
nosy: belopolsky, pitrou, terry.reedy
priority: normal
severity: normal
status: open
title: Bizarre pickle -- exception interaction bug
type: behavior
versions: Python 3.2
Added file: http://bugs.python.org/file20489/frl_pickle1.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10987>
_______________________________________

From report at bugs.python.org  Sun Jan 23 07:24:32 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 23 Jan 2011 06:24:32 +0000
Subject: [issue10987] Bizarre pickle -- exception interaction bug
In-Reply-To: <1295762770.11.0.0669999171717.issue10987@psf.upfronthosting.co.za>
Message-ID: <1295763872.69.0.731789924114.issue10987@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

3.2rc1 on WinXP. I got hanging behavior with both interpreter and IDLE.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10987>
_______________________________________

From report at bugs.python.org  Sun Jan 23 08:09:48 2011
From: report at bugs.python.org (Lennart Regebro)
Date: Sun, 23 Jan 2011 07:09:48 +0000
Subject: [issue10954] No warning for csv.writer API change
In-Reply-To: <1295519548.77.0.698015070506.issue10954@psf.upfronthosting.co.za>
Message-ID: <1295766588.18.0.994409014346.issue10954@psf.upfronthosting.co.za>


Lennart Regebro <regebro at gmail.com> added the comment:

In the worst case, not checking for newline='' is not a big problem, as anyone moving from Python 2 to Python 3 will open the file in binary mode. That error message could tell the user to use binary mode newlines=''.

Using textmode and newlines is only likely to happen with people writing new code for Python 3 and not reading the docs, which is a different problem. :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10954>
_______________________________________

From report at bugs.python.org  Sun Jan 23 08:33:34 2011
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 23 Jan 2011 07:33:34 +0000
Subject: [issue10973] OS X 10.6 IDLE,
	tkinter: Cocoa Tk 8.5 crash when composite character typed in
	text	field
In-Reply-To: <1295620061.05.0.0288010484186.issue10973@psf.upfronthosting.co.za>
Message-ID: <1295768014.87.0.414889181595.issue10973@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

> I disagree. There aren't really "64-bit users" on OSX, thanks to fat
> binaries. So if starting IDLE would start a 32-bit interpreter, users
> likely won't even notice. If they do notice, they can still run in
> 64-bit mode from the command line.

Okay, fair enough.  If it's easy to always let IDLE run in 32-bit mode, I'm fine with that.  What about other programs using tkinter?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10973>
_______________________________________

From report at bugs.python.org  Sun Jan 23 08:54:36 2011
From: report at bugs.python.org (godfryd)
Date: Sun, 23 Jan 2011 07:54:36 +0000
Subject: [issue10960] os.stat() does not mention that it follow symlinks by
	default
In-Reply-To: <1295544486.66.0.118119387237.issue10960@psf.upfronthosting.co.za>
Message-ID: <1295769276.99.0.207593630795.issue10960@psf.upfronthosting.co.za>


godfryd <godfryd at gmail.com> added the comment:

I improved a little bit lstat function description and added note to stat function. 

I see that links :func:`stat` do not lead to stat function but to stat module. Is it Sphinx bug? In my changes I made explicit link to os.stat function.

----------
keywords: +patch
nosy: +godfryd
Added file: http://bugs.python.org/file20490/improved-lstat-doc-patch.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10960>
_______________________________________

From report at bugs.python.org  Sun Jan 23 10:44:41 2011
From: report at bugs.python.org (Steven Bethard)
Date: Sun, 23 Jan 2011 09:44:41 +0000
Subject: [issue10984] argparse add_mutually_exclusive_group should accept
	existing arguments to register conflicts
In-Reply-To: <1295737320.83.0.942830837874.issue10984@psf.upfronthosting.co.za>
Message-ID: <1295775881.74.0.425181231893.issue10984@psf.upfronthosting.co.za>


Steven Bethard <steven.bethard at gmail.com> added the comment:

I'm definitely open to providing such functionality. I assume you're imagining something like:

parser = argparse.ArgumentParser()
a_action = parser.add_argument('-a')
b_action = parser.add_argument('-b')
c_action = parser.add_argument('-c')
d_action = parser.add_argument('-d')
parser.add_mutually_exclusive_group(a_action, c_action)
parser.add_mutually_exclusive_group(a_action, d_action)
...

If you can supply a patch, I'll take a look at it.

----------
type: behavior -> feature request
versions:  -Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10984>
_______________________________________

From report at bugs.python.org  Sun Jan 23 11:11:39 2011
From: report at bugs.python.org (Steven Bethard)
Date: Sun, 23 Jan 2011 10:11:39 +0000
Subject: [issue9509] argparse FileType raises ugly exception for missing file
In-Reply-To: <1280927287.23.0.0771144110186.issue9509@psf.upfronthosting.co.za>
Message-ID: <1295777499.91.0.761843549871.issue9509@psf.upfronthosting.co.za>


Steven Bethard <steven.bethard at gmail.com> added the comment:

Georg, is this something we can patch for rc2? It's a bug - errors encountered by argparse-internal code should be translated into command line errors, and they currently aren't for read-only files.

For what it's worth, the tests fail when the new test_argparse test is added, and pass when the patch is applied, and I have personally reviewed the code and run the entire test suite on OS X and everything still passes.

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9509>
_______________________________________

From report at bugs.python.org  Sun Jan 23 11:15:11 2011
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 23 Jan 2011 10:15:11 +0000
Subject: [issue9509] argparse FileType raises ugly exception for missing file
In-Reply-To: <1280927287.23.0.0771144110186.issue9509@psf.upfronthosting.co.za>
Message-ID: <1295777711.21.0.955485373923.issue9509@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

This would be acceptable to patch; I wonder whether to swallow the exception text of IOError though.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9509>
_______________________________________

From report at bugs.python.org  Sun Jan 23 12:26:01 2011
From: report at bugs.python.org (Steven Bethard)
Date: Sun, 23 Jan 2011 11:26:01 +0000
Subject: [issue9509] argparse FileType raises ugly exception for missing file
In-Reply-To: <1280927287.23.0.0771144110186.issue9509@psf.upfronthosting.co.za>
Message-ID: <1295781961.66.0.871460503471.issue9509@psf.upfronthosting.co.za>


Steven Bethard <steven.bethard at gmail.com> added the comment:

Good point. Here's the updated patch that reports the IOError as well. All tests pass. I'll apply in a bit if I don't hear otherwise.

----------
Added file: http://bugs.python.org/file20491/argparse.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9509>
_______________________________________

From report at bugs.python.org  Sun Jan 23 12:35:56 2011
From: report at bugs.python.org (Nestor Aguilera)
Date: Sun, 23 Jan 2011 11:35:56 +0000
Subject: [issue10973] OS X 10.6 IDLE,
	tkinter: Cocoa Tk 8.5 crash when composite character typed in
	text	field
In-Reply-To: <1295768014.87.0.414889181595.issue10973@psf.upfronthosting.co.za>
Message-ID: <DF0623EE-9C28-44A7-A6F0-1B224BAED2ED@santafe-conicet.gov.ar>


Nestor Aguilera <aguilera at santafe-conicet.gov.ar> added the comment:

On 23 Jan 2011, at 04:33, Georg Brandl wrote:

> Georg Brandl <georg at python.org> added the comment:
> 
>> I disagree. There aren't really "64-bit users" on OSX, thanks to fat
>> binaries. So if starting IDLE would start a 32-bit interpreter, users
>> likely won't even notice. If they do notice, they can still run in
>> 64-bit mode from the command line.

> Okay, fair enough.  If it's easy to always let IDLE run in 32-bit mode, I'm fine with that.  What about other programs using tkinter?

In a previous message (http://bugs.python.org/issue10973#msg126868) I mentioned that I get warning messages with the 32-bit version of 3.1.3 in OSX 10.6. Would a 32-bit version for 3.2 correct these?

----------
title: OS X 10.6 IDLE,	tkinter: Cocoa Tk 8.5 crash when composite character typed in text	field -> OS X 10.6 IDLE, tkinter: Cocoa Tk 8.5 crash when composite character typed in text	field

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10973>
_______________________________________

From report at bugs.python.org  Sun Jan 23 12:37:03 2011
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 23 Jan 2011 11:37:03 +0000
Subject: [issue9509] argparse FileType raises ugly exception for missing file
In-Reply-To: <1280927287.23.0.0771144110186.issue9509@psf.upfronthosting.co.za>
Message-ID: <1295782623.48.0.0520211328742.issue9509@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Library patch looks good.

Tests: Does the create_readonly_file helper work on all platforms, esp. Windows?  Maybe it's better to create a different error situation?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9509>
_______________________________________

From report at bugs.python.org  Sun Jan 23 12:40:24 2011
From: report at bugs.python.org (Nestor Aguilera)
Date: Sun, 23 Jan 2011 11:40:24 +0000
Subject: [issue10974] IDLE 3.2 not loading on double-click in Finder, OSX 10.6
In-Reply-To: <1295682604.31.0.887060902448.issue10974@psf.upfronthosting.co.za>
Message-ID: <FC062A49-8EDC-4D19-9399-AEC13584C8CE@santafe-conicet.gov.ar>


Nestor Aguilera <aguilera at santafe-conicet.gov.ar> added the comment:

On 22 Jan 2011, at 04:50, Ned Deily wrote:

[...]
> A similar exception occurs (without a crash) when saving a file to a non-ASCII file name and LANG is not properly set:
[...]

Is there a way of telling tkinter to set the encoding to utf-8 (or whatever) before seeking recent-files.lst?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10974>
_______________________________________

From report at bugs.python.org  Sun Jan 23 12:40:42 2011
From: report at bugs.python.org (SilentGhost)
Date: Sun, 23 Jan 2011 11:40:42 +0000
Subject: [issue9509] argparse FileType raises ugly exception for missing file
In-Reply-To: <1280927287.23.0.0771144110186.issue9509@psf.upfronthosting.co.za>
Message-ID: <1295782842.4.0.410851914474.issue9509@psf.upfronthosting.co.za>


SilentGhost <ghost.adh at gmail.com> added the comment:

I've tested this on windows. It passed all test.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9509>
_______________________________________

From report at bugs.python.org  Sun Jan 23 12:49:18 2011
From: report at bugs.python.org (Prasun Ratn)
Date: Sun, 23 Jan 2011 11:49:18 +0000
Subject: [issue2889] curses for windows (alternative patch)
In-Reply-To: <1210919907.42.0.842256015219.issue2889@psf.upfronthosting.co.za>
Message-ID: <1295783358.5.0.735452014625.issue2889@psf.upfronthosting.co.za>


Prasun Ratn <prasun3 at gmail.com> added the comment:

What is the status of this bug?

I tried to build the svn trunk with patches provided by zhirsch but I had problems applying the patches. I went ahead and made a new patch which is pretty similar to the earlier patch (mentioned above). The one change is that I implemented mkstemp() so putwin() and getwin() work.

----------
nosy: +Prasun Ratn
Added file: http://bugs.python.org/file20492/pdcurses-changes.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2889>
_______________________________________

From report at bugs.python.org  Sun Jan 23 12:50:57 2011
From: report at bugs.python.org (Prasun Ratn)
Date: Sun, 23 Jan 2011 11:50:57 +0000
Subject: [issue2889] curses for windows (alternative patch)
In-Reply-To: <1210919907.42.0.842256015219.issue2889@psf.upfronthosting.co.za>
Message-ID: <1295783457.21.0.328131568508.issue2889@psf.upfronthosting.co.za>


Changes by Prasun Ratn <prasun3 at gmail.com>:


Added file: http://bugs.python.org/file20493/pdcurses.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2889>
_______________________________________

From report at bugs.python.org  Sun Jan 23 12:53:21 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Sun, 23 Jan 2011 11:53:21 +0000
Subject: [issue10949] logging.RotatingFileHandler not robust enough
In-Reply-To: <1295457072.71.0.821420961283.issue10949@psf.upfronthosting.co.za>
Message-ID: <1295783601.48.0.349848690992.issue10949@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

<facepalm>Sorry, Georg! I think I've been working too hard, this completely passed me by. Should have left py3k till later, as it's not that urgent.</facepalm>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10949>
_______________________________________

From report at bugs.python.org  Sun Jan 23 12:56:02 2011
From: report at bugs.python.org (Steven Bethard)
Date: Sun, 23 Jan 2011 11:56:02 +0000
Subject: [issue9509] argparse FileType raises ugly exception for missing file
In-Reply-To: <1280927287.23.0.0771144110186.issue9509@psf.upfronthosting.co.za>
Message-ID: <1295783762.42.0.43861212966.issue9509@psf.upfronthosting.co.za>


Steven Bethard <steven.bethard at gmail.com> added the comment:

The docs for os.chmod claim:

Availability: Unix, Windows.
Although Windows supports chmod(), you can only set the file's read-only flag with it (via the stat.S_IWRITE and stat.S_IREAD constants or a corresponding integer value). All other bits are ignored.

So at least according to the current docs, we should be okay calling `os.chmod(file_path, stat.S_IREAD)` on Unix and Windows (and of course OS X too). Is that enough or did you have other platforms in mind?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9509>
_______________________________________

From report at bugs.python.org  Sun Jan 23 15:16:53 2011
From: report at bugs.python.org (Michael Foord)
Date: Sun, 23 Jan 2011 14:16:53 +0000
Subject: [issue10973] OS X 10.6 IDLE,
	tkinter: Cocoa Tk 8.5 crash when composite character typed in
	text	field
In-Reply-To: <1295620061.05.0.0288010484186.issue10973@psf.upfronthosting.co.za>
Message-ID: <1295792213.3.0.793181385082.issue10973@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

There are a few issues here.

X11 is not installed by *default* on Mac OS X (it is supplied separately) so it doesn't provide an "out of the box" solution.

Starting IDLE as 32bit alone doesn't solve the problem as it launches a subprocess and you have to ensure that is launched as a 32bit process as well.

I think *clearly* documenting that the Mac OS X 10.6 version *requires* Activestate Tcl / Tk 8.5 is the best solution (assuming I am correct in thinking that using the Activestate distribution solves the problem). This is really a duplicate of issue 10969 by the way. See the discussion there for suggested ways to clarify the dependency on the download page.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10973>
_______________________________________

From report at bugs.python.org  Sun Jan 23 16:32:27 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 23 Jan 2011 15:32:27 +0000
Subject: [issue10987] _pickle doesn't handle recursion limits properly
In-Reply-To: <1295762770.11.0.0669999171717.issue10987@psf.upfronthosting.co.za>
Message-ID: <1295796747.29.0.604662420654.issue10987@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Here is a patch. I also strength the recursion limit testing script by testing both recursion through dicts and through lists.

----------
components: +Extension Modules
keywords: +patch
nosy: +alexandre.vassalotti, amaury.forgeotdarc, georg.brandl
stage:  -> patch review
title: Bizarre pickle -- exception interaction bug -> _pickle doesn't handle recursion limits properly
type: behavior -> crash
versions: +Python 3.1
Added file: http://bugs.python.org/file20494/picklerec.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10987>
_______________________________________

From report at bugs.python.org  Sun Jan 23 17:02:22 2011
From: report at bugs.python.org (R. David Murray)
Date: Sun, 23 Jan 2011 16:02:22 +0000
Subject: [issue10960] os.stat() does not mention that it follow symlinks by
	default
In-Reply-To: <1295544486.66.0.118119387237.issue10960@psf.upfronthosting.co.za>
Message-ID: <1295798542.02.0.409737390684.issue10960@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I don't think Georg considers it a bug in Sphinx, it's just how the disambiguation machinery works.  You can write :func:`~os.stat` if you want the link text to just be 'stat' but the link to be to 'os.stat'.

I don't think the addition to lstat is either helpful or needed.  The addition to stat, which is needed, I don't think should be a note, but rather an inline comment early in the documentation paragraph.

Thanks for working on this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10960>
_______________________________________

From report at bugs.python.org  Sun Jan 23 17:06:31 2011
From: report at bugs.python.org (R. David Murray)
Date: Sun, 23 Jan 2011 16:06:31 +0000
Subject: [issue10954] No warning for csv.writer API change
In-Reply-To: <1295519548.77.0.698015070506.issue10954@psf.upfronthosting.co.za>
Message-ID: <1295798791.53.0.0982675671382.issue10954@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

The API change would be generating an error if newline='' wasn't specified.  Amplifying the bytes-case error message would be fine, though.  On the other hand, we are in RC phase, and I'm not at all sure this is important enough to go in to an RC.  On the gripping hand it is also trivial enough that Georg might approve it.

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10954>
_______________________________________

From report at bugs.python.org  Sun Jan 23 18:26:45 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 23 Jan 2011 17:26:45 +0000
Subject: [issue10987] _pickle doesn't handle recursion limits properly
In-Reply-To: <1295762770.11.0.0669999171717.issue10987@psf.upfronthosting.co.za>
Message-ID: <1295803605.21.0.86888516608.issue10987@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Committed in r88147 (3.2) and r88148 (3.1).

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10987>
_______________________________________

From report at bugs.python.org  Sun Jan 23 19:38:05 2011
From: report at bugs.python.org (Joshua Arnold)
Date: Sun, 23 Jan 2011 18:38:05 +0000
Subject: [issue10988] Descriptor protocol documentation for super bindings is
	incorrect
In-Reply-To: <1295807885.2.0.206629380861.issue10988@psf.upfronthosting.co.za>
Message-ID: <1295807885.2.0.206629380861.issue10988@psf.upfronthosting.co.za>


New submission from Joshua Arnold <josharnold52 at gmail.com>:

In 'Doc/reference/datamodel.rst', the 'Invoking Descriptors' documentation specifies the following behavior for super objects:

[snip]
Super Binding
   If ``a`` is an instance of :class:`super`, then the binding ``super(B,
   obj).m()`` searches ``obj.__class__.__mro__`` for the base class ``A``
   immediately preceding ``B`` and then invokes the descriptor with the call:
   ``A.__dict__['m'].__get__(obj, A)``.
[snip]

In the above paragrah, the call:

   A.__dict__['m'].__get__(obj, A)
   
is incorrect.  In reality, the descriptor is invoked via:

   A.__dict__['m'].__get__(obj, obj.__class__)
   
Loosely speaking, the 'owner' argument is set to the subclass associated with the super object, not the superclass.  There is a similar error in the 'Descriptor HowTo Guide' under 'Invoking Descriptors'

(Strictly speaking, the specification is inaccurate on some other points.  It assumes obj is not a class and doesn't state that the entire mro preceding 'B' is searched for 'm'.  But those may be considered simplifications for the sake of brevity)

I considered reporting this as a bug in the implementation rather than the specification.  But I think the implementation's algorithm is the correct one.  In particular, it yields the desired behavior for classmethods   In any case, the current behavior has been around for a while (it was the fix for issue #535444, dating back to 2.2)

Code demonstrating the current behavior:

class Desc(object):
    def __get__(self, instance, owner):
        return owner

class A(object):
    attr = Desc()

class B(A):
    pass

class C(B):
    pass

instance = C()

assert super(B,instance).attr == C
assert super(B,C).attr == C

#According to the specification, the assertions should be:
#assert super(B,instance).attr == A
#assert super(B,C).attr == A

----------
assignee: docs at python
components: Documentation
messages: 126895
nosy: Joshua.Arnold, docs at python
priority: normal
severity: normal
status: open
title: Descriptor protocol documentation for super bindings is incorrect
versions: Python 2.5, Python 2.6, Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10988>
_______________________________________

From report at bugs.python.org  Sun Jan 23 19:42:50 2011
From: report at bugs.python.org (Ronald Oussoren)
Date: Sun, 23 Jan 2011 18:42:50 +0000
Subject: [issue10955] Possible regression with stdlib in zipfile
In-Reply-To: <1295531540.01.0.823019908764.issue10955@psf.upfronthosting.co.za>
Message-ID: <1295808170.01.0.344185835195.issue10955@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

Data files can be anything that can be a data-file in a setuptools/distribute setup.py file. Note that #10972 isn't necessary when python32.zip is build using the zipfile module, _encodeFilenameFlags uses either ASCII or UTF-8 to encode filenames and the new zipimport behavior matches that.

I can confirm that the current HEAD fixes the problems I had in py2app.

BTW. I do considered this a regression because having the stdlib in a zipfile used to work in earlier versions, was obviously something that was intended to work (python32.zip in the default value for sys.path) and no longer worked.

And last but definitely not least: Thanks for the quick response.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10955>
_______________________________________

From report at bugs.python.org  Sun Jan 23 19:50:01 2011
From: report at bugs.python.org (Ned Deily)
Date: Sun, 23 Jan 2011 18:50:01 +0000
Subject: [issue10973] OS X 10.6 IDLE,
	tkinter: Cocoa Tk 8.5 crash when composite character typed in
	text	field
In-Reply-To: <1295620061.05.0.0288010484186.issue10973@psf.upfronthosting.co.za>
Message-ID: <1295808601.56.0.721385787389.issue10973@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Michael, the crash documented here is *not* fixed by installing ActiveState 8.5; it is currently a problem seen with both A/S and Apple's Tk 8.5.  Also, to answer my own question, I double-checked the Snow Leopard 10.6 installation DVD and, unlike earlier releases, X11 is now installed by default.

That said, there is now some action on the Tcl front which may result in an official patch to at least prevent the crash.  If so, there may be yet another option:

6. for 64-bit installer, have the installer build a Cocoa Tk 8.5 (using the installer's existing third-party lib infrastructure) and ship with the 64-bit installer

So, at the moment, I think the best course of action is to explore the various patch options and, with more info available, a decision for 3.2rc2 made prior to cutoff.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10973>
_______________________________________

From report at bugs.python.org  Sun Jan 23 20:19:17 2011
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 23 Jan 2011 19:19:17 +0000
Subject: [issue10954] No warning for csv.writer API change
In-Reply-To: <1295519548.77.0.698015070506.issue10954@psf.upfronthosting.co.za>
Message-ID: <1295810357.33.0.00982649797623.issue10954@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Can we have a concrete proposal in the form of a patch, please?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10954>
_______________________________________

From report at bugs.python.org  Sun Jan 23 20:56:06 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 23 Jan 2011 19:56:06 +0000
Subject: [issue10988] Descriptor protocol documentation for super bindings is
	incorrect
In-Reply-To: <1295807885.2.0.206629380861.issue10988@psf.upfronthosting.co.za>
Message-ID: <1295812566.99.0.262976173546.issue10988@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <rhettinger at users.sourceforge.net>:


----------
assignee: docs at python -> rhettinger
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10988>
_______________________________________

From report at bugs.python.org  Sun Jan 23 22:14:04 2011
From: report at bugs.python.org (Michal Nowikowski)
Date: Sun, 23 Jan 2011 21:14:04 +0000
Subject: [issue10960] os.stat() does not mention that it follow symlinks by
	default
In-Reply-To: <1295544486.66.0.118119387237.issue10960@psf.upfronthosting.co.za>
Message-ID: <1295817244.75.0.600034194312.issue10960@psf.upfronthosting.co.za>


Michal Nowikowski <godfryd at gmail.com> added the comment:

The patch v2:
- in description of os.stat function added information about following symlinks,
- made list of returned attributes by os.stat function more readable,
- fixed links to os.stat function in whole document.

----------
Added file: http://bugs.python.org/file20495/improved-lstat-doc-patch-v2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10960>
_______________________________________

From report at bugs.python.org  Sun Jan 23 22:21:57 2011
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 23 Jan 2011 21:21:57 +0000
Subject: [issue10985] test_sys triggers a fatal python error when run under
	coverage.py
In-Reply-To: <1295741889.19.0.432522991902.issue10985@psf.upfronthosting.co.za>
Message-ID: <1295817717.56.0.0686773328922.issue10985@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

I have a patch for this which makes it a CPython-only test along with being conditional if a trace function is set. Making it a release blocker to see if Georg will let me commit it.

----------
keywords: +patch
nosy: +georg.brandl
priority: normal -> release blocker
Added file: http://bugs.python.org/file20496/issue10985.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10985>
_______________________________________

From report at bugs.python.org  Sun Jan 23 23:02:05 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 23 Jan 2011 22:02:05 +0000
Subject: [issue10989] ssl.SSLContext(True).load_verify_locations(None,
	True) segfault
In-Reply-To: <1295820125.73.0.864692220479.issue10989@psf.upfronthosting.co.za>
Message-ID: <1295820125.73.0.864692220479.issue10989@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

ssl.SSLContext(True).load_verify_locations(None, True) does segfault. Py_DECREF(cafile_bytes) in Modules/_ssl.c:1686 should be replaced by Py_XDECREF(cafile_bytes).

----------
components: Library (Lib)
messages: 126901
nosy: haypo, pitrou
priority: normal
severity: normal
status: open
title: ssl.SSLContext(True).load_verify_locations(None, True) segfault
versions: Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10989>
_______________________________________

From report at bugs.python.org  Sun Jan 23 23:07:20 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 23 Jan 2011 22:07:20 +0000
Subject: [issue10989] ssl.SSLContext(True).load_verify_locations(None,
	True) segfault
In-Reply-To: <1295820125.73.0.864692220479.issue10989@psf.upfronthosting.co.za>
Message-ID: <1295820440.21.0.989037087315.issue10989@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Needs a patch + tests :)

----------
nosy: +georg.brandl
priority: normal -> high
stage:  -> needs patch
type:  -> crash

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10989>
_______________________________________

From report at bugs.python.org  Sun Jan 23 23:17:34 2011
From: report at bugs.python.org (Skip Montanaro)
Date: Sun, 23 Jan 2011 22:17:34 +0000
Subject: [issue10954] No warning for csv.writer API change
In-Reply-To: <1295519548.77.0.698015070506.issue10954@psf.upfronthosting.co.za>
Message-ID: <1295821054.06.0.316824847826.issue10954@psf.upfronthosting.co.za>


Skip Montanaro <skip at pobox.com> added the comment:

Looking at the csv.rst file I see this statement early in the py3k
docs:

  If *csvfile* is a file object, it should be opened with ``newline=''``.

There is also a footnote about the consequences of leaving it out:

  .. [#] If ``newline=''`` is not specified, newlines embedded inside quoted fields
   will not be interpreted correctly.  It should always be safe to specify
   ``newline=''``, since the csv module does its own universal newline handling
   on input.

Finally, the examples all use "newline=''".  I see two things to change
in the docs:

  * Replace "should" with "must" in the first quoted sentence above.
  * Add that sentence to the documentation for the csv.writer()
    function.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10954>
_______________________________________

From report at bugs.python.org  Sun Jan 23 23:19:40 2011
From: report at bugs.python.org (Skip Montanaro)
Date: Sun, 23 Jan 2011 22:19:40 +0000
Subject: [issue10954] No warning for csv.writer API change
In-Reply-To: <1295519548.77.0.698015070506.issue10954@psf.upfronthosting.co.za>
Message-ID: <1295821180.37.0.984131955086.issue10954@psf.upfronthosting.co.za>


Skip Montanaro <skip at pobox.com> added the comment:

My suggestion attached.

----------
keywords: +patch
Added file: http://bugs.python.org/file20497/csv.rst.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10954>
_______________________________________

From report at bugs.python.org  Sun Jan 23 23:23:22 2011
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 23 Jan 2011 22:23:22 +0000
Subject: [issue10985] test_sys triggers a fatal python error when run under
	coverage.py
In-Reply-To: <1295741889.19.0.432522991902.issue10985@psf.upfronthosting.co.za>
Message-ID: <1295821402.75.0.804468627538.issue10985@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Georg cleared the commit; just waiting for a test run with coverage.py to finish before committing.

----------
resolution:  -> accepted
stage: unit test needed -> commit review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10985>
_______________________________________

From report at bugs.python.org  Mon Jan 24 00:00:18 2011
From: report at bugs.python.org (John Machin)
Date: Sun, 23 Jan 2011 23:00:18 +0000
Subject: [issue10954] No warning for csv.writer API change
In-Reply-To: <1295519548.77.0.698015070506.issue10954@psf.upfronthosting.co.za>
Message-ID: <1295823618.41.0.850702606866.issue10954@psf.upfronthosting.co.za>


John Machin <sjmachin at lexicon.net> added the comment:

Skip, the docs bug is #7198. This is the meaningful-exception bug.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10954>
_______________________________________

From report at bugs.python.org  Mon Jan 24 00:06:35 2011
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 23 Jan 2011 23:06:35 +0000
Subject: [issue10985] test_sys triggers a fatal python error when run under
	coverage.py
In-Reply-To: <1295741889.19.0.432522991902.issue10985@psf.upfronthosting.co.za>
Message-ID: <1295823995.89.0.201696955958.issue10985@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

r88153 w/ a review by Georg Brandl

----------
resolution: accepted -> fixed
stage: commit review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10985>
_______________________________________

From report at bugs.python.org  Mon Jan 24 00:21:16 2011
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 23 Jan 2011 23:21:16 +0000
Subject: [issue10990] tests mutating sys.gettrace() w/o re-instating previous
	state
In-Reply-To: <1295824876.68.0.687534068337.issue10990@psf.upfronthosting.co.za>
Message-ID: <1295824876.68.0.687534068337.issue10990@psf.upfronthosting.co.za>


New submission from Brett Cannon <brett at python.org>:

The attached patch adds resource monitoring to test.regrtest to detect which tests are changing the trace function w/o putting back to what it was previously. The tests listed below are thus all being naughty. This is a meta-issue to help track which tests need to be changed to stop this behavior.

test_doctest
test_exceptions
test_io
test_pdb
test_pickle
test_pickletools
test_richcmp
test_runpy
test_scope
test_sys_settrace
test_zipimport_support

----------
components: Tests
files: sys_gettrace_monitor.diff
keywords: patch
messages: 126908
nosy: brett.cannon
priority: normal
severity: normal
stage: needs patch
status: open
title: tests mutating sys.gettrace() w/o re-instating previous state
type: behavior
versions: Python 3.2, Python 3.3
Added file: http://bugs.python.org/file20498/sys_gettrace_monitor.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10990>
_______________________________________

From report at bugs.python.org  Mon Jan 24 00:31:12 2011
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 23 Jan 2011 23:31:12 +0000
Subject: [issue10991] trace fails when test imported a temporary file
In-Reply-To: <1295825472.67.0.685273364418.issue10991@psf.upfronthosting.co.za>
Message-ID: <1295825472.67.0.685273364418.issue10991@psf.upfronthosting.co.za>


New submission from Brett Cannon <brett at python.org>:

If you run ``test.regrtest -T`` you will discover that (at least) test_importlib and test_runpy prevent coverage data from being written out as 'trace' will try to find files which no longer exist. Both test suites create temp files, import them, and then delete them. Unfortunately 'trace' doesn't ignore that fact and throws an exception that the temporary files are gone.

Since the file is simply gone it probably makes sense to have 'trace' just print out a warning that the file could not be found and move on.

----------
components: Library (Lib)
messages: 126909
nosy: brett.cannon
priority: normal
severity: normal
stage: unit test needed
status: open
title: trace fails when test imported a temporary file
type: behavior
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10991>
_______________________________________

From report at bugs.python.org  Mon Jan 24 01:07:41 2011
From: report at bugs.python.org (Michael Foord)
Date: Mon, 24 Jan 2011 00:07:41 +0000
Subject: [issue10979] setUpClass exception causes explosion with "-b"
In-Reply-To: <1295669611.84.0.453494131357.issue10979@psf.upfronthosting.co.za>
Message-ID: <1295827661.19.0.687175572669.issue10979@psf.upfronthosting.co.za>


Changes by Michael Foord <michael at voidspace.org.uk>:


----------
assignee:  -> michael.foord

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10979>
_______________________________________

From report at bugs.python.org  Mon Jan 24 01:10:24 2011
From: report at bugs.python.org (Ron Adam)
Date: Mon, 24 Jan 2011 00:10:24 +0000
Subject: [issue10961] Pydoc touchups in new browser for 3.2
In-Reply-To: <1295545738.06.0.604274599052.issue10961@psf.upfronthosting.co.za>
Message-ID: <1295827824.5.0.520796627187.issue10961@psf.upfronthosting.co.za>


Changes by Ron Adam <ron_adam at users.sourceforge.net>:


Removed file: http://bugs.python.org/file20473/pydoc_misc_fix_c.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10961>
_______________________________________

From report at bugs.python.org  Mon Jan 24 01:10:55 2011
From: report at bugs.python.org (Ron Adam)
Date: Mon, 24 Jan 2011 00:10:55 +0000
Subject: [issue10961] Pydoc touchups in new browser for 3.2
In-Reply-To: <1295545738.06.0.604274599052.issue10961@psf.upfronthosting.co.za>
Message-ID: <1295827855.24.0.442643817824.issue10961@psf.upfronthosting.co.za>


Ron Adam <ron_adam at users.sourceforge.net> added the comment:

Ok, after input from Eric,  Here is another patch.

Removed a set of unneeded parentheses.

Changed the title of the pages from PyDoc to Pydoc.

A better fix for the uncaught floats.  Wrap the main content in div with style="clear:both;". Should work on nearly everything.  Also avoided floating the "get" and "search" form inputs.  That was causing them to separate too much in IE.


To summarize ...

Minor fixes for new browser mode only.

Fix float problems with the navbar.
Change html page titles to "Pydoc" instead of "Python".
Call html.markup() on topic contents.
Fix topic/object shadowing.
Improved error handling. (Part of the shadowing fix.)

----------
Added file: http://bugs.python.org/file20499/pydoc_misc_fix_d.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10961>
_______________________________________

From report at bugs.python.org  Mon Jan 24 01:30:15 2011
From: report at bugs.python.org (Michael Foord)
Date: Mon, 24 Jan 2011 00:30:15 +0000
Subject: [issue10573] Consistency in unittest assert methods: order of actual, 
	expected
In-Reply-To: <1290992159.72.0.107137027413.issue10573@psf.upfronthosting.co.za>
Message-ID: <1295829015.14.0.511470324565.issue10573@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

There was a BDFL ruling on python-dev mailing list that assert argument names should be (first, second). 

See:

http://mail.python.org/pipermail/python-dev/2010-December/106954.html

I'm basically reverting the patch to go back to (first, second) in the docs and in assertCountEqual.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10573>
_______________________________________

From report at bugs.python.org  Mon Jan 24 01:32:06 2011
From: report at bugs.python.org (Michael Foord)
Date: Mon, 24 Jan 2011 00:32:06 +0000
Subject: [issue10573] Consistency in unittest assert methods: order of actual, 
	expected
In-Reply-To: <1290992159.72.0.107137027413.issue10573@psf.upfronthosting.co.za>
Message-ID: <1295829126.17.0.459676054236.issue10573@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

Note that I looked at making the sequence comparison code symmetric - but it generates nice diffs for even nested containers by using prettyprint and difflib. Switching to a symmetric output ("in first, not in second" etc) would be very difficult without losing functionality.

Generating these diffs can be very slow though, so it may be an issue that needs revisiting.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10573>
_______________________________________

From report at bugs.python.org  Mon Jan 24 03:27:06 2011
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 24 Jan 2011 02:27:06 +0000
Subject: [issue10992] tests failing when run under coverage
In-Reply-To: <1295836026.73.0.339636680883.issue10992@psf.upfronthosting.co.za>
Message-ID: <1295836026.73.0.339636680883.issue10992@psf.upfronthosting.co.za>


New submission from Brett Cannon <brett at python.org>:

A bunch of tests fail when run under coverage (trend seems to be refcount tests). This is to act as a meta-issue to keep track of what tests need to be fixed.

[fail under both coverage.py and regrtest -T]
test_ctypes
test_descr
test_gc
test_metaclass
test_pydoc
test_trace

[coverage.py only]
test_genexps
test_sys

[regrtest -T only]
test_array
test_importlib
test_runpy

----------
components: Tests
messages: 126913
nosy: brett.cannon
priority: normal
severity: normal
stage: needs patch
status: open
title: tests failing when run under coverage
type: behavior
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10992>
_______________________________________

From report at bugs.python.org  Mon Jan 24 04:07:00 2011
From: report at bugs.python.org (Ned Deily)
Date: Mon, 24 Jan 2011 03:07:00 +0000
Subject: [issue10974] IDLE 3.x can crash decoding recent file list
In-Reply-To: <1295635255.29.0.478257321345.issue10974@psf.upfronthosting.co.za>
Message-ID: <1295838420.3.0.725118550994.issue10974@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

IDLE 3.x currently does not specify an explicit encoding when reading or writing the recent files list (~/.idlerc/recent-files.lst) and it defaults to "errors=strict".  So IDLE 3.x is vulnerable to crashes if any of the recent files contain characters that can not be decoded using the LANG environment that IDLE is running under.  That can happen if the user changes LANG or the recent-files.lst was updated by IDLE 2.x or, on OS X, when running as IDLE.app.  The solution in the attached patch is to explicitly force the encoding of the file paths to utf_8 and to set "errors=replace".

Since this has the potential to crash IDLE, I propose it for inclusion in 3.2rc2.

----------
keywords: +patch
nosy: +georg.brandl
stage: needs patch -> commit review
title: IDLE 3.2 not loading on double-click in Finder, OSX 10.6 -> IDLE 3.x can crash decoding recent file list
Added file: http://bugs.python.org/file20500/issue10974.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10974>
_______________________________________

From report at bugs.python.org  Mon Jan 24 04:21:49 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Mon, 24 Jan 2011 03:21:49 +0000
Subject: [issue10639] reindent.py converts newlines to platform default
In-Reply-To: <1291653413.79.0.461728889357.issue10639@psf.upfronthosting.co.za>
Message-ID: <1295839309.09.0.490151353503.issue10639@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

Why is reindent.py translating the whole file to platform default newline such a bad thing? Could not it be considered as helpful behavior, especially in the case where the user has mixed EOLs by mistake?

----------
nosy: +orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10639>
_______________________________________

From report at bugs.python.org  Mon Jan 24 06:07:01 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Mon, 24 Jan 2011 05:07:01 +0000
Subject: [issue1075356] exceeding obscure weakproxy bug
Message-ID: <1295845621.06.0.324318528938.issue1075356@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

I find this problem with 3.x and not with 2.x codeline

----------
nosy: +orsenthil
versions: +Python 3.1, Python 3.2 -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1075356>
_______________________________________

From report at bugs.python.org  Mon Jan 24 08:23:02 2011
From: report at bugs.python.org (Gregory Czajkowski)
Date: Mon, 24 Jan 2011 07:23:02 +0000
Subject: [issue4431] Distutils MSVC doesn't create manifest file (with fix)
In-Reply-To: <1227644194.32.0.230924221438.issue4431@psf.upfronthosting.co.za>
Message-ID: <1295853782.17.0.250764675855.issue4431@psf.upfronthosting.co.za>


Gregory Czajkowski <gcflymoto at gmail.com> added the comment:

Also happening with python2.6 and building pyzmq-2.0.10 using easy_install. dschnur's suggestion fixes it.

----------
nosy: +gcflymoto

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4431>
_______________________________________

From report at bugs.python.org  Mon Jan 24 11:24:56 2011
From: report at bugs.python.org (Sean Reifschneider)
Date: Mon, 24 Jan 2011 10:24:56 +0000
Subject: [issue10924] Adding salt and Modular Crypt Format to crypt library.
In-Reply-To: <1295247997.49.0.7150272714.issue10924@psf.upfronthosting.co.za>
Message-ID: <1295864696.11.0.525075220602.issue10924@psf.upfronthosting.co.za>


Sean Reifschneider <jafo at tummy.com> added the comment:

Thanks.  I had just read that a day or so ago, reviewing it for Brett's work.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10924>
_______________________________________

From report at bugs.python.org  Mon Jan 24 11:28:37 2011
From: report at bugs.python.org (Kristian Vlaardingerbroek)
Date: Mon, 24 Jan 2011 10:28:37 +0000
Subject: [issue10990] tests mutating sys.gettrace() w/o re-instating previous
	state
In-Reply-To: <1295824876.68.0.687534068337.issue10990@psf.upfronthosting.co.za>
Message-ID: <1295864917.43.0.320530738725.issue10990@psf.upfronthosting.co.za>


Changes by Kristian Vlaardingerbroek <kristian.vlaardingerbroek at gmail.com>:


----------
nosy: +Kristian.Vlaardingerbroek

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10990>
_______________________________________

From report at bugs.python.org  Mon Jan 24 11:28:47 2011
From: report at bugs.python.org (Kristian Vlaardingerbroek)
Date: Mon, 24 Jan 2011 10:28:47 +0000
Subject: [issue10992] tests failing when run under coverage
In-Reply-To: <1295836026.73.0.339636680883.issue10992@psf.upfronthosting.co.za>
Message-ID: <1295864927.33.0.397105566455.issue10992@psf.upfronthosting.co.za>


Changes by Kristian Vlaardingerbroek <kristian.vlaardingerbroek at gmail.com>:


----------
nosy: +Kristian.Vlaardingerbroek

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10992>
_______________________________________

From report at bugs.python.org  Mon Jan 24 11:51:43 2011
From: report at bugs.python.org (Tanakorn Leesatapornwongsa)
Date: Mon, 24 Jan 2011 10:51:43 +0000
Subject: [issue10993] HTTPSConnection does not close when call close() method
In-Reply-To: <1295866303.79.0.709048263214.issue10993@psf.upfronthosting.co.za>
Message-ID: <1295866303.79.0.709048263214.issue10993@psf.upfronthosting.co.za>


New submission from Tanakorn Leesatapornwongsa <tanakorn.lsv at gmail.com>:

With this code on python 2.6, I found that HTTPSConnection does not close connection properly.

from httplib import HTTPSConnection

for i in range(1000):
  https = HTTPSConnection("google.com")
  https.connect()
  https.request("GET", "/")
  response = https.getresponse()
  response.close()
  https.close()
  print i

After searching python library, I guess that in ssl.py, implementation of close() method of SSLSocket is wrong.
socket.close(self) should not be called when self._makefile_refs < 1 but should be call when self._makefile_refs == 1, isn't it?
I modified the code, made the patch and attached it with this issue.

----------
components: Library (Lib)
files: ssl.py.patch
keywords: patch
messages: 126919
nosy: tanakorn
priority: normal
severity: normal
status: open
title: HTTPSConnection does not close when call close() method
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file20501/ssl.py.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10993>
_______________________________________

From report at bugs.python.org  Mon Jan 24 12:05:33 2011
From: report at bugs.python.org (Daniel Black)
Date: Mon, 24 Jan 2011 11:05:33 +0000
Subject: [issue10852] SSL/TLS sni use in smtp, pop, imap, nntp,
	ftp client libs by default
In-Reply-To: <1294375380.08.0.187691378511.issue10852@psf.upfronthosting.co.za>
Message-ID: <1295867133.97.0.403881666145.issue10852@psf.upfronthosting.co.za>


Daniel Black <daniel.subs at internode.on.net> added the comment:

ok. should library/ssl.rst be updated to use a SSLContext example?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10852>
_______________________________________

From orsenthil at gmail.com  Mon Jan 24 12:13:56 2011
From: orsenthil at gmail.com (Senthil Kumaran)
Date: Mon, 24 Jan 2011 19:13:56 +0800
Subject: [issue10799] Improve webbrowser.open doc (and, someday, behavior?)
In-Reply-To: <1294791811.71.0.632386139594.issue10799@psf.upfronthosting.co.za>
References: <1293767251.94.0.704365544958.issue10799@psf.upfronthosting.co.za>
	<1294791811.71.0.632386139594.issue10799@psf.upfronthosting.co.za>
Message-ID: <20110124111356.GA1224@rubuntu>

On Wed, Jan 12, 2011 at 12:23:31AM +0000, ?ric Araujo wrote:
> > I thought of adding 'http://' if not present but that would
> > disable opening files in a file browser.
> 
> I think that?s a Windows-specific behavior, not a promise of the
> *web*browser module.

If being lenient with URLs which do not start with http:// is the
idea, then webbrowser module can do explicitly add that. Having a
default protocol option in the open method and we can set it to
'http'.  Many WWW browsers do that.

But, I agree that it should not be related to Windows file-browser
behavior (for whatever it's behavior is). 


From report at bugs.python.org  Mon Jan 24 12:14:06 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Mon, 24 Jan 2011 11:14:06 +0000
Subject: [issue10799] Improve webbrowser.open doc (and, someday, behavior?)
In-Reply-To: <1294791811.71.0.632386139594.issue10799@psf.upfronthosting.co.za>
Message-ID: <20110124111356.GA1224@rubuntu>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

On Wed, Jan 12, 2011 at 12:23:31AM +0000, ?ric Araujo wrote:
> > I thought of adding 'http://' if not present but that would
> > disable opening files in a file browser.
> 
> I think that?s a Windows-specific behavior, not a promise of the
> *web*browser module.

If being lenient with URLs which do not start with http:// is the
idea, then webbrowser module can do explicitly add that. Having a
default protocol option in the open method and we can set it to
'http'.  Many WWW browsers do that.

But, I agree that it should not be related to Windows file-browser
behavior (for whatever it's behavior is).

----------
nosy: +orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10799>
_______________________________________

From report at bugs.python.org  Mon Jan 24 12:59:05 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Mon, 24 Jan 2011 11:59:05 +0000
Subject: [issue10993] HTTPSConnection does not close when call close() method
In-Reply-To: <1295866303.79.0.709048263214.issue10993@psf.upfronthosting.co.za>
Message-ID: <AANLkTi=ise01ytrpCY7pNpxAwVt5T6=JcTPm9XjWrYBE@mail.gmail.com>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

Can you provide a test case which actually illustrates that zombie socket
connections present after the HTTPS Connection and Close?
I see the logic in your patch. But I don't see no left over unclosed
connections upon ssl.close either.

----------
nosy: +orsenthil
Added file: http://bugs.python.org/file20502/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10993>
_______________________________________
-------------- next part --------------
Can you provide a test case which actually illustrates that zombie socket connections present after the HTTPS Connection and Close?<div>I see the logic in your patch. But I don&#39;t see no left over unclosed connections upon ssl.close either.<br>


</div>

From report at bugs.python.org  Mon Jan 24 12:59:31 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Mon, 24 Jan 2011 11:59:31 +0000
Subject: [issue10993] HTTPSConnection does not close when call close() method
In-Reply-To: <1295866303.79.0.709048263214.issue10993@psf.upfronthosting.co.za>
Message-ID: <1295870371.01.0.451820240972.issue10993@psf.upfronthosting.co.za>


Changes by Senthil Kumaran <orsenthil at gmail.com>:


Removed file: http://bugs.python.org/file20502/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10993>
_______________________________________

From report at bugs.python.org  Mon Jan 24 13:47:43 2011
From: report at bugs.python.org (Tanakorn Leesatapornwongsa)
Date: Mon, 24 Jan 2011 12:47:43 +0000
Subject: [issue10993] HTTPSConnection does not close when call close() method
In-Reply-To: <1295866303.79.0.709048263214.issue10993@psf.upfronthosting.co.za>
Message-ID: <1295873263.56.0.912012415382.issue10993@psf.upfronthosting.co.za>


Tanakorn Leesatapornwongsa <tanakorn.lsv at gmail.com> added the comment:

I ran this attached file on my FreeBSD. After it printed "loop finished", I ran command `sockstat | grep python` and it showed


korn     python     58627 3  tcp4   10.0.2.15:28858       64.233.183.99:443
korn     python     58627 4  tcp4   10.0.2.15:23579       64.233.183.147:443
korn     python     58627 5  tcp4   10.0.2.15:52398       64.233.183.106:443
korn     python     58627 6  tcp4   10.0.2.15:18764       64.233.183.105:443
korn     python     58627 7  tcp4   10.0.2.15:46159       64.233.183.104:443
korn     python     58627 8  tcp4   10.0.2.15:36906       64.233.183.103:443
korn     python     58627 9  tcp4   10.0.2.15:45537       64.233.183.99:443
korn     python     58627 10 tcp4   10.0.2.15:24578       64.233.183.103:443
korn     python     58627 11 tcp4   10.0.2.15:26374       64.233.183.147:443
korn     python     58627 12 tcp4   10.0.2.15:57399       64.233.183.106:443
korn     python     58627 13 tcp4   10.0.2.15:12670       64.233.183.105:443
korn     python     58627 14 tcp4   10.0.2.15:56306       64.233.183.104:443
korn     python     58627 15 tcp4   10.0.2.15:42741       64.233.183.103:443
korn     python     58627 16 tcp4   10.0.2.15:16112       64.233.183.99:443
korn     python     58627 17 tcp4   10.0.2.15:25839       64.233.183.147:443
korn     python     58627 18 tcp4   10.0.2.15:59310       64.233.183.106:443
korn     python     58627 19 tcp4   10.0.2.15:35349       64.233.183.105:443
korn     python     58627 20 tcp4   10.0.2.15:31881       64.233.183.104:443
korn     python     58627 21 tcp4   10.0.2.15:21328       64.233.183.103:443
korn     python     58627 22 tcp4   10.0.2.15:61880       64.233.183.99:443
korn     python     58627 23 tcp4   10.0.2.15:47151       64.233.183.147:443
korn     python     58627 24 tcp4   10.0.2.15:12796       64.233.183.106:443
korn     python     58627 25 tcp4   10.0.2.15:57142       64.233.183.105:443
korn     python     58627 26 tcp4   10.0.2.15:17930       64.233.183.104:443
korn     python     58627 27 tcp4   10.0.2.15:13166       64.233.183.103:443
korn     python     58627 28 tcp4   10.0.2.15:43557       64.233.183.99:443
korn     python     58627 29 tcp4   10.0.2.15:39800       64.233.183.147:443
korn     python     58627 30 tcp4   10.0.2.15:17364       64.233.183.106:443
korn     python     58627 31 tcp4   10.0.2.15:50822       64.233.183.105:443
korn     python     58627 32 tcp4   10.0.2.15:59156       64.233.183.104:443
korn     python     58627 33 tcp4   10.0.2.15:41756       64.233.183.103:443
korn     python     58627 34 tcp4   10.0.2.15:18008       64.233.183.99:443
korn     python     58627 35 tcp4   10.0.2.15:44461       64.233.183.147:443

This should not be happend because I call https.close() in every loop iteration. And after I killed this python process, `sockstat | grep python` did not show anything.

Is this test case that you want?

----------
Added file: http://bugs.python.org/file20503/zombiesocket.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10993>
_______________________________________

From report at bugs.python.org  Mon Jan 24 13:56:23 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 24 Jan 2011 12:56:23 +0000
Subject: [issue10993] HTTPSConnection does not close when call close() method
In-Reply-To: <1295866303.79.0.709048263214.issue10993@psf.upfronthosting.co.za>
Message-ID: <1295873783.44.0.273076823433.issue10993@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Can you try with either 2.6.6 or 2.7.1?

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10993>
_______________________________________

From report at bugs.python.org  Mon Jan 24 14:43:40 2011
From: report at bugs.python.org (Maciej Fijalkowski)
Date: Mon, 24 Jan 2011 13:43:40 +0000
Subject: [issue10994] implementation details in sys module
In-Reply-To: <1295876620.3.0.027428786588.issue10994@psf.upfronthosting.co.za>
Message-ID: <1295876620.3.0.027428786588.issue10994@psf.upfronthosting.co.za>


New submission from Maciej Fijalkowski <fijall at gmail.com>:

sys module documentation (as it is online) has some things that in my opinion should be marked as implementation details, but are not. Feel free to counter why not. 

Some of them has info it should be used for specialized purposes only, but IMO it's not the same as not mandatory for other implementations.

Temporary list:

_clear_type_cache

dllhandle

getrefcount

getdlopenflags (?)

getsizeof - it might be not well defined on other implementations

setdlopenflags

api_version

----------
assignee: docs at python
components: Documentation
messages: 126925
nosy: docs at python, fijall
priority: normal
severity: normal
status: open
title: implementation details in sys module
type: behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10994>
_______________________________________

From report at bugs.python.org  Mon Jan 24 14:46:14 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 24 Jan 2011 13:46:14 +0000
Subject: [issue10994] implementation details in sys module
In-Reply-To: <1295876620.3.0.027428786588.issue10994@psf.upfronthosting.co.za>
Message-ID: <1295876774.06.0.174880401046.issue10994@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
stage:  -> needs patch
versions: +Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10994>
_______________________________________

From report at bugs.python.org  Mon Jan 24 14:49:10 2011
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Mon, 24 Jan 2011 13:49:10 +0000
Subject: [issue10994] implementation details in sys module
In-Reply-To: <1295876620.3.0.027428786588.issue10994@psf.upfronthosting.co.za>
Message-ID: <1295876950.15.0.00196166131241.issue10994@psf.upfronthosting.co.za>


Changes by ?ukasz Langa <lukasz at langa.pl>:


----------
nosy: +lukasz.langa

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10994>
_______________________________________

From report at bugs.python.org  Mon Jan 24 15:02:56 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 24 Jan 2011 14:02:56 +0000
Subject: [issue10994] implementation details in sys module
In-Reply-To: <1295876620.3.0.027428786588.issue10994@psf.upfronthosting.co.za>
Message-ID: <1295877776.02.0.970256207863.issue10994@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Well, getsizeof is not better-defined under CPython than elsewhere. It just gives a hint.
Agreed about the other.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10994>
_______________________________________

From report at bugs.python.org  Mon Jan 24 15:05:29 2011
From: report at bugs.python.org (Maciej Fijalkowski)
Date: Mon, 24 Jan 2011 14:05:29 +0000
Subject: [issue10994] implementation details in sys module
In-Reply-To: <1295876620.3.0.027428786588.issue10994@psf.upfronthosting.co.za>
Message-ID: <1295877929.5.0.527131313453.issue10994@psf.upfronthosting.co.za>


Maciej Fijalkowski <fijall at gmail.com> added the comment:

I suppose wrt getsizeof it's more of "if you provide us with a reasonable expectations, we can implement this" other than anything else.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10994>
_______________________________________

From report at bugs.python.org  Mon Jan 24 15:13:32 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 24 Jan 2011 14:13:32 +0000
Subject: [issue10994] implementation details in sys module
In-Reply-To: <1295877929.5.0.527131313453.issue10994@psf.upfronthosting.co.za>
Message-ID: <1295878409.3679.12.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> I suppose wrt getsizeof it's more of "if you provide us with a
> reasonable expectations, we can implement this" other than anything
> else.

The expectation is that it returns the memory footprint of the given
object, and only it (not taking into account sharing, caching,
dependencies or anything else). For example, an instance will not count
its attribute __dict__. But a str object will count its object header
plus the string payload, if the payload is private.

Of course, you are free to tweak these semantics for the PyPy
implementation.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10994>
_______________________________________

From report at bugs.python.org  Mon Jan 24 15:20:50 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 24 Jan 2011 14:20:50 +0000
Subject: [issue10852] SSL/TLS sni use in smtp, pop, imap, nntp,
	ftp client libs by default
In-Reply-To: <1294375380.08.0.187691378511.issue10852@psf.upfronthosting.co.za>
Message-ID: <1295878850.64.0.94317906455.issue10852@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Well, there are already such examples: http://docs.python.org/dev/library/ssl.html#examples
Do you think they are not visible enough?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10852>
_______________________________________

From report at bugs.python.org  Mon Jan 24 15:23:46 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Mon, 24 Jan 2011 14:23:46 +0000
Subject: [issue10995] mailbox.py open() calls don't set encoding
In-Reply-To: <1295879026.46.0.299345130238.issue10995@psf.upfronthosting.co.za>
Message-ID: <1295879026.46.0.299345130238.issue10995@psf.upfronthosting.co.za>


New submission from Steffen Daode Nurpmeso <sdaoden at googlemail.com>:

I'm using the en_GB.UTF-8 locale and thus the entire I/O layer defaults to use UTF-8 encoding.  Perfect.
The problem is that mailboxes are *not* and *never* in UTF-8, generally speaking, according to RFC mail standards!

So i suggest that mailbox.py either offers additional 'encoding="latin1"' constructor arguments or always uses "latin1" in open() calls.
This suffices to make mailbox.py usable -
i.e., the mailbox will be loaded/saved without causing encoder errors, and email.py will behave correctly according to message *content* anyway!

P.S.: i am far from being a Python(1) freak and feel a bit lost on *.python.org, so i might have blown the wrong whistles too load.
Sorry, if this is the case.
Thanks for python(1), it's damn slow and i love C and Perl.  ;-)

----------
components: Library (Lib)
messages: 126930
nosy: Steffen.Daode.Nurpmeso
priority: normal
severity: normal
status: open
title: mailbox.py open() calls don't set encoding
type: behavior
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10995>
_______________________________________

From report at bugs.python.org  Mon Jan 24 15:58:44 2011
From: report at bugs.python.org (R. David Murray)
Date: Mon, 24 Jan 2011 14:58:44 +0000
Subject: [issue10995] mailbox.py open() calls don't set encoding
In-Reply-To: <1295879026.46.0.299345130238.issue10995@psf.upfronthosting.co.za>
Message-ID: <1295881124.11.0.397115291547.issue10995@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Issue 9124 addresses the underlying problem here, so I'm closing this as a duplicate.

----------
nosy: +r.david.murray
resolution:  -> duplicate
stage:  -> committed/rejected
status: open -> closed
superseder:  -> Mailbox module should use binary I/O, not text I/O

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10995>
_______________________________________

From report at bugs.python.org  Mon Jan 24 16:19:22 2011
From: report at bugs.python.org (Giampaolo Rodola')
Date: Mon, 24 Jan 2011 15:19:22 +0000
Subject: [issue10852] SSL/TLS sni use in smtp, pop, imap, nntp,
	ftp client libs by default
In-Reply-To: <1294375380.08.0.187691378511.issue10852@psf.upfronthosting.co.za>
Message-ID: <1295882362.89.0.230513145449.issue10852@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/issue10852>
_______________________________________

From report at bugs.python.org  Mon Jan 24 16:37:37 2011
From: report at bugs.python.org (David Stanek)
Date: Mon, 24 Jan 2011 15:37:37 +0000
Subject: [issue10993] HTTPSConnection does not close when call close() method
In-Reply-To: <1295866303.79.0.709048263214.issue10993@psf.upfronthosting.co.za>
Message-ID: <1295883457.14.0.234216448745.issue10993@psf.upfronthosting.co.za>


Changes by David Stanek <dstanek at dstanek.com>:


----------
nosy: +dstanek

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10993>
_______________________________________

From report at bugs.python.org  Mon Jan 24 16:39:24 2011
From: report at bugs.python.org (David Stanek)
Date: Mon, 24 Jan 2011 15:39:24 +0000
Subject: [issue10983] Errors in http.client.HTTPConnection class (python3)
In-Reply-To: <1295732961.38.0.859825723182.issue10983@psf.upfronthosting.co.za>
Message-ID: <1295883564.94.0.666775408993.issue10983@psf.upfronthosting.co.za>


Changes by David Stanek <dstanek at dstanek.com>:


----------
nosy: +dstanek

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10983>
_______________________________________

From report at bugs.python.org  Mon Jan 24 16:40:45 2011
From: report at bugs.python.org (David Stanek)
Date: Mon, 24 Jan 2011 15:40:45 +0000
Subject: [issue5885] uuid.uuid1() is too slow
In-Reply-To: <1241086416.5.0.850110966894.issue5885@psf.upfronthosting.co.za>
Message-ID: <1295883645.81.0.279435902356.issue5885@psf.upfronthosting.co.za>


Changes by David Stanek <dstanek at dstanek.com>:


----------
nosy: +dstanek

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5885>
_______________________________________

From report at bugs.python.org  Mon Jan 24 16:41:05 2011
From: report at bugs.python.org (David Stanek)
Date: Mon, 24 Jan 2011 15:41:05 +0000
Subject: [issue10911] cgi: add more tests
In-Reply-To: <1295040877.8.0.0807786274615.issue10911@psf.upfronthosting.co.za>
Message-ID: <1295883665.34.0.375416705788.issue10911@psf.upfronthosting.co.za>


Changes by David Stanek <dstanek at dstanek.com>:


----------
nosy: +dstanek

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10911>
_______________________________________

From report at bugs.python.org  Mon Jan 24 16:51:34 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 24 Jan 2011 15:51:34 +0000
Subject: [issue9124] Mailbox module should use binary I/O, not text I/O
In-Reply-To: <1277900903.38.0.556015912714.issue9124@psf.upfronthosting.co.za>
Message-ID: <1295884294.26.0.0528025181039.issue9124@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/issue9124>
_______________________________________

From report at bugs.python.org  Mon Jan 24 18:00:08 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Mon, 24 Jan 2011 17:00:08 +0000
Subject: [issue10993] HTTPSConnection does not close when call close() method
In-Reply-To: <1295883457.17.0.791793462265.issue10993@psf.upfronthosting.co.za>
Message-ID: <20110124165956.GA1174@rubuntu>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

I think, we are facing a platform specific bug here. I had tried
similar program earlier and I tried your attached snippet with python
2.6.6 and release27-maint branch and I dont see the zombie sockets on
Ubuntu 10.10.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10993>
_______________________________________

From report at bugs.python.org  Mon Jan 24 18:02:11 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 24 Jan 2011 17:02:11 +0000
Subject: [issue10993] HTTPSConnection does not close when call close() method
In-Reply-To: <1295866303.79.0.709048263214.issue10993@psf.upfronthosting.co.za>
Message-ID: <1295888531.54.0.806568689278.issue10993@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Rather than labelling it a platform-specific issue, I'd like the OP to test with the latest bugfix releases (2.6.6 and 2.7.1). Some things have definitely been fixed recently.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10993>
_______________________________________

From report at bugs.python.org  Mon Jan 24 18:08:05 2011
From: report at bugs.python.org (Federico Simoncelli)
Date: Mon, 24 Jan 2011 17:08:05 +0000
Subject: [issue10963] "subprocess" can raise OSError (EPIPE) when
	communicating with short-lived processes
In-Reply-To: <1295555014.31.0.879687826689.issue10963@psf.upfronthosting.co.za>
Message-ID: <1295888885.72.0.303452120308.issue10963@psf.upfronthosting.co.za>


Federico Simoncelli <fsimonce at redhat.com> added the comment:

I agree they are orthogonal. The problem is that Popen.communicate doesn't support a way to ignore the exception and keep reading from stdout and sterr until the process dies.
When the child closes the stdin its (error/debug/info) messages on stout/sterr will be lost.
I am not just concerned about checking both the return-code and this exception, I am also worried about losing important information.

----------
nosy: +simon3z

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10963>
_______________________________________

From report at bugs.python.org  Mon Jan 24 18:11:31 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 24 Jan 2011 17:11:31 +0000
Subject: [issue10963] "subprocess" can raise OSError (EPIPE) when
	communicating with short-lived processes
In-Reply-To: <1295555014.31.0.879687826689.issue10963@psf.upfronthosting.co.za>
Message-ID: <1295889091.0.0.285567892049.issue10963@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

You are right, this is suboptimal. It would also be a behaviour change from currently, but it seems beneficial.

----------
nosy: +gregory.p.smith
type:  -> feature request

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10963>
_______________________________________

From report at bugs.python.org  Mon Jan 24 18:19:16 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 24 Jan 2011 17:19:16 +0000
Subject: [issue9723] Add shlex.quote
In-Reply-To: <1283262014.72.0.527039259842.issue9723@psf.upfronthosting.co.za>
Message-ID: <1295889556.93.0.314154486554.issue9723@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> you can just do 'from shlex import quote' in pipes

We would have had to do that anyway, since pipes needs to use the function.  Agreed that a deprecation is not necessary.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9723>
_______________________________________

From report at bugs.python.org  Mon Jan 24 18:28:54 2011
From: report at bugs.python.org (R. David Murray)
Date: Mon, 24 Jan 2011 17:28:54 +0000
Subject: [issue10911] cgi: add more tests
In-Reply-To: <1295040877.8.0.0807786274615.issue10911@psf.upfronthosting.co.za>
Message-ID: <1295890134.05.0.243287702233.issue10911@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Please keep new tests for existing features and new features in separate issues.  A proposed code refactoring should also be a separate issue.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10911>
_______________________________________

From report at bugs.python.org  Mon Jan 24 18:37:19 2011
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 24 Jan 2011 17:37:19 +0000
Subject: [issue10994] implementation details in sys module
In-Reply-To: <1295876620.3.0.027428786588.issue10994@psf.upfronthosting.co.za>
Message-ID: <1295890639.96.0.456589401758.issue10994@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
nosy: +brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10994>
_______________________________________

From report at bugs.python.org  Mon Jan 24 18:50:59 2011
From: report at bugs.python.org (Daniel Urban)
Date: Mon, 24 Jan 2011 17:50:59 +0000
Subject: [issue10996] Typo in What's New in 3.2
In-Reply-To: <1295891459.95.0.208045787052.issue10996@psf.upfronthosting.co.za>
Message-ID: <1295891459.95.0.208045787052.issue10996@psf.upfronthosting.co.za>


New submission from Daniel Urban <urban.dani+py at gmail.com>:

In http://docs.python.org/dev/py3k/whatsnew/3.2.html#abc the example has two typos: 
farenheit -> fahrenheit
celsium -> celsius

----------
assignee: docs at python
components: Documentation
messages: 126938
nosy: docs at python, durban
priority: normal
severity: normal
status: open
title: Typo in What's New in 3.2
type: behavior
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10996>
_______________________________________

From report at bugs.python.org  Mon Jan 24 19:03:54 2011
From: report at bugs.python.org (R. David Murray)
Date: Mon, 24 Jan 2011 18:03:54 +0000
Subject: [issue9723] Add shlex.quote
In-Reply-To: <1283262014.72.0.527039259842.issue9723@psf.upfronthosting.co.za>
Message-ID: <1295892234.29.0.527827563263.issue9723@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Yes, I know you have to do it anyway, that's why I used the adverb 'just' (as in 'just that, and nothing more')  (I note that 'just' as an adverb tends to get overused by English speakers, and so loses some of its semantic value... :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9723>
_______________________________________

From report at bugs.python.org  Mon Jan 24 19:16:08 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 24 Jan 2011 18:16:08 +0000
Subject: [issue10996] Typo in What's New in 3.2
In-Reply-To: <1295891459.95.0.208045787052.issue10996@psf.upfronthosting.co.za>
Message-ID: <1295892968.49.0.0477868384017.issue10996@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <rhettinger at users.sourceforge.net>:


----------
assignee: docs at python -> rhettinger
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10996>
_______________________________________

From report at bugs.python.org  Mon Jan 24 19:19:56 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 24 Jan 2011 18:19:56 +0000
Subject: [issue10996] Typo in What's New in 3.2
In-Reply-To: <1295891459.95.0.208045787052.issue10996@psf.upfronthosting.co.za>
Message-ID: <1295893196.27.0.822045267633.issue10996@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Fixed.  Thanks.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10996>
_______________________________________

From report at bugs.python.org  Mon Jan 24 19:30:53 2011
From: report at bugs.python.org (Giampaolo Rodola')
Date: Mon, 24 Jan 2011 18:30:53 +0000
Subject: [issue10963] "subprocess" can raise OSError (EPIPE) when
	communicating with short-lived processes
In-Reply-To: <1295555014.31.0.879687826689.issue10963@psf.upfronthosting.co.za>
Message-ID: <1295893853.18.0.357058056988.issue10963@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/issue10963>
_______________________________________

From report at bugs.python.org  Mon Jan 24 19:35:16 2011
From: report at bugs.python.org (Ned Deily)
Date: Mon, 24 Jan 2011 18:35:16 +0000
Subject: [issue10997] Duplicate entries in IDLE "Recent Files" menu item on OS
	X
In-Reply-To: <1295894116.03.0.647571188002.issue10997@psf.upfronthosting.co.za>
Message-ID: <1295894116.03.0.647571188002.issue10997@psf.upfronthosting.co.za>


New submission from Ned Deily <nad at acm.org>:

When IDLE is run with an OS X Aqua Tk (Carbon 8.4 or Cocoa 8.5), using the File -> Recent Files menu item to open a previously used file causes that file to show up a second time in the updated menu item and with the same keyboard shortcut.  With X11-based Tk on OS X, no duplicate is seen.  The problem stems from a difference in the way the Tk versions generate sub menus.  With the X11 Tk the sub menu appears to start with a separator in menu index 0 and the first file is added in index 1.  With Aqua Tk, there is no separator and the first file is in index 0.  The code in IDLE to update the menu deletes from 1 to END so, with Aqua Tk, the file name inserted into index 0 is not removed.  The attached patch fixes the problem with Aqua Tk and appears to cause no problems with a current X11 Tk 8.5 on OS X.  Before committing it, though, it should be tested on Windows, which I'm not currently set up to do.

----------
assignee: ned.deily
files: issue_idle_dup_recent.patch
keywords: patch
messages: 126941
nosy: ned.deily
priority: normal
severity: normal
status: open
title: Duplicate entries in IDLE "Recent Files" menu item on OS X
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file20504/issue_idle_dup_recent.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10997>
_______________________________________

From report at bugs.python.org  Mon Jan 24 19:35:30 2011
From: report at bugs.python.org (Ned Deily)
Date: Mon, 24 Jan 2011 18:35:30 +0000
Subject: [issue10997] Duplicate entries in IDLE "Recent Files" menu item on OS
	X
In-Reply-To: <1295894116.03.0.647571188002.issue10997@psf.upfronthosting.co.za>
Message-ID: <1295894130.75.0.18895418946.issue10997@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


----------
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10997>
_______________________________________

From report at bugs.python.org  Mon Jan 24 19:50:35 2011
From: report at bugs.python.org (Ned Deily)
Date: Mon, 24 Jan 2011 18:50:35 +0000
Subject: [issue10997] Duplicate entries in IDLE "Recent Files" menu item on OS
	X
In-Reply-To: <1295894116.03.0.647571188002.issue10997@psf.upfronthosting.co.za>
Message-ID: <1295895035.57.0.148356726703.issue10997@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


----------
nosy: +kbk

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10997>
_______________________________________

From report at bugs.python.org  Mon Jan 24 20:09:37 2011
From: report at bugs.python.org (R. David Murray)
Date: Mon, 24 Jan 2011 19:09:37 +0000
Subject: [issue10960] os.stat() does not mention that it follow symlinks by
	default
In-Reply-To: <1295544486.66.0.118119387237.issue10960@psf.upfronthosting.co.za>
Message-ID: <1295896177.92.0.518894659617.issue10960@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
assignee: docs at python -> r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10960>
_______________________________________

From report at bugs.python.org  Mon Jan 24 20:24:05 2011
From: report at bugs.python.org (Michael Foord)
Date: Mon, 24 Jan 2011 19:24:05 +0000
Subject: [issue10973] OS X 10.6 IDLE,
	tkinter: Cocoa Tk 8.5 crash when composite character typed in
	text	field
In-Reply-To: <1295620061.05.0.0288010484186.issue10973@psf.upfronthosting.co.za>
Message-ID: <1295897045.3.0.767129383719.issue10973@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

Activestate has said (replying to me on Twitter as it happens) that a patch is available and they will do a new 8.5 release before 3.2 final.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10973>
_______________________________________

From report at bugs.python.org  Mon Jan 24 20:25:50 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 24 Jan 2011 19:25:50 +0000
Subject: [issue10998] Remove last traces of -Q / sys.flags.division_warning /
	Py_DivisionWarningFlag
In-Reply-To: <1295897150.32.0.288530737397.issue10998@psf.upfronthosting.co.za>
Message-ID: <1295897150.32.0.288530737397.issue10998@psf.upfronthosting.co.za>


New submission from ?ric Araujo <merwok at netwok.org>:

The -Q command-line option has been removed in Python 3 but there are some leftovers.  Attached patch removes them; tests pass; please review.

I think 3.1 should be fixed too, since no sane program should use those leftovers.

I removed the now-pointless tests in test_cmd_line.  They were not failing; this may be a bug in verify_valid_flag, out of scope for this report.

While I was editing the table used to document sys.flags, I added some link-generating markup (to the respective option doc) and made the table markup easier to read and edit.  I can make those changes in another commit if you prefer it.

----------
assignee: eric.araujo
components: Interpreter Core
files: division_warning.diff
keywords: needs review, patch
messages: 126943
nosy: benjamin.peterson, eric.araujo, georg.brandl
priority: normal
severity: normal
stage: commit review
status: open
title: Remove last traces of -Q / sys.flags.division_warning / Py_DivisionWarningFlag
type: behavior
versions: Python 3.1, Python 3.2
Added file: http://bugs.python.org/file20505/division_warning.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10998>
_______________________________________

From report at bugs.python.org  Mon Jan 24 20:35:01 2011
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 24 Jan 2011 19:35:01 +0000
Subject: [issue10998] Remove last traces of -Q / sys.flags.division_warning /
	Py_DivisionWarningFlag
In-Reply-To: <1295897150.32.0.288530737397.issue10998@psf.upfronthosting.co.za>
Message-ID: <1295897701.31.0.178506975699.issue10998@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

This would have been good for 3.2, but it is an API change...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10998>
_______________________________________

From report at bugs.python.org  Mon Jan 24 20:36:46 2011
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 24 Jan 2011 19:36:46 +0000
Subject: [issue9509] argparse FileType raises ugly exception for missing file
In-Reply-To: <1280927287.23.0.0771144110186.issue9509@psf.upfronthosting.co.za>
Message-ID: <1295897806.87.0.686733901185.issue9509@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

No, it sounds fine then.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9509>
_______________________________________

From report at bugs.python.org  Mon Jan 24 20:38:32 2011
From: report at bugs.python.org (R. David Murray)
Date: Mon, 24 Jan 2011 19:38:32 +0000
Subject: [issue10960] os.stat() does not mention that it follow symlinks by
	default
In-Reply-To: <1295544486.66.0.118119387237.issue10960@psf.upfronthosting.co.za>
Message-ID: <1295897912.54.0.0520925116507.issue10960@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Thanks.

Committed a modified version of the patch in r88164.  I extended your breakout of the attributes to the other paragraphs, and reorganized the order of the paragraphs in the stat docs to put things into a more logical order (I hope).  I decided to change the existing wording about the stat system call to reflect the fact that we aren't making a stat system call on Windows, and did something similar in the lstat entry.

This will get backported to the 2.7 docs (and 3.1) presently, but not right away.

----------
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10960>
_______________________________________

From report at bugs.python.org  Mon Jan 24 20:41:15 2011
From: report at bugs.python.org (R. David Murray)
Date: Mon, 24 Jan 2011 19:41:15 +0000
Subject: [issue10999] os.chflags refers to stat constants,
	but the constants are not documented in the stat module
In-Reply-To: <1295898075.1.0.406467023745.issue10999@psf.upfronthosting.co.za>
Message-ID: <1295898075.1.0.406467023745.issue10999@psf.upfronthosting.co.za>


New submission from R. David Murray <rdmurray at bitdance.com>:

Title pretty much says it all.  The constants are there in the stat module, but they aren't documented.  When they are documented the mentions in the os.chflags entry can be turned into cross reference links.

----------
assignee: docs at python
messages: 126947
nosy: docs at python, r.david.murray
priority: normal
severity: normal
stage: needs patch
status: open
title: os.chflags refers to stat constants, but the constants are not documented in the stat module
type: behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10999>
_______________________________________

From report at bugs.python.org  Mon Jan 24 20:50:07 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Mon, 24 Jan 2011 19:50:07 +0000
Subject: [issue10848] Move test.regrtest from getopt to argparse
In-Reply-To: <1294353259.48.0.852026284896.issue10848@psf.upfronthosting.co.za>
Message-ID: <1295898607.68.0.549772655652.issue10848@psf.upfronthosting.co.za>


Sandro Tosi <sandro.tosi at gmail.com> added the comment:

I finally had the time to look more closely to the issue, and I'd like to hear some comments on the info visualization.

Currently we have --help option to print:

 <usage + additional details about execution + more rigorous testing>
 <options>
 <verbosity>
 <selecting tests>
 <special runs>
 <additional options details>

Now, AFAIK argparse it's not so flexible, so we have to draw a line and choose a trade-off.

F.e., the additional options details: they can't be added in a help='..' kargs but they should be nonetheless be displayed when passing --help to regrtest.py.

* <options>, <verbosity>, <selecting tests>, <special runs> can all be grouped up into argument groups.

* <usage> can be managed "twisting a bit" the usage='...' karg of argparse.ArgumentParser

* but what about <additional options details> ? should we add that to the usage='...' text? or should we somehow override the print_help() and show

 <usage>
 <options & options groups> (this is standard until here)
 <additional options details> (appending the text after options)?

or something different I still don't imagine? :)

Cheers,
Sandro

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10848>
_______________________________________

From report at bugs.python.org  Mon Jan 24 20:53:57 2011
From: report at bugs.python.org (R. David Murray)
Date: Mon, 24 Jan 2011 19:53:57 +0000
Subject: [issue10848] Move test.regrtest from getopt to argparse
In-Reply-To: <1294353259.48.0.852026284896.issue10848@psf.upfronthosting.co.za>
Message-ID: <1295898837.67.0.841957892423.issue10848@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

What about putting the addition option details in the epilog?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10848>
_______________________________________

From report at bugs.python.org  Mon Jan 24 20:55:15 2011
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 24 Jan 2011 19:55:15 +0000
Subject: [issue9723] Add shlex.quote
In-Reply-To: <1283262014.72.0.527039259842.issue9723@psf.upfronthosting.co.za>
Message-ID: <1295898915.38.0.422570242842.issue9723@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Putting quote() into shlex sounds good to me.

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9723>
_______________________________________

From report at bugs.python.org  Mon Jan 24 21:06:20 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 24 Jan 2011 20:06:20 +0000
Subject: [issue10998] Remove last traces of -Q / sys.flags.division_warning /
	Py_DivisionWarningFlag
In-Reply-To: <1295897150.32.0.288530737397.issue10998@psf.upfronthosting.co.za>
Message-ID: <1295899580.57.0.481625199274.issue10998@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

I'm in mildly in favor of getting this done before the next release candidate.  It seems like a desirable clean-up that would better be done sooner than later.

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10998>
_______________________________________

From report at bugs.python.org  Mon Jan 24 21:07:58 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 24 Jan 2011 20:07:58 +0000
Subject: [issue11000] Doc: ast.parse parses source, not just expressions
In-Reply-To: <1295899678.27.0.449949701251.issue11000@psf.upfronthosting.co.za>
Message-ID: <1295899678.27.0.449949701251.issue11000@psf.upfronthosting.co.za>


New submission from Terry J. Reedy <tjreedy at udel.edu>:

"ast.parse(expr, filename='<unknown>', mode='exec') 
Parse an expression into an AST node. Equivalent to compile(expr, filename, mode, ast.PyCF_ONLY_AST)."

but

"compile(source, ...) 
Compile the source into a code or AST object. 
...
The mode argument specifies what kind of code must be compiled; it can be 'exec' if source consists of a sequence of statements,"

and indeed, with all three versions,

>>> import ast
>>> e3=ast.parse('x=1; y=2\nif x: print(y)')
>>> o3 = compile(e3,'','exec')
>>> exec(o3)
2
>>> print(x,y)
(1, 2)

Attached patch (untested) changes doc and doc string.

Inquiry: I suspect that the filename is *not* attached to the ast. (In any case, it must be explicitly supplied to a subsequent compile() call.) If so, it is a useless parameter and the api and doc should be

parse(source, mode) ... Equivalent to compile(source, '<unknown>', ...

If so, and failing such a change, should the doc warn people to not bother supplying a filename arg?

I also wonder whether the mode arg has any effect on the ast. If not, same question.

----------
assignee: docs at python
components: Documentation
files: zast.diff
keywords: patch
messages: 126952
nosy: docs at python, georg.brandl, terry.reedy
priority: normal
severity: normal
status: open
title: Doc: ast.parse parses source, not just expressions
versions: Python 2.7, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file20506/zast.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11000>
_______________________________________

From report at bugs.python.org  Mon Jan 24 21:09:30 2011
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 24 Jan 2011 20:09:30 +0000
Subject: [issue11000] Doc: ast.parse parses source, not just expressions
In-Reply-To: <1295899678.27.0.449949701251.issue11000@psf.upfronthosting.co.za>
Message-ID: <1295899770.85.0.0341466906977.issue11000@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Looks fine.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11000>
_______________________________________

From report at bugs.python.org  Mon Jan 24 21:46:48 2011
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 24 Jan 2011 20:46:48 +0000
Subject: [issue10708] Misc/porting should be folded in to the development FAQ
In-Reply-To: <1292427453.79.0.452399127359.issue10708@psf.upfronthosting.co.za>
Message-ID: <1295902008.08.0.31538538268.issue10708@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

I've done what I plan to do to Misc and moving Porting was not part of it. I have no issue if someone else moves it, though.

----------
resolution:  -> rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10708>
_______________________________________

From report at bugs.python.org  Mon Jan 24 21:47:42 2011
From: report at bugs.python.org (Heikki Toivonen)
Date: Mon, 24 Jan 2011 20:47:42 +0000
Subject: [issue10684] Folders get deleted when trying to change case with
	shutil.move (case insensitive file systems only)
In-Reply-To: <1292149124.13.0.45494559671.issue10684@psf.upfronthosting.co.za>
Message-ID: <1295902062.97.0.468642669056.issue10684@psf.upfronthosting.co.za>


Heikki Toivonen <hjtoi-bugzilla at comcast.net> added the comment:

I also noticed this last week. However, this is not Windows specific. It happens with file systems that are not case sensitive. Besides Windows (NTFS, FAT*) the other common platform is Macintosh (HFS+ with default settings).

What happens is that we copy source into itself, then delete source.

I am not sure what the optimal solution would be but an easy one would be to first try os.rename (which works in this case), but if that fails then do the stuff that is currently shutil.move.

----------
nosy: +heikki
title: Folders get deleted when trying to change case with shutil.move (Windows) -> Folders get deleted when trying to change case with shutil.move (case insensitive file systems only)
versions: +Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10684>
_______________________________________

From report at bugs.python.org  Mon Jan 24 21:48:09 2011
From: report at bugs.python.org (Heikki Toivonen)
Date: Mon, 24 Jan 2011 20:48:09 +0000
Subject: [issue10684] Folders get deleted when trying to change case with
	shutil.move (case insensitive file systems only)
In-Reply-To: <1292149124.13.0.45494559671.issue10684@psf.upfronthosting.co.za>
Message-ID: <1295902089.61.0.0674634158819.issue10684@psf.upfronthosting.co.za>


Changes by Heikki Toivonen <hjtoi-bugzilla at comcast.net>:


----------
assignee:  -> ronaldoussoren
components: +Macintosh
nosy: +ronaldoussoren

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10684>
_______________________________________

From report at bugs.python.org  Mon Jan 24 21:48:40 2011
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 24 Jan 2011 20:48:40 +0000
Subject: [issue9893] Usefulness of the Misc/Vim/ files?
In-Reply-To: <1284827686.39.0.471855984875.issue9893@psf.upfronthosting.co.za>
Message-ID: <1295902120.88.0.514209956247.issue9893@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
assignee:  -> brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9893>
_______________________________________

From report at bugs.python.org  Mon Jan 24 22:06:10 2011
From: report at bugs.python.org (Steven Bethard)
Date: Mon, 24 Jan 2011 21:06:10 +0000
Subject: [issue9509] argparse FileType raises ugly exception for missing file
In-Reply-To: <1280927287.23.0.0771144110186.issue9509@psf.upfronthosting.co.za>
Message-ID: <1295903170.23.0.644866838052.issue9509@psf.upfronthosting.co.za>


Steven Bethard <steven.bethard at gmail.com> added the comment:

Fixed in r88169 and r88171. Thanks everyone for your help! I'll be keeping my eye on the buildbots for a bit to make sure everything stays green.

----------
assignee:  -> bethard
resolution:  -> fixed
stage: patch review -> committed/rejected
status: languishing -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9509>
_______________________________________

From report at bugs.python.org  Mon Jan 24 22:17:08 2011
From: report at bugs.python.org (Ned Deily)
Date: Mon, 24 Jan 2011 21:17:08 +0000
Subject: [issue10973] OS X 10.6 IDLE,
	tkinter: Cocoa Tk 8.5 crash when composite character typed in
	text	field
In-Reply-To: <1295620061.05.0.0288010484186.issue10973@psf.upfronthosting.co.za>
Message-ID: <1295903828.96.0.659702895457.issue10973@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Yes, see http://permalink.gmane.org/gmane.comp.lang.tcl.mac/6871

So the plan for 3.2 is to assume there will be an updated ActiveState Tk 8.5 available.  I will update the web status page accordingly.  And this issue can be closed as a third-party library issue.

----------
resolution:  -> wont fix
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10973>
_______________________________________

From report at bugs.python.org  Mon Jan 24 22:21:55 2011
From: report at bugs.python.org (Daniel Black)
Date: Mon, 24 Jan 2011 21:21:55 +0000
Subject: [issue10852] SSL/TLS sni use in smtp, pop, imap, nntp,
	ftp client libs by default
In-Reply-To: <1294375380.08.0.187691378511.issue10852@psf.upfronthosting.co.za>
Message-ID: <1295904115.62.0.731982632118.issue10852@psf.upfronthosting.co.za>


Daniel Black <daniel.subs at internode.on.net> added the comment:

I thought previous comments you wanted SSLContext to become the primary api rather than wrap_socket? Coding this into the examples is probably a good way of making this happen.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10852>
_______________________________________

From report at bugs.python.org  Mon Jan 24 22:49:53 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 24 Jan 2011 21:49:53 +0000
Subject: [issue9509] argparse FileType raises ugly exception for missing file
In-Reply-To: <1280927287.23.0.0771144110186.issue9509@psf.upfronthosting.co.za>
Message-ID: <1295905793.76.0.525734498391.issue9509@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Oops, I missed that while reading the patch: It introduces a translatable string which may cause i18n issues (discussed in #10528).  I can propose a patch this week if no-one beats me to it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9509>
_______________________________________

From report at bugs.python.org  Mon Jan 24 22:58:11 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 24 Jan 2011 21:58:11 +0000
Subject: [issue10708] Misc/porting should be folded into the development FAQ
	or the devguide
In-Reply-To: <1292427453.79.0.452399127359.issue10708@psf.upfronthosting.co.za>
Message-ID: <1295906291.54.0.691950092347.issue10708@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Well then let's reopen and unassign.

----------
assignee: brett.cannon -> 
nosy: +ncoghlan
resolution: rejected -> 
stage:  -> needs patch
status: closed -> open
title: Misc/porting should be folded in to the development FAQ -> Misc/porting should be folded into the development FAQ or the devguide
versions:  -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10708>
_______________________________________

From report at bugs.python.org  Mon Jan 24 23:02:31 2011
From: report at bugs.python.org (Brian Curtin)
Date: Mon, 24 Jan 2011 22:02:31 +0000
Subject: [issue10684] Folders get deleted when trying to change case with
	shutil.move (case insensitive file systems only)
In-Reply-To: <1292149124.13.0.45494559671.issue10684@psf.upfronthosting.co.za>
Message-ID: <1295906551.77.0.165124237632.issue10684@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
assignee: ronaldoussoren -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10684>
_______________________________________

From report at bugs.python.org  Mon Jan 24 23:13:51 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 24 Jan 2011 22:13:51 +0000
Subject: [issue10998] Remove last traces of -Q / sys.flags.division_warning /
	Py_DivisionWarningFlag
In-Reply-To: <1295897150.32.0.288530737397.issue10998@psf.upfronthosting.co.za>
Message-ID: <1295907231.15.0.0357582009021.issue10998@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

My argument that this change should have no impact so it?s safe to commit also works the other way: there is no pressure to make an exception to the process and commit this after rc1.  3.1 and 3.2 will have the bug, 3.3 won?t.

----------
versions: +Python 3.3 -Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10998>
_______________________________________

From report at bugs.python.org  Mon Jan 24 23:27:45 2011
From: report at bugs.python.org (Luke Plant)
Date: Mon, 24 Jan 2011 22:27:45 +0000
Subject: [issue11001] Various obvious errors in cookies documentation
In-Reply-To: <1295908065.55.0.221906287574.issue11001@psf.upfronthosting.co.za>
Message-ID: <1295908065.55.0.221906287574.issue11001@psf.upfronthosting.co.za>


New submission from Luke Plant <L.Plant.98 at cantab.net>:

Docs for SimpleCookie, BaseCookie.value_encode and BaseCookie.value_decode are obviously incorrect.  Attempt at patch attached.

The error has existed in every Python version I've seen, I've tagged the ones I believe can receive fixes, sorry if I've made a mistake.

Thanks.

----------
assignee: docs at python
components: Documentation
files: http_cookies_doc_corrections.diff
keywords: patch
messages: 126962
nosy: docs at python, spookylukey
priority: normal
severity: normal
status: open
title: Various obvious errors in cookies documentation
versions: Python 2.7, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file20507/http_cookies_doc_corrections.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11001>
_______________________________________

From report at bugs.python.org  Mon Jan 24 23:28:26 2011
From: report at bugs.python.org (Ned Deily)
Date: Mon, 24 Jan 2011 22:28:26 +0000
Subject: [issue10974] IDLE 3.x can crash decoding recent file list
In-Reply-To: <1295635255.29.0.478257321345.issue10974@psf.upfronthosting.co.za>
Message-ID: <1295908106.06.0.858086401115.issue10974@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Committed in py3k (r88174) for 3.2rc2, with release manager approval, and in 3.1 (r88177).

----------
resolution:  -> fixed
stage: commit review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10974>
_______________________________________

From report at bugs.python.org  Mon Jan 24 23:29:06 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 24 Jan 2011 22:29:06 +0000
Subject: [issue11000] Doc: ast.parse parses source, not just expressions
In-Reply-To: <1295899678.27.0.449949701251.issue11000@psf.upfronthosting.co.za>
Message-ID: <1295908146.4.0.763373761963.issue11000@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

r88172, r88173, r88175

----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11000>
_______________________________________

From report at bugs.python.org  Mon Jan 24 23:32:52 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Mon, 24 Jan 2011 22:32:52 +0000
Subject: [issue10848] Move test.regrtest from getopt to argparse
In-Reply-To: <1295898837.67.0.841957892423.issue10848@psf.upfronthosting.co.za>
Message-ID: <AANLkTimD64sVgpNtBbKXDUxVJWq3B0CSBmPzZ_hdFPpf@mail.gmail.com>


Sandro Tosi <sandro.tosi at gmail.com> added the comment:

> R. David Murray <rdmurray at bitdance.com> added the comment:
>
> What about putting the addition option details in the epilog?

maybe it loose the fact that all the doc/explanation for regrtest
options were available from the command-line?

what about a --more-help option that print_help() + all those
information about cmdline switches?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10848>
_______________________________________

From report at bugs.python.org  Tue Jan 25 01:08:16 2011
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 25 Jan 2011 00:08:16 +0000
Subject: [issue10990] tests mutating sys.gettrace() w/o re-instating previous
	state
In-Reply-To: <1295824876.68.0.687534068337.issue10990@psf.upfronthosting.co.za>
Message-ID: <1295914096.39.0.208118814478.issue10990@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Cinder on IRC found that test_exception's RuntimeError test triggers a trace_trampoline() line of code which resets the trace function as an exception gets triggered in the trace function itself.

test_doctest is being messy and setting pdb's trace function w/o putting back what it wrote over.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10990>
_______________________________________

From report at bugs.python.org  Tue Jan 25 01:12:21 2011
From: report at bugs.python.org (Kristian Vlaardingerbroek)
Date: Tue, 25 Jan 2011 00:12:21 +0000
Subject: [issue10990] tests mutating sys.gettrace() w/o re-instating previous
	state
In-Reply-To: <1295824876.68.0.687534068337.issue10990@psf.upfronthosting.co.za>
Message-ID: <1295914341.69.0.241640152093.issue10990@psf.upfronthosting.co.za>


Kristian Vlaardingerbroek <kristian.vlaardingerbroek at gmail.com> added the comment:

test_pickle and test_pickletools both call test_bad_getattr in pickletester.py:1005

This results in a RuntimeError which leads to the same result as test_exceptions

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10990>
_______________________________________

From report at bugs.python.org  Tue Jan 25 01:25:17 2011
From: report at bugs.python.org (Glenn Linderman)
Date: Tue, 25 Jan 2011 00:25:17 +0000
Subject: [issue10879] cgi memory usage
In-Reply-To: <1294648490.09.0.987257947586.issue10879@psf.upfronthosting.co.za>
Message-ID: <1295915117.63.0.404507378195.issue10879@psf.upfronthosting.co.za>


Glenn Linderman <v+python at g.nevcal.com> added the comment:

Issue 4953 has somewhat resolved this issue by using email only for parsing headers (more like 2.x did).  So this issue could be closed, or could be left open to point out the required additional features needed from email before cgi.py can use it for handling body parts as well as headers.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10879>
_______________________________________

From report at bugs.python.org  Tue Jan 25 01:31:43 2011
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 25 Jan 2011 00:31:43 +0000
Subject: [issue10990] tests mutating sys.gettrace() w/o re-instating previous
	state
In-Reply-To: <1295824876.68.0.687534068337.issue10990@psf.upfronthosting.co.za>
Message-ID: <1295915503.54.0.00338575095464.issue10990@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

test_pdb uses pdb.set_trace() w/o putting the original trace function back.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10990>
_______________________________________

From report at bugs.python.org  Tue Jan 25 01:37:28 2011
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 25 Jan 2011 00:37:28 +0000
Subject: [issue10990] tests mutating sys.gettrace() w/o re-instating previous
	state
In-Reply-To: <1295824876.68.0.687534068337.issue10990@psf.upfronthosting.co.za>
Message-ID: <1295915848.13.0.380964988045.issue10990@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

test_scope blindly resets the trace function to None.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10990>
_______________________________________

From report at bugs.python.org  Tue Jan 25 01:38:34 2011
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 25 Jan 2011 00:38:34 +0000
Subject: [issue10990] tests mutating sys.gettrace() w/o re-instating previous
	state
In-Reply-To: <1295824876.68.0.687534068337.issue10990@psf.upfronthosting.co.za>
Message-ID: <1295915914.73.0.220906179721.issue10990@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

And here is a revelation: test_sys_settrace clobbers the trace function blindly.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10990>
_______________________________________

From report at bugs.python.org  Tue Jan 25 01:41:16 2011
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 25 Jan 2011 00:41:16 +0000
Subject: [issue10990] tests mutating sys.gettrace() w/o re-instating previous
	state
In-Reply-To: <1295824876.68.0.687534068337.issue10990@psf.upfronthosting.co.za>
Message-ID: <1295916076.08.0.0381581669913.issue10990@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

test_zipimport_support fails because test_doctest fails; it re-runs the tests from a zipfile.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10990>
_______________________________________

From report at bugs.python.org  Tue Jan 25 01:44:14 2011
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 25 Jan 2011 00:44:14 +0000
Subject: [issue10990] tests mutating sys.gettrace() w/o re-instating previous
	state
In-Reply-To: <1295824876.68.0.687534068337.issue10990@psf.upfronthosting.co.za>
Message-ID: <1295916254.93.0.409862536168.issue10990@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

test_io is causing coverage.py to complain thanks to the TextIOWrapperTests, and the regrtest check is complaining about SignalsTests. Don't know why specifically for either.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10990>
_______________________________________

From report at bugs.python.org  Tue Jan 25 01:51:40 2011
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 25 Jan 2011 00:51:40 +0000
Subject: [issue10990] tests mutating sys.gettrace() w/o re-instating previous
	state
In-Reply-To: <1295824876.68.0.687534068337.issue10990@psf.upfronthosting.co.za>
Message-ID: <1295916700.15.0.259056528248.issue10990@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

test_runpy fails because of a recursion depth test (test_main_recursion_error).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10990>
_______________________________________

From report at bugs.python.org  Tue Jan 25 01:52:53 2011
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 25 Jan 2011 00:52:53 +0000
Subject: [issue10990] tests mutating sys.gettrace() w/o re-instating previous
	state
In-Reply-To: <1295824876.68.0.687534068337.issue10990@psf.upfronthosting.co.za>
Message-ID: <1295916773.73.0.401431939479.issue10990@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

test_richcmp is failing because of a recursion test (test_recursion)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10990>
_______________________________________

From report at bugs.python.org  Tue Jan 25 02:09:16 2011
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 25 Jan 2011 01:09:16 +0000
Subject: [issue10990] tests mutating sys.gettrace() w/o re-instating previous
	state
In-Reply-To: <1295824876.68.0.687534068337.issue10990@psf.upfronthosting.co.za>
Message-ID: <1295917756.66.0.472023716161.issue10990@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

For test_io.*SignalsTests, its all the tests calling check_interrupted_write(). For TestIOWrapperTests its test_threads_write() (although only coverage.py is complaining, not regrtest).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10990>
_______________________________________

From report at bugs.python.org  Tue Jan 25 02:16:10 2011
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 25 Jan 2011 01:16:10 +0000
Subject: [issue10990] tests mutating sys.gettrace() w/o re-instating previous
	state
In-Reply-To: <1295824876.68.0.687534068337.issue10990@psf.upfronthosting.co.za>
Message-ID: <1295918170.87.0.013832209193.issue10990@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

OK, now that all the modules have been analyzed, let's see what is what.

The modules not playing nicely with others by blindly reseting the trace module:

test_doctest
test_pdb
test_scope
test_sys_settrace
test_zipimport_support (because of test_doctest)

And the tests failing because of recursion depth:
test_exceptions
test_pickle
test_pickletools
test_richcmp
test_runpy

And test_io is just special thanks to signals and threading.

Here is my thinking on how to solve this. The tests that are not playing nicely with sys.settrace() should (a) be decorated with test.support.cpython_only, and (b) use addCleanup() to properly put the trace function back.

For the recursion depth tests, either the cause (which is probably trace_trampoline()) needs to be analyzed to decide if some other semantics are needed or need something to unset the trace function and then put it back, but only if sys.gettrace() exists (e.g., don't block on non-CPython VMs).

----------
stage: needs patch -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10990>
_______________________________________

From report at bugs.python.org  Tue Jan 25 02:20:53 2011
From: report at bugs.python.org (R. David Murray)
Date: Tue, 25 Jan 2011 01:20:53 +0000
Subject: [issue10848] Move test.regrtest from getopt to argparse
In-Reply-To: <1294353259.48.0.852026284896.issue10848@psf.upfronthosting.co.za>
Message-ID: <1295918453.44.0.552871377666.issue10848@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

That might be handy.  I thought you were trying to roughly reproduce the current help (which dumps it all out at once), which is why I suggested epilog.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10848>
_______________________________________

From report at bugs.python.org  Tue Jan 25 02:35:24 2011
From: report at bugs.python.org (R. David Murray)
Date: Tue, 25 Jan 2011 01:35:24 +0000
Subject: [issue11001] Various obvious errors in cookies documentation
In-Reply-To: <1295908065.55.0.221906287574.issue11001@psf.upfronthosting.co.za>
Message-ID: <1295919324.41.0.235332523544.issue11001@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

The text in the docstrings appears to be accurate, and it seems to me they clarify it even more than your suggested changes do.  Also, I think SimpleCookie's encode/decode roughly implements some RFC or another (though there are some tweaks), and it might be worth mentioning that.

Even with these changes, though, I don't think it is possible to really understand what cookie is doing without reading the source, and even then it is non-obvious :(

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11001>
_______________________________________

From report at bugs.python.org  Tue Jan 25 02:57:40 2011
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 25 Jan 2011 01:57:40 +0000
Subject: [issue10990] tests mutating sys.gettrace() w/o re-instating previous
	state
In-Reply-To: <1295824876.68.0.687534068337.issue10990@psf.upfronthosting.co.za>
Message-ID: <1295920660.04.0.78646059894.issue10990@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Here is a patch that fixes test_scope.

----------
Added file: http://bugs.python.org/file20508/test_scope.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10990>
_______________________________________

From report at bugs.python.org  Tue Jan 25 02:59:59 2011
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 25 Jan 2011 01:59:59 +0000
Subject: [issue10990] tests mutating sys.gettrace() w/o re-instating previous
	state
In-Reply-To: <1295824876.68.0.687534068337.issue10990@psf.upfronthosting.co.za>
Message-ID: <1295920799.59.0.108773077177.issue10990@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Here is a partial patch for test_sys_settrace. It fails on test_19_no_jump_without_trace_function for some reason I don't understand. It also doesn't protect against it being CPython-only as that is a function decorator and basically the whole module needs to be skipped.

----------
Added file: http://bugs.python.org/file20509/test_sys_settrace.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10990>
_______________________________________

From report at bugs.python.org  Tue Jan 25 03:26:21 2011
From: report at bugs.python.org (Matt Joiner)
Date: Tue, 25 Jan 2011 02:26:21 +0000
Subject: [issue10882] Add os.sendfile()
In-Reply-To: <1294691268.76.0.727179568007.issue10882@psf.upfronthosting.co.za>
Message-ID: <1295922381.01.0.644173239779.issue10882@psf.upfronthosting.co.za>


Matt Joiner <anacrolix at gmail.com> added the comment:

I notice Linux is described as not taking count=0 to mean to send until the end of "in" is reached. Is it possible to pass (size_t)-1 to this field if None is given, or do a loop on non-zero counts from sendfile to emulate this?

I poked around the linux source for 2.6.32, and it appears sendfile() is emulated on top of splice(), but this doesn't provide undocumented count=0 handling as I was hoping.

----------
nosy: +anacrolix

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10882>
_______________________________________

From report at bugs.python.org  Tue Jan 25 04:15:46 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Tue, 25 Jan 2011 03:15:46 +0000
Subject: [issue5863] bz2.BZ2File should accept other file-like objects.
In-Reply-To: <1240898269.47.0.592056792771.issue5863@psf.upfronthosting.co.za>
Message-ID: <1295925346.87.0.46855002786.issue5863@psf.upfronthosting.co.za>


Nadeem Vawda <nadeem.vawda at gmail.com> added the comment:

Here is a patch that rewrites BZ2File to implement the requested feature, and adds some tests using BytesIO objects.

Some notes:
* iteration and the read*() method now use the same buffering machinery, so they can be mixed freely. The test for issue8397 has been updated accordingly.
* readlines() now respects its size argument. The existing implementation appears to effectively ignore it.
* writelines() no longer uses the (deprecated) old buffer protocol, and is now much simpler.
* Currently, calling next() on a writable BZ2File results in a rather unhelpful error message; the patched version checks that the file is readable before trying to actually read.
* The docstrings have been rewritten to clarify that all of the methods deal with bytes and not text strings.

One thing I was unsure of is how to handle exceptions that occur in BZ2File_dealloc(). Does the error status need to be cleared before it returns?

The documentation for the bz2 module appears to be quite out of date; I will upload a patch in the next day or so.

On a related note, the 'buffering' argument to __init__() is ignored, and I was wondering whether this should be documented explicitly? The current documentation claims that it allows the caller to specify a buffer size, or request unbuffered I/O.

----------
keywords: +patch
Added file: http://bugs.python.org/file20510/bz2module-v1.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5863>
_______________________________________

From report at bugs.python.org  Tue Jan 25 04:27:19 2011
From: report at bugs.python.org (Anthony Long)
Date: Tue, 25 Jan 2011 03:27:19 +0000
Subject: [issue5863] bz2.BZ2File should accept other file-like objects.
In-Reply-To: <1240898269.47.0.592056792771.issue5863@psf.upfronthosting.co.za>
Message-ID: <1295926039.05.0.70614984827.issue5863@psf.upfronthosting.co.za>


Anthony Long <antlong at gmail.com> added the comment:

Are there tests for this?

----------
nosy: +antlong

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5863>
_______________________________________

From report at bugs.python.org  Tue Jan 25 04:33:47 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Tue, 25 Jan 2011 03:33:47 +0000
Subject: [issue5863] bz2.BZ2File should accept other file-like objects.
In-Reply-To: <1240898269.47.0.592056792771.issue5863@psf.upfronthosting.co.za>
Message-ID: <1295926427.03.0.938748518644.issue5863@psf.upfronthosting.co.za>


Nadeem Vawda <nadeem.vawda at gmail.com> added the comment:

Yes, see bz2module-v1.diff.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5863>
_______________________________________

From report at bugs.python.org  Tue Jan 25 04:38:50 2011
From: report at bugs.python.org (Anthony Long)
Date: Tue, 25 Jan 2011 03:38:50 +0000
Subject: [issue10976] json.loads() throws TypeError on bytes object
In-Reply-To: <1295636509.41.0.0138366952356.issue10976@psf.upfronthosting.co.za>
Message-ID: <1295926730.52.0.312692723368.issue10976@psf.upfronthosting.co.za>


Anthony Long <antlong at gmail.com> added the comment:

Works for me, py2.7 on snow leopard.

----------
nosy: +antlong

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10976>
_______________________________________

From report at bugs.python.org  Tue Jan 25 05:43:27 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Tue, 25 Jan 2011 04:43:27 +0000
Subject: [issue10684] Folders get deleted when trying to change case with
	shutil.move (case insensitive file systems only)
In-Reply-To: <1292149124.13.0.45494559671.issue10684@psf.upfronthosting.co.za>
Message-ID: <1295930607.91.0.576417561396.issue10684@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

Here is a patch (against release27-maint) for to fix this issue. BTW,what is the best way to check for case insensitive file-system? The test here merely checks if sys.platform returns mac, darwin or win32.

----------
keywords: +patch
nosy: +orsenthil
Added file: http://bugs.python.org/file20511/Issue10684-py27.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10684>
_______________________________________

From report at bugs.python.org  Tue Jan 25 05:44:24 2011
From: report at bugs.python.org (Anthony Long)
Date: Tue, 25 Jan 2011 04:44:24 +0000
Subject: [issue11002] 'Upload' link on Files page is broken
In-Reply-To: <1295930664.52.0.312765274224.issue11002@psf.upfronthosting.co.za>
Message-ID: <1295930664.52.0.312765274224.issue11002@psf.upfronthosting.co.za>


New submission from Anthony Long <antlong at gmail.com>:

On pypi, when you are inside of your packages' files area, the link that is attached to 

1. Use the setup.py "upload" command. # "upload"

is broken, it links to http://www.python.org/doc/dist/package-upload.html which returns a 404.

http://d.pr/mmie

----------
assignee: docs at python
components: Documentation
messages: 126988
nosy: antlong, docs at python
priority: normal
severity: normal
status: open
title: 'Upload' link on Files page is broken
type: behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11002>
_______________________________________

From report at bugs.python.org  Tue Jan 25 06:00:19 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Tue, 25 Jan 2011 05:00:19 +0000
Subject: [issue10684] Folders get deleted when trying to change case with
	shutil.move (case insensitive file systems only)
In-Reply-To: <1292149124.13.0.45494559671.issue10684@psf.upfronthosting.co.za>
Message-ID: <1295931619.35.0.10999795868.issue10684@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

I would also add 'cygwin' to the list. I am not sure about the behavior of OpenVMS or other less prevalent file systems.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10684>
_______________________________________

From report at bugs.python.org  Tue Jan 25 06:14:28 2011
From: report at bugs.python.org (Heikki Toivonen)
Date: Tue, 25 Jan 2011 05:14:28 +0000
Subject: [issue10684] Folders get deleted when trying to change case with
	shutil.move (case insensitive file systems only)
In-Reply-To: <1292149124.13.0.45494559671.issue10684@psf.upfronthosting.co.za>
Message-ID: <1295932468.23.0.943514578425.issue10684@psf.upfronthosting.co.za>


Heikki Toivonen <hjtoi-bugzilla at comcast.net> added the comment:

You can't solve this by trying to do different things on different operating systems. This bug depends on file system properties, not OS.

Also I don't think you can just lower case the path and do a comparison, because there are funky characters that don't round trip lower->upper->lower. And you certainly can't do this for just the last component of the path name - any component of the path could have changed case.

I still think the best avenue would be to first try straight os.rename, and if that fails (maybe only if target exists), the logic that is currently in shutil.move.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10684>
_______________________________________

From report at bugs.python.org  Tue Jan 25 08:07:33 2011
From: report at bugs.python.org (Tanakorn Leesatapornwongsa)
Date: Tue, 25 Jan 2011 07:07:33 +0000
Subject: [issue10993] HTTPSConnection does not close when call close() method
In-Reply-To: <1295866303.79.0.709048263214.issue10993@psf.upfronthosting.co.za>
Message-ID: <1295939253.48.0.257487137501.issue10993@psf.upfronthosting.co.za>


Tanakorn Leesatapornwongsa <tanakorn.lsv at gmail.com> added the comment:

I have tested it on python 2.7.1 already. It quite works.

Thank you.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10993>
_______________________________________

From report at bugs.python.org  Tue Jan 25 08:08:19 2011
From: report at bugs.python.org (Tanakorn Leesatapornwongsa)
Date: Tue, 25 Jan 2011 07:08:19 +0000
Subject: [issue10993] HTTPSConnection does not close when call close() method
In-Reply-To: <1295866303.79.0.709048263214.issue10993@psf.upfronthosting.co.za>
Message-ID: <1295939299.63.0.623141919899.issue10993@psf.upfronthosting.co.za>


Changes by Tanakorn Leesatapornwongsa <tanakorn.lsv at gmail.com>:


----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10993>
_______________________________________

From report at bugs.python.org  Tue Jan 25 08:27:33 2011
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 25 Jan 2011 07:27:33 +0000
Subject: [issue10998] Remove last traces of -Q / sys.flags.division_warning /
	Py_DivisionWarningFlag
In-Reply-To: <1295897150.32.0.288530737397.issue10998@psf.upfronthosting.co.za>
Message-ID: <1295940453.31.0.210863126215.issue10998@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

You can even argue it's a bug fix for 3.2.1, but I'd rather keep the list of changes in the rc small.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10998>
_______________________________________

From report at bugs.python.org  Tue Jan 25 11:21:46 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Tue, 25 Jan 2011 10:21:46 +0000
Subject: [issue10684] Folders get deleted when trying to change case with
	shutil.move (case insensitive file systems only)
In-Reply-To: <1292149124.13.0.45494559671.issue10684@psf.upfronthosting.co.za>
Message-ID: <1295950906.94.0.799980244718.issue10684@psf.upfronthosting.co.za>


Nadeem Vawda <nadeem.vawda at gmail.com> added the comment:

> BTW,what is the best way to check for case insensitive file-system?
> The test here merely checks if sys.platform returns mac, darwin or win32.
I would suggest not checking at all. If the system is case-sensitive, the test will pass, so it doesn't really make a difference. You could write a small function that creates a dummy file and then tries to access it via a case variant of its name, but that seems unnecessary.

> You can't solve this by trying to do different things on different
> operating systems. This bug depends on file system properties, not OS.
It's worth pointing out that it depends on both the FS *and* OS. For example, an NTFS filesystem is case-insensitive under Windows, but case-sensitive under Linux. This has caused me headaches in the past.

> I still think the best avenue would be to first try straight os.rename,
> and if that fails (maybe only if target exists), the logic
> that is currently in shutil.move.
I agree. If os.rename() succeeds, there is no need to copy the file and then delete the original. If it fails because the two paths are on different devices, the existing code can safely be used without any further checks. I'm not sure if there are any other failure cases that would need to be handled, though.

----------
nosy: +nvawda

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10684>
_______________________________________

From report at bugs.python.org  Tue Jan 25 11:37:01 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Tue, 25 Jan 2011 10:37:01 +0000
Subject: [issue9124] Mailbox module should use binary I/O, not text I/O
In-Reply-To: <1277900903.38.0.556015912714.issue9124@psf.upfronthosting.co.za>
Message-ID: <1295951821.47.0.529365331506.issue9124@psf.upfronthosting.co.za>


Steffen Daode Nurpmeso <sdaoden at googlemail.com> added the comment:

Re-New to Python - Re-Started with Py3K in 2011.
'Found myself in a dead-end after 10 days of work because a KOI8-R spam mail causes the file I/O decoding process to fail -
and there is NO WAY TO HANDLE THIS with mailbox.py!
(Went to python.org, searched for mailbox.py, was redirected to Google and found NOTHING related to this problem.
FINALLY found the IssueTracker but was too stupid to re-search.
Well.  Put an issue 10995 which was wrong - unfortunate.)

But now I will spend this entire day to back-port my script to Python 2.7 (and i did not work with Python for some six years)!

I mean - the plan to rewrite the entire mailbox.py exists for about six months now, but mailbox.py is included in the basic library, documented in the library book - but not a single word, not a single comment states that it is in fact *UNUSABLE* in Py3K!

Wouldn't it be sufficient *in the meanwhile* to apply the 10-minutes-work patch mentioned in my issue 10995?
I know it's almost as wrong, but it would gracefully integrate in my fetchmail(1)/mutt(1) local en_GB.UTF-8 stuff 8-}.
Python 3.2 is about to be released in two weeks - shall this unusable module be included the very same way once again?
Thanks for reading this book.

----------
nosy: +sdaoden

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9124>
_______________________________________

From report at bugs.python.org  Tue Jan 25 11:41:56 2011
From: report at bugs.python.org (Jakob Bowyer)
Date: Tue, 25 Jan 2011 10:41:56 +0000
Subject: [issue11003] os.system should be deprecated in favour of subprocess
	module
In-Reply-To: <1295952116.86.0.340970955055.issue11003@psf.upfronthosting.co.za>
Message-ID: <1295952116.86.0.340970955055.issue11003@psf.upfronthosting.co.za>


New submission from Jakob Bowyer <jkbbwr at gmail.com>:

os.system is broken in several fundamental ways. We already have the subprocess module for accessing other processes, lets send os.system the same way as os.Popen.

----------
components: Library (Lib)
messages: 126995
nosy: Jakob.Bowyer
priority: normal
severity: normal
status: open
title: os.system should be deprecated in favour of subprocess module
type: feature request
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/issue11003>
_______________________________________

From report at bugs.python.org  Tue Jan 25 12:10:35 2011
From: report at bugs.python.org (SilentGhost)
Date: Tue, 25 Jan 2011 11:10:35 +0000
Subject: [issue9509] argparse FileType raises ugly exception for missing file
In-Reply-To: <1280927287.23.0.0771144110186.issue9509@psf.upfronthosting.co.za>
Message-ID: <1295953835.7.0.23147187461.issue9509@psf.upfronthosting.co.za>


SilentGhost <ghost.adh at gmail.com> added the comment:

Steven, I'm wondering why do you raise ArgumentTypeError there? From reading doc strings of the relevant errors, it seems obvious to me that it should be ArgumentError. Argument is being used there, there's no conversion occurring anywhere.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9509>
_______________________________________

From report at bugs.python.org  Tue Jan 25 12:42:31 2011
From: report at bugs.python.org (R. David Murray)
Date: Tue, 25 Jan 2011 11:42:31 +0000
Subject: [issue10976] json.loads() throws TypeError on bytes object
In-Reply-To: <1295636509.41.0.0138366952356.issue10976@psf.upfronthosting.co.za>
Message-ID: <1295955751.81.0.371972669966.issue10976@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

anthony: this is python3-only problem.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10976>
_______________________________________

From report at bugs.python.org  Tue Jan 25 12:47:52 2011
From: report at bugs.python.org (Giampaolo Rodola')
Date: Tue, 25 Jan 2011 11:47:52 +0000
Subject: [issue10882] Add os.sendfile()
In-Reply-To: <1294691268.76.0.727179568007.issue10882@psf.upfronthosting.co.za>
Message-ID: <1295956072.01.0.999224765517.issue10882@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

Please note that on FreeBSD things work a little bit differently for non-blocking sockets:
http://www.freebsd.org/cgi/man.cgi?query=sendfile&sektion=2

In details I'm talking about:

> When using a socket marked for non-blocking I/O, sendfile() may send
> fewer bytes than requested.  In this case, the number of bytes 
> success-fully written is returned in *sbytes (if specified), and the 
> error EAGAIN is returned.

...and the similar note about EBUSY, later in the page.
Something like this should work:


ret = sendfile(in, out, offset, &sbytes, &sf, flags);

...

if (ret == -1) {
    if ((errno == EAGAIN) || (errno == EBUSY)) {
        return Py_BuildValue("ll", sbytes, offset + sbytes);
    } 
    return posix_error();
}

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10882>
_______________________________________

From report at bugs.python.org  Tue Jan 25 12:51:33 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 25 Jan 2011 11:51:33 +0000
Subject: [issue9124] Mailbox module should use binary I/O, not text I/O
In-Reply-To: <1277900903.38.0.556015912714.issue9124@psf.upfronthosting.co.za>
Message-ID: <1295956293.11.0.229454982659.issue9124@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
priority: high -> critical
versions: +Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9124>
_______________________________________

From report at bugs.python.org  Tue Jan 25 13:01:58 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 25 Jan 2011 12:01:58 +0000
Subject: [issue11002] 'Upload' link on Files page is broken
In-Reply-To: <1295930664.52.0.312765274224.issue11002@psf.upfronthosting.co.za>
Message-ID: <1295956918.63.0.420206329109.issue11002@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

This bug tracker is used for Python only.  Problems with PyPI should be directed to catalog-sig at python.org.  Thanks.

----------
assignee: docs at python -> 
components:  -Documentation
nosy: +eric.araujo -docs at python
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11002>
_______________________________________

From report at bugs.python.org  Tue Jan 25 13:32:14 2011
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 25 Jan 2011 12:32:14 +0000
Subject: [issue10973] OS X 10.6 IDLE,
	tkinter: Cocoa Tk 8.5 crash when composite character typed in
	text	field
In-Reply-To: <1295620061.05.0.0288010484186.issue10973@psf.upfronthosting.co.za>
Message-ID: <1295958734.6.0.350954443728.issue10973@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

Michael: Why must the subprocess started by IDLE be in 32-bit mode if we'd run IDLE in 32-bit mode?  AFAIK there is no technical reason to do so.

Not that running IDLE in 32-bit mode is an option, it wouldn't fix the issue by itself unless we'd link Tkinter to Tk 8.4 and that would make it impossible to use Tkinter in 64-bit mode at all.

BTW. I'm -1 on using the X11 version of Tk, that would make IDLE look even less like a real Mac application. It would also require additional work to ensure that IDLE.app keeps working as expected.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10973>
_______________________________________

From report at bugs.python.org  Tue Jan 25 13:36:09 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 25 Jan 2011 12:36:09 +0000
Subject: [issue11004] AssertionError on collections.deque().count(1)
In-Reply-To: <1295958969.45.0.0394925969904.issue11004@psf.upfronthosting.co.za>
Message-ID: <1295958969.45.0.0394925969904.issue11004@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

Attached script, bug.py, ends with:

$ python3.2 source2.py 
deque.remove(x): x not in deque
python: ./Modules/_collectionsmodule.c:536: deque_count: Assertion `leftblock->rightlink != ((void *)0)' failed.
Abandon (core dumped)

----------
components: Library (Lib)
files: bug.py
messages: 127001
nosy: haypo
priority: normal
severity: normal
status: open
title: AssertionError on collections.deque().count(1)
type: crash
versions: Python 3.2
Added file: http://bugs.python.org/file20512/bug.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11004>
_______________________________________

From report at bugs.python.org  Tue Jan 25 13:39:41 2011
From: report at bugs.python.org (R. David Murray)
Date: Tue, 25 Jan 2011 12:39:41 +0000
Subject: [issue9124] Mailbox module should use binary I/O, not text I/O
In-Reply-To: <1277900903.38.0.556015912714.issue9124@psf.upfronthosting.co.za>
Message-ID: <1295959181.32.0.254778822735.issue9124@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I'm afraid so.  The python3 uptake process was expected to take five years overall, and we are only up to about the second year at this point.  So while you may have been away from Python for 6 years, you came back right in the middle of an unprecedented transition period.

I agree that it is unfortunate that a shipping library is not functioning correctly with respect to the Python3 bytes/string separation, but no one had tried to use mailbox in python3 enough to have encountered this problem.  You will note that that this bug report was a *performance* bug report initially, and as such had lower priority.  The encoding issue was recognized much more recently.  And before that could be fixed correctly, the email package had to be fixed to handle bytes input.  That happened only just before the end of the beta phase for 3.2.  Now it is too late to make further API changes for 3.3, and in any case it seems counter-productive to make an API change that we don't really want in the library long term.

You could work up a patch to fix this, use it locally, and contribute it so that it makes it in to 3.3.  Perhaps if you and/or someone else can come up with a patch before RC2 it could even go in to 3.2.  I haven't looked at it (yet), but I'm hoping that the patch isn't actually that hard to fix the encoding issues (as opposed to the performance issue, which may take more work).

Or perhaps you could monkey-patch in your encoding fix until 3.3 comes out.  Of course, right now using 2.7 with an eye to staying compatible with python3 is also a perfectly sensible option.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9124>
_______________________________________

From report at bugs.python.org  Tue Jan 25 13:41:14 2011
From: report at bugs.python.org (Michael Foord)
Date: Tue, 25 Jan 2011 12:41:14 +0000
Subject: [issue10973] OS X 10.6 IDLE,
	tkinter: Cocoa Tk 8.5 crash when composite character typed in
	text	field
In-Reply-To: <1295620061.05.0.0288010484186.issue10973@psf.upfronthosting.co.za>
Message-ID: <1295959274.7.0.372336006743.issue10973@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

Ronald: The subprocess also uses Tkinter (right?) so would also require 32bit. 

FWIW I'm -1 on X11 as well.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10973>
_______________________________________

From report at bugs.python.org  Tue Jan 25 13:44:28 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 25 Jan 2011 12:44:28 +0000
Subject: [issue11005] Assertion error on RLock._acquire_restore
In-Reply-To: <1295959468.18.0.305168366567.issue11005@psf.upfronthosting.co.za>
Message-ID: <1295959468.18.0.305168366567.issue11005@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

Attached script (bug2.py) ends with:

$ ~/prog/SVN/py3k/python bug2.py                                                                                                         
python: ./Modules/_threadmodule.c:399: rlock_acquire_restore: Assertion `self->rlock_count == 0' failed.
Abandon

It should raise a classic Python exception, instead of stopping with a fatal assertion error.

----------
components: Library (Lib)
files: bug2.py
messages: 127004
nosy: haypo
priority: normal
severity: normal
status: open
title: Assertion error on RLock._acquire_restore
versions: Python 2.7, Python 3.2
Added file: http://bugs.python.org/file20513/bug2.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11005>
_______________________________________

From report at bugs.python.org  Tue Jan 25 13:44:40 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 25 Jan 2011 12:44:40 +0000
Subject: [issue11004] AssertionError on collections.deque().count(1)
In-Reply-To: <1295958969.45.0.0394925969904.issue11004@psf.upfronthosting.co.za>
Message-ID: <1295959480.74.0.311157416866.issue11004@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
versions: +Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11004>
_______________________________________

From report at bugs.python.org  Tue Jan 25 13:52:17 2011
From: report at bugs.python.org (R. David Murray)
Date: Tue, 25 Jan 2011 12:52:17 +0000
Subject: [issue9124] Mailbox module should use binary I/O, not text I/O
In-Reply-To: <1277900903.38.0.556015912714.issue9124@psf.upfronthosting.co.za>
Message-ID: <1295959937.51.0.952039654958.issue9124@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

That should have been "too late to make API changes for 3.2".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9124>
_______________________________________

From report at bugs.python.org  Tue Jan 25 14:07:36 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 25 Jan 2011 13:07:36 +0000
Subject: [issue5863] bz2.BZ2File should accept other file-like objects.
In-Reply-To: <1240898269.47.0.592056792771.issue5863@psf.upfronthosting.co.za>
Message-ID: <1295960856.71.0.0641141621157.issue5863@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Interesting! If you are motivated, a further approach would be to expose the compressor and decompressor objects from the C extension, and write the file object in Python (as in Lib/gzip.py).

> One thing I was unsure of is how to handle exceptions that occur in
> BZ2File_dealloc(). Does the error status need to be cleared before it
> returns?

Yes, it should. Actually, it would be better to write out the exception using PyErr_WriteUnraisable().

> On a related note, the 'buffering' argument to __init__() is ignored, 
> and I was wondering whether this should be documented explicitly?

Yes, it should probably be deprecated if it's not useful anymore.

By the way, the current patch produces reference leaks:

$ ./python -m test -R 3:2 test_bz2
[1/1] test_bz2
beginning 5 repetitions
12345
.....
test_bz2 leaked [44, 44] references, sum=88

----------
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5863>
_______________________________________

From report at bugs.python.org  Tue Jan 25 14:43:21 2011
From: report at bugs.python.org (Steven Bethard)
Date: Tue, 25 Jan 2011 13:43:21 +0000
Subject: [issue9509] argparse FileType raises ugly exception for missing file
In-Reply-To: <1280927287.23.0.0771144110186.issue9509@psf.upfronthosting.co.za>
Message-ID: <1295963001.1.0.873629417052.issue9509@psf.upfronthosting.co.za>


Steven Bethard <steven.bethard at gmail.com> added the comment:

It's an ArgumentTypeError because that's what you're supposed to raise inside type functions:

http://docs.python.org/dev/library/argparse.html#type

(Note that argparse.FileType.__call__ is what will be called when we pass type=argparse.FileType(...) to add_argument.)

The current docstring for ArgumentTypeError is correct - it says it's "An error from trying to convert a command line string to a type" and we're converting a file path (string) into a file object.  But I certainly wouldn't complain if someone wanted to make the wording there clearer. Basically the rule is:

* Use ArgumentTypeError when you're defining a type= function
* Use ArgumentError otherwise

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9509>
_______________________________________

From report at bugs.python.org  Tue Jan 25 14:51:03 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Tue, 25 Jan 2011 13:51:03 +0000
Subject: [issue5863] bz2.BZ2File should accept other file-like objects.
In-Reply-To: <1240898269.47.0.592056792771.issue5863@psf.upfronthosting.co.za>
Message-ID: <1295963463.54.0.114375483836.issue5863@psf.upfronthosting.co.za>


Nadeem Vawda <nadeem.vawda at gmail.com> added the comment:

> Interesting! If you are motivated, a further approach would be to expose
> the compressor and decompressor objects from the C extension, and write
> the file object in Python (as in Lib/gzip.py).
I had initially considered doing something that, but I decided not to for reasons that I can't quite remember. However, in hindsight it seems like it would have been a better approach than doing everything in C. I'll start on it ASAP.

>> On a related note, the 'buffering' argument to __init__() is ignored, 
>> and I was wondering whether this should be documented explicitly?
> Yes, it should probably be deprecated if it's not useful anymore.
How would I go about doing this? Would it be sufficient to raise a DeprecationWarning if the argument is provided by the caller, and add a note to the docstring and documentation?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5863>
_______________________________________

From report at bugs.python.org  Tue Jan 25 14:54:00 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Tue, 25 Jan 2011 13:54:00 +0000
Subject: [issue5863] bz2.BZ2File should accept other file-like objects.
In-Reply-To: <1240898269.47.0.592056792771.issue5863@psf.upfronthosting.co.za>
Message-ID: <1295963640.94.0.0203465882721.issue5863@psf.upfronthosting.co.za>


Nadeem Vawda <nadeem.vawda at gmail.com> added the comment:

* I had initially considered doing something *like* that

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5863>
_______________________________________

From report at bugs.python.org  Tue Jan 25 15:13:13 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 25 Jan 2011 14:13:13 +0000
Subject: [issue5863] bz2.BZ2File should accept other file-like objects.
In-Reply-To: <1295963463.54.0.114375483836.issue5863@psf.upfronthosting.co.za>
Message-ID: <1295964789.3716.0.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> How would I go about doing this? Would it be sufficient to raise a
> DeprecationWarning if the argument is provided by the caller, and add
> a note to the docstring and documentation?

Yes, totally.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5863>
_______________________________________

From report at bugs.python.org  Tue Jan 25 15:30:09 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 25 Jan 2011 14:30:09 +0000
Subject: [issue11006] warnings with subprocess and pipe2
In-Reply-To: <1295965809.48.0.183733964181.issue11006@psf.upfronthosting.co.za>
Message-ID: <1295965809.48.0.183733964181.issue11006@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

Since r87651, subprocess can raise a RuntimeWarning if pipe2() fails.
I'm not sure there's any point in that, since it's very low-level and it's nothing the user can do about anyway.

Ironically, there is no warning if pipe2() is not available at all.

----------
components: Library (Lib)
messages: 127011
nosy: georg.brandl, gregory.p.smith, pitrou
priority: normal
severity: normal
status: open
title: warnings with subprocess and pipe2
type: behavior
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11006>
_______________________________________

From report at bugs.python.org  Tue Jan 25 15:30:51 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 25 Jan 2011 14:30:51 +0000
Subject: [issue11006] warnings with subprocess and pipe2
In-Reply-To: <1295965809.48.0.183733964181.issue11006@psf.upfronthosting.co.za>
Message-ID: <1295965851.52.0.394135667278.issue11006@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

This can be seen on the sparc Debian buildbot by the way:

/home/pybot/buildarea-sid/3.x.klose-debian-sparc/build/Lib/subprocess.py:1085: RuntimeWarning: pipe2 set errno ENOSYS; falling back to non-atomic pipe+fcntl.
  c2pread, c2pwrite = _create_pipe()
/home/pybot/buildarea-sid/3.x.klose-debian-sparc/build/Lib/subprocess.py:1144: RuntimeWarning: pipe2 set errno ENOSYS; falling back to non-atomic pipe+fcntl.
  errpipe_read, errpipe_write = _create_pipe()
[etc.]

http://www.python.org/dev/buildbot/all/builders/sparc%20Debian%203.x/builds/1/steps/test/logs/stdio

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11006>
_______________________________________

From report at bugs.python.org  Tue Jan 25 15:42:46 2011
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 25 Jan 2011 14:42:46 +0000
Subject: [issue10973] OS X 10.6 IDLE,
	tkinter: Cocoa Tk 8.5 crash when composite character typed
	in	text	field
In-Reply-To: <1295959274.7.0.372336006743.issue10973@psf.upfronthosting.co.za>
Message-ID: <F6A5ABF9-4B95-4510-BF4C-2A9B46E480DD@mac.com>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

On 25 Jan, 2011, at 13:41, Michael Foord wrote:

> 
> Michael Foord <michael at voidspace.org.uk> added the comment:
> 
> Ronald: The subprocess also uses Tkinter (right?) so would also require 32bit. 

Not AFAIK.  I'm pretty sure I've had a 3-way build in the past where IDLE ran as a 32-bit binary and the subprocess was 64-bit one on supported systems.

----------
title: OS X 10.6 IDLE, tkinter: Cocoa Tk 8.5 crash when composite character typed in text	field -> OS X 10.6 IDLE, tkinter: Cocoa Tk 8.5 crash when composite character typed in	text	field

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10973>
_______________________________________

From report at bugs.python.org  Tue Jan 25 15:47:20 2011
From: report at bugs.python.org (Michael Foord)
Date: Tue, 25 Jan 2011 14:47:20 +0000
Subject: [issue10973] OS X 10.6 IDLE,
	tkinter: Cocoa Tk 8.5 crash when composite character typed
	in	text	field
In-Reply-To: <1295620061.05.0.0288010484186.issue10973@psf.upfronthosting.co.za>
Message-ID: <1295966840.97.0.670837489521.issue10973@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

The reason I think it is an issue is that a previous release of Python 2.7 could start IDLE (the initial window would appear), but a dialog would also appear saying that it could not connect to the subprocess and IDLE would exit. IDLE itself had been set to run as a 32bit process by default, but "various people" thought the issue was caused by the subprocess not being launched as 32bit.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10973>
_______________________________________

From report at bugs.python.org  Tue Jan 25 16:12:25 2011
From: report at bugs.python.org (Joshua Blount)
Date: Tue, 25 Jan 2011 15:12:25 +0000
Subject: [issue11007] stack tracebacks should give the relevant class name
In-Reply-To: <1295968345.3.0.31737747868.issue11007@psf.upfronthosting.co.za>
Message-ID: <1295968345.3.0.31737747868.issue11007@psf.upfronthosting.co.za>


New submission from Joshua Blount <hello at joshuablount.com>:

When I get a stack traceback, it would be very handy if the traceback gave me the relevant class name (along with all the current information).

----------
components: Interpreter Core
messages: 127015
nosy: stickwithjosh
priority: normal
severity: normal
status: open
title: stack tracebacks should give the relevant class name
type: feature request
versions: Python 2.5, Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11007>
_______________________________________

From report at bugs.python.org  Tue Jan 25 16:33:04 2011
From: report at bugs.python.org (Nils Philippsen)
Date: Tue, 25 Jan 2011 15:33:04 +0000
Subject: [issue6011] python doesn't build if prefix contains non-ascii
	characters
In-Reply-To: <1242212510.55.0.349129306137.issue6011@psf.upfronthosting.co.za>
Message-ID: <1295969584.98.0.426596112401.issue6011@psf.upfronthosting.co.za>


Nils Philippsen <nils at redhat.com> added the comment:

NB: it's not the shell, but the kernel which interprets the shebang line (and subsequently calls the shell /bin/sh with it if it's missing, causing funny effects when it encounters the first import line and you happen to have ImageMagick installed).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6011>
_______________________________________

From report at bugs.python.org  Tue Jan 25 16:58:43 2011
From: report at bugs.python.org (Andrew Brown)
Date: Tue, 25 Jan 2011 15:58:43 +0000
Subject: [issue11004] AssertionError on collections.deque().count(1)
In-Reply-To: <1295958969.45.0.0394925969904.issue11004@psf.upfronthosting.co.za>
Message-ID: <1295971123.94.0.265649511493.issue11004@psf.upfronthosting.co.za>


Andrew Brown <brownan at gmail.com> added the comment:

This bug trigger can be simplified down, see my attached bug_simplified.py

The problem seems to be in deque_count(). What's happening is that after the rotations, the 16 items reside in the last 16 slots of one block.

In deque_count()'s for loop, the block pointer is incremented regardless of whether the loop has another iteration to go or not. Thus, it's trying to grab the (nonexistant) next block, even though the for loop would have exited anyways.

----------
nosy: +Andrew.Brown
Added file: http://bugs.python.org/file20514/bug_simplified.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11004>
_______________________________________

From report at bugs.python.org  Tue Jan 25 17:37:18 2011
From: report at bugs.python.org (Armin Rigo)
Date: Tue, 25 Jan 2011 16:37:18 +0000
Subject: [issue10994] implementation details in sys module
In-Reply-To: <1295876620.3.0.027428786588.issue10994@psf.upfronthosting.co.za>
Message-ID: <1295973438.5.0.625022653518.issue10994@psf.upfronthosting.co.za>


Armin Rigo <arigo at users.sourceforge.net> added the comment:

> The expectation is that it returns the memory footprint of the given
> object, and only it (not taking into account sharing, caching,
> dependencies or anything else).

It would be nice if this was a well-defined definition, but unfortunately it is not.  For example, string objects may appear different from the user's point of view (e.g. as seen by id() and 'is') but share the implementation's data; they may even share only a part of it (if ropes are enabled).  Conversely, for user-defined objects you would typically think not to count the "shape" information, which is usually shared among several instances -- but then you risk a gross under-estimation in the (rarer) cases where it is not shared.

Another way to look at the "official" definition is to return the size of the object itself and none of its dependencies, because in theory they might be shared; but that would make all strings, lists, tuples, dicts, and so on have a getsizeof() of 8 or 12, which is rather useless.

I hope this clarifies fijal's original comment: "it might be not well defined on other implementations."

----------
nosy: +arigo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10994>
_______________________________________

From report at bugs.python.org  Tue Jan 25 17:53:14 2011
From: report at bugs.python.org (Kristian Vlaardingerbroek)
Date: Tue, 25 Jan 2011 16:53:14 +0000
Subject: [issue10992] tests failing when run under coverage
In-Reply-To: <1295836026.73.0.339636680883.issue10992@psf.upfronthosting.co.za>
Message-ID: <1295974394.6.0.904340049645.issue10992@psf.upfronthosting.co.za>


Kristian Vlaardingerbroek <kristian.vlaardingerbroek at gmail.com> added the comment:

Following tests in test_descr.py fail with both methods:

test_iter_items
test_iter_keys
test_iter_values

regrtest -T causes the following test to fail aswell:

test_slots

The test_iter_* tests fail because __locals__ gets added to the namespace of the class it is testing when tracing is enabled.

test_slots fails on line 1031 in a section marked "Test lookup leaks [SF bug 572567]"

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10992>
_______________________________________

From orsenthil at gmail.com  Tue Jan 25 18:07:21 2011
From: orsenthil at gmail.com (Senthil Kumaran)
Date: Wed, 26 Jan 2011 01:07:21 +0800
Subject: [issue10838] subprocess __all__ is incomplete
In-Reply-To: <1294272926.8.0.857948886182.issue10838@psf.upfronthosting.co.za>
References: <1294260769.5.0.0970426129524.issue10838@psf.upfronthosting.co.za>
	<1294272926.8.0.857948886182.issue10838@psf.upfronthosting.co.za>
Message-ID: <20110125170721.GA1042@rubuntu>

On Thu, Jan 06, 2011 at 12:15:26AM +0000, Antoine Pitrou wrote:
> IMO they should all be prefixed with an underscore. Greg?
> 

+1 to this suggestion. It would make it consistent with expectations.
But yeah, I also think that all public methods should be in __all__ is
not a guarantee.

From report at bugs.python.org  Tue Jan 25 18:07:34 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Tue, 25 Jan 2011 17:07:34 +0000
Subject: [issue10838] subprocess __all__ is incomplete
In-Reply-To: <1294272926.8.0.857948886182.issue10838@psf.upfronthosting.co.za>
Message-ID: <20110125170721.GA1042@rubuntu>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

On Thu, Jan 06, 2011 at 12:15:26AM +0000, Antoine Pitrou wrote:
> IMO they should all be prefixed with an underscore. Greg?
> 

+1 to this suggestion. It would make it consistent with expectations.
But yeah, I also think that all public methods should be in __all__ is
not a guarantee.

----------
nosy: +orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10838>
_______________________________________

From report at bugs.python.org  Tue Jan 25 18:11:33 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Tue, 25 Jan 2011 17:11:33 +0000
Subject: [issue10848] Move test.regrtest from getopt to argparse
In-Reply-To: <1295918453.44.0.552871377666.issue10848@psf.upfronthosting.co.za>
Message-ID: <AANLkTi=vYOa=H=ax1Gq5LPYkyHY2+X9C8SeNkKpAeMtE@mail.gmail.com>


Sandro Tosi <sandro.tosi at gmail.com> added the comment:

On Tue, Jan 25, 2011 at 02:20, R. David Murray <report at bugs.python.org> wrote:
> That might be handy. ?I thought you were trying to roughly reproduce the current help (which dumps it all out at once), which is why I suggested epilog.

actually that was my objective :) but facing the impossibility to
implement it, I asked for advice; I'll go with --help with only usage
& "classic" options descriptions and --more-help for --help + long
options descriptions

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10848>
_______________________________________

From report at bugs.python.org  Tue Jan 25 18:15:58 2011
From: report at bugs.python.org (Kristian Vlaardingerbroek)
Date: Tue, 25 Jan 2011 17:15:58 +0000
Subject: [issue10992] tests failing when run under coverage
In-Reply-To: <1295836026.73.0.339636680883.issue10992@psf.upfronthosting.co.za>
Message-ID: <1295975758.23.0.358736413699.issue10992@psf.upfronthosting.co.za>


Kristian Vlaardingerbroek <kristian.vlaardingerbroek at gmail.com> added the comment:

Following tests in test_descr.py fail:

test_collect_generations (line 261)
test_frame (line 183)
test_get_count (line 249)

These tests count the number of allocations and a trace function can mess this up.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10992>
_______________________________________

From report at bugs.python.org  Tue Jan 25 18:18:16 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 25 Jan 2011 17:18:16 +0000
Subject: [issue10994] implementation details in sys module
In-Reply-To: <1295973438.5.0.625022653518.issue10994@psf.upfronthosting.co.za>
Message-ID: <1295975892.3716.4.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> > The expectation is that it returns the memory footprint of the given
> > object, and only it (not taking into account sharing, caching,
> > dependencies or anything else).
> 
> It would be nice if this was a well-defined definition, but
> unfortunately it is not.

I didn't claim it was. Actually, if you read the rest of my message, I
did mention that PyPy could tweak the semantics if it made more sense.
So, of course, the more sharing and caching takes place, the less
obvious these semantics are, but even with CPython they are not obvious
anyway. It's not supposed to be an exact measurement for the common
developer, rather a hint that experts can use to tweak their data
structures and algorithms; you need to know details of your VM's
implementation to use that information.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10994>
_______________________________________

From report at bugs.python.org  Tue Jan 25 18:18:34 2011
From: report at bugs.python.org (Day Barr)
Date: Tue, 25 Jan 2011 17:18:34 +0000
Subject: [issue11008] logging.dictConfig not documented as new in version 2.7
In-Reply-To: <1295975914.25.0.0685930703721.issue11008@psf.upfronthosting.co.za>
Message-ID: <1295975914.25.0.0685930703721.issue11008@psf.upfronthosting.co.za>


New submission from Day Barr <bugs.python.org at daybarr.com>:

logging.dictConfig is new in version 2.7 but the documentation does not say this.

http://docs.python.org/release/2.7/library/logging.html#logging.dictConfig

c.f. NullHandler, also new in version 2.7 and explicitly documented as such:

http://docs.python.org/release/2.7/library/logging.html#nullhandler

----------
assignee: docs at python
components: Documentation
messages: 127024
nosy: daybarr, docs at python
priority: normal
severity: normal
status: open
title: logging.dictConfig not documented as new in version 2.7
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11008>
_______________________________________

From report at bugs.python.org  Tue Jan 25 18:41:55 2011
From: report at bugs.python.org (Maciej Fijalkowski)
Date: Tue, 25 Jan 2011 17:41:55 +0000
Subject: [issue10994] implementation details in sys module
In-Reply-To: <1295876620.3.0.027428786588.issue10994@psf.upfronthosting.co.za>
Message-ID: <1295977315.39.0.359511117809.issue10994@psf.upfronthosting.co.za>


Maciej Fijalkowski <fijall at gmail.com> added the comment:

I can hardly think about a specification that would potentially help me identify actual sizes. Even as a rough estimation. Which experts you had in mind?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10994>
_______________________________________

From report at bugs.python.org  Tue Jan 25 18:43:37 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 25 Jan 2011 17:43:37 +0000
Subject: [issue10994] implementation details in sys module
In-Reply-To: <1295977315.39.0.359511117809.issue10994@psf.upfronthosting.co.za>
Message-ID: <1295977414.3716.5.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Which experts you had in mind?

People who know how the Python implementation works.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10994>
_______________________________________

From report at bugs.python.org  Tue Jan 25 18:52:41 2011
From: report at bugs.python.org (Maciej Fijalkowski)
Date: Tue, 25 Jan 2011 17:52:41 +0000
Subject: [issue10994] implementation details in sys module
In-Reply-To: <1295876620.3.0.027428786588.issue10994@psf.upfronthosting.co.za>
Message-ID: <1295977961.92.0.336302741306.issue10994@psf.upfronthosting.co.za>


Maciej Fijalkowski <fijall at gmail.com> added the comment:

> > Which experts you had in mind?

> People who know how the Python implementation works.

I'm serious. What semantics would make sense to anyone? Even if you know implementation quite well a single number per object does not provide enough information.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10994>
_______________________________________

From report at bugs.python.org  Tue Jan 25 18:59:47 2011
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 25 Jan 2011 17:59:47 +0000
Subject: [issue10994] implementation details in sys module
In-Reply-To: <1295876620.3.0.027428786588.issue10994@psf.upfronthosting.co.za>
Message-ID: <1295978387.19.0.188357716699.issue10994@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

You could return -1 for everything. =)

In all seriousness, it could simply be proportional. IMO as long as people realize if a list takes up less space than a dict then the numbers seem fine to me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10994>
_______________________________________

From report at bugs.python.org  Tue Jan 25 19:00:33 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 25 Jan 2011 18:00:33 +0000
Subject: [issue10994] implementation details in sys module
In-Reply-To: <1295977961.92.0.336302741306.issue10994@psf.upfronthosting.co.za>
Message-ID: <1295978430.3716.6.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Even if you know implementation quite well a single number per object
> does not provide enough information.

Enough information for what? It can certainly provide information about
the overhead of that particular object (again, regardless of sharing).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10994>
_______________________________________

From report at bugs.python.org  Tue Jan 25 19:10:00 2011
From: report at bugs.python.org (Kristian Vlaardingerbroek)
Date: Tue, 25 Jan 2011 18:10:00 +0000
Subject: [issue10992] tests failing when run under coverage
In-Reply-To: <1295836026.73.0.339636680883.issue10992@psf.upfronthosting.co.za>
Message-ID: <1295979000.5.0.0205547043318.issue10992@psf.upfronthosting.co.za>


Kristian Vlaardingerbroek <kristian.vlaardingerbroek at gmail.com> added the comment:

test_metaclass has some doctests failing because of the added __locals__.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10992>
_______________________________________

From report at bugs.python.org  Tue Jan 25 19:12:13 2011
From: report at bugs.python.org (Kristian Vlaardingerbroek)
Date: Tue, 25 Jan 2011 18:12:13 +0000
Subject: [issue10992] tests failing when run under coverage
In-Reply-To: <1295836026.73.0.339636680883.issue10992@psf.upfronthosting.co.za>
Message-ID: <1295979133.36.0.586898467741.issue10992@psf.upfronthosting.co.za>


Kristian Vlaardingerbroek <kristian.vlaardingerbroek at gmail.com> added the comment:

msg127022 applies to test_gc and not test_descr

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10992>
_______________________________________

From report at bugs.python.org  Tue Jan 25 19:19:08 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 25 Jan 2011 18:19:08 +0000
Subject: [issue10572] Move test sub-packages to Lib/test
In-Reply-To: <1290991979.58.0.262973706564.issue10572@psf.upfronthosting.co.za>
Message-ID: <1295979548.33.0.471612749748.issue10572@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Changing the title to reflect broader scope of this issue.  Json tests were moved to Lib/test/json_tests in r86875.

----------
title: Move unittest test package to Lib/test -> Move test sub-packages to Lib/test

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10572>
_______________________________________

From report at bugs.python.org  Tue Jan 25 19:26:39 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 25 Jan 2011 18:26:39 +0000
Subject: [issue11004] AssertionError on collections.deque().count(1)
In-Reply-To: <1295958969.45.0.0394925969904.issue11004@psf.upfronthosting.co.za>
Message-ID: <1295979999.63.0.551404771666.issue11004@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <rhettinger at users.sourceforge.net>:


----------
assignee:  -> rhettinger
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11004>
_______________________________________

From report at bugs.python.org  Tue Jan 25 19:27:17 2011
From: report at bugs.python.org (Skip Montanaro)
Date: Tue, 25 Jan 2011 18:27:17 +0000
Subject: [issue11003] os.system should be deprecated in favour of subprocess
	module
In-Reply-To: <1295952116.86.0.340970955055.issue11003@psf.upfronthosting.co.za>
Message-ID: <1295980037.16.0.580517413307.issue11003@psf.upfronthosting.co.za>


Skip Montanaro <skip at pobox.com> added the comment:

I disagree.  Both os.popen and os.system work fine in the proper context
and are easier to use (and remember how to use) than the subprocess
module.  You don't give any examples of breakage, or whether said
breakage is platform-dependent.

----------
nosy: +skip.montanaro

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11003>
_______________________________________

From report at bugs.python.org  Tue Jan 25 19:29:55 2011
From: report at bugs.python.org (R. David Murray)
Date: Tue, 25 Jan 2011 18:29:55 +0000
Subject: [issue10848] Move test.regrtest from getopt to argparse
In-Reply-To: <1294353259.48.0.852026284896.issue10848@psf.upfronthosting.co.za>
Message-ID: <1295980195.44.0.112847050756.issue10848@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Hmm.  Am I misunderstanding something about epilog, then?  I thought it was placed at the end of the other help text?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10848>
_______________________________________

From report at bugs.python.org  Tue Jan 25 19:30:44 2011
From: report at bugs.python.org (Skip Montanaro)
Date: Tue, 25 Jan 2011 18:30:44 +0000
Subject: [issue11007] stack tracebacks should give the relevant class name
In-Reply-To: <1295968345.3.0.31737747868.issue11007@psf.upfronthosting.co.za>
Message-ID: <1295980244.32.0.420662813541.issue11007@psf.upfronthosting.co.za>


Skip Montanaro <skip at pobox.com> added the comment:

Given this code:

#!/usr/bin/env python

class C:
    def bomb(self):
        1/0

c = C()
c.bomb()

when run it produces

Traceback (most recent call last):
  File "<stdin>", line 8, in <module>
  File "<stdin>", line 5, in bomb
ZeroDivisionError: integer division or modulo by zero

You would like "bomb" to be "C.bomb"?

----------
nosy: +skip.montanaro

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11007>
_______________________________________

From report at bugs.python.org  Tue Jan 25 19:33:40 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 25 Jan 2011 18:33:40 +0000
Subject: [issue9124] Mailbox module should use binary I/O, not text I/O
In-Reply-To: <1277900903.38.0.556015912714.issue9124@psf.upfronthosting.co.za>
Message-ID: <1295980420.97.0.888365998715.issue9124@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

ISTM an "API change" is okay if it fixes a critical usability bug.

Also, if this is going to ship as-is, the docs should get a big warning right at the top.  Perhaps the source code should also emit a notice that the module is hosed so that people like Steffen don't waste tons of time on hopeless endeavors.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9124>
_______________________________________

From report at bugs.python.org  Tue Jan 25 19:34:06 2011
From: report at bugs.python.org (Joshua Blount)
Date: Tue, 25 Jan 2011 18:34:06 +0000
Subject: [issue11007] stack tracebacks should give the relevant class name
In-Reply-To: <1295968345.3.0.31737747868.issue11007@psf.upfronthosting.co.za>
Message-ID: <1295980446.33.0.967950998285.issue11007@psf.upfronthosting.co.za>


Joshua Blount <hello at joshuablount.com> added the comment:

Yes!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11007>
_______________________________________

From report at bugs.python.org  Tue Jan 25 19:39:12 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Tue, 25 Jan 2011 18:39:12 +0000
Subject: [issue10848] Move test.regrtest from getopt to argparse
In-Reply-To: <1295980195.44.0.112847050756.issue10848@psf.upfronthosting.co.za>
Message-ID: <AANLkTikmYvrghX0R1mH6Vk6kSGbD2EgQ9qEesQ+ee8qG@mail.gmail.com>


Sandro Tosi <sandro.tosi at gmail.com> added the comment:

On Tue, Jan 25, 2011 at 19:29, R. David Murray <report at bugs.python.org> wrote:
>
> R. David Murray <rdmurray at bitdance.com> added the comment:
>
> Hmm. ?Am I misunderstanding something about epilog, then? ?I thought it was placed at the end of the other help text?

Sorry I get confused by the assonance with epydoc (ok they are quite
fare away but still :) now I see argparse.ArgumentParser has an
'epidoc' karg that does exactly what I meant: thanks!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10848>
_______________________________________

From report at bugs.python.org  Tue Jan 25 19:52:19 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 25 Jan 2011 18:52:19 +0000
Subject: [issue11003] os.system should be deprecated in favour of subprocess
	module
In-Reply-To: <1295952116.86.0.340970955055.issue11003@psf.upfronthosting.co.za>
Message-ID: <1295981539.22.0.366805027842.issue11003@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

I'm inclined to reject this out-of-hand.  The os.system() call is a basic call that had been around for very long time, has been widely used successfully, and has parallels in other languages.

Please elaborate on "is broken i several fundamental ways."

----------
assignee:  -> rhettinger
nosy: +rhettinger
versions:  -Python 2.6, Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11003>
_______________________________________

From report at bugs.python.org  Tue Jan 25 19:54:04 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 25 Jan 2011 18:54:04 +0000
Subject: [issue11007] stack tracebacks should give the relevant class name
In-Reply-To: <1295968345.3.0.31737747868.issue11007@psf.upfronthosting.co.za>
Message-ID: <1295981644.88.0.65062955564.issue11007@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Well, given you have the line number at which the method is defined, it is easy to know which class it belongs to.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11007>
_______________________________________

From report at bugs.python.org  Tue Jan 25 19:54:57 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 25 Jan 2011 18:54:57 +0000
Subject: [issue10848] Move test.regrtest from getopt to argparse
In-Reply-To: <1294353259.48.0.852026284896.issue10848@psf.upfronthosting.co.za>
Message-ID: <1295981697.02.0.570299813095.issue10848@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

ISTM that moving from argument parser to another is more likely to introduce bugs than to solve them.  There may be other advantages, but reducing bugginess isn't one of them.  Lots of scripts have used getopts successfully.

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10848>
_______________________________________

From report at bugs.python.org  Tue Jan 25 19:55:52 2011
From: report at bugs.python.org (Skip Montanaro)
Date: Tue, 25 Jan 2011 18:55:52 +0000
Subject: [issue11007] stack tracebacks should give the relevant class name
In-Reply-To: <1295968345.3.0.31737747868.issue11007@psf.upfronthosting.co.za>
Message-ID: <1295981752.27.0.252209166769.issue11007@psf.upfronthosting.co.za>


Skip Montanaro <skip at pobox.com> added the comment:

I'm not sure you can get there from here, certainly not in a
straightforward way.  The traceback formatter gets a reference to
the code object (traceback -> frame -> code).  That object has a name
attribute (which is what's displayed) but it doesn't have a reference
back to the function object.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11007>
_______________________________________

From report at bugs.python.org  Tue Jan 25 20:10:07 2011
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 25 Jan 2011 19:10:07 +0000
Subject: [issue10848] Move test.regrtest from getopt to argparse
In-Reply-To: <1294353259.48.0.852026284896.issue10848@psf.upfronthosting.co.za>
Message-ID: <1295982607.64.0.73047481667.issue10848@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

If Sandro is willing to write test for regrtest as part of the move then that would be a complete net win from the current situation.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10848>
_______________________________________

From report at bugs.python.org  Tue Jan 25 20:31:28 2011
From: report at bugs.python.org (Skip Montanaro)
Date: Tue, 25 Jan 2011 19:31:28 +0000
Subject: [issue11007] stack tracebacks should give the relevant class name
In-Reply-To: <1295968345.3.0.31737747868.issue11007@psf.upfronthosting.co.za>
Message-ID: <1295983888.35.0.138951415506.issue11007@psf.upfronthosting.co.za>


Skip Montanaro <skip at pobox.com> added the comment:

I agree with Antoine, however, if you can come up with a
reasonable patch which implements the desired behavior, I
think it would be reasonable to add it to Python 3.3.  The
definition of "reasonable" is subject to interpretation.
As I indicated in my earlier comment, there is no straight
path from the traceback object to the surrounding class.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11007>
_______________________________________

From report at bugs.python.org  Tue Jan 25 20:48:05 2011
From: report at bugs.python.org (Matthew Barnett)
Date: Tue, 25 Jan 2011 19:48:05 +0000
Subject: [issue2636] Regexp 2.7 (modifications to current re 2.2.2)
In-Reply-To: <1208260672.14.0.711874677361.issue2636@psf.upfronthosting.co.za>
Message-ID: <1295984885.65.0.882847367475.issue2636@psf.upfronthosting.co.za>


Matthew Barnett <python at mrabarnett.plus.com> added the comment:

I've reduced the size of some internal tables.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2636>
_______________________________________

From report at bugs.python.org  Tue Jan 25 21:10:49 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 25 Jan 2011 20:10:49 +0000
Subject: [issue11004] AssertionError on collections.deque().count(1)
In-Reply-To: <1295958969.45.0.0394925969904.issue11004@psf.upfronthosting.co.za>
Message-ID: <1295986249.32.0.483383719041.issue11004@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Victor, thanks for the bug report.  Score one for fuzzing.
Andrew, thanks for the analysis and simplified crasher.
See attached patch.

----------
keywords: +needs review, patch
nosy: +benjamin.peterson, georg.brandl
priority: normal -> release blocker
Added file: http://bugs.python.org/file20515/deque.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11004>
_______________________________________

From report at bugs.python.org  Tue Jan 25 21:24:38 2011
From: report at bugs.python.org (anatoly techtonik)
Date: Tue, 25 Jan 2011 20:24:38 +0000
Subject: [issue11009] urllib.splituser is not documented
In-Reply-To: <1295987078.02.0.421774194417.issue11009@psf.upfronthosting.co.za>
Message-ID: <1295987078.02.0.421774194417.issue11009@psf.upfronthosting.co.za>


New submission from anatoly techtonik <techtonik at gmail.com>:

I'm studying old code that uses urllib.splituser() call and can't find description of this function in Python 2.6.6 docs.

----------
assignee: docs at python
components: Documentation
messages: 127047
nosy: docs at python, techtonik
priority: normal
severity: normal
status: open
title: urllib.splituser is not documented
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11009>
_______________________________________

From report at bugs.python.org  Tue Jan 25 21:28:49 2011
From: report at bugs.python.org (Kristian Vlaardingerbroek)
Date: Tue, 25 Jan 2011 20:28:49 +0000
Subject: [issue10990] tests mutating sys.gettrace() w/o re-instating previous
	state
In-Reply-To: <1295824876.68.0.687534068337.issue10990@psf.upfronthosting.co.za>
Message-ID: <1295987329.61.0.873908180779.issue10990@psf.upfronthosting.co.za>


Kristian Vlaardingerbroek <kristian.vlaardingerbroek at gmail.com> added the comment:

test_trace can be added to this list, each call to runfunc does a sys.settrace()

121:        self.tracer.runfunc(traced_func_loop, 2, 3)
133:        self.tracer.runfunc(traced_func_importing, 2, 5)
145:        self.tracer.runfunc(traced_func_calling_generator)
160:        self.tracer.runfunc(traced_caller_list_comprehension)
183:            tracer.runfunc(method, 20)
225:        self.tracer.runfunc(traced_func_simple_caller, 1)
234:        self.tracer.runfunc(traced_func_importing_caller, 1)
248:        self.tracer.runfunc(obj.inst_method_calling, 1)
266:        self.tracer.runfunc(traced_func_importing_caller, 1)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10990>
_______________________________________

From report at bugs.python.org  Tue Jan 25 21:37:19 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 25 Jan 2011 20:37:19 +0000
Subject: [issue10848] Move test.regrtest from getopt to argparse
In-Reply-To: <1294353259.48.0.852026284896.issue10848@psf.upfronthosting.co.za>
Message-ID: <1295987839.15.0.458734366071.issue10848@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

+1

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10848>
_______________________________________

From report at bugs.python.org  Tue Jan 25 21:56:48 2011
From: report at bugs.python.org (Salman Ahmed)
Date: Tue, 25 Jan 2011 20:56:48 +0000
Subject: [issue5114] 2.5.4.3 and 2.6.2 / test_threading hangs on Solaris
In-Reply-To: <1233347094.1.0.608806299681.issue5114@psf.upfronthosting.co.za>
Message-ID: <1295989008.95.0.359086602951.issue5114@psf.upfronthosting.co.za>


Salman Ahmed <ssahmed537 at gmail.com> added the comment:

Yes, this problem persists on Solaris 9 (SPARC) even with Python 2.7.1.
The problematic processes are:

ssahmed at blade:[~]$ ps -ef|grep -i python
 ssahmed   480   418  0 15:30:25 pts/1    9:14 ./python -Wd -3 -E -tt ./Lib/test/regrtest.py -l
 ssahmed  3062   480  0 15:43:22 pts/1    0:00 /space/home/ssahmed/Python-2.7.1/python -c if 1:            import sys, os, ti
 ssahmed  3063  3062  0 15:43:22 pts/1    0:00 /space/home/ssahmed/Python-2.7.1/python -c if 1:            import sys, os, ti

I was able to workaround the problem by killing the bottom-most process in the list.

----------
nosy: +Salman.Ahmed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5114>
_______________________________________

From report at bugs.python.org  Tue Jan 25 22:09:09 2011
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 25 Jan 2011 21:09:09 +0000
Subject: [issue10990] tests mutating sys.gettrace() w/o re-instating previous
	state
In-Reply-To: <1295824876.68.0.687534068337.issue10990@psf.upfronthosting.co.za>
Message-ID: <1295989749.44.0.23080169917.issue10990@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Thanks for the diagnosis, Kristian. Attached is a patch for test_trace which fixes its over-zealous setting of the trace function (doesn't address the failures, though).

----------
Added file: http://bugs.python.org/file20516/test_trace.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10990>
_______________________________________

From report at bugs.python.org  Tue Jan 25 22:14:43 2011
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 25 Jan 2011 21:14:43 +0000
Subject: [issue10990] tests mutating sys.gettrace() w/o re-instating previous
	state
In-Reply-To: <1295824876.68.0.687534068337.issue10990@psf.upfronthosting.co.za>
Message-ID: <1295990083.26.0.709577136182.issue10990@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Here is a patch for test_pdb; the context manager made this dirt-simple to fix.

----------
Added file: http://bugs.python.org/file20517/test_gdb.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10990>
_______________________________________

From report at bugs.python.org  Tue Jan 25 22:17:49 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Tue, 25 Jan 2011 21:17:49 +0000
Subject: [issue10848] Move test.regrtest from getopt to argparse
In-Reply-To: <1295982607.64.0.73047481667.issue10848@psf.upfronthosting.co.za>
Message-ID: <AANLkTi=wvbhzjjWvmr6fN=+L3yab5sSbUBFSUGgsHRVe@mail.gmail.com>


Sandro Tosi <sandro.tosi at gmail.com> added the comment:

Sure, that would be really interesting to do, and I do commit to write
a "test suite to the tool that runs the python test suite" :)

What I'm asking is: how would you do that? I'm quite new as
contributor so the ideas of experienced core devs are very valuable at
this stage of the task. David proposed to write a parallel
test-directory for regrtest, would you think it's feasible to do that?
and what to put in that dir to "trigger" weird behaviour in regrtest?
Any other input?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10848>
_______________________________________

From report at bugs.python.org  Tue Jan 25 22:21:02 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 25 Jan 2011 21:21:02 +0000
Subject: [issue10848] Move test.regrtest from getopt to argparse
In-Reply-To: <1294353259.48.0.852026284896.issue10848@psf.upfronthosting.co.za>
Message-ID: <1295990462.19.0.533199154593.issue10848@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Some parts of regrtest have been obsoleted by changes in unittest.  Best not to write tests for something that will go.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10848>
_______________________________________

From report at bugs.python.org  Tue Jan 25 22:25:59 2011
From: report at bugs.python.org (onpon4)
Date: Tue, 25 Jan 2011 21:25:59 +0000
Subject: [issue11010] Unicode BOM left in loaded text
In-Reply-To: <1295990759.68.0.350940217236.issue11010@psf.upfronthosting.co.za>
Message-ID: <1295990759.68.0.350940217236.issue11010@psf.upfronthosting.co.za>


New submission from onpon4 <onpon4 at yahoo.com>:

This is for Python 2.7.1. It isn't an issue on 2.6.5 and I haven't tested it on 3.1.

Quite simply, the Unicode BOM (unichr(65279)) is included in the text loaded from a UTF-8 text file. This can cause issues in some cases, but is easily worked around by calling "s.strip(unichr(65279))" on the first line of loaded text.

----------
components: IO, Unicode
messages: 127055
nosy: onpon4
priority: normal
severity: normal
status: open
title: Unicode BOM left in loaded text
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11010>
_______________________________________

From report at bugs.python.org  Tue Jan 25 22:31:41 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 25 Jan 2011 21:31:41 +0000
Subject: [issue11004] AssertionError on collections.deque().count(1)
In-Reply-To: <1295958969.45.0.0394925969904.issue11004@psf.upfronthosting.co.za>
Message-ID: <1295991101.75.0.261690979095.issue11004@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

deque.patch: I'm unable to say if the patch is correct or not, but it is always a good thing to remove asser(...) :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11004>
_______________________________________

From report at bugs.python.org  Tue Jan 25 22:39:02 2011
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 25 Jan 2011 21:39:02 +0000
Subject: [issue10990] tests mutating sys.gettrace() w/o re-instating previous
	state
In-Reply-To: <1295824876.68.0.687534068337.issue10990@psf.upfronthosting.co.za>
Message-ID: <1295991542.75.0.0230801494256.issue10990@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Patch for doctest/test_doctest (yes, both files were wiping out the trace function.

----------
Added file: http://bugs.python.org/file20518/test_doctest.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10990>
_______________________________________

From report at bugs.python.org  Tue Jan 25 22:39:51 2011
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 25 Jan 2011 21:39:51 +0000
Subject: [issue10990] tests mutating sys.gettrace() w/o re-instating previous
	state
In-Reply-To: <1295824876.68.0.687534068337.issue10990@psf.upfronthosting.co.za>
Message-ID: <1295991591.68.0.58442953007.issue10990@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

And with this patch for test_zipimport_support to work thanks to the test_doctest changes, all of the test suites blasting the trace function *should* be fixed.

----------
Added file: http://bugs.python.org/file20519/test_zipimport_support.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10990>
_______________________________________

From report at bugs.python.org  Tue Jan 25 22:45:46 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 25 Jan 2011 21:45:46 +0000
Subject: [issue11004] AssertionError on collections.deque().count(1)
In-Reply-To: <1295958969.45.0.0394925969904.issue11004@psf.upfronthosting.co.za>
Message-ID: <1295991946.26.0.617342578286.issue11004@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Fixed in r88191 and r88192.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11004>
_______________________________________

From report at bugs.python.org  Tue Jan 25 22:45:59 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 25 Jan 2011 21:45:59 +0000
Subject: [issue11004] AssertionError on collections.deque().count(1)
In-Reply-To: <1295958969.45.0.0394925969904.issue11004@psf.upfronthosting.co.za>
Message-ID: <1295991959.57.0.344562989557.issue11004@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <rhettinger at users.sourceforge.net>:


----------
components: +Extension Modules -Library (Lib)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11004>
_______________________________________

From report at bugs.python.org  Tue Jan 25 22:55:44 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 25 Jan 2011 21:55:44 +0000
Subject: [issue10826] pass_fds sometimes fails
In-Reply-To: <1294152290.71.0.646502628705.issue10826@psf.upfronthosting.co.za>
Message-ID: <1295992544.44.0.542393820985.issue10826@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

So, I added some debug info to test_pass_fds:

 -- fds that should have been closed: {5, 6, 7, 8, 9, 10, 11, 12, 13}
 -- fds that remained open: {0, 1, 2, 3, 5}
 -- debug info:
0 8194 posix.stat_result(st_mode=8592, st_ino=12582920, st_dev=82051072, st_nlink=1, st_uid=1140, st_gid=7, st_size=0, st_atime=1295990436, st_mtime=1295991135, st_ctime=1295990436)
1 2 posix.stat_result(st_mode=4096, st_ino=79119887, st_dev=84148224, st_nlink=0, st_uid=1140, st_gid=1, st_size=0, st_atime=1295991135, st_mtime=1295991135, st_ctime=1295991135)
2 8194 posix.stat_result(st_mode=8592, st_ino=12582920, st_dev=82051072, st_nlink=1, st_uid=1140, st_gid=7, st_size=0, st_atime=1295990436, st_mtime=1295991135, st_ctime=1295990436)
3 2 posix.stat_result(st_mode=4096, st_ino=79119882, st_dev=84148224, st_nlink=0, st_uid=1140, st_gid=1, st_size=0, st_atime=1295991135, st_mtime=1295991135, st_ctime=1295991135)
5 8192 posix.stat_result(st_mode=53540, st_ino=56, st_dev=84410368, st_nlink=1, st_uid=0, st_gid=0, st_size=0, st_atime=1269710532, st_mtime=1269710532, st_ctime=1269710532)
FAIL

Each line is in the following form: <fd> <value returned by F_GETFD> <os.fstat(fd)>

Here is my interpretation for fd 5 (which is the offending fd):
- a F_GETFD value of 8192 is different from both pipes (which return 2) and standard stdin/stderr (which return 8194); if the values haven't changed between Solaris versions, 8192 is O_LARGEFILE + O_RDONLY
- a st_mode of 53540 is stat.S_IFSOCK + stat.S_IFIFO + stat.S_IRUSR + stat.S_IRGRP + stat.S_IROTH; so this seems to be some kind of read-only (filesystem-based?) socket

I think it is unlikely that this socket is inherited from the parent process, or present before calling exec(). Instead, perhaps it's the startup of the child Python interpreter (after exec()) which creates such a file descriptor, and doesn't close it. Unfortunately, it seems difficult to diagnose this in more detail.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10826>
_______________________________________

From report at bugs.python.org  Tue Jan 25 23:08:59 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 25 Jan 2011 22:08:59 +0000
Subject: [issue10973] OS X 10.6 IDLE,
	tkinter: Cocoa Tk 8.5 crash when composite character typed
	in	text	field
In-Reply-To: <1295620061.05.0.0288010484186.issue10973@psf.upfronthosting.co.za>
Message-ID: <1295993339.71.0.458501945051.issue10973@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/issue10973>
_______________________________________

From report at bugs.python.org  Tue Jan 25 23:18:21 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 25 Jan 2011 22:18:21 +0000
Subject: [issue9724] help('nonlocal') missing
In-Reply-To: <1283264506.65.0.891353538251.issue9724@psf.upfronthosting.co.za>
Message-ID: <1295993901.43.0.0218828242868.issue9724@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Was this left out of 3.1 and 2.7 on purpose?

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9724>
_______________________________________

From report at bugs.python.org  Tue Jan 25 23:32:22 2011
From: report at bugs.python.org (Jason Baker)
Date: Tue, 25 Jan 2011 22:32:22 +0000
Subject: [issue11011] More functools functions
In-Reply-To: <1295994742.19.0.341586360497.issue11011@psf.upfronthosting.co.za>
Message-ID: <1295994742.19.0.341586360497.issue11011@psf.upfronthosting.co.za>


New submission from Jason Baker <amnorvend at gmail.com>:

I've created a patch that adds some common functional programming tools to functools.  I've made the patch to work against Python 3.2, but that may be a bit aggressive.  If so, then I can adapt it to work with 3.3.

I also wouldn't be opposed to writing some of these in C if there's a performance need.

The functions I added are:

* flip - flip the first two arguments of a function
* const - return a function that always returns the same thing
* compose - compose multiple functions together
* identity - returns what is passed in to it
* trampoline - calls a function and then calls any returned functions.

----------
components: Library (Lib)
files: functools.patch
keywords: patch
messages: 127062
nosy: Jason.Baker
priority: normal
severity: normal
status: open
title: More functools functions
versions: Python 3.2, Python 3.3
Added file: http://bugs.python.org/file20520/functools.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11011>
_______________________________________

From report at bugs.python.org  Tue Jan 25 23:51:24 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 25 Jan 2011 22:51:24 +0000
Subject: [issue10826] pass_fds sometimes fails
In-Reply-To: <1294152290.71.0.646502628705.issue10826@psf.upfronthosting.co.za>
Message-ID: <1295995884.91.0.480831563896.issue10826@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I managed to get further debug info from the OpenIndiana buildbot:

 -- maxfd = 65536
 -- fds that should have been closed: {5, 6, 7, 8, 9, 10, 11, 12, 13}
 -- fds that remained open: {0, 1, 2, 3, 5}
 -- debug info:
0 2 posix.stat_result(st_mode=4096, st_ino=38002789, st_dev=142868480, st_nlink=0, st_uid=101, st_gid=101, st_size=0, st_atime=1295994652, st_mtime=1295994652, st_ctime=1295994652)
1 2 posix.stat_result(st_mode=4096, st_ino=38019207, st_dev=142868480, st_nlink=0, st_uid=101, st_gid=101, st_size=0, st_atime=1295994988, st_mtime=1295994988, st_ctime=1295994988)
2 2 posix.stat_result(st_mode=4096, st_ino=38002791, st_dev=142868480, st_nlink=0, st_uid=101, st_gid=101, st_size=0, st_atime=1295994987, st_mtime=1295994987, st_ctime=1295994987)
3 2 posix.stat_result(st_mode=4096, st_ino=38019202, st_dev=142868480, st_nlink=0, st_uid=101, st_gid=101, st_size=0, st_atime=1295994988, st_mtime=1295994988, st_ctime=1295994988)
5 8192 posix.stat_result(st_mode=53540, st_ino=210, st_dev=146014208, st_nlink=1, st_uid=0, st_gid=0, st_size=0, st_atime=1290335283, st_mtime=1290335283, st_ctime=1290335283)
total 2
dr-x------ 2 buildbot buildbot 528 Jan 25 22:36 .
dr-x--x--x 5 buildbot buildbot 864 Jan 25 22:36 ..
p--------- 0 buildbot buildbot   0 Jan 25 22:30 0
p--------- 0 buildbot buildbot   0 Jan 25 22:36 1
p--------- 0 buildbot buildbot   0 Jan 25 22:36 2
p--------- 0 buildbot buildbot   0 Jan 25 22:36 3
D--------- 1 root     root       0 Nov 21 10:28 5
  File: `/proc/22816/fd/5'
  Size: 0         	Blocks: 0          IO Block: 0      weird file
Device: 8b40000h/146014208d	Inode: 210         Links: 1
Access: (0000/D---------)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2010-11-21 10:28:03.659679536 +0000
Modify: 2010-11-21 10:28:03.659679536 +0000
Change: 2010-11-21 10:28:03.659679536 +0000


So, the offending fd (5) points to a "weird file" (!!) created in November 2010... It definitely can't be the same file as pointed to by fd 5 in the parent process, since that is a standard anonymous pipe. This reinforces the idea that starting up the child Python interpreter sometimes creates that fd and doesn't close it.

Also, while the sparc solaris buildbot doesn't have the "stat" command, it still displays the following debug output:

total 4
dr-x------   2 buildbot other        528 Jan 25 23:58 .
dr-x--x--x   5 buildbot other        832 Jan 25 23:58 ..
c---------   1 buildbot tty       24,  2 Jan 25 23:58 0
p---------   0 buildbot other          0 Jan 25 23:58 1
c---------   1 buildbot tty       24,  2 Jan 25 23:58 2
p---------   0 buildbot other          0 Jan 25 23:58 3
D---------   1 root     root           0 Mar 27  2010 5

... where fd number 5 seems to be the same kind of "weird file" created by root a long time ago. Martin, does that date (Mar 27 2010) ring a bell? Is it when the system was installed? When the buildslave was started?

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10826>
_______________________________________

From report at bugs.python.org  Tue Jan 25 23:54:34 2011
From: report at bugs.python.org (R. David Murray)
Date: Tue, 25 Jan 2011 22:54:34 +0000
Subject: [issue10848] Move test.regrtest from getopt to argparse
In-Reply-To: <1294353259.48.0.852026284896.issue10848@psf.upfronthosting.co.za>
Message-ID: <1295996074.53.0.0953552154006.issue10848@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I would say writing tests for regrtest is going to be a somewhat tricky task.  I think you will have to do some code tweaking to even be able to run certain tests.  I believe that regrtest currently has some built in assumptions about the test directory (ie: that it is Lib/test), even though the regrtest main program provides a testdir argument.  So the first task is probably going to be getting that argument to actually work, and then exposing a way to set it at the regrtest command level (or, alternatively, moving all command functionality out of __main__ and into main).  Once you have that, your test suite can programatically generate a test test-directory and populate it with whatever files you need for each test, using the utilities in test.script_helper.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10848>
_______________________________________

From report at bugs.python.org  Tue Jan 25 23:58:45 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Tue, 25 Jan 2011 22:58:45 +0000
Subject: [issue11010] Unicode BOM left in loaded text
In-Reply-To: <1295990759.68.0.350940217236.issue11010@psf.upfronthosting.co.za>
Message-ID: <1295996325.34.0.850986749944.issue11010@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Can you please be more specific? What do you mean by "text loaded from a UTF-8 text file"? How specifically did you load it?

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11010>
_______________________________________

From report at bugs.python.org  Wed Jan 26 00:00:49 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 25 Jan 2011 23:00:49 +0000
Subject: [issue11010] Unicode BOM left in loaded text
In-Reply-To: <1295990759.68.0.350940217236.issue11010@psf.upfronthosting.co.za>
Message-ID: <1295996449.06.0.569965998639.issue11010@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/issue11010>
_______________________________________

From report at bugs.python.org  Wed Jan 26 00:00:57 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 25 Jan 2011 23:00:57 +0000
Subject: [issue11011] More functools functions
In-Reply-To: <1295994742.19.0.341586360497.issue11011@psf.upfronthosting.co.za>
Message-ID: <1295996457.55.0.62440628049.issue11011@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Some of these have been proposed and rejected before.

Compose has a problematic API because the traditional order of application in mathematics is counter-intuitive for many people.

Const seems reasonable except that we already have ways to do it:  
     twos = lambda :2
     twos = itertools.repeat(2).__next__
The principal use case for const is with map() and itertools.repeat() is already targeted at that use-case:
     cubes = list(map(pow, range(10), repeat(3)))

Flip would be nice on occasion:
     colorseq = list(map(flip, enumerate(
       'red orange yellow green blue indigo violet'.split())))

Identity is problematic for a few reasons.  First, there doesn't seem to be one signature that fits all use cases:
     identity1 = lambda *args:  *args   # always returns a tuple
     identity2 = lambda arg:  arg       # always returns a scalar
Also, the availability of 'identity' seems to encourage bad design.
Speedwise, it is usually better to have two paths (predicate is None vs some given predicate) than have an identity function default (predict=identity).  See the itertools module for examples.

Trampoline is interesting, but the use case doesn't seem to arise much in Python programming and when it does, it is usually clearer to write:
    for f in get_actions():
        f()
That straight-forward code is superior, not just because of its readability but also because it is easily modified to handle return values being feed in to consecutive calls, adding optional and keyword arguments, introducing logging, etc.  

In short, some of these constructs are better suited for languages that a more purely functional in nature.  Those don't treat scalar arguments differently than multiple arguments, those don't use keywords or optional arguments, currying can be done cleanly etc.

Experiences with the itertools module have shown than not all of the usual favorite functional gizmos fit well in the Python language.  They are tempting toys, but typically don't beat regular, clean Python code.

One last comment, any time a group of interoperative tools is proposed, I think it absolutely necessary to construct a bunch of sample code to exercise the APIs working in concert with one another.  With the itertools module, considerable effort was directed at designing a toolkit with cleanly interoperative parts.

Also, when proposing something that changes the fundamentals of how people would design their programs, I think it is necessary to scan real-world code to find many examples where the code would be much improved if it used the new constructs.  (This is similar to the notion of a Phase III clinical trial -- even if something works, it needs to be shown to be better than existing alternatives).

----------
nosy: +rhettinger
versions:  -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11011>
_______________________________________

From report at bugs.python.org  Wed Jan 26 00:08:03 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 25 Jan 2011 23:08:03 +0000
Subject: [issue11011] More functools functions
In-Reply-To: <1295994742.19.0.341586360497.issue11011@psf.upfronthosting.co.za>
Message-ID: <1295996883.08.0.707332584388.issue11011@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

One other thought:  The use of list comprehensions (a.k.a. list displays) and generator expressions has made many functional tools less necessary than ever.

   # preferred over map(pow, repeat(2), range(5))
   [pow(2, x) for x in range(5)]

   # preferred over map(flip, dict.items())
   [(v, k) for k, v in mydict.items()]

The list comprehension and genexp styles are much more flexible and works well with default arguments, constants, and using a combination of features:

   # hard to do with functionals
   [f(g(2,x), h(x, 3, y, flag=True)) for x, y in zip(X, Y) if x>y//2]

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11011>
_______________________________________

From report at bugs.python.org  Wed Jan 26 00:11:29 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 25 Jan 2011 23:11:29 +0000
Subject: [issue11011] More functools functions
In-Reply-To: <1295994742.19.0.341586360497.issue11011@psf.upfronthosting.co.za>
Message-ID: <1295997089.2.0.571945055117.issue11011@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/issue11011>
_______________________________________

From report at bugs.python.org  Wed Jan 26 00:14:33 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 25 Jan 2011 23:14:33 +0000
Subject: [issue6926] socket module missing IPPROTO_IPV6, IPPROTO_IPV4
In-Reply-To: <1253143086.64.0.131724035197.issue6926@psf.upfronthosting.co.za>
Message-ID: <1295997273.34.0.501665942309.issue6926@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Should this be fixed before the final release?

----------
components: +Library (Lib) -IO
nosy: +eric.araujo, georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6926>
_______________________________________

From report at bugs.python.org  Wed Jan 26 00:16:52 2011
From: report at bugs.python.org (Gregory P. Smith)
Date: Tue, 25 Jan 2011 23:16:52 +0000
Subject: [issue6926] socket module missing IPPROTO_IPV6, IPPROTO_IPV4
In-Reply-To: <1253143086.64.0.131724035197.issue6926@psf.upfronthosting.co.za>
Message-ID: <1295997412.59.0.760545684713.issue6926@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

IMNSHO it should but that would violate our release practices to do it this late in the cycle.  I expect the release manager to decline.

It isn't a critical issue, the end result is that people will hard code the constants into their own code themselves since we don't have them in the library yet.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6926>
_______________________________________

From report at bugs.python.org  Wed Jan 26 00:22:10 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 25 Jan 2011 23:22:10 +0000
Subject: [issue6926] socket module missing IPPROTO_IPV6, IPPROTO_IPV4
In-Reply-To: <1253143086.64.0.131724035197.issue6926@psf.upfronthosting.co.za>
Message-ID: <1295997730.36.0.0964505603804.issue6926@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
stage:  -> needs patch
versions: +Python 3.3 -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6926>
_______________________________________

From report at bugs.python.org  Wed Jan 26 00:25:01 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 25 Jan 2011 23:25:01 +0000
Subject: [issue11012] Add log1p(), exp1m(), gamma(), and lgamma() to cmath
In-Reply-To: <1295997901.71.0.113497713942.issue11012@psf.upfronthosting.co.za>
Message-ID: <1295997901.71.0.113497713942.issue11012@psf.upfronthosting.co.za>


New submission from Raymond Hettinger <rhettinger at users.sourceforge.net>:

Where it makes sense, cmath needs to stay in-sync with the math module as much as possible:

  >>> set(dir(math)) - set(dir(cmath))
  {'pow', 'fsum', 'ldexp', 'hypot', 'fabs', 'floor', 'lgamma',
   'frexp', 'degrees', 'modf', 'factorial', 'copysign', 'ceil',
   'trunc', 'expm1', 'radians', 'atan2', 'erf', 'erfc', 'fmod',
   'log1p', 'gamma'}

At some point, it may make sense to implement cmath.fsum() along the lines of:
 
 c_fsum = lambda iterable: 
   complex(*map(fsum, zip(*((z.real, z.imag) for z in iterable))))

----------
assignee: mark.dickinson
components: Extension Modules
messages: 127070
nosy: mark.dickinson, rhettinger
priority: normal
severity: normal
stage: needs patch
status: open
title: Add log1p(), exp1m(), gamma(), and lgamma() to cmath
type: feature request
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11012>
_______________________________________

From report at bugs.python.org  Wed Jan 26 00:34:40 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 25 Jan 2011 23:34:40 +0000
Subject: [issue6926] socket module missing IPPROTO_IPV6, IPPROTO_IPV4
In-Reply-To: <1253143086.64.0.131724035197.issue6926@psf.upfronthosting.co.za>
Message-ID: <1295998480.11.0.530659736851.issue6926@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

I would consider it to be regression and bugfix that is not inappropriate to repair at this point.

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6926>
_______________________________________

From report at bugs.python.org  Wed Jan 26 00:37:33 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Tue, 25 Jan 2011 23:37:33 +0000
Subject: [issue6926] socket module missing IPPROTO_IPV6, IPPROTO_IPV4
In-Reply-To: <1295998480.11.0.530659736851.issue6926@psf.upfronthosting.co.za>
Message-ID: <4D3F5EBC.2040806@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> I would consider it to be regression and bugfix that is not inappropriate to repair at this point.

I'd also be in favor of fixing it. To reduce the risk of breaking
something, I'd only raise socketmodule to a more recent Windows API.
Of course, this, in itself, might also break something.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6926>
_______________________________________

From report at bugs.python.org  Wed Jan 26 00:45:28 2011
From: report at bugs.python.org (onpon4)
Date: Tue, 25 Jan 2011 23:45:28 +0000
Subject: [issue11010] Unicode BOM left in loaded text
In-Reply-To: <1295990759.68.0.350940217236.issue11010@psf.upfronthosting.co.za>
Message-ID: <1295999128.51.0.716245080377.issue11010@psf.upfronthosting.co.za>


onpon4 <onpon4 at yahoo.com> added the comment:

Like this:

f = io.open()
f.readline()

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11010>
_______________________________________

From report at bugs.python.org  Wed Jan 26 01:07:19 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Wed, 26 Jan 2011 00:07:19 +0000
Subject: [issue5863] bz2.BZ2File should accept other file-like objects.
In-Reply-To: <1240898269.47.0.592056792771.issue5863@psf.upfronthosting.co.za>
Message-ID: <1296000439.45.0.320087924509.issue5863@psf.upfronthosting.co.za>


Nadeem Vawda <nadeem.vawda at gmail.com> added the comment:

Here is a quick-and-dirty reimplementation of BZ2File in Python, on top of the existing C implementation of BZ2Compressor and BZ2Decompressor.

There are a couple of issues with this code that need to be fixed:
* BZ2Decompressor doesn't signal when it reaches the EOS marker, so doesn't seem possible to detect a premature end-of-file. This was easy in the C implementation, when using bzDecompress() directly.
* The read*() methods are implemented very inefficiently. Since they have to deal with the bytes objects returned by BZ2Decompressor.decompress(), a large read results in lots of allocations that weren't necessary in the C implementation.

I hope to resolve both of these issues (and do a general code cleanup), by writing a C extension module that provides a thin wrapper around bzCompress()/bzDecompress(), and reimplementing the module's public interface in Python on top of it. This should reduce the size of the code by close to half, and make it easier to read and maintain. I'm not sure when I'll be able to get around to it, though, so I thought I should post what I've done so far.

Other changes in the patch:
* write(), writelines() and seek() now return meaningful values instead of None, in line with the behaviour of other file-like objects.
* Fixed a typo in test_bz2's testReadChunk10() that caused the test to pass regardless of whether the data read was correct (self.assertEqual(text, text) -> self.assertEqual(text, self.TEXT)). This one might be worth committing now, since it isn't dependent on the rewrite.

----------
Added file: http://bugs.python.org/file20521/bz2module-v2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5863>
_______________________________________

From report at bugs.python.org  Wed Jan 26 01:23:11 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Wed, 26 Jan 2011 00:23:11 +0000
Subject: [issue11010] Unicode BOM left in loaded text
In-Reply-To: <1295990759.68.0.350940217236.issue11010@psf.upfronthosting.co.za>
Message-ID: <1296001391.06.0.927205416932.issue11010@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Why are you saying this isn't an issue in 2.6.5? It behaves exactly the same as 2.7.1.

In any case, this is not a bug. Pass encoding="utf-8-sig" to io.open to have the signature stripped when the file is read.

----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11010>
_______________________________________

From report at bugs.python.org  Wed Jan 26 01:34:08 2011
From: report at bugs.python.org (Jason Baker)
Date: Wed, 26 Jan 2011 00:34:08 +0000
Subject: [issue11011] More functools functions
In-Reply-To: <1295994742.19.0.341586360497.issue11011@psf.upfronthosting.co.za>
Message-ID: <1296002048.21.0.378658284085.issue11011@psf.upfronthosting.co.za>


Jason Baker <amnorvend at gmail.com> added the comment:

Ray,  thanks for prompt and thorough feedback.  To address your concerns:

* I'm fine with doing away with const and identity (long story short I haven't really used them in functional languages anyway).  There were reasons for defining identity the way it is, but it's hardly a big deal if that doesn't make it in.
* Personally, I see the mathematical notation for compose to be very intuitive, however it's typically described in a non-intuitive manner.  The functions get called in a left-to-right manner (as is intuitive), however, when you see it defined it is usually in a right-to-left manner.  Thus it can be confusing because we say compose(f, g)(x) [left-to-right]  is equivalent to g(f(x)) [which reads right-to-left, but is still doing what you might expect intuitively].  But I doubt most people that use Python will care about the mathematical usage anyway.  What if we called  the function "pipeline"?  That's essentially what it's doing, and I think people would find that easier to understand.
* I'm not saying you're wrong about trampoline, but I want to make sure that you and I are discussing the same thing.  :-)  The idea for trampoline comes from clojure, which is unique among functional languages in that it has no tail-call recursion.  Trampoline is a way to write a function that is tail recursive, but won't blow the stack.  So your example, while similar isn't *quite* the same thing.  The documentation I wrote shows an example function count_to_a_million.  If I wrote it like this I'd blow the stack:

    def count_to_a_million(i):
        if i < 1000000:
            return count_to_a_million(i)
        else:
            return i

Of course, you could definitely argue that it would just be easier to use a loop (or even better range).  However, many functional programmers' brains have just been wired to use recursion which they might find more intuitive as a means of iteration.  Of course, one could argue that it would be better for them to learn the Pythonic way of doing things, and I would agree.  Python is a multi-paradigm language that supports both functional and imperative approaches, therefore it's Pythonic to provide a functional approach.
* It sounds like you feel flip is useful, but it's a matter of whether you feel it's useful enough to add to the standard library.

Lastly, I love list comprehensions and see where you're coming from, but why do the two have to be mutually exclusive?  I mean, the idea for them came from Haskell which hasn't done away with them.  For instance, take your example:

    [f(g(2,x), h(x, 3, y, flag=True)) for x, y in zip(X, Y) if x>y//2]

I certainly hope you don't really write code like that.  :-)

I think something like this is more readable:

    fg = partial(compose(f, g), 2)
    h1 = lambda x, y:  h(x, 3, y, flag=True)
    [(fg(x), h1(x, y)) for x, y in zip(X, Y) if x>y//2]

...but maybe I'm weird.

If you're still opposed to adding these functions, let me know.  I feel that they have use-cases in the Python standard library, but I can add them to pysistence when I port it to Python 3 and make it a functional data structure/algorithm library.  :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11011>
_______________________________________

From report at bugs.python.org  Wed Jan 26 01:35:37 2011
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 26 Jan 2011 00:35:37 +0000
Subject: [issue10990] tests mutating sys.gettrace() w/o re-instating previous
	state
In-Reply-To: <1295824876.68.0.687534068337.issue10990@psf.upfronthosting.co.za>
Message-ID: <1296002137.16.0.0328950001482.issue10990@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

I have a patch that I am testing right now which deals which fixes all the test suites.

----------
assignee:  -> brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10990>
_______________________________________

From report at bugs.python.org  Wed Jan 26 01:58:51 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 26 Jan 2011 00:58:51 +0000
Subject: [issue9124] Mailbox module should use binary I/O, not text I/O
In-Reply-To: <1277900903.38.0.556015912714.issue9124@psf.upfronthosting.co.za>
Message-ID: <1296003531.34.0.697675959211.issue9124@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

mailbox.patch:
 - open files in binary mode not as text
 - parse as bytes not as Unicode
 - replace email.generator.Generator() by email.generator.BytesGenerator()
 - use .message_from_bytes() instead of .message_from_str()
 - use .message_from_binary_file() instead of .message_from_file()
 - use BytesIO() instead of StringIO()
 - add more methods to _ProxyFile: readable, writable, seekable, flush, closed
 - don't use universal newline (not supported by binary files): I don't remember if the email binary parser supports directly universal newline

I don't know anything about the mailbox module. I just replaced str functions by bytes functions.

Keep Unicode for some things: MH.get_sequence() reads the file using UTF-8 encoding, labels and sequences.

The patch have to be tested on Windows (Windows uses \r\n newline). I only tested on Linux.

----------
keywords: +patch
Added file: http://bugs.python.org/file20522/mailbox.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9124>
_______________________________________

From report at bugs.python.org  Wed Jan 26 02:04:12 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 26 Jan 2011 01:04:12 +0000
Subject: [issue9124] Mailbox module should use binary I/O, not text I/O
In-Reply-To: <1277900903.38.0.556015912714.issue9124@psf.upfronthosting.co.za>
Message-ID: <1296003852.73.0.451085982203.issue9124@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

While working on this issue, I found and fixed two bugs in the email binary parser: r88196 and r88197.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9124>
_______________________________________

From report at bugs.python.org  Wed Jan 26 03:10:32 2011
From: report at bugs.python.org (Geoge R. Goffe)
Date: Wed, 26 Jan 2011 02:10:32 +0000
Subject: [issue11013] Build of CVS version 2.7 fails in readline
In-Reply-To: <1296007832.48.0.816263940952.issue11013@psf.upfronthosting.co.za>
Message-ID: <1296007832.48.0.816263940952.issue11013@psf.upfronthosting.co.za>


New submission from Geoge R. Goffe <grgoffe at yahoo.com>:

Howdy,

I just updated my copy of the SVN version of 2.7 and got the following error messages. Did I do something wrong?

Regards,

George...

building dbm using bdb
building 'readline' extension
gcc -pthread -fPIC -fno-strict-aliasing -g -O2 -g -O0 -Wall -Wstrict-prototypes -I/usr/lsd/Linux/include -I. -IInclude -I./Include -I/usr/local/include -I/usr/local/google/tools/python/release27-maint/Include -I/usr/local/google/tools/python/release27-maint -c /usr/local/google/tools/python/release27-maint/Modules/readline.c -o build/temp.linux-x86_64-2.7-pydebug/usr/local/google/tools/python/release27-maint/Modules/readline.o
/usr/local/google/tools/python/release27-maint/Modules/readline.c: In function ?write_history_file?:
/usr/local/google/tools/python/release27-maint/Modules/readline.c:147: warning: implicit declaration of function ?history_truncate_file?
/usr/local/google/tools/python/release27-maint/Modules/readline.c: In function ?_py_free_history_entry?:
/usr/local/google/tools/python/release27-maint/Modules/readline.c:385: warning: passing argument 1 of ?free? discards qualifiers from pointer target type
/usr/include/stdlib.h:488: note: expected ?void *? but argument is of type ?const char *?
/usr/local/google/tools/python/release27-maint/Modules/readline.c: In function ?py_replace_history?:
/usr/local/google/tools/python/release27-maint/Modules/readline.c:436: warning: implicit declaration of function ?replace_history_entry?
/usr/local/google/tools/python/release27-maint/Modules/readline.c:436: warning: assignment makes pointer from integer without a cast
/usr/local/google/tools/python/release27-maint/Modules/readline.c: In function ?_py_get_history_length?:
/usr/local/google/tools/python/release27-maint/Modules/readline.c:523: error: ?HISTORY_STATE? undeclared (first use in this function)
/usr/local/google/tools/python/release27-maint/Modules/readline.c:523: error: (Each undeclared identifier is reported only once
/usr/local/google/tools/python/release27-maint/Modules/readline.c:523: error: for each function it appears in.)
/usr/local/google/tools/python/release27-maint/Modules/readline.c:523: error: ?hist_st? undeclared (first use in this function)
/usr/local/google/tools/python/release27-maint/Modules/readline.c:523: warning: implicit declaration of function ?history_get_history_state?
/usr/local/google/tools/python/release27-maint/Modules/readline.c: In function ?insert_text?:
/usr/local/google/tools/python/release27-maint/Modules/readline.c:628: warning: implicit declaration of function ?rl_insert_text?
/usr/local/google/tools/python/release27-maint/Modules/readline.c: In function ?flex_complete?:
/usr/local/google/tools/python/release27-maint/Modules/readline.c:847: error: ?rl_completion_suppress_append? undeclared (first use in this function)
/usr/local/google/tools/python/release27-maint/Modules/readline.c:853: warning: implicit declaration of function ?rl_completion_matches?
/usr/local/google/tools/python/release27-maint/Modules/readline.c:853: error: ?rl_compentry_func_t? undeclared (first use in this function)
/usr/local/google/tools/python/release27-maint/Modules/readline.c:853: error: expected expression before ?)? token
/usr/local/google/tools/python/release27-maint/Modules/readline.c: In function ?setup_readline?:
/usr/local/google/tools/python/release27-maint/Modules/readline.c:886: warning: passing argument 2 of ?rl_bind_key_in_map? from incompatible pointer type
/usr/lsd/Linux/include/readline/readline.h:195: note: expected ?int (*)(const char *, int)? but argument is of type ?int (*)(int,  int)?
/usr/local/google/tools/python/release27-maint/Modules/readline.c:887: warning: passing argument 2 of ?rl_bind_key_in_map? from incompatible pointer type
/usr/lsd/Linux/include/readline/readline.h:195: note: expected ?int (*)(const char *, int)? but argument is of type ?int (*)(int,  int)?
/usr/local/google/tools/python/release27-maint/Modules/readline.c: In function ?readline_until_enter_or_signal?:
/usr/local/google/tools/python/release27-maint/Modules/readline.c:940: error: ?rl_catch_signals? undeclared (first use in this function)
/usr/local/google/tools/python/release27-maint/Modules/readline.c:979: warning: implicit declaration of function ?rl_free_line_state?
/usr/local/google/tools/python/release27-maint/Modules/readline.c:980: warning: implicit declaration of function ?rl_cleanup_after_signal?

Python build finished, but the necessary bits to build these modules were not found:
bsddb185           dl                 gdbm            
imageop            sunaudiodev                        
To find the necessary bits, look in setup.py in detect_modules() for the module's name.


Failed to build these modules:
readline

----------
components: Build
messages: 127080
nosy: grgoffe at yahoo.com
priority: normal
severity: normal
status: open
title: Build of CVS version 2.7 fails in readline
type: compile error
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11013>
_______________________________________

From report at bugs.python.org  Wed Jan 26 03:12:31 2011
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 26 Jan 2011 02:12:31 +0000
Subject: [issue10990] tests mutating sys.gettrace() w/o re-instating previous
	state
In-Reply-To: <1295824876.68.0.687534068337.issue10990@psf.upfronthosting.co.za>
Message-ID: <1296007951.81.0.675873582931.issue10990@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

OK, here is a single patch (from `hg outgoing --patch`) that fixes all the tests by introducing the test.support.no_tracing decorator.

----------
Added file: http://bugs.python.org/file20523/trace_fxn_protected.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10990>
_______________________________________

From report at bugs.python.org  Wed Jan 26 03:12:43 2011
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 26 Jan 2011 02:12:43 +0000
Subject: [issue10990] tests mutating sys.gettrace() w/o re-instating previous
	state
In-Reply-To: <1295824876.68.0.687534068337.issue10990@psf.upfronthosting.co.za>
Message-ID: <1296007963.4.0.475221967537.issue10990@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


Removed file: http://bugs.python.org/file20498/sys_gettrace_monitor.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10990>
_______________________________________

From report at bugs.python.org  Wed Jan 26 03:12:48 2011
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 26 Jan 2011 02:12:48 +0000
Subject: [issue10990] tests mutating sys.gettrace() w/o re-instating previous
	state
In-Reply-To: <1295824876.68.0.687534068337.issue10990@psf.upfronthosting.co.za>
Message-ID: <1296007968.73.0.00980215396321.issue10990@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


Removed file: http://bugs.python.org/file20508/test_scope.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10990>
_______________________________________

From report at bugs.python.org  Wed Jan 26 03:12:52 2011
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 26 Jan 2011 02:12:52 +0000
Subject: [issue10990] tests mutating sys.gettrace() w/o re-instating previous
	state
In-Reply-To: <1295824876.68.0.687534068337.issue10990@psf.upfronthosting.co.za>
Message-ID: <1296007972.05.0.886991141024.issue10990@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


Removed file: http://bugs.python.org/file20509/test_sys_settrace.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10990>
_______________________________________

From report at bugs.python.org  Wed Jan 26 03:12:55 2011
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 26 Jan 2011 02:12:55 +0000
Subject: [issue10990] tests mutating sys.gettrace() w/o re-instating previous
	state
In-Reply-To: <1295824876.68.0.687534068337.issue10990@psf.upfronthosting.co.za>
Message-ID: <1296007975.05.0.984648741233.issue10990@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


Removed file: http://bugs.python.org/file20516/test_trace.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10990>
_______________________________________

From report at bugs.python.org  Wed Jan 26 03:12:58 2011
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 26 Jan 2011 02:12:58 +0000
Subject: [issue10990] tests mutating sys.gettrace() w/o re-instating previous
	state
In-Reply-To: <1295824876.68.0.687534068337.issue10990@psf.upfronthosting.co.za>
Message-ID: <1296007978.01.0.162214938594.issue10990@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


Removed file: http://bugs.python.org/file20517/test_gdb.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10990>
_______________________________________

From report at bugs.python.org  Wed Jan 26 03:13:01 2011
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 26 Jan 2011 02:13:01 +0000
Subject: [issue10990] tests mutating sys.gettrace() w/o re-instating previous
	state
In-Reply-To: <1295824876.68.0.687534068337.issue10990@psf.upfronthosting.co.za>
Message-ID: <1296007981.17.0.450831899893.issue10990@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


Removed file: http://bugs.python.org/file20518/test_doctest.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10990>
_______________________________________

From report at bugs.python.org  Wed Jan 26 03:13:04 2011
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 26 Jan 2011 02:13:04 +0000
Subject: [issue10990] tests mutating sys.gettrace() w/o re-instating previous
	state
In-Reply-To: <1295824876.68.0.687534068337.issue10990@psf.upfronthosting.co.za>
Message-ID: <1296007984.24.0.122338739029.issue10990@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


Removed file: http://bugs.python.org/file20519/test_zipimport_support.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10990>
_______________________________________

From report at bugs.python.org  Wed Jan 26 03:14:56 2011
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 26 Jan 2011 02:14:56 +0000
Subject: [issue11013] Build of  2.7 svn fails in readline
In-Reply-To: <1296007832.48.0.816263940952.issue11013@psf.upfronthosting.co.za>
Message-ID: <1296008096.74.0.276215716656.issue11013@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Did you try a `make distclean` before compiling?

----------
nosy: +brett.cannon
title: Build of CVS version 2.7 fails in readline -> Build of  2.7 svn fails in readline

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11013>
_______________________________________

From report at bugs.python.org  Wed Jan 26 03:23:52 2011
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 26 Jan 2011 02:23:52 +0000
Subject: [issue10990] tests mutating sys.gettrace() w/o re-instating previous
	state
In-Reply-To: <1295824876.68.0.687534068337.issue10990@psf.upfronthosting.co.za>
Message-ID: <1296008632.26.0.636469247317.issue10990@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


Removed file: http://bugs.python.org/file20523/trace_fxn_protected.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10990>
_______________________________________

From report at bugs.python.org  Wed Jan 26 03:27:27 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 26 Jan 2011 02:27:27 +0000
Subject: [issue11014] 'filter' argument for Tarfile.add needs to be a
	keyword-only argument
In-Reply-To: <1296008845.92.0.0968306232323.issue11014@psf.upfronthosting.co.za>
Message-ID: <1296008845.92.0.0968306232323.issue11014@psf.upfronthosting.co.za>


New submission from Raymond Hettinger <rhettinger at users.sourceforge.net>:

In 3.2, tarfile.Tarfile added a 'filter' argument while deprecating the 'exclude' argument that precedes it positionally.

The 'filter' argument needs to be keyword-only argument, or any code that uses it positionally will fail when the 'exclude' argument is ultimately removed.

----------
assignee: georg.brandl
components: Library (Lib)
files: tarfile.patch
keywords: patch
messages: 127083
nosy: georg.brandl, rhettinger
priority: high
severity: normal
stage: patch review
status: open
title: 'filter' argument for Tarfile.add needs to be a keyword-only argument
type: behavior
versions: Python 3.2
Added file: http://bugs.python.org/file20524/tarfile.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11014>
_______________________________________

From report at bugs.python.org  Wed Jan 26 03:27:28 2011
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 26 Jan 2011 02:27:28 +0000
Subject: [issue10990] tests mutating sys.gettrace() w/o re-instating previous
	state
In-Reply-To: <1295824876.68.0.687534068337.issue10990@psf.upfronthosting.co.za>
Message-ID: <1296008848.32.0.917794764594.issue10990@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

OK, here is an updated patch that fixes the introduced failure in test_sys_settrace. This should be ready to go for Python 3.3 once the tree opens up (unless someone reviews it and finds a problem).

----------
resolution:  -> accepted
stage:  -> patch review
versions:  -Python 3.2
Added file: http://bugs.python.org/file20525/trace_fxn_protected.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10990>
_______________________________________

From report at bugs.python.org  Wed Jan 26 03:42:00 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 26 Jan 2011 02:42:00 +0000
Subject: [issue11011] More functools functions
In-Reply-To: <1295994742.19.0.341586360497.issue11011@psf.upfronthosting.co.za>
Message-ID: <1296009720.73.0.140676542971.issue11011@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

For flip, const and identity I agree there are already better ways to handle them using either itertools or comprehension syntax.

The problem I have with trampoline is that it depends on the function's *return values* being defined in a certain way (i.e. returning a zero-argument callable instead of just calling them).

The other major factor limiting the appeal of some of the more complex functional programming tools (the one that almost lead to lambda's removal in 3.x) is the availability of nested function definitions.

To rephrase Raymond's last example in more idiomatic Python:

def fg2(x):
  # Comment or docstring explaining fg2
  return f(g(2,x)

def h2(x, y):
  # Comment or docstring explaining h2
  return h(x, 3, y, flag=True)

result = [fg2(x), h2(x, y) for x, y in zip(X, Y) if x>y//2]

I see compose as being the most potential useful, as it would allow us to provide a C accelerated version of the following alternative to trampoline:

def compose(*args):
  def _composed(x):
    for f in args:
      x = f(x)
    return x
  return _composed

While this actually does match the mathematical definition, I agree pointing that out is more confusing than helpful for many people (since the "inside-out" nested evaluation ends up looking like "right-to-left" evaluation when written down)

Raymond's proposed alternative to trampoline could then be written:

  compose(*get_actions())(x)

----------
nosy: +ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11011>
_______________________________________

From report at bugs.python.org  Wed Jan 26 03:46:09 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 26 Jan 2011 02:46:09 +0000
Subject: [issue11015] Bring test.support docs up to date
In-Reply-To: <1296009969.38.0.282241852849.issue11015@psf.upfronthosting.co.za>
Message-ID: <1296009969.38.0.282241852849.issue11015@psf.upfronthosting.co.za>


New submission from Nick Coghlan <ncoghlan at gmail.com>:

The test.support docs are there to help CPython devs with writing good unit tests more easily. There are a few additions we've made in recent years that haven't made it into the .rst file, so it is easy to miss useful tools if you don't go looking through the module source code.

There are some other helper modules (such as test.script_helper) that could also stand to be made easier to find.

Fixing this is just a matter of doing a pass through test.support and the test directory looking for things that might be worth mentioning in the test package docs.

----------
assignee: docs at python
keywords: easy
messages: 127086
nosy: docs at python, ncoghlan
priority: normal
severity: normal
stage: needs patch
status: open
title: Bring test.support docs up to date
type: behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11015>
_______________________________________

From report at bugs.python.org  Wed Jan 26 03:59:07 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 26 Jan 2011 02:59:07 +0000
Subject: [issue9124] Mailbox module should use binary I/O, not text I/O
In-Reply-To: <1277900903.38.0.556015912714.issue9124@psf.upfronthosting.co.za>
Message-ID: <1296010747.13.0.893096015138.issue9124@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Nice.  Thanks Victor.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9124>
_______________________________________

From report at bugs.python.org  Wed Jan 26 04:52:58 2011
From: report at bugs.python.org (Jason Baker)
Date: Wed, 26 Jan 2011 03:52:58 +0000
Subject: [issue11011] More functools functions
In-Reply-To: <1295994742.19.0.341586360497.issue11011@psf.upfronthosting.co.za>
Message-ID: <1296013978.17.0.320781243661.issue11011@psf.upfronthosting.co.za>


Jason Baker <amnorvend at gmail.com> added the comment:

I'm not sure I understand how Raymond's alternative for trampoline works.  Let's take the factorial algorithm from wikipedia's page on tail recursion[1].  I've implemented the tail recursive version of the algorithm in Python using trampoline:

    from functools import trampoline, partial

    def factorial(n):
        def fact(i, acc):
            if i:
                return partial(fact, (i-1), (acc * i))
            else:
                return acc
        return trampoline(fact, n, 1)

    >>> factorial(5)
    120


How would I implement this using Raymond's alternative?

[1] http://en.wikipedia.org/wiki/Tail_call#Example_programs

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11011>
_______________________________________

From report at bugs.python.org  Wed Jan 26 05:11:23 2011
From: report at bugs.python.org (R. David Murray)
Date: Wed, 26 Jan 2011 04:11:23 +0000
Subject: [issue9124] Mailbox module should use binary I/O, not text I/O
In-Reply-To: <1277900903.38.0.556015912714.issue9124@psf.upfronthosting.co.za>
Message-ID: <1296015083.08.0.961403687535.issue9124@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Thanks, Victor, you beat me to it :)  I'll see if I can review this tomorrow, or if not I can probably do it Thursday.

I reverted r88197 because it was incorrect and caused an email test to fail.  Once I come up with a test for it I'll fix it correctly.  I should write a test for the other one, too, even though it is trivial.

Just a note: being as we're in RC, you should get a review even for seemingly trivial fixes.

----------
nosy: +georg.brandl
priority: critical -> release blocker
stage: needs patch -> commit review
versions:  -Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9124>
_______________________________________

From report at bugs.python.org  Wed Jan 26 05:33:49 2011
From: report at bugs.python.org (Geoge R. Goffe)
Date: Wed, 26 Jan 2011 04:33:49 +0000
Subject: [issue11013] Build of  2.7 svn fails in readline
In-Reply-To: <1296008096.74.0.276215716656.issue11013@psf.upfronthosting.co.za>
Message-ID: <571559.62171.qm@web162002.mail.bf1.yahoo.com>


Geoge R. Goffe <grgoffe at yahoo.com> added the comment:

Brett,

THANKS for your response, it's appreciated.

Yes I did... I always do that. I use a more or less standard script to build 
software. I can send the script tomorrow if you would like to see it.

Regards and THANKS for your response.

George...

 "It's not what you know that hurts you, It's what you know that ain't so." Wil 
Rogers

________________________________
From: Brett Cannon <report at bugs.python.org>
To: grgoffe at yahoo.com
Sent: Tue, January 25, 2011 6:14:56 PM
Subject: [issue11013] Build of  2.7 svn fails in readline

Brett Cannon <brett at python.org> added the comment:

Did you try a `make distclean` before compiling?

----------
nosy: +brett.cannon
title: Build of CVS version 2.7 fails in readline -> Build of  2.7 svn fails in 
readline

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11013>
_______________________________________

----------
Added file: http://bugs.python.org/file20526/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11013>
_______________________________________
-------------- next part --------------
<html><head><style type="text/css"><!-- DIV {margin:0px;} --></style></head><body><div style="font-family:times new roman,new york,times,serif;font-size:12pt">Brett,<br><br>THANKS for your response, it's appreciated.<br><br>Yes I did... I always do that. I use a more or less standard script to build software. I can send the script tomorrow if you would like to see it.<br><br>Regards and THANKS for your response.<br><br>George...<br><div>&nbsp;</div>"It's not what you know that hurts you, It's what you know that ain't so." Wil Rogers<div><br></div><div style="font-family: times new roman,new york,times,serif; font-size: 12pt;"><br><div style="font-family: arial,helvetica,sans-serif; font-size: 13px;"><font face="Tahoma" size="2"><hr size="1"><b><span style="font-weight: bold;">From:</span></b> Brett Cannon &lt;report at bugs.python.org&gt;<br><b><span style="font-weight: bold;">To:</span></b> grgoffe at yahoo.com<br><b><span style="font-weight:
 bold;">Sent:</span></b> Tue, January 25, 2011 6:14:56 PM<br><b><span style="font-weight: bold;">Subject:</span></b> [issue11013] Build of  2.7 svn fails in readline<br></font><br>
<br>Brett Cannon &lt;<a ymailto="mailto:brett at python.org" href="mailto:brett at python.org">brett at python.org</a>&gt; added the comment:<br><br>Did you try a `make distclean` before compiling?<br><br>----------<br>nosy: +brett.cannon<br>title: Build of CVS version 2.7 fails in readline -&gt; Build of&nbsp; 2.7 svn fails in readline<br><br>_______________________________________<br>Python tracker &lt;<a ymailto="mailto:report at bugs.python.org" href="mailto:report at bugs.python.org">report at bugs.python.org</a>&gt;<br><span>&lt;<a target="_blank" href="http://bugs.python.org/issue11013">http://bugs.python.org/issue11013</a>&gt;</span><br>_______________________________________<br></div></div>
</div><br>

      </body></html>

From report at bugs.python.org  Wed Jan 26 07:00:42 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 26 Jan 2011 06:00:42 +0000
Subject: [issue11014] 'filter' argument for Tarfile.add needs to be a
	keyword-only argument
In-Reply-To: <1296008845.92.0.0968306232323.issue11014@psf.upfronthosting.co.za>
Message-ID: <1296021642.22.0.557341008575.issue11014@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Also note the 'filter' argument to the add() method is also in Py2.7 though it doesn't have the same issue of the preceding argument being deprecated.  For 2.7, I recommend adding a note to the docs and docstring to not use the 'filter' argument positionally; otherwise, there will be a minor 2-to-3 issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11014>
_______________________________________

From report at bugs.python.org  Wed Jan 26 10:14:41 2011
From: report at bugs.python.org (stan mihai)
Date: Wed, 26 Jan 2011 09:14:41 +0000
Subject: [issue8275] callback function on win64 results in bad behavior. mem
	corruption?
In-Reply-To: <1270061625.47.0.601780173179.issue8275@psf.upfronthosting.co.za>
Message-ID: <1296033281.13.0.729352884767.issue8275@psf.upfronthosting.co.za>


stan mihai <stanmihai4 at gmail.com> added the comment:

Disabling optimizations doesn't really fix the issue, just hides it, for now.

The problem was an uninitialized variable. Attached is the patch that fixes it.

----------
nosy: +stan.mihai
Added file: http://bugs.python.org/file20527/ctypes_win64.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8275>
_______________________________________

From report at bugs.python.org  Wed Jan 26 10:16:04 2011
From: report at bugs.python.org (stan mihai)
Date: Wed, 26 Jan 2011 09:16:04 +0000
Subject: [issue9884] The 4th parameter of method always None or 0 on x64
	Windows.
In-Reply-To: <1284714742.48.0.856656538994.issue9884@psf.upfronthosting.co.za>
Message-ID: <1296033364.46.0.503444469702.issue9884@psf.upfronthosting.co.za>


stan mihai <stanmihai4 at gmail.com> added the comment:

Disabling optimizations doesn't really fix the issue, just hides it, for now.

The problem was an uninitialized variable. Attached is the patch that fixes it.

----------
keywords: +patch
nosy: +stan.mihai
Added file: http://bugs.python.org/file20528/ctypes_win64.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9884>
_______________________________________

From report at bugs.python.org  Wed Jan 26 10:16:43 2011
From: report at bugs.python.org (stan mihai)
Date: Wed, 26 Jan 2011 09:16:43 +0000
Subject: [issue9266] ctypes "ValueError: NULL pointer access" on Win7 x64
In-Reply-To: <1279198550.56.0.12735266712.issue9266@psf.upfronthosting.co.za>
Message-ID: <1296033403.29.0.350026807613.issue9266@psf.upfronthosting.co.za>


stan mihai <stanmihai4 at gmail.com> added the comment:

The problem was an uninitialized variable. Attached is the patch that fixes it.

----------
keywords: +patch
nosy: +stan.mihai
Added file: http://bugs.python.org/file20529/ctypes_win64.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9266>
_______________________________________

From report at bugs.python.org  Wed Jan 26 10:18:22 2011
From: report at bugs.python.org (nooB)
Date: Wed, 26 Jan 2011 09:18:22 +0000
Subject: [issue10684] Folders get deleted when trying to change case with
	shutil.move (case insensitive file systems only)
In-Reply-To: <1292149124.13.0.45494559671.issue10684@psf.upfronthosting.co.za>
Message-ID: <1296033502.25.0.486518718824.issue10684@psf.upfronthosting.co.za>


nooB <nsharish.mit at gmail.com> added the comment:

Few points that could be useful,

1) I added print statements in `shutil.move` and found that the `real_dst` was wrong for the case coz os.path.isdir returns true.

>> import os
>> os.mkdir('test')
>> os.path.isdir('TEst')
True

In shutil.move, when we do shutil.move('test', 'TEst'), os.rename is actually applied to 'test' and 'TEst\test'. Thats why os.rename failed for the case in shutil.move.

2) os.rename has its own problems.

>> import os
>> os.mkdir('test')
>> os.rename('TEst', 'teST')

os.rename succeeded when the source 'TEst' did not exist.
Is this behaviour correct?.
This applies to shutil.move also.

>> import os,shutil
>> os.mkdir('test')
>> shutil.move('TEst', 'teST')

The folder 'test' gets deleted when trying to move 'TEst' to 'teST'. The case check should be done to the source argument also.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10684>
_______________________________________

From report at bugs.python.org  Wed Jan 26 10:35:59 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Wed, 26 Jan 2011 09:35:59 +0000
Subject: [issue11013] Build of  2.7 svn fails in readline
In-Reply-To: <1296007832.48.0.816263940952.issue11013@psf.upfronthosting.co.za>
Message-ID: <1296034559.21.0.960783253334.issue11013@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Please run

gcc -pthread -fPIC -fno-strict-aliasing -g -O2 -g -O0 -Wall -Wstrict-prototypes -I/usr/lsd/Linux/include -I. -IInclude -I./Include -I/usr/local/include -I/usr/local/google/tools/python/release27-maint/Include -I/usr/local/google/tools/python/release27-maint -c /usr/local/google/tools/python/release27-maint/Modules/readline.c -o build/temp.linux-x86_64-2.7-pydebug/usr/local/google/tools/python/release27-maint/Modules/readline.o --save-temps

and attach the resulting readline.i to this report (compressed if necessary).

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11013>
_______________________________________

From report at bugs.python.org  Wed Jan 26 11:00:29 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 26 Jan 2011 10:00:29 +0000
Subject: [issue9124] Mailbox module should use binary I/O, not text I/O
In-Reply-To: <1277900903.38.0.556015912714.issue9124@psf.upfronthosting.co.za>
Message-ID: <1296036029.66.0.291715472733.issue9124@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> I reverted r88197 because it was incorrect and caused an email test
> to fail. Once I come up with a test for it I'll fix it correctly.

test_mailbox is a good (indirect) test suite for this change. The problem of r88197 is that it replaces msg._payload by msg.get_payload() which is wrong. New attached patch mailbox.patch	keeps msg._payload unchanged, but don't call _has_surrogates() (do nothing) if msg._payload is None. This patch has no test, I'm unable to write a test for this case (directly with the email API).

----------
Added file: http://bugs.python.org/file20530/BytesGenerator_handle_text.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9124>
_______________________________________

From report at bugs.python.org  Wed Jan 26 11:41:18 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Wed, 26 Jan 2011 10:41:18 +0000
Subject: [issue10826] pass_fds sometimes fails
In-Reply-To: <1294152290.71.0.646502628705.issue10826@psf.upfronthosting.co.za>
Message-ID: <1296038478.44.0.445705009156.issue10826@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

'D' denotes a door file. There are several of them in the system; the following ones (from /var/run) match the time stamp:

Dr--r--r--   1 daemon   daemon         0 Mar 27  2010 kcfd_door
Dr--r--r--   1 root     root           0 Mar 27  2010 name_service_door
Dr--r--r--   1 root     root           0 Mar 27  2010 picld_door
Drw-r--r--   1 root     root           0 Mar 27  2010 syslog_door

It's common for library routines to open a door and keep it open for the entire process lifetime.

If this was somehow reproducible, I could try to find out what specific door gets opened.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10826>
_______________________________________

From report at bugs.python.org  Wed Jan 26 11:48:10 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 26 Jan 2011 10:48:10 +0000
Subject: [issue10826] pass_fds sometimes fails
In-Reply-To: <1296038478.44.0.445705009156.issue10826@psf.upfronthosting.co.za>
Message-ID: <1296038886.3684.5.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> 'D' denotes a door file. There are several of them in the system; the
> following ones (from /var/run) match the time stamp:

Thanks for the explanation!

> It's common for library routines to open a door and keep it open for
> the entire process lifetime.
> 
> If this was somehow reproducible, I could try to find out what
> specific door gets opened.

test_subprocess fails quite often on your buildbot, so with a bit of
patience you can probably reproduce it for sure. If you use "-r
--randseed 2463396" it will schedule test_subprocess quite early, so you
can stop the test run as soon as that test is finished.

Also, debug output has been added in branches/test_subprocess_10826 :

http://www.python.org/dev/buildbot/all/builders/sparc%20solaris10%20gcc%203.x/builds/2574/steps/test/logs/stdio

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10826>
_______________________________________

From report at bugs.python.org  Wed Jan 26 11:57:26 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 26 Jan 2011 10:57:26 +0000
Subject: [issue11016] Add S_ISDOOR to the stat module
In-Reply-To: <1296039446.69.0.66523737586.issue11016@psf.upfronthosting.co.za>
Message-ID: <1296039446.69.0.66523737586.issue11016@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

Solaris has an additional kind of special files named doors. The standard headers define the following macro:

#define      S_ISDOOR(mode)  (((mode)&0xF000) == 0xd000)

Perhaps it would be nice to include the equivalent in the stat module.

(although funnily even the "stat" command doesn't recognize them and displayed "weird file" instead:

$ stat /var/run/syslog_door 
  File: `/var/run/syslog_door'
  Size: 0               Blocks: 0          IO Block: 0      weird file
Device: 8bc0000h/146538496d     Inode: 44          Links: 1
Access: (0644/Drw-r--r--)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2011-01-26 11:52:34.332492612 +0100
Modify: 2011-01-26 11:52:34.332492612 +0100
Change: 2011-01-26 11:52:34.332499428 +0100
)

----------
components: Library (Lib)
messages: 127100
nosy: jcea, loewis, movement, pitrou
priority: normal
severity: normal
status: open
title: Add S_ISDOOR to the stat module
type: feature request
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11016>
_______________________________________

From report at bugs.python.org  Wed Jan 26 12:55:46 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Wed, 26 Jan 2011 11:55:46 +0000
Subject: [issue9124] Mailbox module should use binary I/O, not text I/O
In-Reply-To: <1277900903.38.0.556015912714.issue9124@psf.upfronthosting.co.za>
Message-ID: <1296042946.5.0.504670864743.issue9124@psf.upfronthosting.co.za>


Steffen Daode Nurpmeso <sdaoden at googlemail.com> added the comment:

This message will not help anyone.
And it's not a chat, but because it seems i really made the horses gone
grazy (direct translation of a german proverb):
- msg127002: RDM, i didn't know all of that and i am really sorry.
  Now I am looking forward to do something good for montys,
  but the truth is: today i ain't able to (yet), because i am so god
  damned re-new to python(1) (16 days today including weekends)!
  My local fix *was indeed already* just using encoding=latin1, which,
  by the way, decreased CPU usage of parsing a 150KB archive mbox from
  4 minutes (!) to about 50 seconds (dumping is a tenth in both cases).
  And it did not fail due to conversion errors, too.
msg127078: haypo, thank you!  I couldn't have done all of this, being
  so far away from the great picture of python encoding internals.
msg127036: RH, "people like Steffen" do the camel-walk!
  *This* is slow!!
  But once i've realized that mailbox.py is a dead-end on Py3K
  (for shipping out of my really useless, brutally simple current
  S-Postman script thing), i would have been much happier if a simple
  sentence like "python3 uptake process in transition" would have
  warned me (in whatever RST output).
Thanks for reading this book in a bug tracker.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9124>
_______________________________________

From report at bugs.python.org  Wed Jan 26 12:58:40 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 26 Jan 2011 11:58:40 +0000
Subject: [issue11011] More functools functions
In-Reply-To: <1295994742.19.0.341586360497.issue11011@psf.upfronthosting.co.za>
Message-ID: <1296043120.62.0.400647292223.issue11011@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

How the conversion from a recursive algorithm to an iterative one works depends on the specific algorithm involved. A trampoline does the job for tail calls, but not necessarily any other recursive algorithm.

Factorial actually has a fairly trivial iterative algorithm, so it isn't a great example for general purpose algorithm conversion:

def factorial(x):
  result = 1
  for i in range(1, x+1):
    result *= i
  return result

I believe having trampoline in functools would end up being something of an attractive nuisance - in cases where it applies, there are probably better, algorithm specific, ways of eliminating a recursive call.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11011>
_______________________________________

From report at bugs.python.org  Wed Jan 26 13:13:14 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Wed, 26 Jan 2011 12:13:14 +0000
Subject: [issue11016] Add S_ISDOOR to the stat module
In-Reply-To: <1296039446.69.0.66523737586.issue11016@psf.upfronthosting.co.za>
Message-ID: <1296043994.56.0.507860823505.issue11016@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

Thanks for the feature request. It seems trivial to implement, but not trivial to test :).

I assign this to myself. I will work on it after Mercurial migration is finished. Getting impatient :).

----------
assignee:  -> jcea

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11016>
_______________________________________

From report at bugs.python.org  Wed Jan 26 13:19:27 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 26 Jan 2011 12:19:27 +0000
Subject: [issue9124] Mailbox module should use binary I/O, not text I/O
In-Reply-To: <1277900903.38.0.556015912714.issue9124@psf.upfronthosting.co.za>
Message-ID: <1296044367.31.0.519698120316.issue9124@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

All test_email and test_mailbox pass with mailbox.patch+BytesGenerator_handle_text.patch on Windows except one test:

======================================================================
ERROR: test_set_item (test.test_mailbox.TestBabyl)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "C:\victor\py3k\lib\test\test_mailbox.py", line 286, in test_set_item
    self._check_sample(self._box[key1])
  File "C:\victor\py3k\lib\mailbox.py", line 76, in __getitem__
    return self.get_message(key)
  File "C:\victor\py3k\lib\mailbox.py", line 1190, in get_message
    body = self._file.read(stop - self._file.tell())
ValueError: read length must be positive or -1

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9124>
_______________________________________

From report at bugs.python.org  Wed Jan 26 13:19:57 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 26 Jan 2011 12:19:57 +0000
Subject: [issue11016] Add S_ISDOOR to the stat module
In-Reply-To: <1296043994.56.0.507860823505.issue11016@psf.upfronthosting.co.za>
Message-ID: <1296044393.3684.6.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Thanks for the feature request. It seems trivial to implement, but not trivial to test :).

You can test against an existing file, such as "/var/run/syslog_door"
(given its name, it is unlikely to be anything other than a door)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11016>
_______________________________________

From report at bugs.python.org  Wed Jan 26 13:29:24 2011
From: report at bugs.python.org (hensing)
Date: Wed, 26 Jan 2011 12:29:24 +0000
Subject: [issue11017] optparse: error: invalid integer value
In-Reply-To: <1296044964.44.0.826782436299.issue11017@psf.upfronthosting.co.za>
Message-ID: <1296044964.44.0.826782436299.issue11017@psf.upfronthosting.co.za>


New submission from hensing <h.dickten at gmx.net>:

OptionParser can't parse int "08" and "09". "8", "9" and "01..07" works.

----------
components: Library (Lib)
files: minimal.py
messages: 127106
nosy: hensing
priority: normal
severity: normal
status: open
title: optparse: error: invalid integer value
type: crash
versions: Python 2.6
Added file: http://bugs.python.org/file20531/minimal.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11017>
_______________________________________

From report at bugs.python.org  Wed Jan 26 13:30:30 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Wed, 26 Jan 2011 12:30:30 +0000
Subject: [issue11016] Add S_ISDOOR to the stat module
In-Reply-To: <1296039446.69.0.66523737586.issue11016@psf.upfronthosting.co.za>
Message-ID: <1296045030.55.0.492262221105.issue11016@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

I do know, but when you are working inside a zone, I am not sure you can count of that file being always present. Syslog even could be disabled or not available inside a zone.

I am thinking about how to manage OS's with no support for doors. Instead of conditionally compile the new STAT, I would rather have the function always available, but returning FALSE when the OS doesn't support doors. But what happen if you mount a Solaris filesystem in a nonsolaris machine?. Let say, a Solaris ZFS filesystem with doors, under linux/*bsd + ZFS?.

So maybe would be better to not compile that function in those OS's, instead of "lying" in corner cases.

Not decided yet. I accept ideas.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11016>
_______________________________________

From report at bugs.python.org  Wed Jan 26 13:41:12 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 26 Jan 2011 12:41:12 +0000
Subject: [issue11016] Add S_ISDOOR to the stat module
In-Reply-To: <1296045030.55.0.492262221105.issue11016@psf.upfronthosting.co.za>
Message-ID: <1296045471.3684.21.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> I do know, but when you are working inside a zone, I am not sure you
> can count of that file being always present. Syslog even could be
> disabled or not available inside a zone.

Then you can just skip the test.

> I am thinking about how to manage OS's with no support for doors.
> Instead of conditionally compile the new STAT,

Lib/stat.py is a pure Python module. There is no compilation to do.
You just have to add the pure Python version of the C macro.
For the record, 0xd000 is (stat.S_IFSOCK + stat.S_IFIFO).

> I would rather have the function always available, but returning FALSE
> when the OS doesn't support doors.

Right.

> But what happen if you mount a Solaris filesystem in a nonsolaris
> machine?. Let say, a Solaris ZFS filesystem with doors, under
> linux/*bsd + ZFS?.

I guess S_ISDOOR would return True.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11016>
_______________________________________

From report at bugs.python.org  Wed Jan 26 13:45:06 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 26 Jan 2011 12:45:06 +0000
Subject: [issue11017] optparse: error: invalid integer value
In-Reply-To: <1296044964.44.0.826782436299.issue11017@psf.upfronthosting.co.za>
Message-ID: <1296045906.66.0.297024313722.issue11017@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

08 is not a valid octal number.  See http://docs.python.org/library/optparse#standard-option-types and http://docs.python.org/reference/lexical_analysis#integer-and-long-integer-literals

Hope this helps.

----------
nosy: +eric.araujo
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed
type: crash -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11017>
_______________________________________

From report at bugs.python.org  Wed Jan 26 14:03:38 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Wed, 26 Jan 2011 13:03:38 +0000
Subject: [issue11016] Add S_ISDOOR to the stat module
In-Reply-To: <1296039446.69.0.66523737586.issue11016@psf.upfronthosting.co.za>
Message-ID: <1296047018.27.0.243760636214.issue11016@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

Given the behaviour of Solaris DOORS, the flags selected are very cleverly chosen. Sensible engineering :).

But now I am wondering... Which organization defines flags like S_IFSOCK or S_IFIFO?. Posix members?. I am worried about flag collision between OSs.

For instance, if DOORS were a real flag defined in Solaris, how other OSs would know to not reuse that flag for some other purpose? :).

Your comment is very valuable and solve my doubts about it. Implementation is truly trivial and could be supported everywhere.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11016>
_______________________________________

From report at bugs.python.org  Wed Jan 26 14:07:00 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 26 Jan 2011 13:07:00 +0000
Subject: [issue11016] Add S_ISDOOR to the stat module
In-Reply-To: <1296047018.27.0.243760636214.issue11016@psf.upfronthosting.co.za>
Message-ID: <1296047217.3684.24.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> But now I am wondering... Which organization defines flags like
> S_IFSOCK or S_IFIFO?. Posix members?. I am worried about flag
> collision between OSs.

They are defined unconditionally in Lib/stat.py.

> For instance, if DOORS were a real flag defined in Solaris, how other
> OSs would know to not reuse that flag for some other purpose? :).

Which flag? S_ISDOOR uses an (unlikely) combination of existing flags.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11016>
_______________________________________

From report at bugs.python.org  Wed Jan 26 14:07:13 2011
From: report at bugs.python.org (hensing)
Date: Wed, 26 Jan 2011 13:07:13 +0000
Subject: [issue11017] optparse: error: invalid integer value
In-Reply-To: <1296044964.44.0.826782436299.issue11017@psf.upfronthosting.co.za>
Message-ID: <1296047233.51.0.994874831103.issue11017@psf.upfronthosting.co.za>


hensing <h.dickten at gmx.net> added the comment:

Shouldn't it be better to parse only numbers with prefix "0o" "0o72" as an octal number?

So it would be consistent to hex and bin (0x and 0b).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11017>
_______________________________________

From report at bugs.python.org  Wed Jan 26 14:07:40 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 26 Jan 2011 13:07:40 +0000
Subject: [issue11017] optparse: error: invalid integer value
In-Reply-To: <1296044964.44.0.826782436299.issue11017@psf.upfronthosting.co.za>
Message-ID: <1296047260.92.0.284437895229.issue11017@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

That change has been done in Python 3.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11017>
_______________________________________

From report at bugs.python.org  Wed Jan 26 14:14:33 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Wed, 26 Jan 2011 13:14:33 +0000
Subject: [issue11016] Add S_ISDOOR to the stat module
In-Reply-To: <1296039446.69.0.66523737586.issue11016@psf.upfronthosting.co.za>
Message-ID: <1296047673.19.0.829299043348.issue11016@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

Antoine, I am not talking about python, I am talking about the UNIX standarization process. In particular, how a new flag (for filesystems) in an OS can be "skipped" and not being reused for some other purpuse in other OS.

Off topic for python, but curious to know anyway :).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11016>
_______________________________________

From report at bugs.python.org  Wed Jan 26 14:33:07 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 26 Jan 2011 13:33:07 +0000
Subject: [issue5863] bz2.BZ2File should accept other file-like objects.
In-Reply-To: <1296000439.45.0.320087924509.issue5863@psf.upfronthosting.co.za>
Message-ID: <1296048784.3684.32.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> * The read*() methods are implemented very inefficiently. Since they
> have to deal with the bytes objects returned by
> BZ2Decompressor.decompress(), a large read results in lots of
> allocations that weren't necessary in the C implementation.

It probably depends on the buffer size. Trying to fix this /might/ be
premature optimization.

Also, as with GzipFile one goal should be for BZFile to be wrappable in
a io.BufferedReader, which has its own very fast buffering layer (and
also a fast readline() if you implement peek() in BZFile).

> * Fixed a typo in test_bz2's testReadChunk10() that caused the test to
> pass regardless of whether the data read was correct
> (self.assertEqual(text, text) -> self.assertEqual(text, self.TEXT)).
> This one might be worth committing now, since it isn't dependent on
> the rewrite.

Ah, thank you. Will take a look.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5863>
_______________________________________

From report at bugs.python.org  Wed Jan 26 14:36:59 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 26 Jan 2011 13:36:59 +0000
Subject: [issue11018] typo in test_bz2
In-Reply-To: <1296049019.27.0.765900313708.issue11018@psf.upfronthosting.co.za>
Message-ID: <1296049019.27.0.765900313708.issue11018@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

This was found by Nadeem in issue5863.

Index: Lib/test/test_bz2.py
===================================================================
--- Lib/test/test_bz2.py	(r?vision 88199)
+++ Lib/test/test_bz2.py	(copie de travail)
@@ -86,7 +86,7 @@
                 if not str:
                     break
                 text += str
-            self.assertEqual(text, text)
+            self.assertEqual(text, self.TEXT)
 
     def testRead100(self):
         # "Test BZ2File.read(100)"

----------
components: Tests
messages: 127116
nosy: georg.brandl, pitrou
priority: normal
severity: normal
stage: patch review
status: open
title: typo in test_bz2
type: behavior
versions: Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11018>
_______________________________________

From report at bugs.python.org  Wed Jan 26 15:07:56 2011
From: report at bugs.python.org (John Levon)
Date: Wed, 26 Jan 2011 14:07:56 +0000
Subject: [issue11016] Add S_ISDOOR to the stat module
In-Reply-To: <1296039446.69.0.66523737586.issue11016@psf.upfronthosting.co.za>
Message-ID: <1296050876.13.0.37253675634.issue11016@psf.upfronthosting.co.za>


John Levon <movement at users.sourceforge.net> added the comment:

Jesus, yes, it's totally possible that POSIX might define:

(stat.S_IFSOCK + stat.S_IFIFO)

to mean something other than S_IDOOR. However, the POSIX committee
is always careful to respect existing usage. It's vanishingly unlikely
that any attempt to do this would actually happen, since it would
be obviously unimplementable on the most popular UNIX (namely Solaris).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11016>
_______________________________________

From report at bugs.python.org  Wed Jan 26 15:12:26 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Wed, 26 Jan 2011 14:12:26 +0000
Subject: [issue11018] typo in test_bz2
In-Reply-To: <1296049019.27.0.765900313708.issue11018@psf.upfronthosting.co.za>
Message-ID: <1296051146.89.0.730124256813.issue11018@psf.upfronthosting.co.za>


Changes by Nadeem Vawda <nadeem.vawda at gmail.com>:


----------
nosy: +nvawda

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11018>
_______________________________________

From report at bugs.python.org  Wed Jan 26 15:19:50 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Wed, 26 Jan 2011 14:19:50 +0000
Subject: [issue11016] Add S_ISDOOR to the stat module
In-Reply-To: <1296039446.69.0.66523737586.issue11016@psf.upfronthosting.co.za>
Message-ID: <1296051590.45.0.794912192743.issue11016@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

I am looking at Linux :-).

Anyway the feedback has been very useful. I will implement this as soon as mercurial switch is done.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11016>
_______________________________________

From report at bugs.python.org  Wed Jan 26 15:21:13 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 26 Jan 2011 14:21:13 +0000
Subject: [issue9124] Mailbox module should use binary I/O, not text I/O
In-Reply-To: <1277900903.38.0.556015912714.issue9124@psf.upfronthosting.co.za>
Message-ID: <1296051673.31.0.331519830235.issue9124@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

There's a missing conversion in mailbox.patch. Running with -bb shows the issue. Here is an updated patch.

----------
Added file: http://bugs.python.org/file20532/mailbox2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9124>
_______________________________________

From report at bugs.python.org  Wed Jan 26 16:04:01 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Wed, 26 Jan 2011 15:04:01 +0000
Subject: [issue5863] bz2.BZ2File should accept other file-like objects.
In-Reply-To: <1240898269.47.0.592056792771.issue5863@psf.upfronthosting.co.za>
Message-ID: <1296054241.96.0.184635002178.issue5863@psf.upfronthosting.co.za>


Nadeem Vawda <nadeem.vawda at gmail.com> added the comment:

>> * The read*() methods are implemented very inefficiently. Since they
>> have to deal with the bytes objects returned by
>> BZ2Decompressor.decompress(), a large read results in lots of
>> allocations that weren't necessary in the C implementation.
>
> It probably depends on the buffer size. Trying to fix this /might/ be
> premature optimization.

Actually, looking at the code again (and not being half-asleep this time), I
think readline() and readlines() are fine. My worry is about read(), where the
problem isn't the size of the buffer but rather the fact that every byte that is
read gets copied around more than necessary:
* Read into the readahead buffer in _fill_readahead().
* Copy into 'data' in _read_block()
* Copy into newly-allocated bytes object for read()'s return value

But you're right; this is probably premature optimization. I'll do some proper
performance measurements before I jump into rewriting. In the meanwhile, FWIW,
I noticed that with the Python implementation, test_bz2 took 20% longer than
with my C implementation (~1.5s up from ~1.25s). I don't think this is a very
reliable indicator of real-world performance, though.

> Also, as with GzipFile one goal should be for BZFile to be wrappable in
> a io.BufferedReader, which has its own very fast buffering layer (and
> also a fast readline() if you implement peek() in BZFile).

Ah, OK. I suppose that is a sensible way of using it. peek() will be quite easy
to implement. How should it interpret its argument, though? PEP3116 (New I/O)
makes no mention of the function. BufferedReader appears to ignore it and
return however much data is convenient.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5863>
_______________________________________

From report at bugs.python.org  Wed Jan 26 16:10:24 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 26 Jan 2011 15:10:24 +0000
Subject: [issue8275] callback function on win64 results in bad behavior. mem
	corruption?
In-Reply-To: <1270061625.47.0.601780173179.issue8275@psf.upfronthosting.co.za>
Message-ID: <1296054624.12.0.666031344117.issue8275@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Would it be possible to add a test case to the patch?

----------
nosy: +georg.brandl, pitrou
stage:  -> patch review
type: behavior -> crash
versions: +Python 3.1, Python 3.2 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8275>
_______________________________________

From report at bugs.python.org  Wed Jan 26 16:51:26 2011
From: report at bugs.python.org (Brian Curtin)
Date: Wed, 26 Jan 2011 15:51:26 +0000
Subject: [issue6926] socket module missing IPPROTO_IPV6, IPPROTO_IPV4
In-Reply-To: <1253143086.64.0.131724035197.issue6926@psf.upfronthosting.co.za>
Message-ID: <1296057086.7.0.976118450378.issue6926@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
nosy: +brian.curtin

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6926>
_______________________________________

From report at bugs.python.org  Wed Jan 26 17:56:58 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 26 Jan 2011 16:56:58 +0000
Subject: [issue11007] stack tracebacks should give the relevant class name
In-Reply-To: <1295968345.3.0.31737747868.issue11007@psf.upfronthosting.co.za>
Message-ID: <1296061018.18.0.354695089989.issue11007@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

trace.py has a hack for this: it uses gc.get_referrers() to crawl back from the code object to the encloding class.
I would not trust this gc.get_referrers() though; it is probably slow, and there are even some crashers related to this function; I would not like it to be called on every traceback.

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11007>
_______________________________________

From report at bugs.python.org  Wed Jan 26 18:39:11 2011
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 26 Jan 2011 17:39:11 +0000
Subject: [issue11013] Build of  2.7 svn fails in readline
In-Reply-To: <1296007832.48.0.816263940952.issue11013@psf.upfronthosting.co.za>
Message-ID: <1296063551.8.0.0183793552267.issue11013@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


Removed file: http://bugs.python.org/file20526/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11013>
_______________________________________

From report at bugs.python.org  Wed Jan 26 18:39:19 2011
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 26 Jan 2011 17:39:19 +0000
Subject: [issue11013] Build of  2.7 svn fails in readline
In-Reply-To: <1296007832.48.0.816263940952.issue11013@psf.upfronthosting.co.za>
Message-ID: <1296063559.14.0.591316189142.issue11013@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11013>
_______________________________________

From report at bugs.python.org  Wed Jan 26 18:39:31 2011
From: report at bugs.python.org (David Stanek)
Date: Wed, 26 Jan 2011 17:39:31 +0000
Subject: [issue8036] Interpreter crashes on invalid arg to spawnl on Windows
In-Reply-To: <1267477949.48.0.216202239381.issue8036@psf.upfronthosting.co.za>
Message-ID: <1296063571.06.0.303204901909.issue8036@psf.upfronthosting.co.za>


David Stanek <dstanek at dstanek.com> added the comment:

Should this just be resolved as a "won't fix"?

----------
nosy: +dstanek

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8036>
_______________________________________

From report at bugs.python.org  Wed Jan 26 18:43:41 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 26 Jan 2011 17:43:41 +0000
Subject: [issue8036] Interpreter crashes on invalid arg to spawnl on Windows
In-Reply-To: <1267477949.48.0.216202239381.issue8036@psf.upfronthosting.co.za>
Message-ID: <1296063821.99.0.922354354805.issue8036@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

No, the issue can be fixed by better checking the arguments.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8036>
_______________________________________

From report at bugs.python.org  Wed Jan 26 18:51:51 2011
From: report at bugs.python.org (David Stanek)
Date: Wed, 26 Jan 2011 17:51:51 +0000
Subject: [issue6584] gzip module has no custom exception
In-Reply-To: <1248675050.27.0.747048824781.issue6584@psf.upfronthosting.co.za>
Message-ID: <1296064311.57.0.116245614124.issue6584@psf.upfronthosting.co.za>


Changes by David Stanek <dstanek at dstanek.com>:


----------
nosy: +dstanek

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6584>
_______________________________________

From report at bugs.python.org  Wed Jan 26 18:52:50 2011
From: report at bugs.python.org (David Stanek)
Date: Wed, 26 Jan 2011 17:52:50 +0000
Subject: [issue8025] TypeError: string argument expected, got 'str'
In-Reply-To: <1267200716.31.0.22497398995.issue8025@psf.upfronthosting.co.za>
Message-ID: <1296064370.68.0.446647435701.issue8025@psf.upfronthosting.co.za>


Changes by David Stanek <dstanek at dstanek.com>:


----------
nosy: +dstanek

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8025>
_______________________________________

From report at bugs.python.org  Wed Jan 26 18:53:06 2011
From: report at bugs.python.org (David Stanek)
Date: Wed, 26 Jan 2011 17:53:06 +0000
Subject: [issue7659] Attribute assignment on object() instances raises wrong
	exception
In-Reply-To: <1262968332.68.0.476240777656.issue7659@psf.upfronthosting.co.za>
Message-ID: <1296064386.18.0.7448913468.issue7659@psf.upfronthosting.co.za>


Changes by David Stanek <dstanek at dstanek.com>:


----------
nosy: +dstanek

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7659>
_______________________________________

From report at bugs.python.org  Wed Jan 26 18:54:16 2011
From: report at bugs.python.org (David Stanek)
Date: Wed, 26 Jan 2011 17:54:16 +0000
Subject: [issue4492] httplib code thinks it closes connection, but does not
In-Reply-To: <1228241719.92.0.946688230988.issue4492@psf.upfronthosting.co.za>
Message-ID: <1296064456.04.0.443726686661.issue4492@psf.upfronthosting.co.za>


Changes by David Stanek <dstanek at dstanek.com>:


----------
nosy: +dstanek

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4492>
_______________________________________

From report at bugs.python.org  Wed Jan 26 18:54:27 2011
From: report at bugs.python.org (David Stanek)
Date: Wed, 26 Jan 2011 17:54:27 +0000
Subject: [issue2007] cookielib lacks FileCookieJar class for Internet Explorer
In-Reply-To: <1202153753.42.0.88577975251.issue2007@psf.upfronthosting.co.za>
Message-ID: <1296064467.3.0.0755900209874.issue2007@psf.upfronthosting.co.za>


Changes by David Stanek <dstanek at dstanek.com>:


----------
nosy: +dstanek

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2007>
_______________________________________

From report at bugs.python.org  Wed Jan 26 18:54:34 2011
From: report at bugs.python.org (David Stanek)
Date: Wed, 26 Jan 2011 17:54:34 +0000
Subject: [issue9233] json.load failure when C optimizations aren't built
In-Reply-To: <1278949665.57.0.214129757073.issue9233@psf.upfronthosting.co.za>
Message-ID: <1296064474.5.0.246539384734.issue9233@psf.upfronthosting.co.za>


Changes by David Stanek <dstanek at dstanek.com>:


----------
nosy: +dstanek

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9233>
_______________________________________

From report at bugs.python.org  Wed Jan 26 18:54:40 2011
From: report at bugs.python.org (David Stanek)
Date: Wed, 26 Jan 2011 17:54:40 +0000
Subject: [issue3849] FUD in documentation for urllib.urlopen()
In-Reply-To: <1221246343.23.0.128587140594.issue3849@psf.upfronthosting.co.za>
Message-ID: <1296064480.87.0.201561735955.issue3849@psf.upfronthosting.co.za>


Changes by David Stanek <dstanek at dstanek.com>:


----------
nosy: +dstanek

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3849>
_______________________________________

From report at bugs.python.org  Wed Jan 26 18:55:35 2011
From: report at bugs.python.org (David Stanek)
Date: Wed, 26 Jan 2011 17:55:35 +0000
Subject: [issue5097] asyncore.dispatcher_with_send undocumented
In-Reply-To: <1233235235.33.0.24123597522.issue5097@psf.upfronthosting.co.za>
Message-ID: <1296064535.51.0.735697388968.issue5097@psf.upfronthosting.co.za>


Changes by David Stanek <dstanek at dstanek.com>:


----------
nosy: +dstanek

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5097>
_______________________________________

From report at bugs.python.org  Wed Jan 26 18:56:01 2011
From: report at bugs.python.org (David Stanek)
Date: Wed, 26 Jan 2011 17:56:01 +0000
Subject: [issue8743] set() operators don't work with collections.Set instances
In-Reply-To: <1274122246.37.0.692277131409.issue8743@psf.upfronthosting.co.za>
Message-ID: <1296064561.79.0.61119913577.issue8743@psf.upfronthosting.co.za>


Changes by David Stanek <dstanek at dstanek.com>:


----------
nosy: +dstanek

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8743>
_______________________________________

From report at bugs.python.org  Wed Jan 26 18:57:42 2011
From: report at bugs.python.org (David Stanek)
Date: Wed, 26 Jan 2011 17:57:42 +0000
Subject: [issue7100] test_xmlrpc: global name 'stop_serving' is not defined
In-Reply-To: <1255207170.52.0.845543632042.issue7100@psf.upfronthosting.co.za>
Message-ID: <1296064662.19.0.480616535543.issue7100@psf.upfronthosting.co.za>


Changes by David Stanek <dstanek at dstanek.com>:


----------
nosy: +dstanek

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7100>
_______________________________________

From report at bugs.python.org  Wed Jan 26 18:58:46 2011
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 26 Jan 2011 17:58:46 +0000
Subject: [issue11018] typo in test_bz2
In-Reply-To: <1296049019.27.0.765900313708.issue11018@psf.upfronthosting.co.za>
Message-ID: <1296064726.41.0.542997304679.issue11018@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Patch looks good to me.

----------
assignee:  -> pitrou
nosy: +brett.cannon
resolution:  -> accepted
stage: patch review -> commit review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11018>
_______________________________________

From report at bugs.python.org  Wed Jan 26 19:09:26 2011
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 26 Jan 2011 18:09:26 +0000
Subject: [issue763708] Failures in test_macostools for --enable-unicode=ucs4
Message-ID: <1296065366.1.0.0356982821142.issue763708@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Since the whole Mac directory got gutted in the switch over to Python 3, macostools is now gone, making this out of date.

----------
resolution:  -> out of date
status: languishing -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue763708>
_______________________________________

From report at bugs.python.org  Wed Jan 26 19:12:39 2011
From: report at bugs.python.org (Christoph Gohlke)
Date: Wed, 26 Jan 2011 18:12:39 +0000
Subject: [issue8275] callback function on win64 results in bad behavior. mem
	corruption?
In-Reply-To: <1270061625.47.0.601780173179.issue8275@psf.upfronthosting.co.za>
Message-ID: <1296065559.85.0.976922586258.issue8275@psf.upfronthosting.co.za>


Christoph Gohlke <cgohlke at uci.edu> added the comment:

Thank you. The new patch works and it also fixes a crash of the 	python-2.5.4.amd64 interpreter at startup when ctypes 1.0.2 and pyreadline 1.6.2 are installed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8275>
_______________________________________

From report at bugs.python.org  Wed Jan 26 19:29:27 2011
From: report at bugs.python.org (Arif Amirani)
Date: Wed, 26 Jan 2011 18:29:27 +0000
Subject: [issue9516] sysconfig: $MACOSX_DEPLOYMENT_TARGET mismatch: now
	"10.3"	but "10.5" during configure
In-Reply-To: <1280955591.23.0.0206270993017.issue9516@psf.upfronthosting.co.za>
Message-ID: <1296066567.98.0.793509203592.issue9516@psf.upfronthosting.co.za>


Changes by Arif Amirani <arif.amirani at gmail.com>:


----------
nosy: +kontinuity

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9516>
_______________________________________

From report at bugs.python.org  Wed Jan 26 20:02:04 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 26 Jan 2011 19:02:04 +0000
Subject: [issue11011] More functools functions
In-Reply-To: <1295994742.19.0.341586360497.issue11011@psf.upfronthosting.co.za>
Message-ID: <1296068524.22.0.0182059628301.issue11011@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

I'm intrigued by the tampoline() but after reading Nick's post, I think it needs to be an external recipe or blog post with extensive examples so that it can mature and either prove its worth or serve as an intellectually stimulating toy.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11011>
_______________________________________

From report at bugs.python.org  Wed Jan 26 20:03:45 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 26 Jan 2011 19:03:45 +0000
Subject: [issue9045] 2.7rc1: 64-bit OSX installer is not built with 64-bit
	tkinter
In-Reply-To: <1277143341.0.0.74848452771.issue9045@psf.upfronthosting.co.za>
Message-ID: <1296068625.49.0.366806462088.issue9045@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I have the impression that there has been progress on tcl/tk on Apple in the last 7 months. Should this issue still be open, and if so, for both 2.7 and 3.2?

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9045>
_______________________________________

From report at bugs.python.org  Wed Jan 26 20:13:53 2011
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Wed, 26 Jan 2011 19:13:53 +0000
Subject: [issue9045] 2.7rc1: 64-bit OSX installer is not built with 64-bit
	tkinter
In-Reply-To: <1296068625.49.0.366806462088.issue9045@psf.upfronthosting.co.za>
Message-ID: <4D40726D.1030108@activestate.com>


Sridhar Ratnakumar <sridharr at activestate.com> added the comment:

Terry J. Reedy wrote:
> Terry J. Reedy<tjreedy at udel.edu>  added the comment:
>
> I have the impression that there has been progress on tcl/tk on Apple in the last 7 months. Should this issue still be open, and if so, for both 2.7 and 3.2?

 From http://www.python.org/download/mac/tcltk/ - it seems that 3.2's 
64-bit build will use ActiveTcl 8.5 that is now built with 64-bit. But 
2.7 still uses 8.4.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9045>
_______________________________________

From report at bugs.python.org  Wed Jan 26 21:00:49 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 26 Jan 2011 20:00:49 +0000
Subject: [issue11014] 'filter' argument for Tarfile.add needs to be a
	keyword-only argument
In-Reply-To: <1296008845.92.0.0968306232323.issue11014@psf.upfronthosting.co.za>
Message-ID: <1296072049.62.0.167129145669.issue11014@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <rhettinger at users.sourceforge.net>:


Added file: http://bugs.python.org/file20533/tarfile.patch2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11014>
_______________________________________

From report at bugs.python.org  Wed Jan 26 21:05:32 2011
From: report at bugs.python.org (Brian Curtin)
Date: Wed, 26 Jan 2011 20:05:32 +0000
Subject: [issue11014] 'filter' argument for Tarfile.add needs to be a
	keyword-only argument
In-Reply-To: <1296008845.92.0.0968306232323.issue11014@psf.upfronthosting.co.za>
Message-ID: <1296072332.85.0.571570111769.issue11014@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

Looks good to me.

As discussed in IRC, a note in 2.7 about the future of the `add` signature would also be helpful.

----------
nosy: +brian.curtin

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11014>
_______________________________________

From report at bugs.python.org  Wed Jan 26 21:08:24 2011
From: report at bugs.python.org (Anthony Long)
Date: Wed, 26 Jan 2011 20:08:24 +0000
Subject: [issue11014] 'filter' argument for Tarfile.add needs to be a
	keyword-only argument
In-Reply-To: <1296008845.92.0.0968306232323.issue11014@psf.upfronthosting.co.za>
Message-ID: <1296072504.45.0.537455600226.issue11014@psf.upfronthosting.co.za>


Anthony Long <antlong at gmail.com> added the comment:

Tests trying all positions and expecting an appropriate TypeError should be included.

----------
nosy: +antlong

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11014>
_______________________________________

From report at bugs.python.org  Wed Jan 26 21:08:40 2011
From: report at bugs.python.org (Anthony Long)
Date: Wed, 26 Jan 2011 20:08:40 +0000
Subject: [issue11014] 'filter' argument for Tarfile.add needs to be a
	keyword-only argument
In-Reply-To: <1296008845.92.0.0968306232323.issue11014@psf.upfronthosting.co.za>
Message-ID: <1296072520.4.0.789213652508.issue11014@psf.upfronthosting.co.za>


Changes by Anthony Long <antlong at gmail.com>:


----------
nosy:  -antlong

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11014>
_______________________________________

From report at bugs.python.org  Wed Jan 26 21:10:19 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 26 Jan 2011 20:10:19 +0000
Subject: [issue11014] 'filter' argument for Tarfile.add needs to be a
	keyword-only argument
In-Reply-To: <1296008845.92.0.0968306232323.issue11014@psf.upfronthosting.co.za>
Message-ID: <1296072619.37.0.224529955026.issue11014@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Anthony, that is what tarfile.patch2 does.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11014>
_______________________________________

From report at bugs.python.org  Wed Jan 26 21:13:52 2011
From: report at bugs.python.org (Anthony Long)
Date: Wed, 26 Jan 2011 20:13:52 +0000
Subject: [issue11014] 'filter' argument for Tarfile.add needs to be a
	keyword-only argument
In-Reply-To: <1296008845.92.0.0968306232323.issue11014@psf.upfronthosting.co.za>
Message-ID: <1296072832.43.0.874746529178.issue11014@psf.upfronthosting.co.za>


Anthony Long <antlong at gmail.com> added the comment:

Strange, I didn't see it until this email came. Probably an old browser cache.

Either way, looks good to me. No issues on mac SL.

----------
nosy: +antlong

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11014>
_______________________________________

From report at bugs.python.org  Wed Jan 26 21:23:01 2011
From: report at bugs.python.org (R. David Murray)
Date: Wed, 26 Jan 2011 20:23:01 +0000
Subject: [issue9124] Mailbox module should use binary I/O, not text I/O
In-Reply-To: <1277900903.38.0.556015912714.issue9124@psf.upfronthosting.co.za>
Message-ID: <1296073381.06.0.827087873194.issue9124@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Haypo: yeah, in an ideal world Generator would use get_payload() and not _payload, but I had to make some compromises with purity of model separation in order to achieve the practical goal of handling bytes usefully.  I'd like to fix that as I work on email in 3.3.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9124>
_______________________________________

From report at bugs.python.org  Wed Jan 26 21:35:38 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 26 Jan 2011 20:35:38 +0000
Subject: [issue11014] 'filter' argument for Tarfile.add needs to be a
	keyword-only argument
In-Reply-To: <1296008845.92.0.0968306232323.issue11014@psf.upfronthosting.co.za>
Message-ID: <1296074138.2.0.693150321608.issue11014@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Fixed in r88201.

Will add a note to 2.7 docs advising use as a keyword-only argument.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11014>
_______________________________________

From report at bugs.python.org  Wed Jan 26 21:53:21 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Wed, 26 Jan 2011 20:53:21 +0000
Subject: [issue11016] Add S_ISDOOR to the stat module
In-Reply-To: <1296045030.55.0.492262221105.issue11016@psf.upfronthosting.co.za>
Message-ID: <4D4089BD.2020305@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> I am thinking about how to manage OS's with no support for doors.
> Instead of conditionally compile the new STAT, I would rather have
> the function always available, but returning FALSE when the OS
> doesn't support doors. But what happen if you mount a Solaris
> filesystem in a nonsolaris machine?. Let say, a Solaris ZFS
> filesystem with doors, under linux/*bsd + ZFS?.
> 
> So maybe would be better to not compile that function in those OS's,
> instead of "lying" in corner cases.

I'd rather see this exposed from the posix module than the stat module
(and see the stat module deprecated in the long term).
As much other stuff, it only be defined if the system actually has the
functionality. sys.path.isdoor could be defined on top of it, returning
False on systems that don't have doors in the first place.

For testing, if S_ISDOR is available but /var/run/name_service_door is
not, the test should get skipped.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11016>
_______________________________________

From report at bugs.python.org  Wed Jan 26 21:56:05 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Wed, 26 Jan 2011 20:56:05 +0000
Subject: [issue11016] Add S_ISDOOR to the stat module
In-Reply-To: <1296047673.19.0.829299043348.issue11016@psf.upfronthosting.co.za>
Message-ID: <4D408A63.4040606@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Am 26.01.2011 14:14, schrieb Jes?s Cea Avi?n:
> 
> Jes?s Cea Avi?n <jcea at jcea.es> added the comment:
> 
> Antoine, I am not talking about python, I am talking about the UNIX
> standarization process. In particular, how a new flag (for
> filesystems) in an OS can be "skipped" and not being reused for some
> other purpuse in other OS.

There is no standards body defining the S_IFMT numerical values.
POSIX defines the symbolic constants:

http://pubs.opengroup.org/onlinepubs/009695399/basedefs/sys/stat.h.html

The Python stat module is flawed in assuming it knows the numeric values
(although by tradition, it is correct on all systems we care about).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11016>
_______________________________________

From report at bugs.python.org  Wed Jan 26 21:57:16 2011
From: report at bugs.python.org (R. David Murray)
Date: Wed, 26 Jan 2011 20:57:16 +0000
Subject: [issue11019] BytesGenerator fails if the Message body is None
In-Reply-To: <1296075436.52.0.0716312714806.issue11019@psf.upfronthosting.co.za>
Message-ID: <1296075436.52.0.0716312714806.issue11019@psf.upfronthosting.co.za>


New submission from R. David Murray <rdmurray at bitdance.com>:

This was discovered by Haypo during work on #9124.  I'll attach a patch with test shortly.

----------
assignee: r.david.murray
messages: 127139
nosy: r.david.murray
priority: high
severity: normal
stage: commit review
status: open
title: BytesGenerator fails if the Message body is None
type: behavior
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11019>
_______________________________________

From report at bugs.python.org  Wed Jan 26 22:02:38 2011
From: report at bugs.python.org (Roumen Petrov)
Date: Wed, 26 Jan 2011 21:02:38 +0000
Subject: [issue3754] cross-compilation support for python build
In-Reply-To: <1220305759.82.0.468834426074.issue3754@psf.upfronthosting.co.za>
Message-ID: <1296075758.33.0.818458285827.issue3754@psf.upfronthosting.co.za>


Roumen Petrov <bugtrack at roumenpetrov.info> added the comment:

fixed patch failure on Parser/pgen.stamp

----------
Added file: http://bugs.python.org/file20534/python-2.7-20110126-CROSS.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3754>
_______________________________________

From report at bugs.python.org  Wed Jan 26 22:04:03 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 26 Jan 2011 21:04:03 +0000
Subject: [issue11019] BytesGenerator fails if the Message body is None
In-Reply-To: <1296075436.52.0.0716312714806.issue11019@psf.upfronthosting.co.za>
Message-ID: <1296075843.53.0.967559615328.issue11019@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

(Patch without patch from #9124)

----------
keywords: +patch
nosy: +haypo
Added file: http://bugs.python.org/file20535/BytesGenerator_handle_text.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11019>
_______________________________________

From report at bugs.python.org  Wed Jan 26 22:05:26 2011
From: report at bugs.python.org (Roumen Petrov)
Date: Wed, 26 Jan 2011 21:05:26 +0000
Subject: [issue3754] cross-compilation support for python build
In-Reply-To: <1220305759.82.0.468834426074.issue3754@psf.upfronthosting.co.za>
Message-ID: <1296075926.57.0.727418962008.issue3754@psf.upfronthosting.co.za>


Changes by Roumen Petrov <bugtrack at roumenpetrov.info>:


Added file: http://bugs.python.org/file20536/python-py3k-20110126-CROSS.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3754>
_______________________________________

From report at bugs.python.org  Wed Jan 26 22:06:28 2011
From: report at bugs.python.org (R. David Murray)
Date: Wed, 26 Jan 2011 21:06:28 +0000
Subject: [issue11019] BytesGenerator fails if the Message body is None
In-Reply-To: <1296075436.52.0.0716312714806.issue11019@psf.upfronthosting.co.za>
Message-ID: <1296075988.6.0.114190918192.issue11019@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Here's the patch and test.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11019>
_______________________________________

From report at bugs.python.org  Wed Jan 26 22:07:17 2011
From: report at bugs.python.org (R. David Murray)
Date: Wed, 26 Jan 2011 21:07:17 +0000
Subject: [issue11019] BytesGenerator fails if the Message body is None
In-Reply-To: <1296075436.52.0.0716312714806.issue11019@psf.upfronthosting.co.za>
Message-ID: <1296076037.03.0.90752640915.issue11019@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

OK, so let's try again, since roundup saw fit to clear the upload field on me...

----------
Added file: http://bugs.python.org/file20537/bytes_generator_none_body.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11019>
_______________________________________

From report at bugs.python.org  Wed Jan 26 22:09:04 2011
From: report at bugs.python.org (Roumen Petrov)
Date: Wed, 26 Jan 2011 21:09:04 +0000
Subject: [issue3871] cross and native build of python for mingw32 with
	distutils
In-Reply-To: <1221433699.47.0.0165458312451.issue3871@psf.upfronthosting.co.za>
Message-ID: <1296076144.87.0.67169739986.issue3871@psf.upfronthosting.co.za>


Roumen Petrov <bugtrack at roumenpetrov.info> added the comment:

fixed test case failure for 32-bit time_t

----------
Added file: http://bugs.python.org/file20538/python-2.7-20110126-MINGW.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3871>
_______________________________________

From report at bugs.python.org  Wed Jan 26 22:11:17 2011
From: report at bugs.python.org (Roumen Petrov)
Date: Wed, 26 Jan 2011 21:11:17 +0000
Subject: [issue3871] cross and native build of python for mingw32 with
	distutils
In-Reply-To: <1221433699.47.0.0165458312451.issue3871@psf.upfronthosting.co.za>
Message-ID: <1296076277.75.0.1698738015.issue3871@psf.upfronthosting.co.za>


Changes by Roumen Petrov <bugtrack at roumenpetrov.info>:


Added file: http://bugs.python.org/file20539/python-2.7-20110126-MINGW.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3871>
_______________________________________

From report at bugs.python.org  Wed Jan 26 22:11:34 2011
From: report at bugs.python.org (Roumen Petrov)
Date: Wed, 26 Jan 2011 21:11:34 +0000
Subject: [issue3871] cross and native build of python for mingw32 with
	distutils
In-Reply-To: <1221433699.47.0.0165458312451.issue3871@psf.upfronthosting.co.za>
Message-ID: <1296076294.44.0.294232103494.issue3871@psf.upfronthosting.co.za>


Changes by Roumen Petrov <bugtrack at roumenpetrov.info>:


Removed file: http://bugs.python.org/file20539/python-2.7-20110126-MINGW.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3871>
_______________________________________

From report at bugs.python.org  Wed Jan 26 22:12:04 2011
From: report at bugs.python.org (Roumen Petrov)
Date: Wed, 26 Jan 2011 21:12:04 +0000
Subject: [issue3871] cross and native build of python for mingw32 with
	distutils
In-Reply-To: <1221433699.47.0.0165458312451.issue3871@psf.upfronthosting.co.za>
Message-ID: <1296076324.13.0.597625177068.issue3871@psf.upfronthosting.co.za>


Changes by Roumen Petrov <bugtrack at roumenpetrov.info>:


Added file: http://bugs.python.org/file20540/python-py3k-20110126-MINGW.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3871>
_______________________________________

From report at bugs.python.org  Wed Jan 26 22:16:17 2011
From: report at bugs.python.org (Ned Deily)
Date: Wed, 26 Jan 2011 21:16:17 +0000
Subject: [issue9045] 2.7rc1: 64-bit OSX installer is not built with 64-bit
	tkinter
In-Reply-To: <1277143341.0.0.74848452771.issue9045@psf.upfronthosting.co.za>
Message-ID: <1296076577.01.0.0329186541515.issue9045@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Terry, we are working on all of the OS X IDLE Tk issues at the moment with focus first on 3.2.  These issues will be updated and closed as they are resolved.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9045>
_______________________________________

From report at bugs.python.org  Wed Jan 26 22:16:51 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 26 Jan 2011 21:16:51 +0000
Subject: [issue11019] BytesGenerator fails if the Message body is None
In-Reply-To: <1296075436.52.0.0716312714806.issue11019@psf.upfronthosting.co.za>
Message-ID: <1296076611.57.0.17814493951.issue11019@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

The new test fails without the fix, and it pass with the fix. The fix itself looks correct because I wrote a similar patch :-) Go on.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11019>
_______________________________________

From report at bugs.python.org  Wed Jan 26 22:23:34 2011
From: report at bugs.python.org (R. David Murray)
Date: Wed, 26 Jan 2011 21:23:34 +0000
Subject: [issue11019] BytesGenerator fails if the Message body is None
In-Reply-To: <1296075436.52.0.0716312714806.issue11019@psf.upfronthosting.co.za>
Message-ID: <1296077014.91.0.850836957583.issue11019@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Committed in r88203.

----------
resolution:  -> fixed
stage: commit review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11019>
_______________________________________

From report at bugs.python.org  Wed Jan 26 22:49:57 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 26 Jan 2011 21:49:57 +0000
Subject: [issue9124] Mailbox module should use binary I/O, not text I/O
In-Reply-To: <1277900903.38.0.556015912714.issue9124@psf.upfronthosting.co.za>
Message-ID: <1296078597.99.0.179450140516.issue9124@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

pitrou> There's a missing conversion in mailbox.patch.
pitrou> Running with -bb shows the issue.
pitrou> Here is an updated patch.

Good catch: test_mailbox now pass on Windows.

--

Some remarks on mailbox2.patch.

get_string() returns a bytes object: I propose to rename it to get_bytes(): """Return a *byte* string representation or raise a KeyError."""

The following comment is outdated, target have to be a *binary* file:
    def _dump_message(self, message, target, mangle_from_=False):
        # This assumes the target file is open in *text* mode ...

get_file(): should we specify that the file-like object is a binary file?

MH.get_sequences() and MH.set_sequences() opens .mh_sequences file in text mode from the locale encoding. I don't know if the locale encoding is a good choice. Does this file contain non-ASCII characters? Should we use ASCII or UTF-8 encoding instead, or parse the file in binary, and only decode requested values from ASCII?

Since all tests of test_mailbox now pass on Windows, it looks like the "universal newline" thing still work. But how can I be sure?

-            from_line = 'From MAILER-DAEMON %s' % time.asctime(time.gmtime())
+            from_line = b'From MAILER-DAEMON ' + time.asctime(time.gmtime()).encode()

Is UTF-8 the right encoding to encode a timestamp? Or should we use something like "=?UTF-8?q?...?=" ?

MH.set_sequences() does... sometimes... decode the sequence name from UTF-8. I don't understand why I had to add the following if:

-                f.write('%s:' % name)
+                if isinstance(name, bytes):
+                    name = name.decode()
+                f.write(name + ':')

Is it correct to decode the timestamp from UTF-8? And is the following change correct?
***********
-            maybe_date = ' '.join(self.get_from().split()[-5:])
+            maybe_date = b' '.join(self.get_from().split()[-5:])
             try:
+                maybe_date = maybe_date.decode('utf-8')
                 message.set_date(calendar.timegm(time.strptime(maybe_date,
                                                       '%a %b %d %H:%M:%S %Y')))
-            except (ValueError, OverflowError):
+            except (ValueError, OverflowError, UnicodeDecodeError):
                 pass
***********


The following change is just enough to fix mailbox. But it would maybe be better to inherit from RawIOBase instead and implement all methods. _PartialFile class might be moved into the io module. All of this can be done later.
****** 
+    def readable(self):
+        return self._file.readable()
 
+    def writable(self):
+        return self._file.writable()
+
+    def seekable(self):
+        return self._file.seekable()
+
+    def flush(self):
+        return self._file.flush()
+
+    @property
+    def closed(self):
+        return self._file.closed
******

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9124>
_______________________________________

From report at bugs.python.org  Wed Jan 26 22:55:16 2011
From: report at bugs.python.org (gmr)
Date: Wed, 26 Jan 2011 21:55:16 +0000
Subject: [issue10878] asyncore does not react properly on close()
In-Reply-To: <1294641638.26.0.753920382409.issue10878@psf.upfronthosting.co.za>
Message-ID: <1296078916.02.0.265440068543.issue10878@psf.upfronthosting.co.za>


gmr <gmr at myyearbook.com> added the comment:

What I noticed in tracing through the code is that it's getting stuck in a loop because it depends on grabbing asyncore.socket_map if map is null when passed into asyncore.loop. I got around this by appending:

asyncore.loop(0.1, map=[], count=1)

After my close(). I believe this bypasses the grab of socket_map from asyncore.socket_map and allows the while loop in asyncore.loop to exit cleanly.

----------
nosy: +Gavin M. Roy
versions: +Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10878>
_______________________________________

From report at bugs.python.org  Wed Jan 26 23:09:44 2011
From: report at bugs.python.org (gmr)
Date: Wed, 26 Jan 2011 22:09:44 +0000
Subject: [issue10878] asyncore does not react properly on close()
In-Reply-To: <1294641638.26.0.753920382409.issue10878@psf.upfronthosting.co.za>
Message-ID: <1296079784.69.0.0248909849583.issue10878@psf.upfronthosting.co.za>


gmr <gmr at myyearbook.com> added the comment:

For more clarity, I am passing in a list because it will evaluate as False in the while loop on 209 and 213. The fix is to add len(map) to the while loops on those lines.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10878>
_______________________________________

From report at bugs.python.org  Wed Jan 26 23:43:14 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 26 Jan 2011 22:43:14 +0000
Subject: [issue10981] argparse: options starting with -- match substrings
In-Reply-To: <1295700552.8.0.933174530734.issue10981@psf.upfronthosting.co.za>
Message-ID: <1296081794.93.0.26678286873.issue10981@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Is this behavior documented?

----------
nosy: +eric.araujo
versions: +Python 2.7, Python 3.2 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10981>
_______________________________________

From report at bugs.python.org  Wed Jan 26 23:46:57 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 26 Jan 2011 22:46:57 +0000
Subject: [issue11003] os.system should be deprecated in favour of subprocess
	module
In-Reply-To: <1295952116.86.0.340970955055.issue11003@psf.upfronthosting.co.za>
Message-ID: <1296082017.57.0.404438651162.issue11003@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Note that os.popen is implemented with subprocess.  For os.system, what Raymond said: It complies with the Python habit of exposing calls as is, and its documentation already advertises subprocess.

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11003>
_______________________________________

From report at bugs.python.org  Thu Jan 27 00:06:10 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Wed, 26 Jan 2011 23:06:10 +0000
Subject: [issue10848] Move test.regrtest from getopt to argparse
In-Reply-To: <1294353259.48.0.852026284896.issue10848@psf.upfronthosting.co.za>
Message-ID: <1296083170.89.0.371155559299.issue10848@psf.upfronthosting.co.za>


Sandro Tosi <sandro.tosi at gmail.com> added the comment:

As suggested by David, I made it possible to specify an alternative test directory by introducing '--testdir DIR' cli option: attached the patch, comments are welcome :)

What about STDTESTS/NOTTESTS in case --testdir is specified? Currently they are executed/excluded even in case we're not running the python test suite: should we remove them in that case?

----------
keywords: +patch
Added file: http://bugs.python.org/file20541/issue10848-testdir-py3k.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10848>
_______________________________________

From report at bugs.python.org  Thu Jan 27 00:13:38 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Wed, 26 Jan 2011 23:13:38 +0000
Subject: [issue10848] Move test.regrtest from getopt to argparse
In-Reply-To: <1294353259.48.0.852026284896.issue10848@psf.upfronthosting.co.za>
Message-ID: <1296083618.25.0.910525651391.issue10848@psf.upfronthosting.co.za>


Sandro Tosi <sandro.tosi at gmail.com> added the comment:

shouldn't we use the same method also for --coverdir (that currently faild the "least surprise" test when specifying a relative path) replacing

coverdir = os.path.join(os.getcwd(), a)

with

coverdir = os.path.join(support.SAVEDCWD, a)

?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10848>
_______________________________________

From report at bugs.python.org  Thu Jan 27 00:22:52 2011
From: report at bugs.python.org (David Caro)
Date: Wed, 26 Jan 2011 23:22:52 +0000
Subject: [issue10981] argparse: options starting with -- match substrings
In-Reply-To: <1295700552.8.0.933174530734.issue10981@psf.upfronthosting.co.za>
Message-ID: <1296084172.97.0.867346298389.issue10981@psf.upfronthosting.co.za>


David Caro <david.caro.estevez at gmail.com> added the comment:

Yes it is, here http://docs.python.org/dev/library/argparse.html#argument-abbreviations.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10981>
_______________________________________

From report at bugs.python.org  Thu Jan 27 00:29:00 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 26 Jan 2011 23:29:00 +0000
Subject: [issue11020] Pyclbr broken because of missing 2-to-3 conversion
In-Reply-To: <1296084540.01.0.814516700337.issue11020@psf.upfronthosting.co.za>
Message-ID: <1296084540.01.0.814516700337.issue11020@psf.upfronthosting.co.za>


New submission from Raymond Hettinger <rhettinger at users.sourceforge.net>:

The command line invocation of pyclbr failed because of a 2-to-3 error.  The dict.values() call returns a dictview which doesn't support the sort() method.

Invoke with:

 $ python -m pyclbr Lib/collections.py

----------
components: Library (Lib)
messages: 127156
nosy: rhettinger
priority: high
severity: normal
stage: patch review
status: open
title: Pyclbr broken because of missing 2-to-3 conversion
type: behavior
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11020>
_______________________________________

From report at bugs.python.org  Thu Jan 27 00:31:51 2011
From: report at bugs.python.org (R. David Murray)
Date: Wed, 26 Jan 2011 23:31:51 +0000
Subject: [issue10848] Move test.regrtest from getopt to argparse
In-Reply-To: <1294353259.48.0.852026284896.issue10848@psf.upfronthosting.co.za>
Message-ID: <1296084711.79.0.600181745651.issue10848@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I would open three new bugs to address the issues you raise.  It ought to be possible to rename things so that we can eliminate the pre-population of NOTTESTS (if not I'd like to know why not!).  STDTESTS appear to move certain tests to the front, possibly for stability reasons?  Perhaps that can be eliminated as well; certainly it seems worth investigating.  If we can't eliminate it then a check could be added such that the tests would not be returned if they don't actually show up in the directory passed to findtests.  The coverdir thing looks like a bug.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10848>
_______________________________________

From report at bugs.python.org  Thu Jan 27 00:32:21 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 26 Jan 2011 23:32:21 +0000
Subject: [issue11018] typo in test_bz2
In-Reply-To: <1296049019.27.0.765900313708.issue11018@psf.upfronthosting.co.za>
Message-ID: <1296084741.56.0.453183063626.issue11018@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Committed in r88204 (3.2), r88205 (3.1) and r88206 (2.7).

----------
resolution: accepted -> fixed
stage: commit review -> committed/rejected
status: open -> closed
versions: +Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11018>
_______________________________________

From report at bugs.python.org  Thu Jan 27 00:35:14 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 26 Jan 2011 23:35:14 +0000
Subject: [issue11020] Pyclbr broken because of missing 2-to-3 conversion
In-Reply-To: <1296084540.01.0.814516700337.issue11020@psf.upfronthosting.co.za>
Message-ID: <1296084914.23.0.557879502095.issue11020@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <rhettinger at users.sourceforge.net>:


----------
keywords: +patch
Added file: http://bugs.python.org/file20542/pyclbr.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11020>
_______________________________________

From report at bugs.python.org  Thu Jan 27 00:46:35 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Wed, 26 Jan 2011 23:46:35 +0000
Subject: [issue10276] zlib crc32/adler32 buffer length truncation (64-bit)
In-Reply-To: <1288604765.69.0.684600327936.issue10276@psf.upfronthosting.co.za>
Message-ID: <1296085595.85.0.686877429359.issue10276@psf.upfronthosting.co.za>


Nadeem Vawda <nadeem.vawda at gmail.com> added the comment:

Here is an update patch, which corrects a typo in the previous patch, and adds a test to test_zlib.

The test uses a memory-mapped sparse file, so it gets skipped on systems without mmap. The alternative would be to allocate a 4+GB buffer of ordinary memory, causes heavy swapping on my machine (4GB of RAM). The test also gets skipped on 32-bit builds, where the address space is too small for this bug to arise.

I'm not sure whether the test can count on the created file actually being sparse, so I had the test require the 'largefile' resource, to be on the safe side.

----------
Added file: http://bugs.python.org/file20543/zlib-v2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10276>
_______________________________________

From report at bugs.python.org  Thu Jan 27 00:46:50 2011
From: report at bugs.python.org (R. David Murray)
Date: Wed, 26 Jan 2011 23:46:50 +0000
Subject: [issue11020] Pyclbr broken because of missing 2-to-3 conversion
In-Reply-To: <1296084540.01.0.814516700337.issue11020@psf.upfronthosting.co.za>
Message-ID: <1296085610.08.0.411877915011.issue11020@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

As long as we are modifying that code, how about fixing the use of 'dict' as a variable name?  Alternative patch attached.

----------
nosy: +r.david.murray
Added file: http://bugs.python.org/file20544/pyclbr2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11020>
_______________________________________

From report at bugs.python.org  Thu Jan 27 00:47:25 2011
From: report at bugs.python.org (David Caro)
Date: Wed, 26 Jan 2011 23:47:25 +0000
Subject: [issue11021] email MIME-Version headers for each part in multipart
	message
In-Reply-To: <1296085645.01.0.978524639714.issue11021@psf.upfronthosting.co.za>
Message-ID: <1296085645.01.0.978524639714.issue11021@psf.upfronthosting.co.za>


New submission from David Caro <david.caro.estevez at gmail.com>:

When attaching a subpart to a multipart message, python should follow the recomendations of the rfcs and remove the MIME-Version header of each part, leaving only one MIME-Version header at the beggining of the message.


>>> from email.mime.multipart import MIMEMultipart
>>> from email.mime.text import MIMEText
>>> usermail=MIMEMultipart('alternative')
>>> part=MIMEText('text')
>>> print part
>From nobody Thu Jan 27 00:33:50 2011
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit

text
>>> usermail.attach(part)
>>> print usermail
>From nobody Thu Jan 27 00:45:26 2011
Content-Type: multipart/alternative; boundary="===============1006894803=="
MIME-Version: 1.0

--===============1006894803==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit

text
--===============1006894803==--

----------
components: Library (Lib)
messages: 127161
nosy: david.caro
priority: normal
severity: normal
status: open
title: email MIME-Version headers for each part in multipart message
type: behavior
versions: Python 2.6, Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11021>
_______________________________________

From report at bugs.python.org  Thu Jan 27 00:50:19 2011
From: report at bugs.python.org (R. David Murray)
Date: Wed, 26 Jan 2011 23:50:19 +0000
Subject: [issue11020] Pyclbr broken because of missing 2-to-3 conversion
In-Reply-To: <1296084540.01.0.814516700337.issue11020@psf.upfronthosting.co.za>
Message-ID: <1296085819.92.0.618130769311.issue11020@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

One fix or the other ought to go in, IMO.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11020>
_______________________________________

From report at bugs.python.org  Thu Jan 27 00:51:20 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 26 Jan 2011 23:51:20 +0000
Subject: [issue6584] gzip module has no custom exception
In-Reply-To: <1248675050.27.0.747048824781.issue6584@psf.upfronthosting.co.za>
Message-ID: <1296085880.83.0.290830138466.issue6584@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
stage: needs patch -> patch review
versions: +Python 3.3 -Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6584>
_______________________________________

From report at bugs.python.org  Thu Jan 27 00:53:13 2011
From: report at bugs.python.org (R. David Murray)
Date: Wed, 26 Jan 2011 23:53:13 +0000
Subject: [issue11021] email MIME-Version headers for each part in multipart
	message
In-Reply-To: <1296085645.01.0.978524639714.issue11021@psf.upfronthosting.co.za>
Message-ID: <1296085993.62.0.437531637278.issue11021@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

For the record, can you point to the relevant part of the relevant RFC?

----------
assignee:  -> r.david.murray
nosy: +r.david.murray
stage:  -> needs patch
versions: +Python 3.1, Python 3.2 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11021>
_______________________________________

From report at bugs.python.org  Thu Jan 27 01:09:20 2011
From: report at bugs.python.org (Skip Montanaro)
Date: Thu, 27 Jan 2011 00:09:20 +0000
Subject: [issue11003] os.system should be deprecated in favour of subprocess
	module
In-Reply-To: <1296082017.57.0.404438651162.issue11003@psf.upfronthosting.co.za>
Message-ID: <19776.47021.561068.372916@montanaro.dyndns.org>


Skip Montanaro <skip at pobox.com> added the comment:

Eric> Note that os.popen is implemented with subprocess.

That seems somewhat wrong to me.  There is a stdio popen function which
os.popen used to expose.  I thought that was the goal (thin wrapper around
many library functions, then build higher level stuff on that).

Skip

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11003>
_______________________________________

From report at bugs.python.org  Thu Jan 27 01:17:33 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 27 Jan 2011 00:17:33 +0000
Subject: [issue11020] Pyclbr broken because of missing 2-to-3 conversion
In-Reply-To: <1296084540.01.0.814516700337.issue11020@psf.upfronthosting.co.za>
Message-ID: <1296087453.61.0.26044907134.issue11020@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

At some point, we ought to clean-up bad variable names.  For now (close to the release), I'll stick with the minimal fix.

Fixed r88207 and r88028.

----------
resolution:  -> fixed
status: open -> closed
versions: +Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11020>
_______________________________________

From report at bugs.python.org  Thu Jan 27 01:48:51 2011
From: report at bugs.python.org (Bob Ippolito)
Date: Thu, 27 Jan 2011 00:48:51 +0000
Subject: [issue9233] json.load failure when C optimizations aren't built
In-Reply-To: <1278949665.57.0.214129757073.issue9233@psf.upfronthosting.co.za>
Message-ID: <1296089331.22.0.15473305672.issue9233@psf.upfronthosting.co.za>


Bob Ippolito <bob at redivi.com> added the comment:

For what it's worth, I don't think any of the failures mentioned here are in the current version of simplejson. There aren't any tests that check the speedup module name, the speedup tests are skipped when speedups are not detected, and the empty json object bug was fixed in June 2009.

http://code.google.com/p/simplejson/issues/detail?id=57

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9233>
_______________________________________

From report at bugs.python.org  Thu Jan 27 03:31:40 2011
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 27 Jan 2011 02:31:40 +0000
Subject: [issue8914] Run clang's static analyzer
In-Reply-To: <1275795174.58.0.536949662024.issue8914@psf.upfronthosting.co.za>
Message-ID: <1296095500.76.0.218253777913.issue8914@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Analyzed by downloading the latest Clang static analyzer from http://clang-analyzer.llvm.org/ and running ``scan-build ./configure --with-pydebug; scan-build make -s -j2``. The attached tar.xz (yes I went with a cutting edge archival format; get pax on UNIX to read it) contains the HTML report.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8914>
_______________________________________

From report at bugs.python.org  Thu Jan 27 03:36:52 2011
From: report at bugs.python.org (R. David Murray)
Date: Thu, 27 Jan 2011 02:36:52 +0000
Subject: [issue9124] Mailbox module should use binary I/O, not text I/O
In-Reply-To: <1277900903.38.0.556015912714.issue9124@psf.upfronthosting.co.za>
Message-ID: <1296095812.5.0.366036182274.issue9124@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I haven't looked at the items Haypo has pointed to yet, but I have looked at the API issues (get_string, add, etc).  It seems to me that we have to make a decision here: do we break API backward compatibility and convert to consuming and emitting bytes pretty much everywhere we handle non-Message messages, or do we maintain backward compatibility by extending the APIs to handle bytes as well as strings?  In the email module I took the second approach.  I'm leaning toward that approach here as well, but it is a little messier than it was for email, where there ended up being distinct interfaces for bytes versus string.  Here we'd have get_string and get_bytes, but it seems more sensible to have add and similar methods accept both bytes and strings rather than making duplicate methods for each of the cases (since they are polymorphic between string and Message already).

And then there is get_file, which is *documented* as returning a binary file, but in fact has been returning a text file.  It makes sense that it should return a binary file.  So that's one backward incompatible bug fix already....unless we introduce get_binary_file and change the docs.

I think we need opinions from more than just haypo and I, but given that we are in RC I'm leaning toward a polymorphic API for add and friends and new get_bytes and get_binary_file methods.  That's more work than the patch haypo produced, though, since it requires some new code and tests in addition to what he's already done.  

Either approach introduces API changes in an RC, but unless we want to continue to ship a mailbox module that is as half-functional (or less) as what email was in 3.1, we have to do something.

I should have some time to work on this tomorrow, and a bit more on Friday, but we're getting down to the wire here.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9124>
_______________________________________

From report at bugs.python.org  Thu Jan 27 03:50:09 2011
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 27 Jan 2011 02:50:09 +0000
Subject: [issue8914] Run clang's static analyzer
In-Reply-To: <1275795174.58.0.536949662024.issue8914@psf.upfronthosting.co.za>
Message-ID: <1296096609.46.0.0172753895312.issue8914@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Well, there is no upload because the compressed file is 70 MB. But you can download the file from https://docs.google.com/leaf?id=0B7CvitGf6YffMGFlYTg2N2UtMjY3Yi00ZTg1LWI2NWUtNmRiMmEwYzZjMTQ1&sort=name&layout=list&num=50 .

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8914>
_______________________________________

From report at bugs.python.org  Thu Jan 27 04:05:40 2011
From: report at bugs.python.org (R. David Murray)
Date: Thu, 27 Jan 2011 03:05:40 +0000
Subject: [issue11003] os.system should be deprecated in favour of subprocess
	module
In-Reply-To: <1295952116.86.0.340970955055.issue11003@psf.upfronthosting.co.za>
Message-ID: <1296097540.69.0.256797542939.issue11003@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I wasn't around when that decision was made, but looking at the posixmodule.c source, system is a straightforward wrapper, but popen gets...byzantine on anything but unix.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11003>
_______________________________________

From report at bugs.python.org  Thu Jan 27 04:48:20 2011
From: report at bugs.python.org (R. David Murray)
Date: Thu, 27 Jan 2011 03:48:20 +0000
Subject: [issue11017] optparse: error: invalid integer value
In-Reply-To: <1296044964.44.0.826782436299.issue11017@psf.upfronthosting.co.za>
Message-ID: <1296100100.3.0.815401805265.issue11017@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

09 is still an invalid token in python3.  Since int('09') works in python2 it might be worth looking in to this further.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11017>
_______________________________________

From report at bugs.python.org  Thu Jan 27 04:54:37 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 27 Jan 2011 03:54:37 +0000
Subject: [issue10848] Move test.regrtest from getopt to argparse
In-Reply-To: <1294353259.48.0.852026284896.issue10848@psf.upfronthosting.co.za>
Message-ID: <1296100477.75.0.375100499186.issue10848@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

As I recall, STDTESTS is there to check we have a basically functioning interpreter (i.e. the compiler works, etc). The idea is that if any of those fail, everything else is likely to go belly up as well. If regrtest is being used to run some other set of tests, then that won't apply.

I thought we actually did use the testdir arg to handle the PID specific directory naming on the buildbots, but I may be misrembering where that appears in the execution sequence.

----------
nosy: +ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10848>
_______________________________________

From report at bugs.python.org  Thu Jan 27 04:56:49 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Thu, 27 Jan 2011 03:56:49 +0000
Subject: [issue3849] FUD in documentation for urllib.urlopen()
In-Reply-To: <1221246343.23.0.128587140594.issue3849@psf.upfronthosting.co.za>
Message-ID: <1296100609.7.0.179776726942.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  Thu Jan 27 05:05:49 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 27 Jan 2011 04:05:49 +0000
Subject: [issue7659] Attribute assignment on object() instances raises wrong
	exception
In-Reply-To: <1262968332.68.0.476240777656.issue7659@psf.upfronthosting.co.za>
Message-ID: <1296101149.83.0.476167354369.issue7659@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Object instances don't get a __dict__ by default to save the space the pointer and dict instance would require. Most builtins are missing that pointer. It is also the main memory saving provided by the use of __slots__.

As far as AttributeError vs TypeError goes, the CPython core is actually pretty arbitrary as to which it raises (usually for historical reasons). In this case, AttributeError is technically correct, since object.__setattr__ *does* support writable attributes. It just so happens that a bare object() instance doesn't have any (since __doc__ is read-only).

I asked Guido ages ago about cleaning some of this up (due to some discrepancies between __enter__ and __exit__ and other special methods), but he was of the opinion that the backwards compatibility hassles weren't worth the gain in consistency.

----------
nosy: +ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7659>
_______________________________________

From report at bugs.python.org  Thu Jan 27 05:18:22 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 27 Jan 2011 04:18:22 +0000
Subject: [issue7659] Attribute assignment on object() instances raises wrong
	exception
In-Reply-To: <1262968332.68.0.476240777656.issue7659@psf.upfronthosting.co.za>
Message-ID: <1296101902.33.0.887464727851.issue7659@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Along the lines of RDM's last post, see:
http://code.activestate.com/recipes/52308-the-simple-but-handy-collector-of-a-bunch-of-named/

Or, if you do a few web searches for terms like "bethard coghlan namespaces" or "bethard generic objects" you'll get results along the lines of:
http://mail.python.org/pipermail/python-list/2005-February/305129.html

collections.namedtuple is a simpler alternative to most of these ideas, though.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7659>
_______________________________________

From report at bugs.python.org  Thu Jan 27 11:30:28 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 27 Jan 2011 10:30:28 +0000
Subject: [issue11017] optparse: error: invalid integer value
In-Reply-To: <1296044964.44.0.826782436299.issue11017@psf.upfronthosting.co.za>
Message-ID: <1296124228.28.0.590059699125.issue11017@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I think it?s good: optparse checks for a leading 0 and will use int(value, 8) in that case.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11017>
_______________________________________

From report at bugs.python.org  Thu Jan 27 11:54:03 2011
From: report at bugs.python.org (Hiroaki Kawai)
Date: Thu, 27 Jan 2011 10:54:03 +0000
Subject: [issue5305] imaplib should support international mailbox names
In-Reply-To: <1234935371.11.0.35650041724.issue5305@psf.upfronthosting.co.za>
Message-ID: <1296125643.08.0.629931751646.issue5305@psf.upfronthosting.co.za>


Hiroaki Kawai <hiroaki.kawai at gmail.com> added the comment:

twisted's code does not work good for "\t", "\r", "\n", those characters must encoded in modified base64 form according to RFC 3501.

----------
nosy: +Hiroaki.Kawai

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5305>
_______________________________________

From report at bugs.python.org  Thu Jan 27 12:00:25 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Thu, 27 Jan 2011 11:00:25 +0000
Subject: [issue11022] locale.setlocale() doesn't change I/O codec,
	os.environ[] does
In-Reply-To: <1296126025.04.0.965125504096.issue11022@psf.upfronthosting.co.za>
Message-ID: <1296126025.04.0.965125504096.issue11022@psf.upfronthosting.co.za>


New submission from Steffen Daode Nurpmeso <sdaoden at googlemail.com>:

This bug may be based on same problem as Issue 6203.
- My system locale is en_GB.UTF-8.
- Given a latin1 text file, open()+ will fail with
  'UnicodeDecodeError: 'utf8' codec can't decode byte 0xf6...'
- Using locale.setlocale(..., ...)
- Re-open causes same error, I/O layer codec has not been changed!
- Using os.environ["LC_ALL"] = ...
- Re-open works properly, I/O layer codec has been changed.
P.S.: i am new to Python, please don't assume i can help in solving the problem!

----------
components: Library (Lib)
messages: 127177
nosy: sdaoden
priority: normal
severity: normal
status: open
title: locale.setlocale() doesn't change I/O codec, os.environ[] does
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11022>
_______________________________________

From report at bugs.python.org  Thu Jan 27 12:01:17 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Thu, 27 Jan 2011 11:01:17 +0000
Subject: [issue11022] locale.setlocale() doesn't change I/O codec,
	os.environ[] does
In-Reply-To: <1296126025.04.0.965125504096.issue11022@psf.upfronthosting.co.za>
Message-ID: <1296126077.54.0.45623281287.issue11022@psf.upfronthosting.co.za>


Changes by Steffen Daode Nurpmeso <sdaoden at googlemail.com>:


----------
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11022>
_______________________________________

From report at bugs.python.org  Thu Jan 27 12:19:28 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 27 Jan 2011 11:19:28 +0000
Subject: [issue11022] locale.setlocale() doesn't change I/O codec,
	os.environ[] does
In-Reply-To: <1296126025.04.0.965125504096.issue11022@psf.upfronthosting.co.za>
Message-ID: <1296127168.49.0.954723791274.issue11022@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> - Using locale.setlocale(..., ...)
> - Re-open causes same error, I/O layer codec has not been changed!

Yes, this is the expected behaviour with the current code.

TextIOWrapper uses indirectly locale.getpreferredencoding() to choose your file encoding. If locale has the CODESET constant, this function sets LC_CTYPE to "" and uses nl_langinfo(CODESET) to get the locale encoding.

locale.getpreferredencoding() has an option to not set the LC_CTYPE to "": locale.getpreferredencoding(False).

Example:
---------------------------
$ python3.1
Type "help", "copyright", "credits" or "license" for more information.
>>> from locale import getpreferredencoding, setlocale, LC_CTYPE
>>> from locale import nl_langinfo, CODESET

>>> setlocale(LC_CTYPE, None)
'fr_FR.utf8'
>>> getpreferredencoding()
'UTF-8'
>>> getpreferredencoding(False)
'UTF-8'

>>> setlocale(LC_CTYPE, 'fr_FR.iso88591')
'fr_FR.iso88591'
>>> nl_langinfo(CODESET)
'ISO-8859-1'
>>> getpreferredencoding()
'UTF-8'
>>> getpreferredencoding(False)
'ISO-8859-1'
---------------------------

Setting LC_CTYPE does change directly nl_langinfo(CODESET) result, but not getpreferredencoding() result because getpreferredencoding() doesn't care of the current locale: it uses its own LC_CTYPE value ("").

getpreferredencoding(False) uses the current locale and give the expected result.

> - Using os.environ["LC_ALL"] = ...
> - Re-open works properly, I/O layer codec has been changed.

Set LC_ALL works because getpreferredencoding() sets the LC_CTYPE to "" which will read the current value of the "LC_ALL" and "LC_CTYPE" environment variables.

--

Actually, TextIOWrapper doesn't use the current locale, it only uses (indirectly) the environment variables. I don't know which behaviour is better.

If you would like that TextIOWrapper uses your current locale, use: open(filename, encoding=locale.getpreferredencoding(True)).

Anyway, I don't know understand why do you change your locale, because you know that your file encoding is Latin1. Why don't you use directly: open(filename, encoding='latin1')?

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11022>
_______________________________________

From report at bugs.python.org  Thu Jan 27 12:24:41 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 27 Jan 2011 11:24:41 +0000
Subject: [issue11022] locale.setlocale() doesn't change I/O codec,
	os.environ[] does
In-Reply-To: <1296126025.04.0.965125504096.issue11022@psf.upfronthosting.co.za>
Message-ID: <1296127481.83.0.71321826326.issue11022@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> This bug may be based on same problem as Issue 6203.

Nope, both issues are different. Here you want that TextIOWrapper reads your current locale, and not your environment variables. Issue #6203 asks why LC_CTYPE is not C by default, but the user locale LC_CTYPE (read from LC_ALL or LC_CTYPE environment variables).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11022>
_______________________________________

From report at bugs.python.org  Thu Jan 27 12:40:08 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 27 Jan 2011 11:40:08 +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: <1296128408.51.0.401498914216.issue6203@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> To add a little bit more analysis: posix.device_encoding requires that
> the LC_CTYPE is set. Setting it just in this function would not be
> possible, as setlocale is not thread-safe.

open() does indirectly (locale.getpreferredencoding()) change temporary the locale (set LC_CTYPE to "") if the file is not a TTY (if it is a TTY, device_encoding() calls nl_langinfo(CODESET) without changing the current locale). If setlocale() is not thread-safe we have (maybe?) a problem here. See also #11022: report of an user not understanding why setlocale() doesn't impact open() (TextIOWrapper) encoding). A quick solution is to call locale.getpreferredencoding(False) which doesn't change the locale.

Do you really need os.device_encoding()? If we change TextIOWrapper to call locale.getpreferredencoding(False), os.device_encoding() and locale.getpreferredencoding(False) will give the same result. Except on Windows: os.device_encoding() uses GetConsoleCP() if fd==0 and GetConsoleOutputCP() if fd in (1, 2). But we can use GetConsoleCP() and GetConsoleOutputCP() directly in initstdio(). If someone closes sys.std* and recreate them later: os.device_encoding() can be use explicitly to keep the previous behaviour.

> It would still be better it is was unset afterwards. Third-party
> extensions could have LC_CTYPE-dependent behaviour.

If Python is embeded, it should not change the locale. Even if it is not embeded, it is maybe better to never set LC_CTYPE.

It is too late to touch such critical point in Python 3.2, but we may change it in Python 3.3.

----------
nosy: +haypo
versions: +Python 3.3 -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6203>
_______________________________________

From report at bugs.python.org  Thu Jan 27 12:42:30 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Thu, 27 Jan 2011 11:42:30 +0000
Subject: [issue11008] logging.dictConfig not documented as new in version 2.7
In-Reply-To: <1295975914.25.0.0685930703721.issue11008@psf.upfronthosting.co.za>
Message-ID: <1296128550.42.0.204573784466.issue11008@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

This also applies to Python 3.2 docs. I've made the changes - OK to checkin, Georg? (For 3.2, I mean)

----------
assignee: docs at python -> vinay.sajip
nosy: +georg.brandl, vinay.sajip
versions: +Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11008>
_______________________________________

From report at bugs.python.org  Thu Jan 27 13:34:21 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 27 Jan 2011 12:34:21 +0000
Subject: [issue4177] Crash in MIMEText on FreeBSD
In-Reply-To: <1224700839.13.0.201844476382.issue4177@psf.upfronthosting.co.za>
Message-ID: <1296131661.45.0.20914476362.issue4177@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> Something is very wrong with our code too. I have dumped the text
> that's cousing the "freeze" and run it using the test case scripts.
> It worked slow, but worked.

I retried test_MIMEText.tar.bz2	on FreeBSD 8.0 with 640 MB of memory: the program takes ~5 minutes, but it doesn't fail (no memory error or crash).

I suppose that the crash cannot be reproduced by test_MIMEText.tar.bz2 example, only with the full program. Because I don't have access to the full program, I am unable to reproduce the bug, and because there is no activity on this issue since 2 years: I close this issue.

If you have more information (especially a short script to reproduce the crash), reopen the issue or create a new issue (maybe more specific? eg. patch MIMEText to use less memory).

----------
nosy: +haypo
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4177>
_______________________________________

From report at bugs.python.org  Thu Jan 27 13:35:26 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 27 Jan 2011 12:35:26 +0000
Subject: [issue10952] Don't normalize module names to NFKC?
In-Reply-To: <1295488499.02.0.313090900295.issue10952@psf.upfronthosting.co.za>
Message-ID: <1296131726.59.0.551048718708.issue10952@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

It looks like there is nothing interesting to do here, so I close the issue (which is not a bug :-)).

----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10952>
_______________________________________

From report at bugs.python.org  Thu Jan 27 14:17:15 2011
From: report at bugs.python.org (Alan Isaac)
Date: Thu, 27 Jan 2011 13:17:15 +0000
Subject: [issue11023] pep 227 missing text
In-Reply-To: <1296134235.25.0.738218358402.issue11023@psf.upfronthosting.co.za>
Message-ID: <1296134235.25.0.738218358402.issue11023@psf.upfronthosting.co.za>


New submission from Alan Isaac <alan.isaac at gmail.com>:

In PEP 227 missing text is marked with XXX.  Most of this is just calls for examples and elaboration.  However under the Implementation section XXX marks a substantive question about the documentation.

Fixing this may be low priority, but a tracker search suggested it is currently not even being tracked ...

----------
assignee: docs at python
components: Documentation
messages: 127184
nosy: aisaac, docs at python
priority: normal
severity: normal
status: open
title: pep 227 missing text
type: feature request

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11023>
_______________________________________

From report at bugs.python.org  Thu Jan 27 14:29:23 2011
From: report at bugs.python.org (Giampaolo Rodola')
Date: Thu, 27 Jan 2011 13:29:23 +0000
Subject: [issue5097] asyncore.dispatcher_with_send undocumented
In-Reply-To: <1233235235.33.0.24123597522.issue5097@psf.upfronthosting.co.za>
Message-ID: <1296134963.89.0.997809608932.issue5097@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

I documented this some months ago:
http://docs.python.org/library/asyncore.html#asyncore.dispatcher_with_send
Being asynchat's push() method more convenient for such kind of task I expressively avoided to be too specific about dispatcher_with_send.

----------
resolution:  -> fixed
status: open -> closed
versions:  -Python 2.6, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5097>
_______________________________________

From report at bugs.python.org  Thu Jan 27 14:35:01 2011
From: report at bugs.python.org (Sebastian Spaeth)
Date: Thu, 27 Jan 2011 13:35:01 +0000
Subject: [issue11024] imaplib: Time2Internaldate() returns localized strings
In-Reply-To: <1296135301.42.0.767818406183.issue11024@psf.upfronthosting.co.za>
Message-ID: <1296135301.42.0.767818406183.issue11024@psf.upfronthosting.co.za>


New submission from Sebastian Spaeth <sebastian at sspaeth.de>:

imaplib's Time2Internaldate returns invalid (as localized) INTERNALDATE strings. Appending a message with such a time string leads to a:
19 BAD Command Argument Error. 11 (for MS?Exchange IMAP servers)

it returned "26-led-2011 18:23:44 +0100", however:

http://tools.ietf.org/html/rfc2060.html defines:
date_month      ::= "Jan" / "Feb" / "Mar" / "Apr" / "May" / "Jun" /
                    "Jul" / "Aug" / "Sep" / "Oct" / "Nov" / "Dec"

so it expects an English date format.

imaplib's Time2Internaldate uses time.strftime() to create the final string which uses the current locale, returning things such as:

"26-led-2011 18:23:44 +0100" rather than "26-Jan-2011 18:23:44 +0100".

For the right thing to do, we would need to set locale.setlocale(locale.LC_TIME, '') to get English formatting or we would need to use some home-grown parser that hardcodes the proper terms.

----------
components: Library (Lib)
messages: 127186
nosy: spaetz
priority: normal
severity: normal
status: open
title: imaplib: Time2Internaldate() returns localized strings
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11024>
_______________________________________

From report at bugs.python.org  Thu Jan 27 14:40:10 2011
From: report at bugs.python.org (Sebastian Spaeth)
Date: Thu, 27 Jan 2011 13:40:10 +0000
Subject: [issue11024] imaplib: Time2Internaldate() returns localized strings
In-Reply-To: <1296135301.42.0.767818406183.issue11024@psf.upfronthosting.co.za>
Message-ID: <1296135610.48.0.771309074686.issue11024@psf.upfronthosting.co.za>


Sebastian Spaeth <sebastian at sspaeth.de> added the comment:

P.S. To replicate this in ipython:

import locale, imaplib

locale.setlocale(locale.LC_ALL,'de_CH.utf8')
imaplib.Time2Internaldate(220254431)
Out[1]: '"24-Dez-1976 06:47:11 +0100"'

(Note the German 'Dez' rather than 'Dec')

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11024>
_______________________________________

From report at bugs.python.org  Thu Jan 27 14:47:23 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Thu, 27 Jan 2011 13:47:23 +0000
Subject: [issue11022] locale.setlocale() doesn't change I/O codec,
	os.environ[] does
In-Reply-To: <1296126025.04.0.965125504096.issue11022@psf.upfronthosting.co.za>
Message-ID: <1296136043.16.0.599021671506.issue11022@psf.upfronthosting.co.za>


Steffen Daode Nurpmeso <sdaoden at googlemail.com> added the comment:

> Anyway, I don't know understand why do you change your locale,
> because you know that your file encoding is Latin1. Why don't you
> use directly: open(filename, encoding='latin1')?

Fortunately Issue 9124 is being solved soon due to the very active
happy hacker haypo ...
I have read haypo's add-on to Issue 6203 and, since he refers to
this issue here, i'll add some thoughts of mine, though they possibly
should not belong into a bug tracker ...

My misunderstanding was based upon an old project of mine,
where i've used the environment to initialize the library state
upon program startup only, but afterwards the entire handling was centralized upon some "Locale" class (changes therein were dispatched
to and thus reflected by a TextCodec etc. - you may see Issue 9727,
though my solution was hardwired).
Like that turning one screw managed the entire system.

If Python would be my project, i would change this code,
because i do not see a real difference in os.environ[LC_]=
and locale.setlocale(LC_,)!
Both cases indicate the users desire to change a specific locale
setting and thus - of course - all the changes which that implies!
So why should there be a difference?

What i really have to say is that the (3.1) implementation of getpreferredencoding() is horror, not only in respect to SMP
(it's a no-go, then, even with locking, but that's not present).
If Python would be mine (after thinking one hour without any
feedback of anybody else), i would do the following:
- upon program startup, init LibC environment:
  setlocale(LC_ALL, "");
  (see <http://pubs.opengroup.org/onlinepubs/009695399/functions/setlocale.html>)
  Then init this very basic codeset in an unthreaded state:
  global_very_default_codeset = nl_langinfo(CODESET);
  After that, rename this terrible "do_setlocale" argument to
  "use_locale_active_on_program_startup".
  Then i would start a discussion wether such an argument is useful at
  all, because you possibly always ever say "False".
  Do ya???

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11022>
_______________________________________

From report at bugs.python.org  Thu Jan 27 14:51:44 2011
From: report at bugs.python.org (Giampaolo Rodola')
Date: Thu, 27 Jan 2011 13:51:44 +0000
Subject: [issue1191964] asynchronous Subprocess
Message-ID: <1296136304.58.0.697980679585.issue1191964@psf.upfronthosting.co.za>


Changes by Giampaolo Rodola' <g.rodola at gmail.com>:


----------
versions: +Python 3.3 -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1191964>
_______________________________________

From report at bugs.python.org  Thu Jan 27 15:15:37 2011
From: report at bugs.python.org (Sebastian Spaeth)
Date: Thu, 27 Jan 2011 14:15:37 +0000
Subject: [issue11024] imaplib: Time2Internaldate() returns localized strings
In-Reply-To: <1296135301.42.0.767818406183.issue11024@psf.upfronthosting.co.za>
Message-ID: <1296137737.17.0.112475929833.issue11024@psf.upfronthosting.co.za>


Sebastian Spaeth <sebastian at sspaeth.de> added the comment:

CC'ing lavajoe as he seemed to be busy with some of imaplib's Date stuff the last couple of days.

----------
nosy: +lavajoe

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11024>
_______________________________________

From report at bugs.python.org  Thu Jan 27 15:17:02 2011
From: report at bugs.python.org (Boris FELD)
Date: Thu, 27 Jan 2011 14:17:02 +0000
Subject: [issue11025] Distutils2 install command without setup.py or setup.cfg
	create an UNKNOWN-UNKNOWN.dist-info distribution
In-Reply-To: <1296137822.54.0.488417839066.issue11025@psf.upfronthosting.co.za>
Message-ID: <1296137822.54.0.488417839066.issue11025@psf.upfronthosting.co.za>


New submission from Boris FELD <lothiraldan at gmail.com>:

Distutils2 install command don't display error if you try to launch it in a directory without setup.py nor setup.cfg files. It install an UNKNOWN-UNKNOWN.dist-info distribution in your site-package with all meta-data file set to UNKNOWN.

----------
assignee: tarek
components: Distutils2
files: METADATA
messages: 127190
nosy: Boris.FELD, eric.araujo, tarek, tarek-ziade
priority: normal
severity: normal
status: open
title: Distutils2 install command without setup.py or setup.cfg create an UNKNOWN-UNKNOWN.dist-info distribution
versions: Python 2.6
Added file: http://bugs.python.org/file20545/METADATA

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11025>
_______________________________________

From report at bugs.python.org  Thu Jan 27 15:34:04 2011
From: report at bugs.python.org (Thorsten Simons)
Date: Thu, 27 Jan 2011 14:34:04 +0000
Subject: [issue10932] distutils.core.setup - data_files misbehaviour ?
In-Reply-To: <1295353825.23.0.755300594789.issue10932@psf.upfronthosting.co.za>
Message-ID: <1296138844.91.0.162670217583.issue10932@psf.upfronthosting.co.za>


Thorsten Simons <th at snomis.de> added the comment:

Hi ?ric, All,

thank you for the directions you gave me!
It's all about a call of os.path.basename() missing in sdist.py. Pls. see attached diff.

Regards,
Thorsten

----------
keywords: +patch
Added file: http://bugs.python.org/file20546/fix-sdist.py.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10932>
_______________________________________

From report at bugs.python.org  Thu Jan 27 15:35:35 2011
From: report at bugs.python.org (Boris FELD)
Date: Thu, 27 Jan 2011 14:35:35 +0000
Subject: [issue11026] Distutils2 install command fail with python 2.5/2.7
In-Reply-To: <1296138935.4.0.881048172812.issue11026@psf.upfronthosting.co.za>
Message-ID: <1296138935.4.0.881048172812.issue11026@psf.upfronthosting.co.za>


New submission from Boris FELD <lothiraldan at gmail.com>:

Distutils2 install command fail with both python 2.5 and python 2.7 while it works with python 2.6.

$ python -V
python 2.5.4
$ python -m "distutils2.run" install
usage: run.py [global_opts] cmd1 [cmd1_opts] [cmd2 [cmd2_opts] ...]
   or: run.py --help [cmd1 cmd2 ...]
   or: run.py --help-commands
   or: run.py cmd --help

error: Invalid command install
################################
$ python -V
Python 2.7.1
$ python -m "distutils2.run" install
usage: run.py [global_opts] cmd1 [cmd1_opts] [cmd2 [cmd2_opts] ...]
   or: run.py --help [cmd1 cmd2 ...]
   or: run.py --help-commands
   or: run.py cmd --help

error: Invalid command install

It fail it a setup.cfg exists or not in the current directory.

----------
assignee: tarek
components: Distutils2
messages: 127192
nosy: Boris.FELD, eric.araujo, tarek, tarek-ziade
priority: normal
severity: normal
status: open
title: Distutils2 install command fail with python 2.5/2.7
versions: Python 2.5, Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11026>
_______________________________________

From report at bugs.python.org  Thu Jan 27 15:37:06 2011
From: report at bugs.python.org (Boris FELD)
Date: Thu, 27 Jan 2011 14:37:06 +0000
Subject: [issue11026] Distutils2 install command fail with python 2.5/2.7
In-Reply-To: <1296138935.4.0.881048172812.issue11026@psf.upfronthosting.co.za>
Message-ID: <1296139026.28.0.271098170433.issue11026@psf.upfronthosting.co.za>


Changes by Boris FELD <lothiraldan at gmail.com>:


----------
type:  -> crash

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11026>
_______________________________________

From report at bugs.python.org  Thu Jan 27 15:37:05 2011
From: report at bugs.python.org (Kunjesh Kaushik)
Date: Thu, 27 Jan 2011 14:37:05 +0000
Subject: [issue11027] Allow spaces around section header in ConfigParser
In-Reply-To: <1296139025.05.0.619488294513.issue11027@psf.upfronthosting.co.za>
Message-ID: <1296139025.05.0.619488294513.issue11027@psf.upfronthosting.co.za>


New submission from Kunjesh Kaushik <kunjesh.kaushik at gmail.com>:

It is often desirable to be able to write a section with spaces around the header, as in "[ default ]" instead of "[default]" for the sake of readability of configuration file. I am not sure if this is the "standard" format of configuration files.

The following (attached) patch will achieve the desired result. It is also backward-compatible. Kindly arrange for the patch to be applied to the repository or to a future release.

Original Code Location: http://svn.python.org/view/*checkout*/python/branches/release27-maint/Lib/ConfigParser.py?revision=84443

Index: Lib/ConfigParser.py
===================================================================
--- Lib/ConfigParser.py	(revision 84443)
+++ Lib/ConfigParser.py	(working copy)
@@ -432,7 +432,7 @@
     #
     SECTCRE = re.compile(
         r'\['                                 # [
-        r'(?P<header>[^]]+)'                  # very permissive!
+        r'\s*(?P<header>[^]]+)\s*'            # very permissive!
         r'\]'                                 # ]
         )
     OPTCRE = re.compile(

----------
components: Library (Lib)
files: allow_spaces_around_section_header.diff
keywords: patch
messages: 127193
nosy: Kunjesh.Kaushik
priority: normal
severity: normal
status: open
title: Allow spaces around section header in ConfigParser
type: feature request
versions: Python 2.7
Added file: http://bugs.python.org/file20547/allow_spaces_around_section_header.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11027>
_______________________________________

From report at bugs.python.org  Thu Jan 27 15:39:39 2011
From: report at bugs.python.org (Boris FELD)
Date: Thu, 27 Jan 2011 14:39:39 +0000
Subject: [issue11026] Distutils2 install command fail with python 2.5/2.7
In-Reply-To: <1296138935.4.0.881048172812.issue11026@psf.upfronthosting.co.za>
Message-ID: <1296139179.5.0.261580334126.issue11026@psf.upfronthosting.co.za>


Boris FELD <lothiraldan at gmail.com> added the comment:

The new command for installation is install_dist, sorry.

----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11026>
_______________________________________

From report at bugs.python.org  Thu Jan 27 15:39:52 2011
From: report at bugs.python.org (Joe Peterson)
Date: Thu, 27 Jan 2011 14:39:52 +0000
Subject: [issue11024] imaplib: Time2Internaldate() returns localized strings
In-Reply-To: <1296135301.42.0.767818406183.issue11024@psf.upfronthosting.co.za>
Message-ID: <1296139192.52.0.302799050477.issue11024@psf.upfronthosting.co.za>


Joe Peterson <joe at skyrush.com> added the comment:

Sebastian,

Yes, in fact Alexander Belopolsky (belopolsky) brought up the the locale issue for this very function in one of the other issue comments.

The invert function, Internaldate2tuple(), actually does its own parsing using a regex match (and so does not have the problem), but you are right, Time2Internaldate() has this issue.

----------
versions: +3rd party -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11024>
_______________________________________

From report at bugs.python.org  Thu Jan 27 15:44:33 2011
From: report at bugs.python.org (Boris FELD)
Date: Thu, 27 Jan 2011 14:44:33 +0000
Subject: [issue11025] Distutils2 install command without setup.py or setup.cfg
	create an UNKNOWN-UNKNOWN.dist-info distribution
In-Reply-To: <1296137822.54.0.488417839066.issue11025@psf.upfronthosting.co.za>
Message-ID: <1296139473.04.0.402502124936.issue11025@psf.upfronthosting.co.za>


Boris FELD <lothiraldan at gmail.com> added the comment:

It also fails with python 2.5 and python 2.7 with install_dist command.

----------
versions: +Python 2.5, Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11025>
_______________________________________

From report at bugs.python.org  Thu Jan 27 15:45:08 2011
From: report at bugs.python.org (alain tty)
Date: Thu, 27 Jan 2011 14:45:08 +0000
Subject: [issue11028] Implement the setup.py -> setup.cfg in mkcfg
In-Reply-To: <1296139508.67.0.695480903327.issue11028@psf.upfronthosting.co.za>
Message-ID: <1296139508.67.0.695480903327.issue11028@psf.upfronthosting.co.za>


New submission from alain tty <alaintty at gmail.com>:

It shall be interesting to simplify the building of the setup.cfg from an existing setup.py.
A distutils2.mkcfg.load_existing_setup_script function already exists but it raises NotImplementedError.
Since taking into account setuptools could be straightforward we propose to add a implementation that takes care of distutils arguments only.

----------
assignee: tarek
components: Distutils2
messages: 127197
nosy: alaintty, eric.araujo, tarek, tarek-ziade
priority: normal
severity: normal
status: open
title: Implement the setup.py -> setup.cfg in mkcfg
type: feature request

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11028>
_______________________________________

From report at bugs.python.org  Thu Jan 27 15:50:09 2011
From: report at bugs.python.org (Martin von Gagern)
Date: Thu, 27 Jan 2011 14:50:09 +0000
Subject: [issue10680] argparse: titles and add_mutually_exclusive_group don't
	mix (even with workaround)
In-Reply-To: <1292083248.97.0.928495782189.issue10680@psf.upfronthosting.co.za>
Message-ID: <1296139809.55.0.264893674603.issue10680@psf.upfronthosting.co.za>


Martin von Gagern <Martin.vGagern at gmx.net> added the comment:

I've added a unit test for this nested mutex scenario. The attached patch includes the original fix as well, as for some reason the patch by loewis wouldn't apply to my tree automatically.

----------
nosy: +gagern
Added file: http://bugs.python.org/file20548/issue10680_withTestcase.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10680>
_______________________________________

From report at bugs.python.org  Thu Jan 27 16:43:52 2011
From: report at bugs.python.org (Sebastian Spaeth)
Date: Thu, 27 Jan 2011 15:43:52 +0000
Subject: [issue11024] imaplib: Time2Internaldate() returns localized strings
In-Reply-To: <1296135301.42.0.767818406183.issue11024@psf.upfronthosting.co.za>
Message-ID: <1296143032.31.0.170546466388.issue11024@psf.upfronthosting.co.za>


Sebastian Spaeth <sebastian at sspaeth.de> added the comment:

I think I found the issue he mentioned, however it was about the functions taking the local time (rather than UTC), which is fine.

The problem is that Time2Internaldate is used for every .append() operation internally, producing invalid dates which are handed to the IMAP server. So in most cases, the IMAP server will silently ignore the time and use the current time (as per IMAP?RFC) or it will complain and barf out (as the MS?Exchange server rightly does.

So this is more than just an inconvenience, it outright prevents intenational users from APPENDing new messages to a server (or silently bodges the message date) as there is no way around using that function...

Sorry if this sounds like whining :-) I don't even have a patch handy...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11024>
_______________________________________

From report at bugs.python.org  Thu Jan 27 16:52:29 2011
From: report at bugs.python.org (Joe Peterson)
Date: Thu, 27 Jan 2011 15:52:29 +0000
Subject: [issue11024] imaplib: Time2Internaldate() returns localized strings
In-Reply-To: <1296135301.42.0.767818406183.issue11024@psf.upfronthosting.co.za>
Message-ID: <1296143549.97.0.376927317016.issue11024@psf.upfronthosting.co.za>


Joe Peterson <joe at skyrush.com> added the comment:

Yes, that's serious, certainly.

A patch should be fairly straightforward, given that part of the formatting logic is already there (for the TZ offset at the end).  You just need to format the 6 values, and do a lookup for the month name.

If you want to try to work up one, I can take a look, or maybe, if I have some time today, I'll try to do one quickly...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11024>
_______________________________________

From report at bugs.python.org  Thu Jan 27 17:58:10 2011
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Thu, 27 Jan 2011 16:58:10 +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: <1296147490.78.0.493021453916.issue6203@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/issue6203>
_______________________________________

From report at bugs.python.org  Thu Jan 27 17:58:48 2011
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Thu, 27 Jan 2011 16:58:48 +0000
Subject: [issue11022] locale.setlocale() doesn't change I/O codec,
	os.environ[] does
In-Reply-To: <1296126025.04.0.965125504096.issue11022@psf.upfronthosting.co.za>
Message-ID: <1296147528.15.0.66727743477.issue11022@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/issue11022>
_______________________________________

From report at bugs.python.org  Thu Jan 27 18:01:04 2011
From: report at bugs.python.org (Scott M)
Date: Thu, 27 Jan 2011 17:01:04 +0000
Subject: [issue11029] Crash, 2.7.1, Tkinter and threads and line drawing
In-Reply-To: <1296147664.2.0.443864502869.issue11029@psf.upfronthosting.co.za>
Message-ID: <1296147664.2.0.443864502869.issue11029@psf.upfronthosting.co.za>


New submission from Scott M <scott.mayo at comcast.net>:

Running on dual core Windows XP. 

The function should draw a parabolicish shape for each click on launch. But if you click Launch over and over, very fast, you get bizarre crashes instead: Python.exe has encoutered a problem, yadda. tcl85.dll. It rarely takes many clicks.

Apologies for the coding style; this has been hacked down from a larger app.

In the console window:

Exception in thread Thread-5:
Traceback (most recent call last):
  File "C:\Python27\lib\threading.py", line 530, in __bootstrap_inner
    self.run()
  File "C:\Documents and Settings\mayos\Desktop\PMT2\MyProjects\TkinterCrash.py"
, line 47, in run
    self.app.arrival_122((self.target, y, z))
  File "C:\Documents and Settings\mayos\Desktop\PMT2\MyProjects\TkinterCrash.py"
, line 100, in arrival_122
    self.label.config(text= str(message[0])+ " " + str(message[1]))
  File "C:\Python27\lib\lib-tk\Tkinter.py", line 1202, in configure
    return self._configure('configure', cnf, kw)
  File "C:\Python27\lib\lib-tk\Tkinter.py", line 1193, in _configure
    self.tk.call(_flatten((self._w, cmd)) + self._options(cnf))
TclError: invalid command name "source C:/Python27/tcl/tk8.5/menu.tcl"

Exception in thread Thread-4:
Traceback (most recent call last):
  File "C:\Python27\lib\threading.py", line 530, in __bootstrap_inner
    self.run()
  File "C:\Documents and Settings\mayos\Desktop\PMT2\MyProjects\TkinterCrash.py"
, line 47, in run
    self.app.arrival_122((self.target, y, z))
  File "C:\Documents and Settings\mayos\Desktop\PMT2\MyProjects\TkinterCrash.py"
, line 125, in arrival_122
    self.graph.create_line(self.trackCoordinates[tn], new_yz)
  File "C:\Python27\lib\lib-tk\Tkinter.py", line 2201, in create_line
    return self._create('line', args, kw)
  File "C:\Python27\lib\lib-tk\Tkinter.py", line 2189, in _create
    *(args + self._options(cnf, kw))))
TclError: invalid command name "line"

Also saw:
  File "C:\Python27\lib\lib-tk\Tkinter.py", line 2201, in create_line
    return self._create('line', args, kw)
  File "C:\Python27\lib\lib-tk\Tkinter.py", line 2189, in _create
    *(args + self._options(cnf, kw))))
TclError: bad option "665.4400009999997": must be addtag, bbox, bind, canvasx, canvasy, cget, configure, coords, create, dchars, delete, dtag, find, focus, gettags, icursor, index, insert, itemcget, itemconfigure, lower, move, postscript, raise, scale, scan, select, type, xview, or yview

----------
components: Tkinter
files: TkinterCrash.py
messages: 127201
nosy: PythonInTheGrass
priority: normal
severity: normal
status: open
title: Crash, 2.7.1, Tkinter and threads and line drawing
type: crash
versions: Python 2.7
Added file: http://bugs.python.org/file20549/TkinterCrash.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11029>
_______________________________________

From report at bugs.python.org  Thu Jan 27 18:06:24 2011
From: report at bugs.python.org (Brian Curtin)
Date: Thu, 27 Jan 2011 17:06:24 +0000
Subject: [issue11029] Crash, 2.7.1, Tkinter and threads and line drawing
In-Reply-To: <1296147664.2.0.443864502869.issue11029@psf.upfronthosting.co.za>
Message-ID: <1296147984.93.0.208237545835.issue11029@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
nosy: +brian.curtin

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11029>
_______________________________________

From report at bugs.python.org  Thu Jan 27 18:49:22 2011
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 27 Jan 2011 17:49:22 +0000
Subject: [issue11008] logging.dictConfig not documented as new in version 2.7
In-Reply-To: <1295975914.25.0.0685930703721.issue11008@psf.upfronthosting.co.za>
Message-ID: <1296150562.99.0.24230178154.issue11008@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Yes, please go ahead.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11008>
_______________________________________

From report at bugs.python.org  Thu Jan 27 18:49:57 2011
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 27 Jan 2011 17:49:57 +0000
Subject: [issue8914] Run clang's static analyzer
In-Reply-To: <1275795174.58.0.536949662024.issue8914@psf.upfronthosting.co.za>
Message-ID: <1296150597.38.0.548363262316.issue8914@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Turns out I was using pax wrong. =) Thought it automatically compressed new files; turns out it doesn't. Using the zx compressor it shrank the 70 MB file down, so ignore the Google Docs upload and just grab this.

----------
Added file: http://bugs.python.org/file20550/clang_analyzer_253.tar.xz

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8914>
_______________________________________

From report at bugs.python.org  Thu Jan 27 18:54:11 2011
From: report at bugs.python.org (R. David Murray)
Date: Thu, 27 Jan 2011 17:54:11 +0000
Subject: [issue11017] optparse: error: invalid integer value
In-Reply-To: <1296044964.44.0.826782436299.issue11017@psf.upfronthosting.co.za>
Message-ID: <1296150851.85.0.401425992151.issue11017@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Well, it is certainly intentional, then.  Whether it is good is a different story, but also a moot question since optparse has been replaced by argparse.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11017>
_______________________________________

From report at bugs.python.org  Thu Jan 27 18:54:27 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 27 Jan 2011 17:54:27 +0000
Subject: [issue8914] Run clang's static analyzer
In-Reply-To: <1275795174.58.0.536949662024.issue8914@psf.upfronthosting.co.za>
Message-ID: <1296150867.8.0.2100136267.issue8914@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

For the record, you don't have to use pax, recent GNU tar handles xz fine (use the -J option).

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8914>
_______________________________________

From report at bugs.python.org  Thu Jan 27 19:12:59 2011
From: report at bugs.python.org (R. David Murray)
Date: Thu, 27 Jan 2011 18:12:59 +0000
Subject: [issue11024] imaplib: Time2Internaldate() returns localized strings
In-Reply-To: <1296135301.42.0.767818406183.issue11024@psf.upfronthosting.co.za>
Message-ID: <1296151979.02.0.988222832003.issue11024@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
nosy: +r.david.murray
stage:  -> needs patch
versions: +Python 2.7, Python 3.1, Python 3.2 -3rd party

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11024>
_______________________________________

From report at bugs.python.org  Thu Jan 27 19:16:29 2011
From: report at bugs.python.org (R. David Murray)
Date: Thu, 27 Jan 2011 18:16:29 +0000
Subject: [issue11027] Allow spaces around section header in ConfigParser
In-Reply-To: <1296139025.05.0.619488294513.issue11027@psf.upfronthosting.co.za>
Message-ID: <1296152189.79.0.440261848695.issue11027@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

A feature request can only go in to 3.3 at this point.  ConfigParser has had a serious overhaul in 3.2, by the way.

----------
assignee:  -> lukasz.langa
nosy: +lukasz.langa, r.david.murray
versions: +Python 3.3 -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11027>
_______________________________________

From report at bugs.python.org  Thu Jan 27 19:48:57 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Thu, 27 Jan 2011 18:48:57 +0000
Subject: [issue11030] regrtest - allow for relative path with --coverdir
In-Reply-To: <1296154137.39.0.416513090061.issue11030@psf.upfronthosting.co.za>
Message-ID: <1296154137.39.0.416513090061.issue11030@psf.upfronthosting.co.za>


New submission from Sandro Tosi <sandro.tosi at gmail.com>:

Hi, following up msg127157 here's a patch to allow for relative path when using --coverdir.

The current solution uses getcwd() but since CWD is replaced by a temporary location before calling main(), then the resulting dir is in an unexpected location.

using support.SAVECWD we use the saved CWD that's where the script is executed, so the relative path is created/used where expected.

----------
assignee: sandro.tosi
components: Tests
files: regrtest_coverdir_relative_path-py3k.patch
keywords: patch
messages: 127207
nosy: sandro.tosi
priority: low
severity: normal
stage: patch review
status: open
title: regrtest - allow for relative path with --coverdir
versions: Python 3.3
Added file: http://bugs.python.org/file20551/regrtest_coverdir_relative_path-py3k.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11030>
_______________________________________

From report at bugs.python.org  Thu Jan 27 19:49:22 2011
From: report at bugs.python.org (Geoge R. Goffe)
Date: Thu, 27 Jan 2011 18:49:22 +0000
Subject: [issue11013] Build of  2.7 svn fails in readline
In-Reply-To: <1296007832.48.0.816263940952.issue11013@psf.upfronthosting.co.za>
Message-ID: <1296154162.09.0.20710085738.issue11013@psf.upfronthosting.co.za>


Geoge R. Goffe <grgoffe at yahoo.com> added the comment:

Brett,

Here's the file you requested.

Thanks for your help.

George...

----------
status: pending -> open
Added file: http://bugs.python.org/file20552/readline.i.gz

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11013>
_______________________________________

From report at bugs.python.org  Thu Jan 27 19:50:21 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 27 Jan 2011 18:50:21 +0000
Subject: [issue11022] locale.setlocale() doesn't change I/O codec,
	os.environ[] does
In-Reply-To: <1296126025.04.0.965125504096.issue11022@psf.upfronthosting.co.za>
Message-ID: <1296154221.96.0.598359216981.issue11022@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Both cases indicate the users desire to change a specific locale
> setting and thus - of course - all the changes which that implies!
> So why should there be a difference?

I don't think it's intentional. I would be +1 on changing to getpreferredencoding(False).

----------
components: +IO
nosy: +loewis, pitrou
versions: +Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11022>
_______________________________________

From report at bugs.python.org  Thu Jan 27 19:51:32 2011
From: report at bugs.python.org (Michal Nowikowski)
Date: Thu, 27 Jan 2011 18:51:32 +0000
Subject: [issue10999] os.chflags refers to stat constants,
	but the constants are not documented in the stat module
In-Reply-To: <1295898075.1.0.406467023745.issue10999@psf.upfronthosting.co.za>
Message-ID: <1296154292.48.0.594925415122.issue10999@psf.upfronthosting.co.za>


Changes by Michal Nowikowski <godfryd at gmail.com>:


----------
nosy: +godfryd

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10999>
_______________________________________

From report at bugs.python.org  Thu Jan 27 19:54:02 2011
From: report at bugs.python.org (Uoti Urpala)
Date: Thu, 27 Jan 2011 18:54:02 +0000
Subject: [issue3982] support .format for bytes
In-Reply-To: <1222530641.39.0.0764973101836.issue3982@psf.upfronthosting.co.za>
Message-ID: <1296154442.72.0.0972227378927.issue3982@psf.upfronthosting.co.za>


Uoti Urpala <uoti.urpala at pp1.inet.fi> added the comment:

This kind of formatting is needed quite often when working on network protocols or file formats, and I think the replies here fail to address important issues. In general you can't encode after formatting, as that doesn't work with binary data, and often it's not appropriate for the low-level routines doing the formatting to know what charset the data is in even if it is text (so it should be fed in already encoded as bytes). The replies from Martin v. L?wis seem to argue that you could use methods other than formatting; that would work almost as well as an argument to remove formatting support from text strings, and IMO cases where formatting is the best option are common.

Here's an example (based on real use but simplified):

template = b"""
stuff here
header1: {}
header2: {}
more stuff
"""

def lowlevel_send(s, b1, b2):  # s socket, b1 and b2 bytes
    s.send(template.format(b1, b2))

To clarify the requirements a bit, the issue is not so much about having a .format method on byte string objects (that's just the most natural-looking way of solving it); the core requirement is to have a formatting operator that can take byte strings as *arguments* and produce byte string *output* where the arguments can be placed unchanged.

----------
nosy: +uau

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3982>
_______________________________________

From report at bugs.python.org  Thu Jan 27 19:55:40 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 27 Jan 2011 18:55:40 +0000
Subject: [issue11027] Allow spaces around section header in ConfigParser
In-Reply-To: <1296139025.05.0.619488294513.issue11027@psf.upfronthosting.co.za>
Message-ID: <1296154540.24.0.317961505364.issue11027@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

There's a case to be made that the current regex is buggy.  It already accepts whitespace around the header name but doesn't strip it.  ISTM, this is undesirable:  [ section header ]  --> ' section header ' instead of 'section header'.

>>> import configparser
>>> r = configparser.ConfigParser.SECTCRE
>>> r.match('[ section header ]').group('header')
' section header '

That result is not want people would usually want or expect.  I don't see any advantage to deferring this to 3.3.

----------
keywords: +easy -patch
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11027>
_______________________________________

From report at bugs.python.org  Thu Jan 27 20:02:19 2011
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 27 Jan 2011 19:02:19 +0000
Subject: [issue11013] Build of  2.7 svn fails in readline
In-Reply-To: <1296007832.48.0.816263940952.issue11013@psf.upfronthosting.co.za>
Message-ID: <1296154939.38.0.118010316066.issue11013@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Martin actually asked for the file and deserves the thanks.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11013>
_______________________________________

From report at bugs.python.org  Thu Jan 27 20:17:32 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Thu, 27 Jan 2011 19:17:32 +0000
Subject: [issue11008] logging.dictConfig not documented as new in version 2.7
In-Reply-To: <1295975914.25.0.0685930703721.issue11008@psf.upfronthosting.co.za>
Message-ID: <1296155852.16.0.893021907658.issue11008@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

Fix checked into py3k and release27-maint (r88214).

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11008>
_______________________________________

From report at bugs.python.org  Thu Jan 27 20:31:04 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 27 Jan 2011 19:31:04 +0000
Subject: [issue11022] locale.setlocale() doesn't change I/O codec,	os.environ
In-Reply-To: <1296154221.96.0.598359216981.issue11022@psf.upfronthosting.co.za>
Message-ID: <4D41C7F4.7070101@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

>> Both cases indicate the users desire to change a specific locale
>> setting and thus - of course - all the changes which that implies!
>> So why should there be a difference?
> 
> I don't think it's intentional. I would be +1 on changing to getpreferredencoding(False).

That won't actually work. If you always use the C library's locale
setting, most scripts will run in the C locale, and fail to read text
files properly.

----------
title: locale.setlocale() doesn't change I/O codec, os.environ[] does -> locale.setlocale() doesn't change I/O codec,	os.environ

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11022>
_______________________________________

From report at bugs.python.org  Thu Jan 27 20:33:08 2011
From: report at bugs.python.org (Kunjesh Kaushik)
Date: Thu, 27 Jan 2011 19:33:08 +0000
Subject: [issue11027] Allow spaces around section header in ConfigParser
In-Reply-To: <1296139025.05.0.619488294513.issue11027@psf.upfronthosting.co.za>
Message-ID: <1296156788.38.0.833026038793.issue11027@psf.upfronthosting.co.za>


Kunjesh Kaushik <kunjesh.kaushik at gmail.com> added the comment:

Mr. Raymond has raised a valid point. On second thought, I think the submitted patch won't resolve the issue.

>>> import re
>>> r = re.compile(r'\[\s*(?P<header>[^]]+)\s*\]') # as in the patch
>>> r.match('[ section header ]').group('header')  # still has issues
'section header '

ISTM, the only solution to this problem is to strip the section headers while parsing the file. Subsequent access mechanism should also follow suit. IMHO, section headers should be made case-insensitive as well -- similar to option keys.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11027>
_______________________________________

From report at bugs.python.org  Thu Jan 27 20:38:23 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 27 Jan 2011 19:38:23 +0000
Subject: [issue11013] Build of  2.7 svn fails in readline
In-Reply-To: <1296007832.48.0.816263940952.issue11013@psf.upfronthosting.co.za>
Message-ID: <1296157103.71.0.206792344838.issue11013@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

What is /usr/lsd/Linux? This seems broken. Please take a look at /usr/lsd/Linux/include/readline/history.h - it appears to be an empty file. Make sure you have a working copy of the readline header files installed, and make sure the build process picks them up.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11013>
_______________________________________

From report at bugs.python.org  Thu Jan 27 20:58:49 2011
From: report at bugs.python.org (Geoge R. Goffe)
Date: Thu, 27 Jan 2011 19:58:49 +0000
Subject: [issue11013] Build of  2.7 svn fails in readline
In-Reply-To: <1296157103.71.0.206792344838.issue11013@psf.upfronthosting.co.za>
Message-ID: <208542.3961.qm@web162012.mail.bf1.yahoo.com>


Geoge R. Goffe <grgoffe at yahoo.com> added the comment:

Martin,

I'm looking at the file right now. history.h is a link to readline.h which has 6771 characters in it.

George...

goffe at goffeg bash-4.1 /usr/lsd };-) find . -name 'readline.h' -ls
205381?????? 8 -r--r--r--???? 1 goffe?????? nonconf?????????? 6771 Nov 23 11:49 ./Linux/include/readline/readline.h
goffe at goffeg bash-4.1 /usr/lsd };-) l /usr/lsd/Linux/include/readline/history.h
lrwxrwxrwx 1 goffe nonconf 10 Nov 23 11:49 /usr/lsd/Linux/include/readline/history.h -> readline.h
goffe at goffeg bash-4.1 /usr/lsd };-) l /usr/lsd/Linux/include/readline/readline.h
-r--r--r-- 1 goffe nonconf 6771 Nov 23 11:49 /usr/lsd/Linux/include/readline/readline.h

"It's not what you know that hurts you, It's what you know that ain't so." Wil Rogers

--- On Thu, 1/27/11, Martin v. L??wis <report at bugs.python.org> wrote:

From: Martin v. L??wis <report at bugs.python.org>
Subject: [issue11013] Build of  2.7 svn fails in readline
To: grgoffe at yahoo.com
Date: Thursday, January 27, 2011, 11:38 AM

Martin v. L??wis <martin at v.loewis.de> added the comment:

What is /usr/lsd/Linux? This seems broken. Please take a look at /usr/lsd/Linux/include/readline/history.h - it appears to be an empty file. Make sure you have a working copy of the readline header files installed, and make sure the build process picks them up.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11013>
_______________________________________

----------
Added file: http://bugs.python.org/file20553/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11013>
_______________________________________
-------------- next part --------------
<table cellspacing="0" cellpadding="0" border="0" ><tr><td valign="top" style="font: inherit;">Martin,<br><br>I'm looking at the file right now. history.h is a link to readline.h which has 6771 characters in it.<br><br>George...<br><br>goffe at goffeg bash-4.1 /usr/lsd };-) find . -name 'readline.h' -ls<br>205381&nbsp;&nbsp;&nbsp; 8 -r--r--r--&nbsp;&nbsp; 1 goffe&nbsp;&nbsp;&nbsp; nonconf&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 6771 Nov 23 11:49 ./Linux/include/readline/readline.h<br>goffe at goffeg bash-4.1 /usr/lsd };-) l /usr/lsd/Linux/include/readline/history.h<br>lrwxrwxrwx 1 goffe nonconf 10 Nov 23 11:49 /usr/lsd/Linux/include/readline/history.h -&gt; readline.h<br>goffe at goffeg bash-4.1 /usr/lsd };-) l /usr/lsd/Linux/include/readline/readline.h<br>-r--r--r-- 1 goffe nonconf 6771 Nov 23 11:49 /usr/lsd/Linux/include/readline/readline.h<br><br><br><br><br><br>"It's not what you know that hurts you, It's what you know that ain't so." Wil Rogers<br><br>--- On <b>Thu,
 1/27/11, Martin v. L??wis <i>&lt;report at bugs.python.org&gt;</i></b> wrote:<br><blockquote style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px;"><br>From: Martin v. L??wis &lt;report at bugs.python.org&gt;<br>Subject: [issue11013] Build of  2.7 svn fails in readline<br>To: grgoffe at yahoo.com<br>Date: Thursday, January 27, 2011, 11:38 AM<br><br><div class="plainMail"><br>Martin v. L??wis &lt;<a ymailto="mailto:martin at v.loewis.de" href="/mc/compose?to=martin at v.loewis.de">martin at v.loewis.de</a>&gt; added the comment:<br><br>What is /usr/lsd/Linux? This seems broken. Please take a look at /usr/lsd/Linux/include/readline/history.h - it appears to be an empty file. Make sure you have a working copy of the readline header files installed, and make sure the build process picks them up.<br><br>----------<br><br>_______________________________________<br>Python tracker &lt;<a ymailto="mailto:report at bugs.python.org"
 href="/mc/compose?to=report at bugs.python.org">report at bugs.python.org</a>&gt;<br>&lt;<a href="http://bugs.python.org/issue11013" target="_blank">http://bugs.python.org/issue11013</a>&gt;<br>_______________________________________<br></div></blockquote></td></tr></table><br>

From report at bugs.python.org  Thu Jan 27 21:01:52 2011
From: report at bugs.python.org (R. David Murray)
Date: Thu, 27 Jan 2011 20:01:52 +0000
Subject: [issue11027] Allow spaces around section header in ConfigParser
In-Reply-To: <1296139025.05.0.619488294513.issue11027@psf.upfronthosting.co.za>
Message-ID: <1296158512.66.0.554948604325.issue11027@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Well, there's still a backward compatibility issue: if this is changed, currently working code may break.  Maybe Lukasz or Fred will have a guess as to how likely that is, because I don't.

----------
nosy: +fdrake

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11027>
_______________________________________

From report at bugs.python.org  Thu Jan 27 21:12:03 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 27 Jan 2011 20:12:03 +0000
Subject: [issue11013] Build of  2.7 svn fails in readline
In-Reply-To: <208542.3961.qm@web162012.mail.bf1.yahoo.com>
Message-ID: <4D41D192.3090909@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> I'm looking at the file right now. history.h is a link to readline.h

Ah, that's wrong. It must be a separate file, entirely different from
readline.h.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11013>
_______________________________________

From report at bugs.python.org  Thu Jan 27 21:21:06 2011
From: report at bugs.python.org (Geoge R. Goffe)
Date: Thu, 27 Jan 2011 20:21:06 +0000
Subject: [issue11013] Build of  2.7 svn fails in readline
In-Reply-To: <4D41D192.3090909@v.loewis.de>
Message-ID: <146148.16485.qm@web162012.mail.bf1.yahoo.com>


Geoge R. Goffe <grgoffe at yahoo.com> added the comment:

Martin,

I traced back to where that readline installation came from... It's the latest version from ftp.gnu.org + patches.

George...

"It's not what you know that hurts you, It's what you know that ain't so." Wil Rogers

--- On Thu, 1/27/11, Martin v. L??wis <report at bugs.python.org> wrote:

From: Martin v. L??wis <report at bugs.python.org>
Subject: [issue11013] Build of  2.7 svn fails in readline
To: grgoffe at yahoo.com
Date: Thursday, January 27, 2011, 12:12 PM

Martin v. L??wis <martin at v.loewis.de> added the comment:

> I'm looking at the file right now. history.h is a link to readline.h

Ah, that's wrong. It must be a separate file, entirely different from
readline.h.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11013>
_______________________________________

----------
Added file: http://bugs.python.org/file20554/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11013>
_______________________________________
-------------- next part --------------
<table cellspacing="0" cellpadding="0" border="0" ><tr><td valign="top" style="font: inherit;">Martin,<br><br>I traced back to where that readline installation came from... It's the latest version from ftp.gnu.org + patches.<br><br>George...<br><br>"It's not what you know that hurts you, It's what you know that ain't so." Wil Rogers<br><br>--- On <b>Thu, 1/27/11, Martin v. L??wis <i>&lt;report at bugs.python.org&gt;</i></b> wrote:<br><blockquote style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px;"><br>From: Martin v. L??wis &lt;report at bugs.python.org&gt;<br>Subject: [issue11013] Build of  2.7 svn fails in readline<br>To: grgoffe at yahoo.com<br>Date: Thursday, January 27, 2011, 12:12 PM<br><br><div class="plainMail"><br>Martin v. L??wis &lt;<a ymailto="mailto:martin at v.loewis.de" href="/mc/compose?to=martin at v.loewis.de">martin at v.loewis.de</a>&gt; added the comment:<br><br>&gt; I'm looking at the file right now. history.h is a
 link to readline.h<br><br>Ah, that's wrong. It must be a separate file, entirely different from<br>readline.h.<br><br>----------<br><br>_______________________________________<br>Python tracker &lt;<a ymailto="mailto:report at bugs.python.org" href="/mc/compose?to=report at bugs.python.org">report at bugs.python.org</a>&gt;<br>&lt;<a href="http://bugs.python.org/issue11013" target="_blank">http://bugs.python.org/issue11013</a>&gt;<br>_______________________________________<br></div></blockquote></td></tr></table><br>

      

From report at bugs.python.org  Thu Jan 27 21:29:38 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 27 Jan 2011 20:29:38 +0000
Subject: [issue11013] Build of  2.7 svn fails in readline
In-Reply-To: <146148.16485.qm@web162012.mail.bf1.yahoo.com>
Message-ID: <4D41D5B0.5040604@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> I traced back to where that readline installation came from... It's
> the latest version from ftp.gnu.org + patches.

Did you mean to imply that you have now fixed your installation, or that
you consider it correct?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11013>
_______________________________________

From report at bugs.python.org  Thu Jan 27 21:29:59 2011
From: report at bugs.python.org (Scott M)
Date: Thu, 27 Jan 2011 20:29:59 +0000
Subject: [issue11029] Crash, 2.7.1, Tkinter and threads and line drawing
In-Reply-To: <1296147664.2.0.443864502869.issue11029@psf.upfronthosting.co.za>
Message-ID: <1296160199.75.0.402079249814.issue11029@psf.upfronthosting.co.za>


Scott M <scott.mayo at comcast.net> added the comment:

To make this more interesting, I'm trying to push for adoption of Python at a scripting tool where I work, and I uncovered this crasher in example code I was about to hand out, under the heading of "look how easy Python is". For obvious reasons I'm holding off on handing out the example; I won't get far selling Python if it crashes when drawing lines... if this is a result of something boneheaded I did, please slap me upside the head ASAP. Conversely if there's a quick fix possible, that will speed Python adoption where I work... thanks.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11029>
_______________________________________

From report at bugs.python.org  Thu Jan 27 21:35:12 2011
From: report at bugs.python.org (Fred L. Drake, Jr.)
Date: Thu, 27 Jan 2011 20:35:12 +0000
Subject: [issue11027] Allow spaces around section header in ConfigParser
In-Reply-To: <1296139025.05.0.619488294513.issue11027@psf.upfronthosting.co.za>
Message-ID: <1296160512.44.0.588359884152.issue11027@psf.upfronthosting.co.za>


Fred L. Drake, Jr. <fdrake at acm.org> added the comment:

I doubt anyone is looking for section names with leading or trailing whitespace.

One approach to dealing with this is to provide and sectionxform similar to optionxform.  If we're wrong and someone really is expecting leading or trailing whitespace, they can set that (to str) to cancel out the change in behavior.

While I'd be surprised if anyone relies on this, it is a feature change, no matter how it's implemented, so must wait for 3.3.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11027>
_______________________________________

From report at bugs.python.org  Thu Jan 27 21:46:03 2011
From: report at bugs.python.org (Michal Nowikowski)
Date: Thu, 27 Jan 2011 20:46:03 +0000
Subject: [issue10999] os.chflags refers to stat constants,
	but the constants are not documented in the stat module
In-Reply-To: <1295898075.1.0.406467023745.issue10999@psf.upfronthosting.co.za>
Message-ID: <1296161163.96.0.0934186404848.issue10999@psf.upfronthosting.co.za>


Michal Nowikowski <godfryd at gmail.com> added the comment:

I have prepared a patch that:
- documents flags for os.chflags function in stat module
- adds links for these flags os module to stat module.

----------
components: +None
keywords: +patch
Added file: http://bugs.python.org/file20555/documented-os_chflags-flags.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10999>
_______________________________________

From report at bugs.python.org  Thu Jan 27 22:06:01 2011
From: report at bugs.python.org (Joe Peterson)
Date: Thu, 27 Jan 2011 21:06:01 +0000
Subject: [issue11024] imaplib: Time2Internaldate() returns localized strings
In-Reply-To: <1296135301.42.0.767818406183.issue11024@psf.upfronthosting.co.za>
Message-ID: <1296162361.6.0.600244831144.issue11024@psf.upfronthosting.co.za>


Joe Peterson <joe at skyrush.com> added the comment:

OK, I attached a patch that should work.  Note that this patch works for Python 2 and Python 3.

As an aside, the str type is still returned as before (even in Python 3), and the _month_names list uses str.  As has been discussed, it may be more proper to return a bytes array and be consistent throughout imaplib, but this is not addressed here.

Also, I return a leading zero on the day instead of a leading space, since this appears to be what is returned by two IMAP servers I have just tested (gmail's and dovecot).

----------
keywords: +patch
Added file: http://bugs.python.org/file20556/imaplib_Time2Internaldate_locale_fix.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11024>
_______________________________________

From report at bugs.python.org  Thu Jan 27 22:06:31 2011
From: report at bugs.python.org (Joe Peterson)
Date: Thu, 27 Jan 2011 21:06:31 +0000
Subject: [issue11024] imaplib: Time2Internaldate() returns localized strings
In-Reply-To: <1296135301.42.0.767818406183.issue11024@psf.upfronthosting.co.za>
Message-ID: <1296162391.56.0.930882825522.issue11024@psf.upfronthosting.co.za>


Changes by Joe Peterson <joe at skyrush.com>:


Removed file: http://bugs.python.org/file20556/imaplib_Time2Internaldate_locale_fix.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11024>
_______________________________________

From report at bugs.python.org  Thu Jan 27 22:06:43 2011
From: report at bugs.python.org (Joe Peterson)
Date: Thu, 27 Jan 2011 21:06:43 +0000
Subject: [issue11024] imaplib: Time2Internaldate() returns localized strings
In-Reply-To: <1296135301.42.0.767818406183.issue11024@psf.upfronthosting.co.za>
Message-ID: <1296162403.98.0.212761018042.issue11024@psf.upfronthosting.co.za>


Changes by Joe Peterson <joe at skyrush.com>:


Added file: http://bugs.python.org/file20557/imaplib_Time2Internaldate_locale_fix.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11024>
_______________________________________

From report at bugs.python.org  Thu Jan 27 22:40:55 2011
From: report at bugs.python.org (Geoge R. Goffe)
Date: Thu, 27 Jan 2011 21:40:55 +0000
Subject: [issue11013] Build of  2.7 svn fails in readline
In-Reply-To: <4D41D5B0.5040604@v.loewis.de>
Message-ID: <990493.71288.qm@web162013.mail.bf1.yahoo.com>


Geoge R. Goffe <grgoffe at yahoo.com> added the comment:

Martin,

After the rebuild/reinstall of readline, readline.h is different than history.h... AND NOT A LINK. NO OTHER CHANGES. Same build script...

I did NOT do "svn up" but this current build attempt succeeded. AND THE BEST PART... command line editing works now.?? This probably explains why my python-3.x build and IDLE didn't do command line editing either. Sigh... To err is human, to get things really screwed up requires a computer.

I wonder why I had this problem with readline? Maybe it only happens with a fresh install? I'll try that.

Let me do an svn up and re-build... This worked WITHOUT INCIDENT. Go figure...

I guess you can close this bug... If I discover what the problem is/was, I'll let you guys know.

THANKS for all your help...

George...

"It's not what you know that hurts you, It's what you know that ain't so." Wil Rogers

--- On Thu, 1/27/11, Martin v. L??wis <report at bugs.python.org> wrote:

From: Martin v. L??wis <report at bugs.python.org>
Subject: [issue11013] Build of  2.7 svn fails in readline
To: grgoffe at yahoo.com
Date: Thursday, January 27, 2011, 12:29 PM

Martin v. L??wis <martin at v.loewis.de> added the comment:

> I traced back to where that readline installation came from... It's
> the latest version from ftp.gnu.org + patches.

Did you mean to imply that you have now fixed your installation, or that
you consider it correct?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11013>
_______________________________________

----------
Added file: http://bugs.python.org/file20558/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11013>
_______________________________________
-------------- next part --------------
<table cellspacing="0" cellpadding="0" border="0" ><tr><td valign="top" style="font: inherit;">Martin,<br><br>After the rebuild/reinstall of readline, readline.h is different than history.h... AND NOT A LINK. NO OTHER CHANGES. Same build script...<br><br>I did NOT do "svn up" but this current build attempt succeeded. AND THE BEST PART... command line editing works now.&nbsp; This probably explains why my python-3.x build and IDLE didn't do command line editing either. Sigh... To err is human, to get things really screwed up requires a computer.<br><br>I wonder why I had this problem with readline? Maybe it only happens with a fresh install? I'll try that.<br><br>Let me do an svn up and re-build... This worked WITHOUT INCIDENT. Go figure...<br><br>I guess you can close this bug... If I discover what the problem is/was, I'll let you guys know.<br><br>THANKS for all your help...<br><br>George...<br><br><br>"It's not what you know that hurts you, It's what
 you know that ain't so." Wil Rogers<br><br>--- On <b>Thu, 1/27/11, Martin v. L??wis <i>&lt;report at bugs.python.org&gt;</i></b> wrote:<br><blockquote style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px;"><br>From: Martin v. L??wis &lt;report at bugs.python.org&gt;<br>Subject: [issue11013] Build of  2.7 svn fails in readline<br>To: grgoffe at yahoo.com<br>Date: Thursday, January 27, 2011, 12:29 PM<br><br><div class="plainMail"><br>Martin v. L??wis &lt;<a ymailto="mailto:martin at v.loewis.de" href="/mc/compose?to=martin at v.loewis.de">martin at v.loewis.de</a>&gt; added the comment:<br><br>&gt; I traced back to where that readline installation came from... It's<br>&gt; the latest version from ftp.gnu.org + patches.<br><br>Did you mean to imply that you have now fixed your installation, or that<br>you consider it correct?<br><br>----------<br><br>_______________________________________<br>Python tracker &lt;<a
 ymailto="mailto:report at bugs.python.org" href="/mc/compose?to=report at bugs.python.org">report at bugs.python.org</a>&gt;<br>&lt;<a href="http://bugs.python.org/issue11013" target="_blank">http://bugs.python.org/issue11013</a>&gt;<br>_______________________________________<br></div></blockquote></td></tr></table><br>

      

From report at bugs.python.org  Thu Jan 27 22:49:36 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Thu, 27 Jan 2011 21:49:36 +0000
Subject: [issue11031] regrtest - --testdir,
	new command-line option to specify alternative test directory
In-Reply-To: <1296164976.55.0.598223857745.issue11031@psf.upfronthosting.co.za>
Message-ID: <1296164976.55.0.598223857745.issue11031@psf.upfronthosting.co.za>


New submission from Sandro Tosi <sandro.tosi at gmail.com>:

from msg127153 + msg127157 + msg127172 I prepared this patch to introduce a new cli option to regrtest.py, --testdir DIR, that allows to specify a different location for the directory containing the test files.

along the way, I added a description of what STDTESTS and NOTTESTS is and differentiate the call to findtests() if testdir is passed to not use those information.

----------
assignee: sandro.tosi
components: Tests
files: regrtest_add_testdir-py3k.patch
keywords: patch
messages: 127227
nosy: sandro.tosi
priority: low
severity: normal
stage: patch review
status: open
title: regrtest - --testdir, new command-line option to specify alternative test directory
versions: Python 3.3
Added file: http://bugs.python.org/file20559/regrtest_add_testdir-py3k.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11031>
_______________________________________

From report at bugs.python.org  Thu Jan 27 22:51:44 2011
From: report at bugs.python.org (Geoge R. Goffe)
Date: Thu, 27 Jan 2011 21:51:44 +0000
Subject: [issue11013] Build of  2.7 svn fails in readline
In-Reply-To: <4D41D5B0.5040604@v.loewis.de>
Message-ID: <547661.52652.qm@web162009.mail.bf1.yahoo.com>


Geoge R. Goffe <grgoffe at yahoo.com> added the comment:

Martin,

command line editing with 3.2 (I just did a "svn co") works now as well...

Regards and have a GREAT day,

George...

"It's not what you know that hurts you, It's what you know that ain't so." Wil Rogers

--- On Thu, 1/27/11, Martin v. L??wis <report at bugs.python.org> wrote:

From: Martin v. L??wis <report at bugs.python.org>
Subject: [issue11013] Build of  2.7 svn fails in readline
To: grgoffe at yahoo.com
Date: Thursday, January 27, 2011, 12:29 PM

Martin v. L??wis <martin at v.loewis.de> added the comment:

> I traced back to where that readline installation came from... It's
> the latest version from ftp.gnu.org + patches.

Did you mean to imply that you have now fixed your installation, or that
you consider it correct?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11013>
_______________________________________

----------
Added file: http://bugs.python.org/file20560/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11013>
_______________________________________
-------------- next part --------------
<table cellspacing="0" cellpadding="0" border="0" ><tr><td valign="top" style="font: inherit;">Martin,<br><br>command line editing with 3.2 (I just did a "svn co") works now as well...<br><br>Regards and have a GREAT day,<br><br>George...<br><br>"It's not what you know that hurts you, It's what you know that ain't so." Wil Rogers<br><br>--- On <b>Thu, 1/27/11, Martin v. L??wis <i>&lt;report at bugs.python.org&gt;</i></b> wrote:<br><blockquote style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px;"><br>From: Martin v. L??wis &lt;report at bugs.python.org&gt;<br>Subject: [issue11013] Build of  2.7 svn fails in readline<br>To: grgoffe at yahoo.com<br>Date: Thursday, January 27, 2011, 12:29 PM<br><br><div class="plainMail"><br>Martin v. L??wis &lt;<a ymailto="mailto:martin at v.loewis.de" href="/mc/compose?to=martin at v.loewis.de">martin at v.loewis.de</a>&gt; added the comment:<br><br>&gt; I traced back to where that readline installation came
 from... It's<br>&gt; the latest version from ftp.gnu.org + patches.<br><br>Did you mean to imply that you have now fixed your installation, or that<br>you consider it correct?<br><br>----------<br><br>_______________________________________<br>Python tracker &lt;<a ymailto="mailto:report at bugs.python.org" href="/mc/compose?to=report at bugs.python.org">report at bugs.python.org</a>&gt;<br>&lt;<a href="http://bugs.python.org/issue11013" target="_blank">http://bugs.python.org/issue11013</a>&gt;<br>_______________________________________<br></div></blockquote></td></tr></table><br>

      

From report at bugs.python.org  Thu Jan 27 22:53:47 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Thu, 27 Jan 2011 21:53:47 +0000
Subject: [issue10848] Move test.regrtest from getopt to argparse
In-Reply-To: <1294353259.48.0.852026284896.issue10848@psf.upfronthosting.co.za>
Message-ID: <1296165227.46.0.65199160193.issue10848@psf.upfronthosting.co.za>


Changes by Sandro Tosi <sandro.tosi at gmail.com>:


Removed file: http://bugs.python.org/file20541/issue10848-testdir-py3k.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10848>
_______________________________________

From report at bugs.python.org  Thu Jan 27 22:58:09 2011
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 27 Jan 2011 21:58:09 +0000
Subject: [issue11013] Build of  2.7 svn fails in readline
In-Reply-To: <1296007832.48.0.816263940952.issue11013@psf.upfronthosting.co.za>
Message-ID: <1296165489.46.0.0062304495817.issue11013@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11013>
_______________________________________

From report at bugs.python.org  Thu Jan 27 23:02:27 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Thu, 27 Jan 2011 22:02:27 +0000
Subject: [issue10848] Move test.regrtest from getopt to argparse
In-Reply-To: <1294353259.48.0.852026284896.issue10848@psf.upfronthosting.co.za>
Message-ID: <1296165747.23.0.63831642478.issue10848@psf.upfronthosting.co.za>


Sandro Tosi <sandro.tosi at gmail.com> added the comment:

I've created two new issues (David, I think I've lost why I'd need 3 :) )

* issue11030 - finally allows to specify a relative dir with --coverdir
* issue11031 - to expose --testdir in order to specify a different location of the directory containing tests (disabling stdtest & nottest if testdir is set).

Thanks Nick for your explanation of what's the purpose of STDTEST & NOTTESTS, I've added a brief comment in the code to write that in stone :)

do you think issue11031 should be in dependencies?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10848>
_______________________________________

From report at bugs.python.org  Thu Jan 27 23:13:03 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 27 Jan 2011 22:13:03 +0000
Subject: [issue11027] Allow spaces around section header in ConfigParser
In-Reply-To: <1296139025.05.0.619488294513.issue11027@psf.upfronthosting.co.za>
Message-ID: <1296166383.13.0.973884691091.issue11027@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Could just expand the docs to show examples of customizing behavior through monkey-patching or subclassing:

  class MyConfigParser(ConfigParser):
     SECTRE = re.compile(r'[\*(?P<header>[^]]+)\s*]'

or:

  RawConfigParser.SECTRE = re.compile(r'[\*(?P<header>[^]]+)\s*]'

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11027>
_______________________________________

From report at bugs.python.org  Thu Jan 27 23:22:32 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 27 Jan 2011 22:22:32 +0000
Subject: [issue11022] locale.setlocale() doesn't change I/O codec,	os.environ
In-Reply-To: <1296126025.04.0.965125504096.issue11022@psf.upfronthosting.co.za>
Message-ID: <1296166952.13.0.0587397274961.issue11022@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Set version to 3.3, I think that it is too late to change such critical code in Python 3.2.

----------
versions: +Python 3.3 -Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11022>
_______________________________________

From report at bugs.python.org  Thu Jan 27 23:29:04 2011
From: report at bugs.python.org (R. David Murray)
Date: Thu, 27 Jan 2011 22:29:04 +0000
Subject: [issue10848] Move test.regrtest from getopt to argparse
In-Reply-To: <1294353259.48.0.852026284896.issue10848@psf.upfronthosting.co.za>
Message-ID: <1296167344.12.0.761480911272.issue10848@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I would say so, otherwise how are you going to run the tests you write :)

As for the other issue...I hadn't counted one for --testdir, but making that a new issue was a good idea.  So the other two I had in mind was for STDTESTS and NOTTESTS.  I still think the NOTTESTS pre-population should be eliminated by renaming the two problematic files, unless someone can explain why they need to be named test_xxx.  For STDTESTS...you can fix that as part of 11031 (don't return them if they don't exist in the test dir).

----------
dependencies: +regrtest - --testdir, new command-line option to specify alternative test directory

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10848>
_______________________________________

From report at bugs.python.org  Thu Jan 27 23:32:55 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 27 Jan 2011 22:32:55 +0000
Subject: [issue11022] locale.setlocale() doesn't change I/O codec,	os.environ
In-Reply-To: <1296126025.04.0.965125504096.issue11022@psf.upfronthosting.co.za>
Message-ID: <1296167575.93.0.54037501928.issue11022@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> upon program startup, init LibC environment: setlocale(LC_ALL, "");

Python 3 does something like that: Py_InitializeEx() calls setlocale(LC_CTYPE, ""). But I (and others) consider that as a bug (see #6203 discussion): Python should not do that (nor any library) implicitly, but a *program* can do that (once) at startup (explicitly).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11022>
_______________________________________

From report at bugs.python.org  Thu Jan 27 23:35:50 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 27 Jan 2011 22:35:50 +0000
Subject: [issue11022] locale.setlocale() doesn't change I/O codec, os.environ
In-Reply-To: <4D41C7F4.7070101@v.loewis.de>
Message-ID: <1296167747.3693.6.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> >> Both cases indicate the users desire to change a specific locale
> >> setting and thus - of course - all the changes which that implies!
> >> So why should there be a difference?
> > 
> > I don't think it's intentional. I would be +1 on changing to getpreferredencoding(False).
> 
> That won't actually work. If you always use the C library's locale
> setting, most scripts will run in the C locale, and fail to read text
> files properly.

Well, is it any different from today? That's an innocent question: I
don't know if there's a difference between "C locale" and "empty
locale".

----------
title: locale.setlocale() doesn't change I/O codec,	os.environ -> locale.setlocale() doesn't change I/O codec, os.environ

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11022>
_______________________________________

From report at bugs.python.org  Thu Jan 27 23:44:52 2011
From: report at bugs.python.org (Kristian Vlaardingerbroek)
Date: Thu, 27 Jan 2011 22:44:52 +0000
Subject: [issue10990] tests mutating sys.gettrace() w/o re-instating previous
	state
In-Reply-To: <1295824876.68.0.687534068337.issue10990@psf.upfronthosting.co.za>
Message-ID: <1296168292.79.0.975877867127.issue10990@psf.upfronthosting.co.za>


Kristian Vlaardingerbroek <kristian.vlaardingerbroek at gmail.com> added the comment:

Cleaned up patch file. Removed non-related diffs and redundant updates.

refcount_test decorator is still in there.

----------
Added file: http://bugs.python.org/file20561/issue10990.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10990>
_______________________________________

From report at bugs.python.org  Fri Jan 28 00:07:56 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 27 Jan 2011 23:07:56 +0000
Subject: [issue11032] _string: formatter_field_name_split() and
	formatter_parser doesn't check input type
In-Reply-To: <1296169676.06.0.782920211182.issue11032@psf.upfronthosting.co.za>
Message-ID: <1296169676.06.0.782920211182.issue11032@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

$ ./python 
Python 3.2rc1+ (unknown, Jan 18 2011, 00:55:20) 
>>> import _string
>>> _string.formatter_field_name_split(1)
python: Objects/stringlib/string_format.h:1347: formatter_field_name_split: Assertion `((((((PyObject*)(self))->ob_type))->tp_flags & ((1L<<28))) != 0)' failed.
Abandon

$ ./python 
Python 3.2rc1+ (unknown, Jan 18 2011, 00:55:20) 
>>> import _string
>>> _string.formatter_parser(1)
python: Objects/stringlib/string_format.h:1206: formatter_parser: Assertion `((((((PyObject*)(self))->ob_type))->tp_flags & ((1L<<28))) != 0)' failed.
Abandon

Attached patch fixes both crashes and add tests on the _string module (which has only these two functions).

----------
components: Library (Lib)
files: _string.patch
keywords: patch
messages: 127236
nosy: haypo
priority: normal
severity: normal
status: open
title: _string: formatter_field_name_split() and formatter_parser doesn't check input type
versions: Python 3.1, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file20562/_string.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11032>
_______________________________________

From report at bugs.python.org  Fri Jan 28 00:10:56 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 27 Jan 2011 23:10:56 +0000
Subject: [issue10989] ssl.SSLContext(True).load_verify_locations(None,
	True) segfault
In-Reply-To: <1295820125.73.0.864692220479.issue10989@psf.upfronthosting.co.za>
Message-ID: <1296169856.8.0.685037084425.issue10989@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Here is a patch including a test.

The test pass on regrtest with -R 3:3: (no reference leak).

----------
keywords: +patch
Added file: http://bugs.python.org/file20563/ssl.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10989>
_______________________________________

From report at bugs.python.org  Fri Jan 28 00:27:52 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 27 Jan 2011 23:27:52 +0000
Subject: [issue10989] ssl.SSLContext(True).load_verify_locations(None,
	True) segfault
In-Reply-To: <1295820125.73.0.864692220479.issue10989@psf.upfronthosting.co.za>
Message-ID: <1296170872.26.0.385894510878.issue10989@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Looks good to me.

----------
resolution:  -> accepted
stage: needs patch -> commit review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10989>
_______________________________________

From report at bugs.python.org  Fri Jan 28 01:07:36 2011
From: report at bugs.python.org (Peter Cai)
Date: Fri, 28 Jan 2011 00:07:36 +0000
Subject: [issue11033] ElementTree.fromstring doesn't work with Unicode
In-Reply-To: <1296173256.62.0.363094614198.issue11033@psf.upfronthosting.co.za>
Message-ID: <1296173256.62.0.363094614198.issue11033@psf.upfronthosting.co.za>


New submission from Peter Cai <newptcai at gmail.com>:

xml.etree.ElementTree.fromstring doesn't work with Unicode string.  See the code below:

>>> from xml.etree import ElementTree
>>> t = ElementTree.fromstring(u'<doc>?</doc>')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "D:\Python26\lib\xml\etree\ElementTree.py", line 963, in XML
    parser.feed(text)
  File "D:\Python26\lib\xml\etree\ElementTree.py", line 1245, in feed
    self._parser.Parse(data, 0)
UnicodeEncodeError: 'ascii' codec can't encode character u'\u8bd7' in position 5
: ordinal not in range(128)

----------
components: XML
messages: 127239
nosy: Peter.Cai
priority: normal
severity: normal
status: open
title: ElementTree.fromstring doesn't work with Unicode
type: crash
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11033>
_______________________________________

From report at bugs.python.org  Fri Jan 28 01:44:19 2011
From: report at bugs.python.org (Eric Smith)
Date: Fri, 28 Jan 2011 00:44:19 +0000
Subject: [issue11032] _string: formatter_field_name_split() and
	formatter_parser doesn't check input type
In-Reply-To: <1296169676.06.0.782920211182.issue11032@psf.upfronthosting.co.za>
Message-ID: <1296175459.05.0.065682125698.issue11032@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

I'll review this tomorrow.

----------
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11032>
_______________________________________

From report at bugs.python.org  Fri Jan 28 03:05:16 2011
From: report at bugs.python.org (Glyph Lefkowitz)
Date: Fri, 28 Jan 2011 02:05:16 +0000
Subject: [issue7175] Define a standard location and API for configuration files
In-Reply-To: <1256037677.34.0.670034749287.issue7175@psf.upfronthosting.co.za>
Message-ID: <1296180316.01.0.435822466333.issue7175@psf.upfronthosting.co.za>


Glyph Lefkowitz <glyph at twistedmatrix.com> added the comment:

I agree with Michael Foord; my comment on issue 8404 <http://bugs.python.org/issue8084#msg122935> may be of interest to anyone looking at this as well.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7175>
_______________________________________

From report at bugs.python.org  Fri Jan 28 04:03:33 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Fri, 28 Jan 2011 03:03:33 +0000
Subject: [issue11015] Bring test.support docs up to date
In-Reply-To: <1296009969.38.0.282241852849.issue11015@psf.upfronthosting.co.za>
Message-ID: <1296183813.24.0.977561592653.issue11015@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/issue11015>
_______________________________________

From report at bugs.python.org  Fri Jan 28 04:42:25 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Fri, 28 Jan 2011 03:42:25 +0000
Subject: [issue11015] Bring test.support docs up to date
In-Reply-To: <1296009969.38.0.282241852849.issue11015@psf.upfronthosting.co.za>
Message-ID: <1296186145.19.0.681643083837.issue11015@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

I don't know if it matters much, but there's a slight mismatch in the description of test.support.verbose. The documentation says it's a boolean, while it's 0 or 1 in reality. 

Can it just be changed to True/False in the code of test.support and test.regrtest? It appears that all the other flags are True/False and there's no reason to keep this 0/1 (which is probably a relic from a distant past)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11015>
_______________________________________

From report at bugs.python.org  Fri Jan 28 05:12:40 2011
From: report at bugs.python.org (Christoph Gohlke)
Date: Fri, 28 Jan 2011 04:12:40 +0000
Subject: [issue11029] Crash, 2.7.1, Tkinter and threads and line drawing
In-Reply-To: <1296147664.2.0.443864502869.issue11029@psf.upfronthosting.co.za>
Message-ID: <1296187960.49.0.531288111084.issue11029@psf.upfronthosting.co.za>


Christoph Gohlke <cgohlke at uci.edu> added the comment:

Tkinter is not thread safe. You are changing UI elements from a thread that is not the main thread. Use a Queue as described at http://effbot.org/zone/tkinter-threads.htm.

----------
nosy: +cgohlke

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11029>
_______________________________________

From report at bugs.python.org  Fri Jan 28 05:19:54 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Fri, 28 Jan 2011 04:19:54 +0000
Subject: [issue11015] Bring test.support docs up to date
In-Reply-To: <1296009969.38.0.282241852849.issue11015@psf.upfronthosting.co.za>
Message-ID: <1296188394.84.0.273645672307.issue11015@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

Here's a patch fixing the 0/1 to True/False in a couple of places in test.support and test.regrtest

I ran the test suite and it passes.

A review is needed to commit. I'll keep working on the documentation itself in the meantime.

----------
keywords: +patch
Added file: http://bugs.python.org/file20564/issue11015.py3k.1.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11015>
_______________________________________

From report at bugs.python.org  Fri Jan 28 05:26:26 2011
From: report at bugs.python.org (R. David Murray)
Date: Fri, 28 Jan 2011 04:26:26 +0000
Subject: [issue9124] Mailbox module should use binary I/O, not text I/O
In-Reply-To: <1277900903.38.0.556015912714.issue9124@psf.upfronthosting.co.za>
Message-ID: <1296188786.27.0.168997258543.issue9124@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Attached is a patch that builds on Victor's patch, but takes the approach I discussed of maintaining backward compatibility (for the most part; see below).  The test suite in this version is substantially unchanged.  The major changes are adding tests for the bytes input and the new method (get_bytes).  The changes to existing test methods are to methods that test internal interfaces (because those now handle bytes, not string).

I've included doc changes, which are mostly adding notes about where bytes are accepted (add, __setitem__), and for the new get_bytes method.

get_string is now implemented by calling get_bytes, passing the result to email.message.Message, and then calling as_string.  This defeats the efficiency purpose of using get_string, but in that use case code should really be using get_bytes.

I kept the change to get_file: it returns a binary file, as currently documented.  I think this is less likely to cause backward compatibility issues (assuming any 3.x code exists that uses mailbox!) than get_string returning bytes (or dissapearing) would.

As with email.message.Message's get_unixfrom method, get_from returns a string, and set_from takes a string.  Although there are no real standards for this "header", I believe that it is restricted to ASCII, and have written the code accordingly.  This is my answer to Victor's question about maybe_date and the from line: I think we should use ascii as the encoding.  That is certainly true for the date; asctime does not use the locale, and English date fields are definitely the de-facto standard for From lines.

I haven't looked at the mh_sequences question yet.  I don't think there are any formal restrictions on what characters can be used in a sequence name, but I haven't looked to see if there are any standards documents for mh.  I'll test to see if my nmh installation accepts non-ascci chars for sequence names tomorrow.  I'm also going to try to go over Victor's changes section by section, but everything I've looked at other than the mh_sequences issue he raised looks good to me so far.

I note that we still don't have an RM call on whether or not this can go in if it passes review.

Oh, also note that neither Victor's patch nor my patch have any tests for non-ASCII characters.  Some should be added :)

----------
Added file: http://bugs.python.org/file20565/mailbox3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9124>
_______________________________________

From report at bugs.python.org  Fri Jan 28 06:37:03 2011
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 28 Jan 2011 05:37:03 +0000
Subject: [issue10992] tests failing when run under coverage
In-Reply-To: <1295836026.73.0.339636680883.issue10992@psf.upfronthosting.co.za>
Message-ID: <1296193023.96.0.792634498669.issue10992@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Attached is a patch against test_gc that shows what I think should be done for the tests failing because of refcounts. Basically I added a refcount_test decorator to test.support that skips a decorated test if it is not being run under CPython and otherwise unsets the trace function.

This should work for all tests that are discovered to fail because of refcounts.

----------
keywords: +patch
Added file: http://bugs.python.org/file20566/test_gc.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10992>
_______________________________________

From report at bugs.python.org  Fri Jan 28 06:38:12 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Fri, 28 Jan 2011 05:38:12 +0000
Subject: [issue11015] Bring test.support docs up to date
In-Reply-To: <1296009969.38.0.282241852849.issue11015@psf.upfronthosting.co.za>
Message-ID: <1296193092.57.0.72935060046.issue11015@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

Here's a patch to Doc/library/test.rst with additional several exported functions documented. These are the ones I found most important and clear. fcmp() is currently not documented (pending discussion in pydev).

----------
stage: needs patch -> patch review
Added file: http://bugs.python.org/file20567/issue11015.py3k.testdoc.1.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11015>
_______________________________________

From report at bugs.python.org  Fri Jan 28 06:39:12 2011
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 28 Jan 2011 05:39:12 +0000
Subject: [issue10992] tests failing when run under coverage
In-Reply-To: <1295836026.73.0.339636680883.issue10992@psf.upfronthosting.co.za>
Message-ID: <1296193152.56.0.346482623828.issue10992@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Attached is a patch for test_descr. I suspect the __locals__ failures will all be the same; simply skip the test when a trace function is set.

And thanks for identifying the cause of the failures, Kristian; helps me make sure I am not misdiagnosing the problem.

----------
Added file: http://bugs.python.org/file20568/test_descr.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10992>
_______________________________________

From report at bugs.python.org  Fri Jan 28 08:37:36 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Fri, 28 Jan 2011 07:37:36 +0000
Subject: [issue11034] Build problem on Windows with MSVC++ Express 2008
In-Reply-To: <1296200256.35.0.305421418262.issue11034@psf.upfronthosting.co.za>
Message-ID: <1296200256.35.0.305421418262.issue11034@psf.upfronthosting.co.za>


New submission from Eli Bendersky <eliben at gmail.com>:

On a clean checkout of py3k, I try to open PCBuild/pcbuild.sln with my MSVC++ Express 2008. When opening, a message box pops saying:

  Solution folders are not supported in this version of the application.
  Solution folder "Solution Items" will be displayed as unavailable.

I go on building following instructions (F7, leaving the default Debug win32 configuration). I get a bunch of LNK1181 errors:

  27> LINK : fatal error LNK1181: cannot open input file '.\python32_d.lib'

When I try to build the pythoncore project only, I get:

  1>c1 : fatal error C1083: Cannot open source file: 'D:\eli\python-py3k-trunk\PCbuild\Win32-temp-Debug\pythoncore\\getbuildinfo2.c': No such file or directory

Maybe there's some problem with the make_buildinfo call in the pre-build event?

----------
components: Build
messages: 127249
nosy: eli.bendersky, loewis
priority: normal
severity: normal
status: open
title: Build problem on Windows with MSVC++ Express 2008
type: compile error
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11034>
_______________________________________

From report at bugs.python.org  Fri Jan 28 08:42:04 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Fri, 28 Jan 2011 07:42:04 +0000
Subject: [issue11034] Build problem on Windows with MSVC++ Express 2008
In-Reply-To: <1296200256.35.0.305421418262.issue11034@psf.upfronthosting.co.za>
Message-ID: <1296200524.19.0.348389678078.issue11034@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

I tried running make_buildinfo.exe manually from a VC command prompt, and I get an error for invoking subwcrev.exe:

D:\eli\python-py3k-trunk\PCbuild>make_buildinfo.exe Debug Win32-temp-Debug
"C:\Program Files\TortoiseSVN\bin\subwcrev.exe" .. ..\Modules\getbuildinfo.c "Win32-temp-Debug\getbuildinfo2.c"
'C:\Program' is not recognized as an internal or external command,
operable program or batch file.

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11034>
_______________________________________

From report at bugs.python.org  Fri Jan 28 08:59:47 2011
From: report at bugs.python.org (Kunjesh Kaushik)
Date: Fri, 28 Jan 2011 07:59:47 +0000
Subject: [issue11027] Allow spaces around section header in ConfigParser
In-Reply-To: <1296139025.05.0.619488294513.issue11027@psf.upfronthosting.co.za>
Message-ID: <1296201587.11.0.767010771462.issue11027@psf.upfronthosting.co.za>


Kunjesh Kaushik <kunjesh.kaushik at gmail.com> added the comment:

I think we are dealing with two separate issues: a feature request for sectionxform kind of functionality desirable in a future release (3.3 maybe) and a behaviour issue in current releases (2.x and 3.x both). I suggest we split the two issues and solve them as such. Deferring the latter may be undesirable.

Also, I found that a non-greedy pattern will work with the original patch:

>>> import re
>>> r = re.compile(r'\[\s*(?P<header>[^]]+?)\s*\]') # note +? instead of +
>>> r.match('[ section header ]').group('header')   # works as "expected"
'section header'

Attaching a new patch file as well.

----------
keywords: +patch
Added file: http://bugs.python.org/file20569/allow_spaces_around_section_header.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11027>
_______________________________________

From report at bugs.python.org  Fri Jan 28 09:02:42 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Fri, 28 Jan 2011 08:02:42 +0000
Subject: [issue11034] Build problem on Windows with MSVC++ Express 2008
In-Reply-To: <1296200256.35.0.305421418262.issue11034@psf.upfronthosting.co.za>
Message-ID: <1296201762.03.0.643202429428.issue11034@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

After some investigation of running make_buildinfo standalone, it boils down to this:

When it executes the path with quotes around the last argument:

"C:\Program Files\TortoiseSVN\bin\subwcrev.exe" .. ..\Modules\getbuildinfo.c "Win32-temp-Debug\getbuildinfo2.c"

I see the error about 'C:\Program' being unrecognized.

When it executes without quotes around the last argument:

"C:\Program Files\TortoiseSVN\bin\subwcrev.exe" .. ..\Modules\getbuildinfo.c Win32-temp-Debug\getbuildinfo2.c

It works just fine.

Could this be some bizzarre bug in the quote parser of cmd.exe? I run Win XP Home SP3.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11034>
_______________________________________

From report at bugs.python.org  Fri Jan 28 09:10:41 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 28 Jan 2011 08:10:41 +0000
Subject: [issue11034] Build problem on Windows with MSVC++ Express 2008
In-Reply-To: <1296200256.35.0.305421418262.issue11034@psf.upfronthosting.co.za>
Message-ID: <1296202241.85.0.394214007837.issue11034@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

> Could this be some bizzarre bug in the quote parser of cmd.exe?
Yes, this is even documented with "cmd /?":
"""
[...]If you specify /c or /k, cmd processes the remainder of string and quotation marks are preserved only if all of the following conditions are met:
[...]- You use exactly one set of quotation marks.
"""

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11034>
_______________________________________

From report at bugs.python.org  Fri Jan 28 09:13:07 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Fri, 28 Jan 2011 08:13:07 +0000
Subject: [issue11034] Build problem on Windows with MSVC++ Express 2008
In-Reply-To: <1296200256.35.0.305421418262.issue11034@psf.upfronthosting.co.za>
Message-ID: <1296202387.82.0.0673733054789.issue11034@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

Amaury, seems like it - thanks. So I suppose the fix would be just to remove the quotes in make_buildinfo.c

I wonder why it worked for others & buildbots?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11034>
_______________________________________

From report at bugs.python.org  Fri Jan 28 09:26:05 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Fri, 28 Jan 2011 08:26:05 +0000
Subject: [issue11034] Build problem on Windows with MSVC++ Express 2008
In-Reply-To: <1296200256.35.0.305421418262.issue11034@psf.upfronthosting.co.za>
Message-ID: <1296203165.29.0.398984699662.issue11034@psf.upfronthosting.co.za>


Changes by Eli Bendersky <eliben at gmail.com>:


----------
priority: normal -> high

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11034>
_______________________________________

From report at bugs.python.org  Fri Jan 28 09:30:19 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Fri, 28 Jan 2011 08:30:19 +0000
Subject: [issue11034] Build problem on Windows with MSVC++ Express 2008
In-Reply-To: <1296200256.35.0.305421418262.issue11034@psf.upfronthosting.co.za>
Message-ID: <1296203419.44.0.95561189639.issue11034@psf.upfronthosting.co.za>


Changes by Eli Bendersky <eliben at gmail.com>:


----------
nosy: +krisvale

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11034>
_______________________________________

From report at bugs.python.org  Fri Jan 28 09:33:48 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Fri, 28 Jan 2011 08:33:48 +0000
Subject: [issue10501] make_buildinfo regression with unquoted path
In-Reply-To: <1290420103.87.0.191839202946.issue10501@psf.upfronthosting.co.za>
Message-ID: <1296203628.34.0.922570481803.issue10501@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

Please see issue 11034

----------
nosy: +eli.bendersky
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10501>
_______________________________________

From report at bugs.python.org  Fri Jan 28 09:52:04 2011
From: report at bugs.python.org (Martin)
Date: Fri, 28 Jan 2011 08:52:04 +0000
Subject: [issue11034] Build problem on Windows with MSVC++ Express 2008
In-Reply-To: <1296200256.35.0.305421418262.issue11034@psf.upfronthosting.co.za>
Message-ID: <1296204724.38.0.669512823046.issue11034@psf.upfronthosting.co.za>


Martin <gzlist at googlemail.com> added the comment:

Removing the quotes rebreaks the case where tmppath contains a space.

Instead, either:
* Call subwcrev.exe  directly without going through COMSPEC: switch 'system' to 'CreateProcess'.
* More quotes! Change `"A" .. "B"` to `""A" .. "B""` which when it hits case 2 from what Amuary was quoting, does what's intended.

"""
1.  If all of the following conditions are met...
"""
... they aren't...
"""
2.  Otherwise, old behavior is to see if the first character is a quote character and if so, strip the leading character and remove the last quote character on the command line, preserving any text after the last quote character.
"""

----------
nosy: +gz

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11034>
_______________________________________

From report at bugs.python.org  Fri Jan 28 09:58:29 2011
From: report at bugs.python.org (Sebastian Spaeth)
Date: Fri, 28 Jan 2011 08:58:29 +0000
Subject: [issue11024] imaplib: Time2Internaldate() returns localized strings
In-Reply-To: <1296162404.04.0.195358090459.issue11024@psf.upfronthosting.co.za>
Message-ID: <87tygt76bz.fsf@SSpaeth.de>


Sebastian Spaeth <sebastian at sspaeth.de> added the comment:

> Added file: imaplib_Time2Internaldate_locale_fix.patch

The patch looks very good to me and works. I agree that we should be
returning a bytearray but this is should not be part of this issue.

For all that it's worth:
Signed-off-by: Sebastian Spaeth <Sebastian at SSpaeth.de>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11024>
_______________________________________

From report at bugs.python.org  Fri Jan 28 10:07:49 2011
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Fri, 28 Jan 2011 09:07:49 +0000
Subject: [issue11034] Build problem on Windows with MSVC++ Express 2008
In-Reply-To: <1296200256.35.0.305421418262.issue11034@psf.upfronthosting.co.za>
Message-ID: <1296205669.55.0.295349390268.issue11034@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

Bizarre indeed.
I think more quotes is the answer, since it is simpler to implement.
But the question remains, why has it worked until now?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11034>
_______________________________________

From report at bugs.python.org  Fri Jan 28 10:23:05 2011
From: report at bugs.python.org (Martin)
Date: Fri, 28 Jan 2011 09:23:05 +0000
Subject: [issue11034] Build problem on Windows with MSVC++ Express 2008
In-Reply-To: <1296200256.35.0.305421418262.issue11034@psf.upfronthosting.co.za>
Message-ID: <1296206585.62.0.619840965431.issue11034@psf.upfronthosting.co.za>


Martin <gzlist at googlemail.com> added the comment:

This bug only hits people who:
1) Have TortoiseSVN installed (buildbots won't, I don't)
2) ...on a path that needs quoting.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11034>
_______________________________________

From report at bugs.python.org  Fri Jan 28 10:23:53 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 28 Jan 2011 09:23:53 +0000
Subject: [issue11015] Bring test.support docs up to date
In-Reply-To: <1296009969.38.0.282241852849.issue11015@psf.upfronthosting.co.za>
Message-ID: <1296206633.85.0.805425851768.issue11015@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

verbose isn't a boolean at all - it's an integer. You can supply it multiple times to bump the logging level up even higher than normal.

~/devel/py3k/Lib/test$ grep "verbose >" *.py
regrtest.py:                    if self.verbose > 1:
test_cmd_line_script.py:        if verbose > 1:
test_cmd_line_script.py:        if verbose > 1:
test_cmd_line_script.py:        if verbose > 1:
test_cmd_line_script.py:                if verbose > 1:
test_cmd_line_script.py:                    if verbose > 1:
test_fork1.py:                    if verbose > 1:
test_fork1.py:                    if verbose > 1:

(I didn't check explicitly, but I believe those verbose values are shorthand references to test.support.verbose)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11015>
_______________________________________

From report at bugs.python.org  Fri Jan 28 10:25:37 2011
From: report at bugs.python.org (Martin)
Date: Fri, 28 Jan 2011 09:25:37 +0000
Subject: [issue10765] Build regression from automation changes on windows
In-Reply-To: <1293146347.8.0.828425848028.issue10765@psf.upfronthosting.co.za>
Message-ID: <1296206737.26.0.915643468893.issue10765@psf.upfronthosting.co.za>


Martin <gzlist at googlemail.com> added the comment:

My build is still affected by this, can you find some time to look at the attached patch please?

Relevant bit of log is:

Performing Makefile project actions
Microsoft (R) Program Maintenance Utility Version 9.00.21022.08
Copyright (C) Microsoft Corporation.  All rights reserved.
NMAKE : fatal error U1073: don't know how to make 'User\py3k\PCbuild\'
Stop.
Project : error PRJ0019: A tool returned an error code from "Performing Makefile project actions"

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10765>
_______________________________________

From report at bugs.python.org  Fri Jan 28 10:27:54 2011
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Fri, 28 Jan 2011 09:27:54 +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: <1296206874.76.0.903442834495.issue6203@psf.upfronthosting.co.za>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Python can be embedded into other applications and unconditionally
changing the locale (esp. the LC_CTYPE) is not good practice, since
it's not thread-safe and affects the entire process. An application
may have set LC_CTYPE (or the locale) to something completely
different.

If at all, Python should be more careful using this call (pseudo
code):

lc_ctype = setlocale(LC_CTYPE, NULL);
if (lc_ctype == NULL || strcmp(lc_ctype, "") || strcmp(lc_ctype, "C")) {
    env_lc_ctype = setlocale(LC_CTYPE, "");
    setlocale(LC_CTYPE, lc_ctype);
    lc_ctype = env_lc_ctype;
}

Then use lc_ctype to figure out encodings, etc.

While this is not thread-safe, it at least reverts the change back
to the original setting and only applies the change if needed. That's
still not optimal, but better than nothing.

An clean alternative would be adding LC_* variable parsing code to
Python to avoid the setlocale() call altogether.

----------
nosy: +lemburg

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6203>
_______________________________________

From report at bugs.python.org  Fri Jan 28 10:29:33 2011
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Fri, 28 Jan 2011 09:29:33 +0000
Subject: [issue11022] locale.setlocale() doesn't change I/O codec,	os.environ
In-Reply-To: <1296167575.93.0.54037501928.issue11022@psf.upfronthosting.co.za>
Message-ID: <4D428C7B.9050106@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

STINNER Victor wrote:
> 
> STINNER Victor <victor.stinner at haypocalc.com> added the comment:
> 
>> upon program startup, init LibC environment: setlocale(LC_ALL, "");
> 
> Python 3 does something like that: Py_InitializeEx() calls setlocale(LC_CTYPE, ""). But I (and others) consider that as a bug (see #6203 discussion): Python should not do that (nor any library) implicitly, but a *program* can do that (once) at startup (explicitly).

Agreed. See the discussion on the ticket for more details.

setlocale() should only be called by applications, not by libraries.
For Python this means: calling it in main() is fine, but not
in Py_InitializeEx().

----------
nosy: +lemburg
title: locale.setlocale() doesn't change I/O codec, os.environ -> locale.setlocale() doesn't change I/O codec,	os.environ

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11022>
_______________________________________

From report at bugs.python.org  Fri Jan 28 10:30:18 2011
From: report at bugs.python.org (Ned Deily)
Date: Fri, 28 Jan 2011 09:30:18 +0000
Subject: [issue10940] IDLE 3.2 hangs with Cmd-M hotkey on OS X 10.6 with
	64-bit installer and A/S Tk 8.5
In-Reply-To: <1295391844.43.0.912463306116.issue10940@psf.upfronthosting.co.za>
Message-ID: <1296207018.12.0.169286112333.issue10940@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

After more investigation, I found that my original speculation about a Cmd-M conflict with Cocoa Tk 8.5 was not correct. And the problem is not just limited to the keyboard accelerator for the Open Module command; it can also be seen with the keyboard accelerators for the Go To Line and New Ident Width commands, although none are always repeatable.  What all three have in common is that they use the tkinter.simpledialog module to get user input in response to the command. There does not seem to be a problem ever if the menu commands are clicked on rather than opened with a keyboard accelerator nor is the problem seen when using the older Carbon Tk 8.4.  The problem occurs at the end of the common Dialog class (simpledialog.py lines 167-169) where the tk "wait visibility" command does not cause the intended window to appear and the tk "wait window" (to be destroyed) command hangs waiting on a non-visible window.  Adding some debugging code makes it seem that the hangup is the display of the Entry widget within the dialog window.  Why that is a problem when going though the lengthy execution path triggered by a menu keyboard type-in, and not the clicking-on-menu-item path, is still not clear.  Most likely it is a bug in Cocoa Tk 8.5 but so far I have not yet been able to reduce it to a simpler, reproducible test case.

For 3.2rc2 and 3.2, I propose to add a temporary patch to IDLE that removes the keyboard accelerators for these three commands when running with Cocoa Tk 8.5.  That should prevent users from running into the hang and, thereby, losing work.  The patch should be available later today.

----------
nosy: +georg.brandl
priority: high -> critical

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10940>
_______________________________________

From report at bugs.python.org  Fri Jan 28 10:33:40 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Fri, 28 Jan 2011 09:33:40 +0000
Subject: [issue6203] 3.x locale does not default to C,
	contrary to the documentation and to 2.x behavior
In-Reply-To: <1296206874.76.0.903442834495.issue6203@psf.upfronthosting.co.za>
Message-ID: <4D428D72.6000402@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> An clean alternative would be adding LC_* variable parsing code to
> Python to avoid the setlocale() call altogether.

That would be highly non-portable, and repeat the mistakes of
getdefaultlocale.

----------
title: 3.x locale does not default to C, contrary to the documentation and to 2.x behavior -> 3.x locale does not default to C,	contrary to the documentation and to 2.x behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6203>
_______________________________________

From report at bugs.python.org  Fri Jan 28 10:36:50 2011
From: report at bugs.python.org (Dmitry Groshev)
Date: Fri, 28 Jan 2011 09:36:50 +0000
Subject: [issue11035] Segmentation fault
In-Reply-To: <1296207410.47.0.601145412555.issue11035@psf.upfronthosting.co.za>
Message-ID: <1296207410.47.0.601145412555.issue11035@psf.upfronthosting.co.za>


New submission from Dmitry Groshev <lambdadmitry at gmail.com>:

Here is a console output:
si14 at si14-work:~/repos/monitoring/root$ python2.7 server.py 

127.0.0.1 - - [2011-01-28 12:29:30] "GET /update HTTP/1.1" 200 320 "-" "Python-urllib/2.7"
{"seenby":[1],"received":1296207058.993983,"observer":1,"type":"ping","source":102,"time":1296207058.990101,"data":[[1296206970.543701,0.010154962539672852],[1296206980.383922,0.010203123092651367],[1296206990.222841,0.01015615463256836],[1296207000.050695,0.010264873504638672],[1296207009.876834,0.011881113052368164],[1296207019.698611,0.010120153427124023],[1296207029.519147,0.010251045227050781],[1296207039.342266,0.010113000869750977],[1296207049.167352,0.010238885879516602],[1296207058.990089,0.010174989700317383]],"class":"statistics"}
127.0.0.1 - - [2011-01-28 12:30:59] "POST / HTTP/1.1" 200 2 "-" "Python-urllib/2.7"
Segmentation fault
si14 at si14-work:~/repos/monitoring/root$ 
I'm not sure that this is a gevent issue, so I'm posting it here. server.py sources are attached.

----------
components: Interpreter Core
files: server.py
messages: 127266
nosy: Dmitry.Groshev
priority: normal
severity: normal
status: open
title: Segmentation fault
type: crash
versions: Python 2.7
Added file: http://bugs.python.org/file20570/server.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11035>
_______________________________________

From report at bugs.python.org  Fri Jan 28 10:40:41 2011
From: report at bugs.python.org (Dmitry Groshev)
Date: Fri, 28 Jan 2011 09:40:41 +0000
Subject: [issue11035] Segmentation fault
In-Reply-To: <1296207410.47.0.601145412555.issue11035@psf.upfronthosting.co.za>
Message-ID: <1296207641.12.0.015798584628.issue11035@psf.upfronthosting.co.za>


Dmitry Groshev <lambdadmitry at gmail.com> added the comment:

I should also say that this bug appears at first time, but it doesn't make it less scary. The packet that crashed python was the same as the one shown and I've already used this tiny "server" for a day or two without modifications, so it seems to me that this is not my mistake.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11035>
_______________________________________

From report at bugs.python.org  Fri Jan 28 10:51:35 2011
From: report at bugs.python.org (Dmitry Groshev)
Date: Fri, 28 Jan 2011 09:51:35 +0000
Subject: [issue11035] Segmentation fault
In-Reply-To: <1296207410.47.0.601145412555.issue11035@psf.upfronthosting.co.za>
Message-ID: <1296208295.33.0.239047917224.issue11035@psf.upfronthosting.co.za>


Dmitry Groshev <lambdadmitry at gmail.com> added the comment:

Ok, I've played with this some more and got some more segmenation faults. It looks like a gevent problem, but I think that python shouldn't completely fall so easy. Here is more traces:

si14 at si14-work:~/repos/monitoring/root$ python2.7 server.py 
{"seenby":[1],"received":1296208139.606481,"observer":1,"type":"ping","source":102,"time":1296208139.603046,"data":[[1296208051.083743,0.010155200958251953],[1296208060.923999,0.011048078536987305],[1296208070.76751,0.010570049285888672],[1296208080.613247,0.011930227279663086],[1296208090.454012,0.010123968124389648],[1296208100.283144,0.010128021240234375],[1296208110.114118,0.010215997695922852],[1296208119.943081,0.010147809982299805],[1296208129.774567,0.010593891143798828],[1296208139.603033,0.010541915893554688]],"class":"statistics"}
127.0.0.1 - - [2011-01-28 12:48:59] "POST / HTTP/1.1" 200 2 "-" "Python-urllib/2.7"
Traceback (most recent call last):
  File "evhttp.pxi", line 473, in gevent.core._http_cb_handler (gevent/core.c:13165)
Segmentation fault

127.0.0.1 - - [2011-01-28 12:47:30] "GET /update HTTP/1.1" 200 320 "-" "Python-urllib/2.7"
^CTraceback (most recent call last):
  File "server.py", line 34, in <module>
    gevent.wsgi.WSGIServer(("localhost", 8020), printer).serve_forever()
  File "build/bdist.linux-i686/egg/gevent/baseserver.py", line 183, in serve_forever
TypeError: raise: arg 3 must be a traceback or None
Segmentation fault
si14 at si14-work:~/repos/monitoring/root$

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11035>
_______________________________________

From report at bugs.python.org  Fri Jan 28 11:03:09 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Fri, 28 Jan 2011 10:03:09 +0000
Subject: [issue11034] Build problem on Windows with MSVC++ Express 2008
In-Reply-To: <1296200256.35.0.305421418262.issue11034@psf.upfronthosting.co.za>
Message-ID: <1296208989.01.0.317134490695.issue11034@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

Martin,

This makes sense, but keep in mind that:

1) Many, if indeed not *most* Windows SVN users use TortoiseSVN (and our dev guide recommends it, IIRC)
2) When TortoiseSVN *is* installed, it almost always goes into "Program Files" (its default installation path)

So the Windows buildbots don't represent one of the most common (IMHO) usage cases of building on Windows. Is it hard to implement? [i.e. use TortoiseSVN instead of cmd-line SVN on one of the Windows bots?]

Kristj?n - will you submit a patch for review? (this issue seems like a release blocker to me - but I'll leave it to Georg to decide on setting its priority)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11034>
_______________________________________

From report at bugs.python.org  Fri Jan 28 11:13:33 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Fri, 28 Jan 2011 10:13:33 +0000
Subject: [issue11034] Build problem on Windows with MSVC++ Express 2008
In-Reply-To: <1296208989.01.0.317134490695.issue11034@psf.upfronthosting.co.za>
Message-ID: <4D4296CB.9010601@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> Kristj?n - will you submit a patch for review? (this issue seems like
> a release blocker to me - but I'll leave it to Georg to decide on
> setting its priority)

I wouldn't say it's a release blocker: I can build Python just fine,
so the release isn't really blocked by this. For the bug, there is
an easy work-around: just create a file no_subwcrev, or avoid paths
with spaces in them.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11034>
_______________________________________

From report at bugs.python.org  Fri Jan 28 11:30:28 2011
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Fri, 28 Jan 2011 10:30:28 +0000
Subject: [issue11027] Implement sectionxform in configparser
In-Reply-To: <1296139025.05.0.619488294513.issue11027@psf.upfronthosting.co.za>
Message-ID: <1296210628.79.0.780436757768.issue11027@psf.upfronthosting.co.za>


?ukasz Langa <lukasz at langa.pl> added the comment:

Kunjesh, first of all many thanks for your feedback! A bit of advice, though. I have myself made the mistake of calling features I personally want as "often needed". The reality is that they are not often needed if they weren't reported before. While the current behaviour is not intuitive and probably unwelcome, it's hardly a bug if it has been that way for 15 years now.

At one point I had `sectionxform` implemented for configparser 3.2 but it made the source less readable. Then I thought about what Raymond taught me: is this a feature that follows a real use case? I concluded it didn't so I left it out. That being said, your report proves that such functionality would be welcome. I checked and ConfigObj does strip whitespace from section names, too. Nevertheless, in my opinion that's a feature request that only applies to Python 3.3. Your patches are for 2.7.

Let me elaborate a bit on a broader issue: configparser as of 3.2 still has only limited ability to write configuration files back (it strips whitespace and comments between options, option names get xformed). I want to fix that for 3.3 so the file can be altered and written back with only minimal changes. `optionxform` already gets in the way, `sectionxform` would too, if improperly implemented.

Raymond, I would want to keep the regexes as raw as possible as to enable writing the file back with the whitespace preserved. That includes whitespace around the section name, if we are to support that.

To conclude: I won't touch the regexes, I will implement `sectionxform` while implementing on-save whitespace and comment preservation for 3.3.

----------
keywords:  -patch
stage:  -> needs patch
title: Allow spaces around section header in ConfigParser -> Implement sectionxform in configparser

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11027>
_______________________________________

From report at bugs.python.org  Fri Jan 28 11:30:52 2011
From: report at bugs.python.org (Gael Pasgrimaud)
Date: Fri, 28 Jan 2011 10:30:52 +0000
Subject: [issue11036] Allow multiple files in the description-file metadata
In-Reply-To: <1296210652.15.0.670840085537.issue11036@psf.upfronthosting.co.za>
Message-ID: <1296210652.15.0.670840085537.issue11036@psf.upfronthosting.co.za>


New submission from Gael Pasgrimaud <gael at gawel.org>:

It can be usefull to allow more than one file in the description-file metadata so people can concatenate README and CHANGES file.

----------
assignee: tarek
components: Distutils2
messages: 127272
nosy: eric.araujo, gawel, tarek
priority: normal
severity: normal
status: open
title: Allow multiple files in the description-file metadata
type: feature request

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11036>
_______________________________________

From report at bugs.python.org  Fri Jan 28 11:32:15 2011
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 28 Jan 2011 10:32:15 +0000
Subject: [issue10940] IDLE 3.2 hangs with Cmd-M hotkey on OS X 10.6 with
	64-bit installer and A/S Tk 8.5
In-Reply-To: <1295391844.43.0.912463306116.issue10940@psf.upfronthosting.co.za>
Message-ID: <1296210735.08.0.988835341932.issue10940@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Why don't we just remove IDLE...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10940>
_______________________________________

From report at bugs.python.org  Fri Jan 28 11:34:50 2011
From: report at bugs.python.org (Sebastien Douche)
Date: Fri, 28 Jan 2011 10:34:50 +0000
Subject: [issue11037] How distutils2 handle namespaces
In-Reply-To: <1296210890.87.0.618097241127.issue11037@psf.upfronthosting.co.za>
Message-ID: <1296210890.87.0.618097241127.issue11037@psf.upfronthosting.co.za>


New submission from Sebastien Douche <sdouche at gmail.com>:

Namespace is very useful. In my company, we use a root namespace (sact.*) and a sub-namespace for each big project (sact.nevrax.*, sact.storage.*).

----------
assignee: tarek
components: Distutils2
messages: 127274
nosy: eric.araujo, sdouche, tarek
priority: normal
severity: normal
status: open
title: How distutils2 handle namespaces

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11037>
_______________________________________

From report at bugs.python.org  Fri Jan 28 11:37:58 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 28 Jan 2011 10:37:58 +0000
Subject: [issue10940] IDLE 3.2 hangs with Cmd-M hotkey on OS X 10.6 with
	64-bit installer and A/S Tk 8.5
In-Reply-To: <1295391844.43.0.912463306116.issue10940@psf.upfronthosting.co.za>
Message-ID: <1296211078.17.0.693306042656.issue10940@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Ned, I agree with your idea to knock-out the three problematic hot-kye combinations.

Georg, your solution is too radical and would do more harm than good.  I've been getting excellent use out of Py3.2's IDLE and I expect to use it as a teaching aid in some upcoming classes on advanced Python.  The loss of IDLE would be felt most actutely by beginners who don't necessarily have good alternatives.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10940>
_______________________________________

From report at bugs.python.org  Fri Jan 28 11:39:03 2011
From: report at bugs.python.org (Martin)
Date: Fri, 28 Jan 2011 10:39:03 +0000
Subject: [issue11034] Build problem on Windows with MSVC++ Express 2008
In-Reply-To: <1296200256.35.0.305421418262.issue11034@psf.upfronthosting.co.za>
Message-ID: <1296211143.02.0.909072495804.issue11034@psf.upfronthosting.co.za>


Martin <gzlist at googlemail.com> added the comment:

Eli, was just answering your question about why this didn't fail for other people.

Try the attached patch to see if it fixes the problem for you.

----------
keywords: +patch
Added file: http://bugs.python.org/file20571/issue11034.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11034>
_______________________________________

From report at bugs.python.org  Fri Jan 28 11:39:15 2011
From: report at bugs.python.org (Gael Pasgrimaud)
Date: Fri, 28 Jan 2011 10:39:15 +0000
Subject: [issue11038] Some commands should stop if Name and Version are missing
In-Reply-To: <1296211155.96.0.0798615868084.issue11038@psf.upfronthosting.co.za>
Message-ID: <1296211155.96.0.0798615868084.issue11038@psf.upfronthosting.co.za>


New submission from Gael Pasgrimaud <gael at gawel.org>:

distutils2 commands should stop if at least Name and Version metadatas are not provided in setup.cfg

For now you'll get a UNKNOWN-UNKNOWN.tar.gz

----------
assignee: tarek
components: Distutils2
messages: 127277
nosy: eric.araujo, gawel, tarek
priority: normal
severity: normal
status: open
title: Some commands should stop if Name and Version are missing
type: feature request

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11038>
_______________________________________

From report at bugs.python.org  Fri Jan 28 11:41:31 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 28 Jan 2011 10:41:31 +0000
Subject: [issue11027] Implement sectionxform in configparser
In-Reply-To: <1296139025.05.0.619488294513.issue11027@psf.upfronthosting.co.za>
Message-ID: <1296211291.92.0.694696884871.issue11027@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

My recommendation wasn't to change the regexes.

Instead, I recommended documenting how to override them in a subclass.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11027>
_______________________________________

From report at bugs.python.org  Fri Jan 28 11:43:03 2011
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Fri, 28 Jan 2011 10:43:03 +0000
Subject: [issue11027] Implement sectionxform in configparser
In-Reply-To: <1296139025.05.0.619488294513.issue11027@psf.upfronthosting.co.za>
Message-ID: <1296211383.85.0.147038875239.issue11027@psf.upfronthosting.co.za>


?ukasz Langa <lukasz at langa.pl> added the comment:

Sure, that I can do right away.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11027>
_______________________________________

From report at bugs.python.org  Fri Jan 28 11:45:36 2011
From: report at bugs.python.org (Martin)
Date: Fri, 28 Jan 2011 10:45:36 +0000
Subject: [issue11034] Build problem on Windows with MSVC++ Express 2008
In-Reply-To: <1296200256.35.0.305421418262.issue11034@psf.upfronthosting.co.za>
Message-ID: <1296211536.09.0.781060794216.issue11034@psf.upfronthosting.co.za>


Martin <gzlist at googlemail.com> added the comment:

...and this apparently came up on the mailinglist as well with Prasun providing nearly exactly the same patch:

<http://mail.python.org/pipermail/python-dev/2011-January/107599.html>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11034>
_______________________________________

From report at bugs.python.org  Fri Jan 28 12:02:40 2011
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 28 Jan 2011 11:02:40 +0000
Subject: [issue10940] IDLE 3.2 hangs with Cmd-M hotkey on OS X 10.6 with
	64-bit installer and A/S Tk 8.5
In-Reply-To: <1295391844.43.0.912463306116.issue10940@psf.upfronthosting.co.za>
Message-ID: <1296212560.63.0.681395098805.issue10940@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

I was just kidding (but I wish I weren't).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10940>
_______________________________________

From report at bugs.python.org  Fri Jan 28 12:03:09 2011
From: report at bugs.python.org (Kunjesh Kaushik)
Date: Fri, 28 Jan 2011 11:03:09 +0000
Subject: [issue11027] Implement sectionxform in configparser
In-Reply-To: <1296139025.05.0.619488294513.issue11027@psf.upfronthosting.co.za>
Message-ID: <1296212589.4.0.62015738681.issue11027@psf.upfronthosting.co.za>


Kunjesh Kaushik <kunjesh.kaushik at gmail.com> added the comment:

Very well, then. I would rely on sub-classing for now. The patch would work for me as I am only reading configuration. :)

And yes, I wouldn't deny the personal bias anyway. Thanks a lot for all your help, folks. Keep up the good work!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11027>
_______________________________________

From report at bugs.python.org  Fri Jan 28 12:05:46 2011
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Fri, 28 Jan 2011 11:05:46 +0000
Subject: [issue6203] 3.x locale does not default to C,
	contrary to the documentation and to 2.x behavior
In-Reply-To: <4D428D72.6000402@v.loewis.de>
Message-ID: <4D42A308.2000406@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Martin v. L?wis wrote:
> 
> Martin v. L?wis <martin at v.loewis.de> added the comment:
> 
>> An clean alternative would be adding LC_* variable parsing code to
>> Python to avoid the setlocale() call altogether.
> 
> That would be highly non-portable, and repeat the mistakes of
> getdefaultlocale.

You say that often, but I don't really know why. It's certainly portable
between various Unix platforms, perhaps not Windows, but then i18n
on Windows is a different story altogether.

BTW: For Windows, you can adjust setlocale() to work thread-based
using: _configthreadlocale()
(http://msdn.microsoft.com/de-de/library/26c0tb7x(v=vs.80).aspx)

Perhaps we ought to expose this in _locale and use it in
getdefaultlocal() on Windows to query the locale settings
via the pseudocode I posted.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6203>
_______________________________________

From report at bugs.python.org  Fri Jan 28 12:23:25 2011
From: report at bugs.python.org (Konstantin Osipov)
Date: Fri, 28 Jan 2011 11:23:25 +0000
Subject: [issue11039] Use of 'L' specifier is inconsistent when printing long
	integers
In-Reply-To: <1296213805.8.0.5306438252.issue11039@psf.upfronthosting.co.za>
Message-ID: <1296213805.8.0.5306438252.issue11039@psf.upfronthosting.co.za>


New submission from Konstantin Osipov <kostja.osipov at gmail.com>:

I'm using a 64 bit system, but the issue is as well repeatable on 32 bit systems: 

kostja at shmita:~$ python
Python 2.6.5 (r265:79063, Apr 16 2010, 13:57:41) 
[GCC 4.4.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> 0xffffffffffffffff
18446744073709551615L
>>> [0xffffffffffffffff]
[18446744073709551615L]
>>> str(0xffffffffffffffff)
'18446744073709551615'
>>> str([0xffffffffffffffff])
'[18446744073709551615L]'

Notice the 'L' specifier disappears when creating a string from an integer. I.e. depending on conversion order, 'L' specifier is present or absent in the resulting string representation.

I don't know the reason why 'L' specifier is necessary at all when printing integers, rather, I'd say it's very harmful, because makes Python program platform-dependent (since int is mapped to C long, 32-bit systems print 'L' where 64-bit systems don't), but please at least make the output consistent!

Thanks,
-- 
kostja

----------
components: None
messages: 127284
nosy: kostja
priority: normal
severity: normal
status: open
title: Use of 'L' specifier is inconsistent when printing long integers
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11039>
_______________________________________

From report at bugs.python.org  Fri Jan 28 12:31:29 2011
From: report at bugs.python.org (Julien Miotte)
Date: Fri, 28 Jan 2011 11:31:29 +0000
Subject: [issue11040] After registering a project to PyPI,
	classifiers fields aren't displayed.
In-Reply-To: <1296214289.89.0.718507704088.issue11040@psf.upfronthosting.co.za>
Message-ID: <1296214289.89.0.718507704088.issue11040@psf.upfronthosting.co.za>


New submission from Julien Miotte <miotte.julien at gmail.com>:

When I register a project with a setup.cfg with the following classifiers:

classifier =
    Development Status :: 3 - Alpha
    License :: OSI Approved :: GNU General Public License (GPL)
    Environment :: X11 Applications :: Qt

And using the command:
$ python -m distutils2.run register

I can't find the classifiers on the PyPI project page, althought they can be found in the PKG-INFO generated by the 'sdist' command.

----------
assignee: tarek
components: Distutils2
messages: 127285
nosy: Julien.Miotte, eric.araujo, tarek, tarek-ziade
priority: normal
severity: normal
status: open
title: After registering a project to PyPI, classifiers fields aren't displayed.
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11040>
_______________________________________

From report at bugs.python.org  Fri Jan 28 12:32:41 2011
From: report at bugs.python.org (Julien Miotte)
Date: Fri, 28 Jan 2011 11:32:41 +0000
Subject: [issue11040] After registering a project to PyPI,
	classifiers fields aren't displayed.
In-Reply-To: <1296214289.89.0.718507704088.issue11040@psf.upfronthosting.co.za>
Message-ID: <1296214361.27.0.723884566931.issue11040@psf.upfronthosting.co.za>


Changes by Julien Miotte <miotte.julien at gmail.com>:


----------
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11040>
_______________________________________

From report at bugs.python.org  Fri Jan 28 12:36:53 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Fri, 28 Jan 2011 11:36:53 +0000
Subject: [issue11034] Build problem on Windows with MSVC++ Express 2008
In-Reply-To: <1296200256.35.0.305421418262.issue11034@psf.upfronthosting.co.za>
Message-ID: <1296214613.35.0.308195510594.issue11034@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

Martin, the patch fixed the problem for me and the code looks good.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11034>
_______________________________________

From report at bugs.python.org  Fri Jan 28 12:39:48 2011
From: report at bugs.python.org (Julien Miotte)
Date: Fri, 28 Jan 2011 11:39:48 +0000
Subject: [issue11041] On the distutils2 documentation,
	'requires-python' shouldn't be documented as *multi
In-Reply-To: <1296214788.72.0.049703794101.issue11041@psf.upfronthosting.co.za>
Message-ID: <1296214788.72.0.049703794101.issue11041@psf.upfronthosting.co.za>


New submission from Julien Miotte <miotte.julien at gmail.com>:

On the documentation page: http://distutils2.notmyidea.org/setupcfg.html, one can read :

# requires-python: Specifies the Python version the distribution requires. The value is a version number, as described in PEP 345. *optional *multi *environ

This is not consistant with the PEP 345 (http://www.python.org/dev/peps/pep-0345/#requires-python), which doesn't specify that this field is of multiple use.

Distutils's behaviour on this matter is consistent with the PEP thought, so there's only need to remove the "*multi" in the documentation.

----------
assignee: tarek
components: Distutils2
messages: 127287
nosy: Julien.Miotte, eric.araujo, tarek, tarek-ziade
priority: normal
severity: normal
status: open
title: On the distutils2 documentation, 'requires-python' shouldn't be documented as *multi

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11041>
_______________________________________

From report at bugs.python.org  Fri Jan 28 12:46:18 2011
From: report at bugs.python.org (Julien Miotte)
Date: Fri, 28 Jan 2011 11:46:18 +0000
Subject: [issue11042] [PyPI CSS] Adding project urls onto a project page using
	register, apparition of an overhead over the title
In-Reply-To: <1296215178.29.0.349266521718.issue11042@psf.upfronthosting.co.za>
Message-ID: <1296215178.29.0.349266521718.issue11042@psf.upfronthosting.co.za>


New submission from Julien Miotte <miotte.julien at gmail.com>:

When adding project urls onto a PyPI project page using the following setup.cfg extract:

project_url =
    Source repository,https://github.com/mike-perdide/qGitFilterBranch

And then registering the project with:

python -m distutils2.run register

Causes a not-so-nice overhead to appear just above the project title.

Can be seen in http://pypi.python.org/pypi/qGitFilterBranch/0.9.

----------
assignee: tarek
components: Distutils2
messages: 127288
nosy: Julien.Miotte, eric.araujo, tarek, tarek-ziade
priority: normal
severity: normal
status: open
title: [PyPI CSS] Adding project urls onto a project page using register, apparition of an overhead over the title

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11042>
_______________________________________

From report at bugs.python.org  Fri Jan 28 12:50:57 2011
From: report at bugs.python.org (Julien Miotte)
Date: Fri, 28 Jan 2011 11:50:57 +0000
Subject: [issue11043] On GNU/Linux (Ubuntu) distutils2.mkcfg shouldn't create
	an executable setup.cfg
In-Reply-To: <1296215457.79.0.848370821924.issue11043@psf.upfronthosting.co.za>
Message-ID: <1296215457.79.0.848370821924.issue11043@psf.upfronthosting.co.za>


New submission from Julien Miotte <miotte.julien at gmail.com>:

When using the command:

  $ python -m distutils2.mkcfg

To create a new setup.cfg, the resulting setup.cfg has the following permissions:

-rwxr-xr-x 1 mike mike  151 2011-01-28 12:47 setup.cfg*

I think the permissions should be 644

----------
assignee: tarek
components: Distutils2
messages: 127289
nosy: Julien.Miotte, eric.araujo, tarek, tarek-ziade
priority: normal
severity: normal
status: open
title: On GNU/Linux (Ubuntu) distutils2.mkcfg shouldn't create an executable setup.cfg
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11043>
_______________________________________

From report at bugs.python.org  Fri Jan 28 12:57:47 2011
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Fri, 28 Jan 2011 11:57:47 +0000
Subject: [issue11027] Implement sectionxform in configparser
In-Reply-To: <1296139025.05.0.619488294513.issue11027@psf.upfronthosting.co.za>
Message-ID: <1296215867.26.0.455590057356.issue11027@psf.upfronthosting.co.za>


Changes by ?ukasz Langa <lukasz at langa.pl>:


----------
Removed message: http://bugs.python.org/msg127279

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11027>
_______________________________________

From report at bugs.python.org  Fri Jan 28 12:58:06 2011
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Fri, 28 Jan 2011 11:58:06 +0000
Subject: [issue11027] Implement sectionxform in configparser
In-Reply-To: <1296139025.05.0.619488294513.issue11027@psf.upfronthosting.co.za>
Message-ID: <1296215886.81.0.866709514183.issue11027@psf.upfronthosting.co.za>


?ukasz Langa <lukasz at langa.pl> added the comment:

Documentation updated in r88220.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11027>
_______________________________________

From report at bugs.python.org  Fri Jan 28 13:00:54 2011
From: report at bugs.python.org (Julien Miotte)
Date: Fri, 28 Jan 2011 12:00:54 +0000
Subject: [issue11044] The description-file isn't handled by distutils2
In-Reply-To: <1296216054.85.0.726988451009.issue11044@psf.upfronthosting.co.za>
Message-ID: <1296216054.85.0.726988451009.issue11044@psf.upfronthosting.co.za>


New submission from Julien Miotte <miotte.julien at gmail.com>:

When using the description-file field with a README.txt, and then using the 'sdist' command, the generated PKG-INFO file will contain:

Description: UNKNOWN



Note: when using the description field with a simple string, the generated PKG-INFO file will contain the correct string.

----------
assignee: tarek
components: Distutils2
messages: 127291
nosy: Julien.Miotte, eric.araujo, tarek, tarek-ziade
priority: normal
severity: normal
status: open
title: The description-file isn't handled by distutils2
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11044>
_______________________________________

From report at bugs.python.org  Fri Jan 28 13:06:44 2011
From: report at bugs.python.org (Eric Smith)
Date: Fri, 28 Jan 2011 12:06:44 +0000
Subject: [issue11032] _string: formatter_field_name_split() and
	formatter_parser doesn't check input type
In-Reply-To: <1296169676.06.0.782920211182.issue11032@psf.upfronthosting.co.za>
Message-ID: <1296216404.09.0.269308026779.issue11032@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

The patch looks good to me. I've added some more tests to cover some corner cases.

Go ahead and commit it.

----------
Added file: http://bugs.python.org/file20572/_string0.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11032>
_______________________________________

From report at bugs.python.org  Fri Jan 28 13:08:39 2011
From: report at bugs.python.org (Ross Lagerwall)
Date: Fri, 28 Jan 2011 12:08:39 +0000
Subject: [issue10882] Add os.sendfile()
In-Reply-To: <1294691268.76.0.727179568007.issue10882@psf.upfronthosting.co.za>
Message-ID: <1296216519.46.0.648270276439.issue10882@psf.upfronthosting.co.za>


Ross Lagerwall <rosslagerwall at gmail.com> added the comment:

Attached is a new sendfile patch which fixes the issue with FreeBSD (and Mac OS X & DragonFly BSD from what I can see).

With regards to anacrolix's request, I think what Martin said in msg126049. i.e. if we want to provide a unifying layer on top of sendfile we can, but this should just expose sendfile() as is.

----------
Added file: http://bugs.python.org/file20573/sendfile_v3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10882>
_______________________________________

From report at bugs.python.org  Fri Jan 28 13:45:20 2011
From: report at bugs.python.org (Eric Smith)
Date: Fri, 28 Jan 2011 12:45:20 +0000
Subject: [issue11039] Use of 'L' specifier is inconsistent when printing long
	integers
In-Reply-To: <1296213805.8.0.5306438252.issue11039@psf.upfronthosting.co.za>
Message-ID: <1296218720.19.0.9891650072.issue11039@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

There is no suffix in python 3.x. Since this is a feature request, and there will be no new releases of 2.x, I'm closing this.

----------
nosy: +eric.smith
resolution:  -> rejected
stage:  -> committed/rejected
status: open -> closed
type:  -> feature request

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11039>
_______________________________________

From report at bugs.python.org  Fri Jan 28 13:48:01 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 28 Jan 2011 12:48:01 +0000
Subject: [issue11035] Segmentation fault
In-Reply-To: <1296207410.47.0.601145412555.issue11035@psf.upfronthosting.co.za>
Message-ID: <1296218881.14.0.195575437846.issue11035@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

I don't reproduce the issue. Could you run python under gdb and give us the C backtrace?

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11035>
_______________________________________

From report at bugs.python.org  Fri Jan 28 14:01:07 2011
From: report at bugs.python.org (Dmitry Groshev)
Date: Fri, 28 Jan 2011 13:01:07 +0000
Subject: [issue11035] Segmentation fault
In-Reply-To: <1296207410.47.0.601145412555.issue11035@psf.upfronthosting.co.za>
Message-ID: <1296219667.67.0.188294797534.issue11035@psf.upfronthosting.co.za>


Dmitry Groshev <lambdadmitry at gmail.com> added the comment:

I've changed gevent.wsgi server to gevent.pywsgi and it works as expected. Now I switched it back to gevent.wsgi and it doesn't crash too! That's strange, but I understand that you can't fix it without normal backtrace. I'm sorry for the inconvenience.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11035>
_______________________________________

From report at bugs.python.org  Fri Jan 28 14:03:20 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Fri, 28 Jan 2011 13:03:20 +0000
Subject: [issue11015] Bring test.support docs up to date
In-Reply-To: <1296009969.38.0.282241852849.issue11015@psf.upfronthosting.co.za>
Message-ID: <1296219800.67.0.945650661816.issue11015@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

Nick, agreed regarding verbose. Somehow I didn't think it would be used in other modules like that, and only looked in regrtest where I didn't see anything meaningful about verbose not being binary.

It's a good thing to document it, then :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11015>
_______________________________________

From report at bugs.python.org  Fri Jan 28 14:03:25 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Fri, 28 Jan 2011 13:03:25 +0000
Subject: [issue11015] Bring test.support docs up to date
In-Reply-To: <1296009969.38.0.282241852849.issue11015@psf.upfronthosting.co.za>
Message-ID: <1296219805.81.0.957701767447.issue11015@psf.upfronthosting.co.za>


Changes by Eli Bendersky <eliben at gmail.com>:


Removed file: http://bugs.python.org/file20564/issue11015.py3k.1.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11015>
_______________________________________

From report at bugs.python.org  Fri Jan 28 14:12:47 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 28 Jan 2011 13:12:47 +0000
Subject: [issue11039] Use of 'L' specifier is inconsistent when printing long
	integers
In-Reply-To: <1296213805.8.0.5306438252.issue11039@psf.upfronthosting.co.za>
Message-ID: <1296220367.93.0.592539821781.issue11039@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Python objects can have two textual representations: see the difference between str() and repr():
http://docs.python.org/tutorial/inputoutput.html
And indeed, Python3 chose to drop the 'L' suffix.

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11039>
_______________________________________

From report at bugs.python.org  Fri Jan 28 14:32:54 2011
From: report at bugs.python.org (Giampaolo Rodola')
Date: Fri, 28 Jan 2011 13:32:54 +0000
Subject: [issue10882] Add os.sendfile()
In-Reply-To: <1294691268.76.0.727179568007.issue10882@psf.upfronthosting.co.za>
Message-ID: <1296221574.18.0.807313337151.issue10882@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

Could you please also add support for offset argument on Linux?
Also, "headers", "trailers" and "flags" could be turned in keyword args for simplicity.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10882>
_______________________________________

From report at bugs.python.org  Fri Jan 28 14:48:10 2011
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Fri, 28 Jan 2011 13:48:10 +0000
Subject: [issue11045] shutil._make_tarball
In-Reply-To: <1296222490.15.0.786706157889.issue11045@psf.upfronthosting.co.za>
Message-ID: <1296222490.15.0.786706157889.issue11045@psf.upfronthosting.co.za>


New submission from Tarek Ziad? <ziade.tarek at gmail.com>:

This line : logger.info("creating %s" % archive_dir)

should check that logger is not None before being called..

----------
assignee: tarek
components: Library (Lib)
messages: 127300
nosy: tarek
priority: high
severity: normal
status: open
title: shutil._make_tarball
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11045>
_______________________________________

From report at bugs.python.org  Fri Jan 28 14:48:45 2011
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Fri, 28 Jan 2011 13:48:45 +0000
Subject: [issue11045] shutil._make_tarball
In-Reply-To: <1296222490.15.0.786706157889.issue11045@psf.upfronthosting.co.za>
Message-ID: <1296222525.62.0.620791542099.issue11045@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

will fix + write patch

----------
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11045>
_______________________________________

From report at bugs.python.org  Fri Jan 28 14:57:44 2011
From: report at bugs.python.org (Kelsey)
Date: Fri, 28 Jan 2011 13:57:44 +0000
Subject: [issue11045] shutil._make_tarball
In-Reply-To: <1296222490.15.0.786706157889.issue11045@psf.upfronthosting.co.za>
Message-ID: <1296223064.64.0.396305689891.issue11045@psf.upfronthosting.co.za>


Kelsey <kelsey.hightower at gmail.com> added the comment:

Adding stacktrace to ticket

----------
nosy: +kelseyhightower
Added file: http://bugs.python.org/file20574/distutils2_logger.info_bug.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11045>
_______________________________________

From report at bugs.python.org  Fri Jan 28 15:07:18 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Fri, 28 Jan 2011 14:07:18 +0000
Subject: [issue9124] Mailbox module should use binary I/O, not text I/O
In-Reply-To: <1277900903.38.0.556015912714.issue9124@psf.upfronthosting.co.za>
Message-ID: <1296223638.81.0.175646102437.issue9124@psf.upfronthosting.co.za>


Steffen Daode Nurpmeso <sdaoden at googlemail.com> added the comment:

After cloning branches/py3k (i now have three different detached repo snakes in my arena (2.7,3.1,py3k), by the way - not bad for a greenhorn, huh?).
I've applied RDMs patch from msg127245.
Note: the test mails are *malformed*!
Stuff in brackets are my error messages, rest is "str(ex)".

1. Single Latin-1 character in "From:" (00F6;LATIN SMALL LETTER O WITH DIAERESIS):
    [ERROR: failed to handle box "/Users/steffen/tmp/au.latin1":] expected string or buffer
2. Whatever-Encoding in "Subject:" (see example 2 below):
    [PANIC: Box source-changes.mdir: message-add failed, mails may be lost:] 'ascii' codec can't encode character '\ufffd' in position 8: ordinal not in range(128)

Here are two stripped header fields pasted in an UTF-8 environment:

From: "SAJATNAPTAR.COM" <info at sajatnaptar.com>$
Subject: Falinapt?r ingyenes h?zhozsz?ll?t?ssal. M?r rendelt?l? Olvass el!

From: "Syria Trade Center :" <no-reply at syriatc.com>$
Subject: ?????? ?????? ??????? ?????? - ?????? 2011

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9124>
_______________________________________

From report at bugs.python.org  Fri Jan 28 15:26:24 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Fri, 28 Jan 2011 14:26:24 +0000
Subject: [issue11046] darwin/MacOS X setup.py hack
In-Reply-To: <1296224784.81.0.0525228154056.issue11046@psf.upfronthosting.co.za>
Message-ID: <1296224784.81.0.0525228154056.issue11046@psf.upfronthosting.co.za>


New submission from Steffen Daode Nurpmeso <sdaoden at googlemail.com>:

I always hated GNU Autoconf and M4.
After cloning branches/py3k today i needed two and a half hour to build and compile a Python which includes the readline module.
I'll attach a primitive setup.py patch which should better not make it into a release version ...

Some more notes on the compilation:
Snow Leopard here has SDK's 10.5 and 10.6.
I did not understand what was going on, configure does everything to explain me it is using (nonexistent) 10.4.
The configure script is
    checking for OSX 10.5 SDK or later... yes
but that doesn't seem to matter.  I gave up on hacking (the anyway generated) configure (around line 5532), no matter what i do, i still get
    CONFIGURE_MACOSX_DEPLOYMENT_TARGET='10.4'
Damn!
Ooh, Ooh, how nice are plain Makefiles and small-team projects.

----------
components: Build
files: DIFF
messages: 127304
nosy: sdaoden
priority: normal
severity: normal
status: open
title: darwin/MacOS X setup.py hack
versions: Python 3.2
Added file: http://bugs.python.org/file20575/DIFF

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11046>
_______________________________________

From report at bugs.python.org  Fri Jan 28 15:27:21 2011
From: report at bugs.python.org (R. David Murray)
Date: Fri, 28 Jan 2011 14:27:21 +0000
Subject: [issue9124] Mailbox module should use binary I/O, not text I/O
In-Reply-To: <1277900903.38.0.556015912714.issue9124@psf.upfronthosting.co.za>
Message-ID: <1296224841.73.0.559315573902.issue9124@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Steffen: thanks for testing.  Do those error messages have tracebacks?  Can you post them?  Can you post example messages and a short program that demonstrates the problem?  I'm going to be creating some non-ascii test cases, but any additional info you can provide will give me a leg up on that.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9124>
_______________________________________

From report at bugs.python.org  Fri Jan 28 15:50:21 2011
From: report at bugs.python.org (Peter)
Date: Fri, 28 Jan 2011 14:50:21 +0000
Subject: [issue10148] st_mtime differs after shutil.copy2
In-Reply-To: <1287530071.19.0.608159353416.issue10148@psf.upfronthosting.co.za>
Message-ID: <1296226221.96.0.846664004322.issue10148@psf.upfronthosting.co.za>


Peter <p.j.a.cock at googlemail.com> added the comment:

I'm also seeing this on 32bit Windows XP using Python 3.1.2, and Python 3.2rc1 on a local NTFS filesystem.

e.g. from os.stat(filename).st_mtime after using shutil.copy2(...)

1293634856.1402586 source
1293634856.1402581 copied

I've been using shutil.copy2 then expecting st_mtime will be equal (or at least that the copy file will be newer than the original). As you can see in this case, the copy is sometimes a fraction older.

The same issue occurs using shutil.copy then shutils.copystat (probably not a surprise).

----------
nosy: +maubp

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10148>
_______________________________________

From report at bugs.python.org  Fri Jan 28 15:54:19 2011
From: report at bugs.python.org (Scott M)
Date: Fri, 28 Jan 2011 14:54:19 +0000
Subject: [issue11029] Crash, 2.7.1, Tkinter and threads and line drawing
In-Reply-To: <1296147664.2.0.443864502869.issue11029@psf.upfronthosting.co.za>
Message-ID: <1296226459.02.0.877442468546.issue11029@psf.upfronthosting.co.za>


Scott M <scott.mayo at comcast.net> added the comment:

OK, now all calls to Tkinter are funneled to a single thread, through a queue. (Technically there are two threads in Tkinter - one is parked in .mainloop(), the other makes a call to Canvas.create_line and a call to Label.config.) Different crash, but still a crash. This one seems to be mostly consistent; see below and new attached code.

If you're going to tell me that Tkinter simply can never be called by any thread other than the one animating mainloop - in other words, Tkinter calls are only safe within Tkinter callbacks like a Button's command function - then please suggest an alternative library that is sturdier. There's nothing I can do about the fact that multiple threads produce independent data that has to go onto a single graph.

Exception in thread Thread-1:
Traceback (most recent call last):
  File "C:\Python27\lib\threading.py", line 530, in __bootstrap_inner
    self.run()
  File "C:\Documents and Settings\mayos\Desktop\PMT2\MyProjects\TkinterCrash.py", line 68, in run
    self.graph.create_line(element[0], element[1], element[2], element[3])
  File "C:\Python27\lib\lib-tk\Tkinter.py", line 2201, in create_line
    return self._create('line', args, kw)
  File "C:\Python27\lib\lib-tk\Tkinter.py", line 2189, in _create
    *(args + self._options(cnf, kw))))
ValueError: invalid literal for int() with base 10: 'None'

But once I got:

Exception in thread Thread-1:
Traceback (most recent call last):
  File "C:\Python27\lib\threading.py", line 530, in __bootstrap_inner
    self.run()
  File "C:\Documents and Settings\mayos\Desktop\PMT2\MyProjects\TkinterCrash2.py", line 68, in run
    self.graph.create_line(element[0], element[1], element[2], element[3])
  File "C:\Python27\lib\lib-tk\Tkinter.py", line 2201, in create_line
    return self._create('line', args, kw)
  File "C:\Python27\lib\lib-tk\Tkinter.py", line 2189, in _create
    *(args + self._options(cnf, kw))))
TclError: can not find channel named "Nonefile13cad48"

----------
Added file: http://bugs.python.org/file20576/TkinterCrash2.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11029>
_______________________________________

From report at bugs.python.org  Fri Jan 28 15:57:43 2011
From: report at bugs.python.org (R. David Murray)
Date: Fri, 28 Jan 2011 14:57:43 +0000
Subject: [issue11046] darwin/MacOS X setup.py hack
In-Reply-To: <1296224784.81.0.0525228154056.issue11046@psf.upfronthosting.co.za>
Message-ID: <1296226663.17.0.364658156485.issue11046@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

The OSX build process is...hairy.  Windows likewise (because you have to use MS tools).  Elsewhere, it is pretty straightforward :)

The 10.4 deployment target is the one we want.  You can build for a 10.4 deployment target even if you are using a later SDK (IIUC).  More that that I don't know, but I'm adding our Mac experts to the nosy list in case there is something here that's useful, and so they can correct me if I'm wrong :)

There should probably be more notes about this in the Mac/README.

----------
assignee:  -> ronaldoussoren
components: +Macintosh
nosy: +ned.deily, r.david.murray, ronaldoussoren

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11046>
_______________________________________

From report at bugs.python.org  Fri Jan 28 15:59:49 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Fri, 28 Jan 2011 14:59:49 +0000
Subject: [issue9124] Mailbox module should use binary I/O, not text I/O
In-Reply-To: <1277900903.38.0.556015912714.issue9124@psf.upfronthosting.co.za>
Message-ID: <1296226789.62.0.521367018065.issue9124@psf.upfronthosting.co.za>


Steffen Daode Nurpmeso <sdaoden at googlemail.com> added the comment:

Indeed i tried to create tracebacks (even with "import traceback"), but these all end up in my code (and all the time).  I have not yet figured out how to create tracebacks which leave my code and reach the source, which surely must be somewhere in email/ - even with the -d command line switch.
Wait a bit for the rest - i would indeed post my halfway-thought-through-and-developed S-Postman if you would ask for it.  It however simply uses the email package (mailbox,email,FeedParser) and is a 30KB thing with config-file parsing etc..

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9124>
_______________________________________

From report at bugs.python.org  Fri Jan 28 16:01:13 2011
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Fri, 28 Jan 2011 15:01:13 +0000
Subject: [issue11022] locale.setlocale() doesn't change I/O codec,
	os.environ does
In-Reply-To: <1296126025.04.0.965125504096.issue11022@psf.upfronthosting.co.za>
Message-ID: <1296226873.28.0.317787077187.issue11022@psf.upfronthosting.co.za>


Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:


----------
title: locale.setlocale() doesn't change I/O codec,	os.environ -> locale.setlocale() doesn't change I/O codec, os.environ does

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11022>
_______________________________________

From report at bugs.python.org  Fri Jan 28 16:01:17 2011
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Fri, 28 Jan 2011 15:01:17 +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: <1296226877.86.0.278443285871.issue6203@psf.upfronthosting.co.za>


Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:


----------
title: 3.x locale does not default to C,	contrary to the documentation and to 2.x behavior -> 3.x locale does not default to C, contrary to the documentation and to 2.x behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6203>
_______________________________________

From report at bugs.python.org  Fri Jan 28 16:08:20 2011
From: report at bugs.python.org (R. David Murray)
Date: Fri, 28 Jan 2011 15:08:20 +0000
Subject: [issue9124] Mailbox module should use binary I/O, not text I/O
In-Reply-To: <1277900903.38.0.556015912714.issue9124@psf.upfronthosting.co.za>
Message-ID: <1296227300.58.0.324474512793.issue9124@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I don't see those error messages in the mailbox source.  I'm guess your application isn trapping the errors in a try/except.  In that case, just do a bare 'raise' in the except clause, and you should get the full traceback.

I'm sure I'll discover problems just using your simple examples.  Likely your full code would be more of a distraction than a help, unless we end up in a situation where I've fixed all the bugs I can find and you are still having problems.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9124>
_______________________________________

From report at bugs.python.org  Fri Jan 28 16:09:17 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 28 Jan 2011 15:09:17 +0000
Subject: [issue10845] test_multiprocessing failure under Windows
In-Reply-To: <1294309581.41.0.731804987161.issue10845@psf.upfronthosting.co.za>
Message-ID: <1296227357.82.0.875226628224.issue10845@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

There isn't really much "-m test" can do to flag this - multiprocessing is making assumptions about the meaning of __file__ that may be flat out invalid when -m is used to execute the main module.

Fixing that properly is going to require a PEP so the interpreter preserves the information that multiprocessing needs in order to spawn the child process correctly on Windows. (I already have that on my personal todo list for 3.3)

I'm not sure what to do for 3.2. We could comment out the assert, since that will be slightly less broken than the current total failure (it will still be slightly broken, though).

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10845>
_______________________________________

From report at bugs.python.org  Fri Jan 28 16:09:22 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Fri, 28 Jan 2011 15:09:22 +0000
Subject: [issue11046] darwin/MacOS X setup.py hack
In-Reply-To: <1296224784.81.0.0525228154056.issue11046@psf.upfronthosting.co.za>
Message-ID: <1296227362.87.0.665929632835.issue11046@psf.upfronthosting.co.za>


Steffen Daode Nurpmeso <sdaoden at googlemail.com> added the comment:

Ok, thanks.  Mac/README is not for me, though, i'm only a simple Ex-FreeBSD user which buyed good hardware with the wrong operating system.  All these mysterious frameworks and AvailabilityMacros.h really make you weird  ;-)  There are indeed frameworks (AU - speak this as if it hurts!) which tell you something in an event handler and after that returns they will have forgotten it.  Etc.  Nope, i'm doing the UNIX thing.

But it's worse now, because after i've only using
    ./configure --prefix=$HOME/usr --with-suffix=no
(without --pydebug, that was an error of mine) i can't compile it no more at all, because of:
   Failed to build these modules:
   _multiprocessing
And now i would *really* appreciate any help i can get.
(Thank all of you right now, i'm offline for next hours...)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11046>
_______________________________________

From report at bugs.python.org  Fri Jan 28 16:14:49 2011
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Fri, 28 Jan 2011 15:14:49 +0000
Subject: [issue10148] st_mtime differs after shutil.copy2
In-Reply-To: <1287530071.19.0.608159353416.issue10148@psf.upfronthosting.co.za>
Message-ID: <1296227689.56.0.29586477432.issue10148@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/issue10148>
_______________________________________

From report at bugs.python.org  Fri Jan 28 16:20:46 2011
From: report at bugs.python.org (A.M. Kuchling)
Date: Fri, 28 Jan 2011 15:20:46 +0000
Subject: [issue9124] Mailbox module should use binary I/O, not text I/O
In-Reply-To: <1277900903.38.0.556015912714.issue9124@psf.upfronthosting.co.za>
Message-ID: <1296228046.86.0.410257587406.issue9124@psf.upfronthosting.co.za>


Changes by A.M. Kuchling <lists at amk.ca>:


----------
nosy:  -akuchling

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9124>
_______________________________________

From report at bugs.python.org  Fri Jan 28 16:21:27 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Fri, 28 Jan 2011 15:21:27 +0000
Subject: [issue9124] Mailbox module should use binary I/O, not text I/O
In-Reply-To: <1277900903.38.0.556015912714.issue9124@psf.upfronthosting.co.za>
Message-ID: <1296228087.28.0.850479917738.issue9124@psf.upfronthosting.co.za>


Steffen Daode Nurpmeso <sdaoden at googlemail.com> added the comment:

You're indeed right, i've overseen a try..catch!
I'll even be able to give you some fast code hints now
(and i'll be offline the next few hours - the mails are simply mails with illegal charsets, say):

Traceback (most recent call last):
  File "/Users/steffen/tmp/y/s-postman.py", line 1098, in <module>
    sys.exit(main())
  File "/Users/steffen/tmp/y/s-postman.py", line 1088, in main
    xclass = xclass() # Impl. class chosen upon commline args
  File "/Users/steffen/tmp/y/s-postman.py", line 951, in __init__
    self._walk()
       def _walk(self):
                verb("--dispatch: starting iteration over input boxes")
                for b, t in _Dispatch_Boxes:
                        box = open_mailbox(b, type=t, create=False)
                        try:
                                self._do_box(box)
                        except Exception as e:
                                raise
  File "/Users/steffen/tmp/y/s-postman.py", line 958, in _walk
    self._do_box(box)
        def _do_box(self, box):
                cnt = len(box)
                log("* Box contains ", cnt, " messages")
                for nr in range(cnt):
                        log("  * Dispatching message ", nr+1)
                        msg = box.get_message(nr)
                        Ticket.process_msg(msg)
                log("  @ Dispatched ", cnt, " messages, finished box")
  File "/Users/steffen/tmp/y/s-postman.py", line 982, in _do_box
    Ticket.process_msg(msg)
        @staticmethod
        def process_msg(msg):
                ticket = Ticket(msg)
                (match, ruleset, to_box) = Ruleset.dispatch_ticket(ticket)
                if not match:
                        to_box.add_ticket(ticket)
                        return
                splitter = to_box.get_archive_splitter()
                if not splitter or config.get_keep_archives():
                        to_box.add_ticket(ticket)
                        return
                log("    @ Treating ticket ", ticket._id,
                        " as archive, splitting")
                for msg in splitter(msg):
                        ticket = Ticket(msg)
                        to_box.add_ticket(ticket)
  File "/Users/steffen/tmp/y/s-postman.py", line 898, in process_msg
    to_box.add_ticket(ticket)
        def add_ticket(self, ticket, ignore_errors=False):
                efun = panic
                if ignore_errors:
                        efun = error
                log("    @ Saving ticket ", ticket.get_id(),
                        " in \"", self._ident, "\"")
                mbox = self._mailbox
                if not mbox:
                        mbox = os.path.join(config.get_folder(), self._path)
                        mbox = open_mailbox(mbox, type=self._type, create=True)
                        self._mailbox = mbox
                        try:
                                mbox.lock()
                        except Exception as e:
                                efun("Could not gain mailbox lock!")
                try:
                        mbox.add(ticket.get_msg())
                        mbox.flush()
                except Exception as e:
                        #efun("Box ", self._ident,
                        #       ": message-add failed, ",
                        #       "mails may be lost: ", str(e))
                        raise
  File "/Users/steffen/tmp/y/s-postman.py", line 680, in add_ticket
    mbox.add(ticket.get_msg())
  File "/Users/steffen/usr/lib/python3.2/mailbox.py", line 259, in add
    self._dump_message(message, tmp_file)
  File "/Users/steffen/usr/lib/python3.2/mailbox.py", line 205, in _dump_message
    gen.flatten(message)
  File "/Users/steffen/usr/lib/python3.2/email/generator.py", line 88, in flatten
    self._write(msg)
  File "/Users/steffen/usr/lib/python3.2/email/generator.py", line 141, in _write
    self._write_headers(msg)
  File "/Users/steffen/usr/lib/python3.2/email/generator.py", line 372, in _write_headers
    header_name=h)
  File "/Users/steffen/usr/lib/python3.2/email/header.py", line 197, in __init__
    self.append(s, charset, errors)
  File "/Users/steffen/usr/lib/python3.2/email/header.py", line 275, in append
    s.encode(output_charset, errors)
UnicodeEncodeError: 'ascii' codec can't encode character '\ufffd' in position 8: ordinal not in range(128)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9124>
_______________________________________

From report at bugs.python.org  Fri Jan 28 17:28:45 2011
From: report at bugs.python.org (Ronald Oussoren)
Date: Fri, 28 Jan 2011 16:28:45 +0000
Subject: [issue11046] darwin/MacOS X setup.py hack
In-Reply-To: <1296224784.81.0.0525228154056.issue11046@psf.upfronthosting.co.za>
Message-ID: <1296232125.87.0.301316365222.issue11046@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

Use:

configure ...[other args]... MACOSX_DEPLOYMENT_TARGET=10.5

(or 10.6 when you're on a 10.6 system)

This will build using the deployment target you mention, and will automaticly include the readline module using Apple's compatiblity wrapper around libedit.  To use GNU's readline you have to install that first and arrange for that to be on the search path (for example by installing into /usr/local).

BTW. Mac/README is for you, you are on OSX after all and that file explains a lot of the mac-specific issues w.r.t. building.  

Feel free to suggest additions to that file, I'm way to much at home on OSX and with the build process to truly know what a new user on OSX would like to see mentioned in that file.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11046>
_______________________________________

From report at bugs.python.org  Fri Jan 28 17:30:53 2011
From: report at bugs.python.org (Daniel Urban)
Date: Fri, 28 Jan 2011 16:30:53 +0000
Subject: [issue1294232] Error in metaclass search order
Message-ID: <1296232253.32.0.787989656278.issue1294232@psf.upfronthosting.co.za>


Daniel Urban <urban.dani+py at gmail.com> added the comment:

It seems, that this possible problem already came up when __build_class__ got implemented, see issue1681101. The second and third version of the patch at this issue (file7874 and file7875) contains a comment: "XXX Should we do the "winner" calculation here?". But the next version, which contains the C implementation of __build_class__ still uses simply the first base. The "winner calculation" probably refers to the algorithm determining the proper metaclass in lines 1950-1976 of typeobject.c (in type_new).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1294232>
_______________________________________

From report at bugs.python.org  Fri Jan 28 17:38:12 2011
From: report at bugs.python.org (Scott M)
Date: Fri, 28 Jan 2011 16:38:12 +0000
Subject: [issue11029] Crash, 2.7.1, Tkinter and threads and line drawing
In-Reply-To: <1296147664.2.0.443864502869.issue11029@psf.upfronthosting.co.za>
Message-ID: <1296232692.27.0.198807278882.issue11029@psf.upfronthosting.co.za>


Scott M <scott.mayo at comcast.net> added the comment:

Alright. More digging turned up the Tkinter "after" function, aka WM_TIMER for Windowy people like me, and that plus a nonblocking queue get() gets all my drawing operations back into the mainLoop() thread. Voil?, no more crashes.

Let me suggest that page one, sentence one of any Tkinter documentation should begin "Tkinter is not thread safe", with a link to an example of after() and nonblocking get(). I've changed the component to Documentation. This would save a few days for poor sods like me -- I'm used to low level Windows C++ GUI work, where any thread can call any SDK function at any time, and Windows sorts it all out. 

Having to force everything into a single thread, and then poll for my data (*GAG*), is something I thought died in the 80's. Is anyone looking at thread safe GUI libraries?

----------
assignee:  -> docs at python
components: +Documentation -Tkinter
nosy: +docs at python

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11029>
_______________________________________

From report at bugs.python.org  Fri Jan 28 17:53:28 2011
From: report at bugs.python.org (Oren Held)
Date: Fri, 28 Jan 2011 16:53:28 +0000
Subject: [issue11047] Bad description for a change
In-Reply-To: <1296233608.02.0.630598474753.issue11047@psf.upfronthosting.co.za>
Message-ID: <1296233608.02.0.630598474753.issue11047@psf.upfronthosting.co.za>


New submission from Oren Held <oren at held.org.il>:

In the "what's new in 2.7", there is some mistake in the description of issue 7902.

7902, afaik, disables the fallback to absolute import, when requesting a relative import fails. If I got it right, the description states the opposite.

----------
assignee: docs at python
components: Documentation
files: whatsnew_issue_7902_fix.patch
keywords: patch
messages: 127317
nosy: Oren_Held, docs at python
priority: normal
severity: normal
status: open
title: Bad description for a change
versions: Python 2.7
Added file: http://bugs.python.org/file20577/whatsnew_issue_7902_fix.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11047>
_______________________________________

From report at bugs.python.org  Fri Jan 28 18:05:10 2011
From: report at bugs.python.org (Pavel Labushev)
Date: Fri, 28 Jan 2011 17:05:10 +0000
Subject: [issue11048] "import ctypes" causes segfault on read-only filesystem
In-Reply-To: <1296234309.62.0.290829997988.issue11048@psf.upfronthosting.co.za>
Message-ID: <1296234309.62.0.290829997988.issue11048@psf.upfronthosting.co.za>


New submission from Pavel Labushev <p.labushev at gmail.com>:

"import ctypes" causes segfault on read-only filesystem

This regression was introduced in python-2.6.6 and exists in all the later versions.

To reproduce run python -c "import ctypes" on read-only filesystem:


(gdb) file python3.2
Reading symbols from /usr/bin/python3.2...done.
(gdb) run -c "import ctypes"
Starting program: /usr/bin/python3.2 -c "import ctypes"
[Thread debugging using libthread_db enabled]

Program received signal SIGSEGV, Segmentation fault.
0xb7af605c in CThunkObject_dealloc (_self=0xb7b35344)
    at /var/tmp/portage/dev-lang/python-3.2_pre20110123/work/python-3.2_pre20110123/Modules/_ctypes/callbacks.c:18
18      /var/tmp/portage/dev-lang/python-3.2_pre20110123/work/python-3.2_pre20110123/Modules/_ctypes/callbacks.c: No such file or directory.
        in /var/tmp/portage/dev-lang/python-3.2_pre20110123/work/python-3.2_pre20110123/Modules/_ctypes/callbacks.c
(gdb) bt
#0  0xb7af605c in CThunkObject_dealloc (_self=0xb7b35344)
    at /var/tmp/portage/dev-lang/python-3.2_pre20110123/work/python-3.2_pre20110123/Modules/_ctypes/callbacks.c:18
#1  0xb7af63b4 in _ctypes_alloc_callback (callable=0xb7b10bec, converters=0xb7c4e02c, restype=0xb810c544, flags=257)
    at /var/tmp/portage/dev-lang/python-3.2_pre20110123/work/python-3.2_pre20110123/Modules/_ctypes/callbacks.c:439
#2  0xb7af1f57 in PyCFuncPtr_new (type=0xb810b0bc, args=0xb7b3618c, kwds=0x0)
    at /var/tmp/portage/dev-lang/python-3.2_pre20110123/work/python-3.2_pre20110123/Modules/_ctypes/_ctypes.c:3339
#3  0xb7ea2355 in type_call (type=0xb810b0bc, args=0xb7b3618c, kwds=0x0) at Objects/typeobject.c:676
#4  0xb7e4f34e in PyObject_Call (func=0xb810b0bc, arg=0xb7b3618c, kw=0x0) at Objects/abstract.c:2149
#5  0xb7eedee3 in do_call (f=0xb80fdb44, throwflag=0) at Python/ceval.c:4095
#6  call_function (f=0xb80fdb44, throwflag=0) at Python/ceval.c:3898
#7  PyEval_EvalFrameEx (f=0xb80fdb44, throwflag=0) at Python/ceval.c:2673
#8  0xb7ef0639 in PyEval_EvalCodeEx (_co=0xb7b159d0, globals=0xb7bf40b4, locals=0xb7bf40b4, args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0, defcount=0,
    kwdefs=0x0, closure=0x0) at Python/ceval.c:3311
#9  0xb7ef08b6 in PyEval_EvalCode (co=0xb7b159d0, globals=0xb7bf40b4, locals=0xb7bf40b4) at Python/ceval.c:761
#10 0xb7f0121c in PyImport_ExecCodeModuleWithPathnames (name=0xbfffd9fb "ctypes", co=0xb7b159d0,
    pathname=0xbfffa89b "/usr/lib/python3.2/ctypes/__pycache__/__init__.cpython-32.pyc",
    cpathname=0xbfffa89b "/usr/lib/python3.2/ctypes/__pycache__/__init__.cpython-32.pyc") at Python/import.c:809
#11 0xb7f03ce8 in load_source_module (name=<value optimized out>, pathname=<value optimized out>, fp=0xb8020b28) at Python/import.c:1339
#12 0xb7f044f8 in load_package (name=<value optimized out>, pathname=<value optimized out>) at Python/import.c:1435
#13 0xb7f04da7 in import_submodule (mod=<value optimized out>, subname=<value optimized out>, fullname=0xbfffd9fb "ctypes") at Python/import.c:2894
#14 0xb7f050b4 in load_next (mod=<value optimized out>, altmod=<value optimized out>, p_name=0xbfffd9ec, buf=0xbfffd9fb "ctypes", p_buflen=0xbfffd9f4)
    at Python/import.c:2706
#15 0xb7f05774 in import_module_level (name=0x0, globals=<value optimized out>, locals=0xb7c2035c, fromlist=0xb7f98ca0, level=0) at Python/import.c:2422
#16 0xb7f05d14 in PyImport_ImportModuleLevel (name=0xb7c0f8e8 "ctypes", globals=0xb7c2035c, locals=0xb7c2035c, fromlist=0xb7f98ca0, level=0)
    at Python/import.c:2474
#17 0xb7ee73c1 in builtin___import__ (self=0xb7c6726c, args=0xb7c7b9bc, kwds=0x0) at Python/bltinmodule.c:168
#18 0xb7e907fe in PyCFunction_Call (func=0xb7c6730c, arg=0xb7c7b9bc, kw=0xb7b35344) at Objects/methodobject.c:84
#19 0xb7e4f34e in PyObject_Call (func=0xb7c6730c, arg=0xb7c7b9bc, kw=0x0) at Objects/abstract.c:2149
#20 0xb7ee802f in PyEval_CallObjectWithKeywords (func=0xb7c6730c, arg=0xb7c7b9bc, kw=0x0) at Python/ceval.c:3755
#21 0xb7eec962 in PyEval_EvalFrameEx (f=0xb8072564, throwflag=0) at Python/ceval.c:2332
#22 0xb7ef0639 in PyEval_EvalCodeEx (_co=0xb7bdb7f0, globals=0xb7c2035c, locals=0xb7c2035c, args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0, defcount=0,
    kwdefs=0x0, closure=0x0) at Python/ceval.c:3311
#23 0xb7ef08b6 in PyEval_EvalCode (co=0xb7bdb7f0, globals=0xb7c2035c, locals=0xb7c2035c) at Python/ceval.c:761
#24 0xb7f0eabc in run_mod (mod=<value optimized out>, filename=<value optimized out>, globals=0xb7c2035c, locals=0xb7c2035c, flags=0xbfffefa8,
    arena=0xb8071030) at Python/pythonrun.c:1760
#25 0xb7f0edf9 in PyRun_StringFlags (str=0xb7bf5330 "import ctypes\n", start=257, globals=0xb7c2035c, locals=0xb7c2035c, flags=0xbfffefa8)
    at Python/pythonrun.c:1694
#26 0xb7f11006 in PyRun_SimpleStringFlags (command=0xb7bf5330 "import ctypes\n", flags=0xbfffefa8) at Python/pythonrun.c:1267
#27 0xb7f2477c in run_command (argc=3, argv=0xb8001018) at Modules/main.c:258
#28 Py_Main (argc=3, argv=0xb8001018) at Modules/main.c:647
#29 0xb7fffc4f in main (argc=3, argv=0xbffff0d4) at ./Modules/python.c:82
(gdb) quit

----------
assignee: theller
components: ctypes
messages: 127318
nosy: Arach, Arfrever, theller
priority: normal
severity: normal
status: open
title: "import ctypes" causes segfault on read-only filesystem
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/issue11048>
_______________________________________

From report at bugs.python.org  Fri Jan 28 18:23:57 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 28 Jan 2011 17:23:57 +0000
Subject: [issue11043] On GNU/Linux (Ubuntu) distutils2.mkcfg shouldn't create
	an executable setup.cfg
In-Reply-To: <1296215457.79.0.848370821924.issue11043@psf.upfronthosting.co.za>
Message-ID: <1296235437.68.0.533361635073.issue11043@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Hello Julien, thanks for the bug reporting, that?s helpful.

A few tips for better bug reports:
1) Setting the ?Distutils2? component will automatically add Tarek and I to nosy, you don?t have to do it manually (especially when you find an obsolete user name for Tarek).
2) The ?Versions? field is used to manage CPython releases; given that d2 is not in the CPython tree, the right value here is always 3rd party?.  Including the OS and Python version in your report text is useful, though.  We want to support 2.4-2.7 in d2 (and 3.x Really Soon Now?).
3) Always try to reproduce the bug with the latest version from bitbucket.org/tarek/distutils2

I borrowed the time machine and fixed that bug in 82c9a472e8b8, six days ago.  :)

----------
assignee: tarek -> eric.araujo
nosy:  -tarek-ziade
resolution:  -> out of date
stage:  -> committed/rejected
status: open -> closed
versions: +3rd party -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11043>
_______________________________________

From report at bugs.python.org  Fri Jan 28 18:27:37 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 28 Jan 2011 17:27:37 +0000
Subject: [issue7175] Define a standard location and API for configuration files
In-Reply-To: <1256037677.34.0.670034749287.issue7175@psf.upfronthosting.co.za>
Message-ID: <1296235657.12.0.215857474474.issue7175@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

The issue proved more complicated than expected, due to antics of Mac OS X and Windows Vista, so I set it aside for later.  I intend to summarize all useful comments from the python-dev thread and bug reports comments and try to reach agreement for 3.3.

----------
assignee:  -> eric.araujo
versions: +Python 3.3 -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7175>
_______________________________________

From report at bugs.python.org  Fri Jan 28 18:58:45 2011
From: report at bugs.python.org (Giampaolo Rodola')
Date: Fri, 28 Jan 2011 17:58:45 +0000
Subject: [issue3561] Windows installer should add Python and Scripts
	directories to the PATH environment variable
In-Reply-To: <1218820643.64.0.47446345444.issue3561@psf.upfronthosting.co.za>
Message-ID: <1296237525.24.0.49965060956.issue3561@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/issue3561>
_______________________________________

From report at bugs.python.org  Fri Jan 28 19:17:22 2011
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 28 Jan 2011 18:17:22 +0000
Subject: [issue11035] Segmentation fault
In-Reply-To: <1296207410.47.0.601145412555.issue11035@psf.upfronthosting.co.za>
Message-ID: <1296238642.26.0.180072712343.issue11035@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Closing as invalid since gevent seems to be the culprit of the segfault.

----------
nosy: +brett.cannon
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11035>
_______________________________________

From report at bugs.python.org  Fri Jan 28 19:22:21 2011
From: report at bugs.python.org (Daniel Urban)
Date: Fri, 28 Jan 2011 18:22:21 +0000
Subject: [issue10977] Concrete object C API needs abstract path for subclasses
	of builtin types
In-Reply-To: <1295653779.62.0.836506069174.issue10977@psf.upfronthosting.co.za>
Message-ID: <1296238941.07.0.431132782366.issue10977@psf.upfronthosting.co.za>


Changes by Daniel Urban <urban.dani+py at gmail.com>:


----------
nosy: +durban

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10977>
_______________________________________

From report at bugs.python.org  Fri Jan 28 19:42:10 2011
From: report at bugs.python.org (Joe Peterson)
Date: Fri, 28 Jan 2011 18:42:10 +0000
Subject: [issue10947] imaplib: Internaldate2tuple and ParseFlags require (and
	latter returns) bytes arrays; should allow/return str
In-Reply-To: <1295451332.43.0.977417439806.issue10947@psf.upfronthosting.co.za>
Message-ID: <1296240130.57.0.202403233698.issue10947@psf.upfronthosting.co.za>


Changes by Joe Peterson <joe at skyrush.com>:


----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10947>
_______________________________________

From report at bugs.python.org  Fri Jan 28 20:05:32 2011
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 28 Jan 2011 19:05:32 +0000
Subject: [issue11049] add tests for test.support
In-Reply-To: <1296241531.97.0.670133219758.issue11049@psf.upfronthosting.co.za>
Message-ID: <1296241531.97.0.670133219758.issue11049@psf.upfronthosting.co.za>


New submission from Brett Cannon <brett at python.org>:

It seems a little negligent that test.support has no tests. The test.test_support name is available in py3k and backporting issues to 2.7 shouldn't be a problem (rare chance something does happen it can be handling manually). There doesn't seem to be any reason not to make sure that proper unit testing is being done short of just laziness on our parts.

And if this does occur it should probably be listed as an essential test in regrtest.

----------
components: Tests
keywords: easy
messages: 127322
nosy: brett.cannon, r.david.murray
priority: normal
severity: normal
stage: needs patch
status: open
title: add tests for test.support
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11049>
_______________________________________

From report at bugs.python.org  Fri Jan 28 20:06:11 2011
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 28 Jan 2011 19:06:11 +0000
Subject: [issue11049] add tests for test.support
In-Reply-To: <1296241531.97.0.670133219758.issue11049@psf.upfronthosting.co.za>
Message-ID: <1296241571.63.0.322608570449.issue11049@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

I should note that I am not suggesting that test.support suddenly be considered a module with a stable API that the public can use. Simply that we take the proper measures to make sure the code in there does what is expected.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11049>
_______________________________________

From report at bugs.python.org  Fri Jan 28 20:12:46 2011
From: report at bugs.python.org (R. David Murray)
Date: Fri, 28 Jan 2011 19:12:46 +0000
Subject: [issue9124] Mailbox module should use binary I/O, not text I/O
In-Reply-To: <1277900903.38.0.556015912714.issue9124@psf.upfronthosting.co.za>
Message-ID: <1296241966.13.0.789673332657.issue9124@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

What is the data type returned by your get_msg?  I bet it is string, and email can't handle messages in string format that have non-ASCII characters (I'm adding an explicit error message for this).  You either need to use a Message object, or, more likely in your case, change the return type of get_msg to be bytes.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9124>
_______________________________________

From report at bugs.python.org  Fri Jan 28 20:20:06 2011
From: report at bugs.python.org (Jason R. Coombs)
Date: Fri, 28 Jan 2011 19:20:06 +0000
Subject: [issue6081] str.format_map()
In-Reply-To: <1242948196.62.0.545811632191.issue6081@psf.upfronthosting.co.za>
Message-ID: <1296242406.21.0.437632137333.issue6081@psf.upfronthosting.co.za>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

Good work Eric.

When I first heard of new string formatting, I was a little wary. The syntax to supply a dictionary of keyword replacements seemed awkward. It took me a while before I realized why it really bothered me. There's string formatting you can do with the old format operator (%) that you can't do with str.format.

Here's an example.

    import random
    class MyDynamicObject:
        def __getitem__(self, name):
            return name + ' ' + str(random.randint(1,10))

    print("%(foo)s" % MyDynamicObject()) # works!
    print("{foo}".format(**MyDynamicObject())) # can't do that because
MyDynamicObject can't enumerate every possible kwparam

As you can see, the % operator naturally accepts any object that responds to __getitem__ but .format requires that all keyword params be enumerated in advance. This limitation seems to me to be a serious problem to favoring .format over %.

I frequently use % to format the properties of an object... and while
it's true one can use myob.__dict__ or vars(myob) to get a dictionary of
some of the values, that doesn't work for properties and other dynamic
behavior.

format_map addresses this shortcoming nicely. Thanks.

----------
nosy: +jaraco

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6081>
_______________________________________

From report at bugs.python.org  Fri Jan 28 20:30:19 2011
From: report at bugs.python.org (Ross Lagerwall)
Date: Fri, 28 Jan 2011 19:30:19 +0000
Subject: [issue10882] Add os.sendfile()
In-Reply-To: <1294691268.76.0.727179568007.issue10882@psf.upfronthosting.co.za>
Message-ID: <1296243019.29.0.705659875038.issue10882@psf.upfronthosting.co.za>


Ross Lagerwall <rosslagerwall at gmail.com> added the comment:

Attached is an updated patch that uses keyword arguments.

Using an offset with Linux was always supported although I have cleaned up the documentation a bit to make that clearer.
E.g. the following script sends part of a file over a socket (shows using an offset and None).
This requires listening with a socket on the same computer on port 8001 (e.g. nc -l 8001).

import os
import socket

with open("/tmp/test", "wb") as fp:
    fp.write(b"testdata\n" * 1000000)

cli = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
cli.connect(('localhost', 8010))
c = cli.fileno()
f = os.open("/tmp/test", os.O_RDONLY)

os.sendfile(c, f, 1, 7) # "estdata"
cli.send(b"\n\n")
os.sendfile(c, f, None, 4) # "test"
cli.send(b"\n\n")
os.sendfile(c, f, None, 4) # "data"
cli.send(b"\n\n")

----------
Added file: http://bugs.python.org/file20578/sendfile_v4.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10882>
_______________________________________

From report at bugs.python.org  Fri Jan 28 20:38:03 2011
From: report at bugs.python.org (R. David Murray)
Date: Fri, 28 Jan 2011 19:38:03 +0000
Subject: [issue9124] Mailbox module should use binary I/O, not text I/O
In-Reply-To: <1277900903.38.0.556015912714.issue9124@psf.upfronthosting.co.za>
Message-ID: <1296243483.15.0.574330976502.issue9124@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I'm updating the patch to contain a couple tests using non-ASCII.  More are needed.

Before this patch, one could process a file containing non-ASCII characters as text, and if your default encoding happened to be able to decode it, things would appear to more or less work.  In real life doing this is most likely to produce mojibake.  So the patch now rejects string input that contains non-ASCII characters with a helpful message about using bytes or Message input.  Email doesn't handle messages in string format that contain non-ASCII characters, either (which, I think, was the source of the error Steffen encountered).  This means that the string backward-compatibility is reduced to ascii-only messages.  But if mailbox in py3 is being used successfully by anybody, it is most likely to be someone processing ascii only messages for some reason.

----------
Added file: http://bugs.python.org/file20579/mailbox3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9124>
_______________________________________

From report at bugs.python.org  Fri Jan 28 20:38:12 2011
From: report at bugs.python.org (R. David Murray)
Date: Fri, 28 Jan 2011 19:38:12 +0000
Subject: [issue9124] Mailbox module should use binary I/O, not text I/O
In-Reply-To: <1277900903.38.0.556015912714.issue9124@psf.upfronthosting.co.za>
Message-ID: <1296243492.95.0.672299672335.issue9124@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


Removed file: http://bugs.python.org/file20565/mailbox3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9124>
_______________________________________

From report at bugs.python.org  Fri Jan 28 20:43:04 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 28 Jan 2011 19:43:04 +0000
Subject: [issue11024] imaplib: Time2Internaldate() returns localized strings
In-Reply-To: <1296135301.42.0.767818406183.issue11024@psf.upfronthosting.co.za>
Message-ID: <1296243784.14.0.0977850404962.issue11024@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Two nitpicks:

1. To avoid repetition, I would now define Mon2num as 

Mon2num = dict(zip(_month_names, range(1, 13)))

2. Please keep lines under 79 characters long.

This does not seem important enough to push to RC2, but if you think otherwise please get RM approval.

----------
nosy: +belopolsky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11024>
_______________________________________

From report at bugs.python.org  Fri Jan 28 20:44:04 2011
From: report at bugs.python.org (Michael Foord)
Date: Fri, 28 Jan 2011 19:44:04 +0000
Subject: [issue10573] Consistency in unittest assert methods: order of actual, 
	expected
In-Reply-To: <1290992159.72.0.107137027413.issue10573@psf.upfronthosting.co.za>
Message-ID: <1296243844.21.0.938472894815.issue10573@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

Patch to docs and minor change to assertCountEqual to not use actual / expected internally.

----------
Added file: http://bugs.python.org/file20580/expected-actual.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10573>
_______________________________________

From report at bugs.python.org  Fri Jan 28 20:44:39 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 28 Jan 2011 19:44:39 +0000
Subject: [issue11024] imaplib: Time2Internaldate() returns localized strings
In-Reply-To: <1296135301.42.0.767818406183.issue11024@psf.upfronthosting.co.za>
Message-ID: <1296243879.2.0.330187876854.issue11024@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Also, isn't day supposed to be space- rather than 0- padded?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11024>
_______________________________________

From report at bugs.python.org  Fri Jan 28 20:50:30 2011
From: report at bugs.python.org (R. David Murray)
Date: Fri, 28 Jan 2011 19:50:30 +0000
Subject: [issue10573] Consistency in unittest assert methods: order of actual, 
	expected
In-Reply-To: <1290992159.72.0.107137027413.issue10573@psf.upfronthosting.co.za>
Message-ID: <1296244230.05.0.198858137665.issue10573@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Code patch looks good to me.  Unittest tests pass.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10573>
_______________________________________

From report at bugs.python.org  Fri Jan 28 20:52:41 2011
From: report at bugs.python.org (Michael Foord)
Date: Fri, 28 Jan 2011 19:52:41 +0000
Subject: [issue10573] Consistency in unittest assert methods: order of actual, 
	expected
In-Reply-To: <1290992159.72.0.107137027413.issue10573@psf.upfronthosting.co.za>
Message-ID: <1296244361.32.0.145278097622.issue10573@psf.upfronthosting.co.za>


Changes by Michael Foord <michael at voidspace.org.uk>:


----------
resolution:  -> fixed
stage: commit review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10573>
_______________________________________

From report at bugs.python.org  Fri Jan 28 20:58:35 2011
From: report at bugs.python.org (Daniel Urban)
Date: Fri, 28 Jan 2011 19:58:35 +0000
Subject: [issue11048] "import ctypes" causes segfault on read-only filesystem
In-Reply-To: <1296234309.62.0.290829997988.issue11048@psf.upfronthosting.co.za>
Message-ID: <1296244715.53.0.735373103447.issue11048@psf.upfronthosting.co.za>


Daniel Urban <urban.dani+py at gmail.com> added the comment:

I cannot reproduce this with the current py3k branch (Ubuntu 10.04 32 bit).

----------
nosy: +durban
type:  -> crash

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11048>
_______________________________________

From report at bugs.python.org  Fri Jan 28 21:04:32 2011
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 28 Jan 2011 20:04:32 +0000
Subject: [issue10990] tests mutating sys.gettrace() w/o re-instating previous
	state
In-Reply-To: <1295824876.68.0.687534068337.issue10990@psf.upfronthosting.co.za>
Message-ID: <1296245072.52.0.140360269727.issue10990@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Attached is a fixed copy of Kristian's patch; error in test_trace where self.settrace was being called.

----------
Added file: http://bugs.python.org/file20581/issue10990.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10990>
_______________________________________

From report at bugs.python.org  Fri Jan 28 21:04:38 2011
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 28 Jan 2011 20:04:38 +0000
Subject: [issue10990] tests mutating sys.gettrace() w/o re-instating previous
	state
In-Reply-To: <1295824876.68.0.687534068337.issue10990@psf.upfronthosting.co.za>
Message-ID: <1296245078.32.0.192989377752.issue10990@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


Removed file: http://bugs.python.org/file20561/issue10990.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10990>
_______________________________________

From report at bugs.python.org  Fri Jan 28 21:04:44 2011
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 28 Jan 2011 20:04:44 +0000
Subject: [issue10990] tests mutating sys.gettrace() w/o re-instating previous
	state
In-Reply-To: <1295824876.68.0.687534068337.issue10990@psf.upfronthosting.co.za>
Message-ID: <1296245084.79.0.519006028569.issue10990@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


Removed file: http://bugs.python.org/file20525/trace_fxn_protected.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10990>
_______________________________________

From report at bugs.python.org  Fri Jan 28 21:06:35 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Fri, 28 Jan 2011 20:06:35 +0000
Subject: [issue11046] darwin/MacOS X setup.py hack
In-Reply-To: <1296224784.81.0.0525228154056.issue11046@psf.upfronthosting.co.za>
Message-ID: <1296245195.27.0.364164774092.issue11046@psf.upfronthosting.co.za>


Steffen Daode Nurpmeso <sdaoden at googlemail.com> added the comment:

Thank you, RO, exactly that very line would be great as an add-on for the mentioned file - and (better: but - i'm lazy) it would be even better if that hint would appear somewhere in 'configure --help'!  That would make the apple glow.
(In the meanwhile i've compiled Py3K without --pydebug - possibly the '10.6' -> '10.5' hack did it, or i've forgotten a 'make distclean' in the hurry this afternoon; i will definitely remember 'MACOSX_DEPLOYMENT_TARGET=10.5', though!)

After having the time to look back and think a second time about the patch which helped me out this morning, i've rewritten it in a more generic form.
All lines which i would *definitely* change before a merge have been marked with 'STEFFEN HACK', but i think 'does_library_chainload_library()' may be worth throwing an eye on it.
It's a bit of a hack, but it also encapsulates some difficulties of using different tools on different UNIX platforms.

----------
Added file: http://bugs.python.org/file20582/DIFF

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11046>
_______________________________________

From report at bugs.python.org  Fri Jan 28 21:07:49 2011
From: report at bugs.python.org (Giampaolo Rodola')
Date: Fri, 28 Jan 2011 20:07:49 +0000
Subject: [issue10882] Add os.sendfile()
In-Reply-To: <1294691268.76.0.727179568007.issue10882@psf.upfronthosting.co.za>
Message-ID: <1296245269.0.0.773981280097.issue10882@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

> Copy *count* bytes from file descriptor *in* to file descriptor 
> *out*, starting at *offset* and continuing for *count* bytes.

The latter part is incorrect as it is not guaranteed that all bytes specified in "count" argument are going to be sent and it also sounds like the function is blocking.
I'd change that in just "Copy *count* bytes from file descriptor *in* to file descriptor *out*."

Also, I'd be for using the BSD notation and rename the "count" argument to "nbytes", which is more clear.

Docstring should be changed to reflect the keyword arguments:
- sendfile(out, in, offset, count, headers, trailers, flags)\n\
+ sendfile(out, in, offset, count[, headers[, trailers], flags]]])\n\

Finally, tests for header and trailer arguments should be written.

The rest of the patch looks ok to me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10882>
_______________________________________

From report at bugs.python.org  Fri Jan 28 21:17:59 2011
From: report at bugs.python.org (Barry A. Warsaw)
Date: Fri, 28 Jan 2011 20:17:59 +0000
Subject: [issue7175] Define a standard location and API for configuration files
In-Reply-To: <1256037677.34.0.670034749287.issue7175@psf.upfronthosting.co.za>
Message-ID: <1296245879.98.0.801970828597.issue7175@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

I'm mildly uncomfortable advocating many different new dot directories in $HOME (e.g. .python2.7 .python3.1 .python3.2).   Let's say -0.  Also, because of backward compatibility, I think most configuration files will end up being similar enough between Python versions.  Without having thought through all the details, it seems that ~/.python would work in general for configuration files that are compatible across Pythons, with X.Y subdirectories for version specific config files.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7175>
_______________________________________

From report at bugs.python.org  Fri Jan 28 21:28:53 2011
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Fri, 28 Jan 2011 20:28:53 +0000
Subject: [issue1674555] sys.path in tests contains system directories
Message-ID: <1296246533.22.0.0149389018415.issue1674555@psf.upfronthosting.co.za>


Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com> added the comment:

I'm attaching the patch, which works for me.
- New, private variable (_PYTHONNOSITEPACKAGES) disables addition of site-packages directories to sys.path.
- regrtest.py always runs test_site.py in a subprocess.

----------
Added file: http://bugs.python.org/file20583/python-3.2-issue1674555.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1674555>
_______________________________________

From report at bugs.python.org  Fri Jan 28 21:29:21 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Fri, 28 Jan 2011 20:29:21 +0000
Subject: [issue9124] Mailbox module should use binary I/O, not text I/O
In-Reply-To: <1277900903.38.0.556015912714.issue9124@psf.upfronthosting.co.za>
Message-ID: <1296246561.01.0.261385876547.issue9124@psf.upfronthosting.co.za>


Steffen Daode Nurpmeso <sdaoden at googlemail.com> added the comment:

> What is the data type returned by your get_msg?  I bet it is string,
> and email can't handle messages in string format that have non-ASCII
> characters

(Now i see that the local names 'box', 'mbox' and 'mailbox' have become somewhat messed up, which may have been misleading.)
The answer is (somewhat) definitely no:

    class Ticket:
        @staticmethod
        def process_msg(msg):
                ticket = Ticket(msg)
        ...
        def __init__(self, msg):
                global _Ticket_Count
                _Ticket_Count += 1
                self._id = _Ticket_Count
                self._msg = msg
                log("    @ Creating ticket number ", self._id, ":")

... instantiated by either:
                        msg = mbox.get_message(nr) # It's a Mailbox
                        Ticket.process_msg(msg)

... or:
def openbsd_splitter(msg):
        if msg.is_multipart():
                log("      @ Multipart message: not splitting")
                return [msg]
        i = msg["Subject"]
        if i is None or "digest," not in i:
                log("      @ \"digest,\" not in Subject: not splitting")
                return [msg]
        # Real splitter: nl, SPLITTER, nl, Date: header..
        SPLITTER = "------------------------------"
        def __create_msg(charset, lines):
                try:
                        fp = email.feedparser.FeedParser()
                        headerok, lastnl = False, False
                        while len(lines) > 0:
                                l = lines.pop(0)
                                if SPLITTER in l and lastnl:
                                        break
                                lastnl = not len(l.strip())
                                if not headerok:
                                        if lastnl:
                                                headerok = True
                                        else:
                                                l = split_header_line_helper(.....)
                                fp.feed(l + "\n")
                        return fp.close()
                except Exception as e:
                        log("      @ Error - not splitting: ", str(e))
                        return None
        result = list()
        lines = msg.get_payload().splitlines()
        while len(lines):
                l = lines.pop(0)
                if SPLITTER in l:
                        break
        while len(lines):
                l = lines[0]
                if l.startswith("Date: "):
                        nm = __create_msg(charset, lines)
                        if not nm:
                                return [msg]
                        result.append(nm)
                else:
                        lines.pop(0)
        return result
... which then ends up as the shown
                for msg in splitter(msg):
                        ticket = Ticket(msg)
                        to_box.add_ticket(ticket) # This is 'class Box'

... and it's the very Box.add_ticket() which has been shown in msg127313.  That's all - note however that the email.message.Message headers may either be strings or 'Header' objects - this is work in transition (i somehow want to deal with these malformed mails and at least encapsulate all str() headers to 'Header' headers with the fallback 'quopri' encoding ISO-8859-1 - like this the mail will at least be clean on the disk ...)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9124>
_______________________________________

From report at bugs.python.org  Fri Jan 28 21:29:44 2011
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Fri, 28 Jan 2011 20:29:44 +0000
Subject: [issue1674555] sys.path in tests contains system directories
Message-ID: <1296246584.14.0.928721883041.issue1674555@psf.upfronthosting.co.za>


Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:


Added file: http://bugs.python.org/file20584/python-2.7-issue1674555.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1674555>
_______________________________________

From report at bugs.python.org  Fri Jan 28 21:31:02 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 28 Jan 2011 20:31:02 +0000
Subject: [issue11024] imaplib: Time2Internaldate() returns localized strings
In-Reply-To: <1296243879.2.0.330187876854.issue11024@psf.upfronthosting.co.za>
Message-ID: <AANLkTikA8Hg4eZJT-do=dr1dto0+cOMM_aCqXH6JmkEB@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Fri, Jan 28, 2011 at 2:44 PM, Alexander Belopolsky
<report at bugs.python.org> wrote:
..
> Also, isn't day supposed to be space- rather than 0- padded?

To the best of my understanding, rfc 2060 requires space-padded day
(strftime code %e):

"""
date_day_fixed  ::= (SPACE digit) / 2digit
                    ;; Fixed-format version of date_day
...
date_time       ::= <"> date_day_fixed "-" date_month "-" date_year
                    SPACE time SPACE zone <">
...
msg_att         ::= ...
                    "INTERNALDATE" SPACE date_time /
...
"""

See http://tools.ietf.org/html/rfc2060.html

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11024>
_______________________________________

From report at bugs.python.org  Fri Jan 28 21:31:41 2011
From: report at bugs.python.org (Glyph Lefkowitz)
Date: Fri, 28 Jan 2011 20:31:41 +0000
Subject: [issue7175] Define a standard location and API for configuration files
In-Reply-To: <1256037677.34.0.670034749287.issue7175@psf.upfronthosting.co.za>
Message-ID: <1296246701.29.0.457970913838.issue7175@psf.upfronthosting.co.za>


Glyph Lefkowitz <glyph at twistedmatrix.com> added the comment:

I would still prefer ~/.local/something-parallel-to-where-it's-usually-installed for its ease of documentation.  But ~/.python/X.Y isn't terribly objectionable.

A minor point about Michael Foord's fallback proposal: I don't know why everyone is so keen to stuff things into ~/Library on the mac, but dotfiles don't go in ~/Library/Preferences.  While that directory isn't exclusively populated with plist files, it's pretty close.  If you want to try for consistency with platform convention, 'org.python.distutils.cfg' would be a better name for it, but I've never hand-edited a text file in that directory either and I get the impression one isn't meant to.

But, since framework builds of Python already has ~/Library/Python/X.Y directories that they look in for other things, that location should probably be recycled if one wishes to have a fallback.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7175>
_______________________________________

From report at bugs.python.org  Fri Jan 28 21:34:33 2011
From: report at bugs.python.org (Joe Peterson)
Date: Fri, 28 Jan 2011 20:34:33 +0000
Subject: [issue11024] imaplib: Time2Internaldate() returns localized strings
In-Reply-To: <1296135301.42.0.767818406183.issue11024@psf.upfronthosting.co.za>
Message-ID: <1296246873.61.0.762911151351.issue11024@psf.upfronthosting.co.za>


Joe Peterson <joe at skyrush.com> added the comment:

> Also, isn't day supposed to be space- rather than 0- padded?

This is not clear to me.  RFC2822 (referenced from RFC3501 for internal date) discusses date formats, but as used in the header.  In this case, day is specified as "([FWS] 1*2DIGIT)", which implies optional space and 1 or 2 digit day.  I am not sure this disallows leading-zero format.  But this date spec also says dates should be space-separated (like "12 Jan 2011"), and clearly INTERNALDATE needs "-" (like "12-Jan-2011").  Therefore, I cannot see this date format as being authoritative fro INTERNALDATE.

Also, RFC3501, in chage #71, is extra confusing in that it puts the 3-letter month in all-caps.  Python's Internaldate2tuple(), e.g., cannot handle this currently (nor can it handle a single-digit day with no space or 0, but its regex does handle a leading zero, which led me to think 0 is OK).

Also, it seems that gmail's imap server and Dovecot imap server return leading zero, not leading space, when you fetch INTERNALDATE.  So I concluded from all this that 0 might actually be preferred.  If this is true, leading zero is better also in that it is less error-prone (e.g., strip can remove the leading space, which will cause problems).

I'll keep looking for definitive info, but if you know of some I missed, please let me know.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11024>
_______________________________________

From report at bugs.python.org  Fri Jan 28 21:47:33 2011
From: report at bugs.python.org (Joe Peterson)
Date: Fri, 28 Jan 2011 20:47:33 +0000
Subject: [issue11024] imaplib: Time2Internaldate() returns localized strings
In-Reply-To: <1296135301.42.0.767818406183.issue11024@psf.upfronthosting.co.za>
Message-ID: <1296247653.3.0.531459403164.issue11024@psf.upfronthosting.co.za>


Joe Peterson <joe at skyrush.com> added the comment:

Our messages crossed...  :)

Hm, I see that in RFC 3501, as well (which obsoletes 2060).

But...  I wonder: does "(SP DIGIT) / 2DIGIT" mean that " 1" and "01" are both OK?  It seems ambiguous to me.

I still don't see why major IMAP servers are returning leading zeros if now allowed...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11024>
_______________________________________

From report at bugs.python.org  Fri Jan 28 21:58:23 2011
From: report at bugs.python.org (R. David Murray)
Date: Fri, 28 Jan 2011 20:58:23 +0000
Subject: [issue9124] Mailbox module should use binary I/O, not text I/O
In-Reply-To: <1277900903.38.0.556015912714.issue9124@psf.upfronthosting.co.za>
Message-ID: <1296248303.19.0.710873101882.issue9124@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Well, that's a bunch of code, and I'm afraid I don't know what your answer to my question was.  What error do you get now if you use the new version of mailbox3.patch?

If you feed the new mailbox/email bytes, it will preserve the bytes as is, as long as you don't try to convert the invalid headers to strings.  If you convert them to string (by accessing them through the Message object), it will encode them as 'unknown-8bit' using quopri or base64 as appropriate (ie: depending on how many non-ascii chars there are).  If you want instead to guess that they are latin-1, you can call decode_header on the stringified version to get back the original bytes, and then substitute your preferred guessed charset for the 'unknown-8bit' charset and go from there to unicode.  (For Python3.3 I plan to provide tools to make this kind of processing much simpler.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9124>
_______________________________________

From report at bugs.python.org  Fri Jan 28 22:05:22 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 28 Jan 2011 21:05:22 +0000
Subject: [issue11029] Crash, 2.7.1, Tkinter and threads and line drawing
In-Reply-To: <1296147664.2.0.443864502869.issue11029@psf.upfronthosting.co.za>
Message-ID: <1296248722.02.0.97829825778.issue11029@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

There are other gui libraries with Python interfaces that you can look at. I agree that something in doc about how to feed data from multiple threads would be nice.

----------
nosy: +terry.reedy
type: crash -> behavior
versions: +Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11029>
_______________________________________

From report at bugs.python.org  Fri Jan 28 22:10:39 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Fri, 28 Jan 2011 21:10:39 +0000
Subject: [issue11037] How distutils2 handle namespaces
In-Reply-To: <1296210890.87.0.618097241127.issue11037@psf.upfronthosting.co.za>
Message-ID: <1296249039.38.0.0171009222235.issue11037@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

See PEP 382: http://www.python.org/dev/peps/pep-0382/

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11037>
_______________________________________

From report at bugs.python.org  Fri Jan 28 22:11:04 2011
From: report at bugs.python.org (R. David Murray)
Date: Fri, 28 Jan 2011 21:11:04 +0000
Subject: [issue9124] Mailbox module should use binary I/O, not text I/O
In-Reply-To: <1277900903.38.0.556015912714.issue9124@psf.upfronthosting.co.za>
Message-ID: <1296249064.07.0.108680261498.issue9124@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Added two more tests of non-ASCII.  I think the tests now cover the necessary cases.

I still want to do a full code review tomorrow, but I think the patch is in final form if anyone else is available to do a review as well.

Georg, are you OK with this going in?  I think it is an important part of the "email is fixed" story and thus worth bending the rules for.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9124>
_______________________________________

From report at bugs.python.org  Fri Jan 28 22:22:15 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Fri, 28 Jan 2011 21:22:15 +0000
Subject: [issue6203] 3.x locale does not default to C,
	contrary to the documentation and to 2.x behavior
In-Reply-To: <4D42A308.2000406@egenix.com>
Message-ID: <4D433385.3020704@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

>> That would be highly non-portable, and repeat the mistakes of
>> getdefaultlocale.
> 
> You say that often, but I don't really know why. It's certainly portable
> between various Unix platforms, perhaps not Windows, but then i18n
> on Windows is a different story altogether.

No, it's absolutely not portable across Unix platforms. Looking at
LANG or LC_ALL does *not* allow you to infer the region name, or
the locale's character set. For example, using glibc, in some
installations, /etc/locale.alias is considered to map a value of LANG
to the final locale name. As an option, glibc also considers a
LOCALE_ALIAS_PATH that may point to a (colon-separated) path of
files to search for locale aliases.

Other systems may use other databases to map a locale name to locale
properties.

Unless you know exactly what version of C library is running on
a system, parsing environment variables yourself is doomed to fail.

----------
title: 3.x locale does not default to C, contrary to the documentation and to 2.x behavior -> 3.x locale does not default to C,	contrary to the documentation and to 2.x behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6203>
_______________________________________

From report at bugs.python.org  Fri Jan 28 22:23:38 2011
From: report at bugs.python.org (R. David Murray)
Date: Fri, 28 Jan 2011 21:23:38 +0000
Subject: [issue9124] Mailbox module should use binary I/O, not text I/O
In-Reply-To: <1277900903.38.0.556015912714.issue9124@psf.upfronthosting.co.za>
Message-ID: <1296249818.5.0.737401759478.issue9124@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


Added file: http://bugs.python.org/file20585/mailbox3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9124>
_______________________________________

From report at bugs.python.org  Fri Jan 28 22:23:50 2011
From: report at bugs.python.org (R. David Murray)
Date: Fri, 28 Jan 2011 21:23:50 +0000
Subject: [issue9124] Mailbox module should use binary I/O, not text I/O
In-Reply-To: <1277900903.38.0.556015912714.issue9124@psf.upfronthosting.co.za>
Message-ID: <1296249830.8.0.111902271176.issue9124@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


Removed file: http://bugs.python.org/file20579/mailbox3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9124>
_______________________________________

From report at bugs.python.org  Fri Jan 28 22:27:02 2011
From: report at bugs.python.org (Julien Miotte)
Date: Fri, 28 Jan 2011 21:27:02 +0000
Subject: [issue11043] On GNU/Linux (Ubuntu) distutils2.mkcfg shouldn't create
	an executable setup.cfg
In-Reply-To: <1296215457.79.0.848370821924.issue11043@psf.upfronthosting.co.za>
Message-ID: <1296250022.92.0.0283352025942.issue11043@psf.upfronthosting.co.za>


Julien Miotte <miotte.julien at gmail.com> added the comment:

Hey Eric,

Sorry for that, I should know better. I'll have a look at the other submitted issues and I'll check they are still present in the latest version.

Regards.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11043>
_______________________________________

From report at bugs.python.org  Fri Jan 28 22:33:45 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Fri, 28 Jan 2011 21:33:45 +0000
Subject: [issue9124] Mailbox module should use binary I/O, not text I/O
In-Reply-To: <1277900903.38.0.556015912714.issue9124@psf.upfronthosting.co.za>
Message-ID: <1296250425.04.0.0826832863427.issue9124@psf.upfronthosting.co.za>


Steffen Daode Nurpmeso <sdaoden at googlemail.com> added the comment:

I missed your mailbox3.patch, but now i've merged it in.
One error changed, it now happens when a re.search is applied to a header value and thus seems to match what you say.  I'm not able to understand this error this evening, but i will review it once again tomorrow and will notify this issue if it seems to me it's something different than what you say.
The other error almost remains the same from my point of view, again, i'm out today, but here i'll add the traceback again.

... as before ...
  File "s-postman.py", line 685, in add_ticket
    mbox.add(ticket.get_msg())
  File "/Users/steffen/usr/lib/python3.2/mailbox.py", line 269, in add
    self._dump_message(message, tmp_file)
  File "/Users/steffen/usr/lib/python3.2/mailbox.py", line 215, in _dump_message
    gen.flatten(message)
  File "/Users/steffen/usr/lib/python3.2/email/generator.py", line 88, in flatten
    self._write(msg)
  File "/Users/steffen/usr/lib/python3.2/email/generator.py", line 141, in _write
    self._write_headers(msg)
  File "/Users/steffen/usr/lib/python3.2/email/generator.py", line 372, in _write_headers
    header_name=h)
  File "/Users/steffen/usr/lib/python3.2/email/header.py", line 197, in __init__
    self.append(s, charset, errors)
  File "/Users/steffen/usr/lib/python3.2/email/header.py", line 275, in append
    s.encode(output_charset, errors)
UnicodeEncodeError: 'ascii' codec can't encode character '\ufffd' in position 8: ordinal not in range(128)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9124>
_______________________________________

From report at bugs.python.org  Fri Jan 28 22:36:54 2011
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Fri, 28 Jan 2011 21:36:54 +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: <1296250614.95.0.24427849018.issue6203@psf.upfronthosting.co.za>


Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com> added the comment:

Martin v. L?wis:
It seems that your web browser replaces ", " with ",\t" in the title (where "\t" is a tab character) each time you add a comment.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6203>
_______________________________________

From report at bugs.python.org  Fri Jan 28 22:38:46 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Fri, 28 Jan 2011 21:38:46 +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: <1296250726.72.0.891268352091.issue6203@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

More likely, it's my email reader. Sorry about that.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6203>
_______________________________________

From report at bugs.python.org  Fri Jan 28 22:38:49 2011
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 28 Jan 2011 21:38:49 +0000
Subject: [issue10992] tests failing when run under coverage
In-Reply-To: <1295836026.73.0.339636680883.issue10992@psf.upfronthosting.co.za>
Message-ID: <1296250729.38.0.339669313737.issue10992@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

The attached patch has all tests passing when run under coverage.py. Most places are flat-out skipped since there is no good way around the tests short of coding up a second set of test values. Plus editing doctests to have optional values is way too painful, so in those cases I just skip the whole doctest.

----------
Added file: http://bugs.python.org/file20586/issue10992.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10992>
_______________________________________

From report at bugs.python.org  Fri Jan 28 22:49:47 2011
From: report at bugs.python.org (Julien Miotte)
Date: Fri, 28 Jan 2011 21:49:47 +0000
Subject: [issue11044] The description-file isn't handled by distutils2
In-Reply-To: <1296216054.85.0.726988451009.issue11044@psf.upfronthosting.co.za>
Message-ID: <1296251387.58.0.329767724975.issue11044@psf.upfronthosting.co.za>


Julien Miotte <miotte.julien at gmail.com> added the comment:

My bad, works fine with r903:c3cf81fc64db.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11044>
_______________________________________

From report at bugs.python.org  Fri Jan 28 22:50:33 2011
From: report at bugs.python.org (Julien Miotte)
Date: Fri, 28 Jan 2011 21:50:33 +0000
Subject: [issue11044] The description-file isn't handled by distutils2
In-Reply-To: <1296216054.85.0.726988451009.issue11044@psf.upfronthosting.co.za>
Message-ID: <1296251433.27.0.379711725012.issue11044@psf.upfronthosting.co.za>


Changes by Julien Miotte <miotte.julien at gmail.com>:


----------
resolution:  -> out of date

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11044>
_______________________________________

From report at bugs.python.org  Fri Jan 28 22:50:59 2011
From: report at bugs.python.org (Julien Miotte)
Date: Fri, 28 Jan 2011 21:50:59 +0000
Subject: [issue11044] The description-file isn't handled by distutils2
In-Reply-To: <1296216054.85.0.726988451009.issue11044@psf.upfronthosting.co.za>
Message-ID: <1296251459.01.0.19538019859.issue11044@psf.upfronthosting.co.za>


Changes by Julien Miotte <miotte.julien at gmail.com>:


----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11044>
_______________________________________

From report at bugs.python.org  Fri Jan 28 22:57:06 2011
From: report at bugs.python.org (R. David Murray)
Date: Fri, 28 Jan 2011 21:57:06 +0000
Subject: [issue9124] Mailbox module should use binary I/O, not text I/O
In-Reply-To: <1277900903.38.0.556015912714.issue9124@psf.upfronthosting.co.za>
Message-ID: <1296251826.79.0.424599287618.issue9124@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

If you are using the most recent mailbox3 patch (I should have renamed it, sorry...I've no done so to make it clear) you should be getting an error message that tells you to use binary or Message.  So I don't understand how you are getting this message.  I still don't know what it is you are passing to the add method.

RC2 will be cut starting Sunday morning CET, and after that we will be making no further non-critical changes.  So if you've got bugs, best we find them before the end of the day tomorrow ;)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9124>
_______________________________________

From report at bugs.python.org  Fri Jan 28 23:03:23 2011
From: report at bugs.python.org (Alex)
Date: Fri, 28 Jan 2011 22:03:23 +0000
Subject: [issue9233] json.load failure when C optimizations aren't built
In-Reply-To: <1278949665.57.0.214129757073.issue9233@psf.upfronthosting.co.za>
Message-ID: <1296252203.47.0.499926019991.issue9233@psf.upfronthosting.co.za>


Alex <alex.gaynor at gmail.com> added the comment:

Just a note from downstream with PyPy: we've cherry-picked the commit Bob linked into our copy of the 2.7 stdlib since we don't have an _json (yet).

----------
nosy: +alex

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9233>
_______________________________________

From report at bugs.python.org  Fri Jan 28 23:12:45 2011
From: report at bugs.python.org (Joe Peterson)
Date: Fri, 28 Jan 2011 22:12:45 +0000
Subject: [issue11024] imaplib: Time2Internaldate() returns localized strings
In-Reply-To: <1296135301.42.0.767818406183.issue11024@psf.upfronthosting.co.za>
Message-ID: <1296252765.25.0.608445860846.issue11024@psf.upfronthosting.co.za>


Changes by Joe Peterson <joe at skyrush.com>:


Removed file: http://bugs.python.org/file20557/imaplib_Time2Internaldate_locale_fix.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11024>
_______________________________________

From report at bugs.python.org  Fri Jan 28 23:17:47 2011
From: report at bugs.python.org (Joe Peterson)
Date: Fri, 28 Jan 2011 22:17:47 +0000
Subject: [issue11024] imaplib: Time2Internaldate() returns localized strings
In-Reply-To: <1296135301.42.0.767818406183.issue11024@psf.upfronthosting.co.za>
Message-ID: <1296253067.57.0.36021243108.issue11024@psf.upfronthosting.co.za>


Joe Peterson <joe at skyrush.com> added the comment:

Here's a new patch.  I would still like to discuss the leading space vs. leading zero issue, but I have reverted to using a leading space in this patch - fewer changes that way.

The long line is also fixed (sorry about that - yes, long lines are ugly).  And I have used your suggested Mon2num dict creation.  Note that I do an encode() in there for compatibility with Python 3, which throws an exception if the keys are not bytes arrays (consistent with the fix in issue 10939).

----------
Added file: http://bugs.python.org/file20587/imaplib_Time2Internaldate_locale_fix.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11024>
_______________________________________

From report at bugs.python.org  Fri Jan 28 23:20:11 2011
From: report at bugs.python.org (Joe Peterson)
Date: Fri, 28 Jan 2011 22:20:11 +0000
Subject: [issue10939] imaplib: Internaldate2tuple raises KeyError parsing
	month and does not work with negative TZ offset due to
	bytes/str issues
In-Reply-To: <1295389900.99.0.76199090445.issue10939@psf.upfronthosting.co.za>
Message-ID: <1296253211.63.7.84517053332e-05.issue10939@psf.upfronthosting.co.za>


Changes by Joe Peterson <joe at skyrush.com>:


Removed file: http://bugs.python.org/file20444/imaplib_Internaldate2tuple_bytes_fixes_python32.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10939>
_______________________________________

From report at bugs.python.org  Fri Jan 28 23:21:02 2011
From: report at bugs.python.org (Joe Peterson)
Date: Fri, 28 Jan 2011 22:21:02 +0000
Subject: [issue11024] imaplib: Time2Internaldate() returns localized strings
In-Reply-To: <1296135301.42.0.767818406183.issue11024@psf.upfronthosting.co.za>
Message-ID: <1296253262.04.0.348205474074.issue11024@psf.upfronthosting.co.za>


Changes by Joe Peterson <joe at skyrush.com>:


Removed file: http://bugs.python.org/file20587/imaplib_Time2Internaldate_locale_fix.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11024>
_______________________________________

From report at bugs.python.org  Fri Jan 28 23:22:39 2011
From: report at bugs.python.org (Joe Peterson)
Date: Fri, 28 Jan 2011 22:22:39 +0000
Subject: [issue10939] imaplib: Internaldate2tuple raises KeyError parsing
	month and does not work with negative TZ offset due to
	bytes/str issues
In-Reply-To: <1295389900.99.0.76199090445.issue10939@psf.upfronthosting.co.za>
Message-ID: <1296253359.38.0.364855459043.issue10939@psf.upfronthosting.co.za>


Changes by Joe Peterson <joe at skyrush.com>:


Added file: http://bugs.python.org/file20588/imaplib_Internaldate2tuple_bytes_fixes_python32.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10939>
_______________________________________

From report at bugs.python.org  Fri Jan 28 23:27:19 2011
From: report at bugs.python.org (Joe Peterson)
Date: Fri, 28 Jan 2011 22:27:19 +0000
Subject: [issue11024] imaplib: Time2Internaldate() returns localized strings
In-Reply-To: <1296135301.42.0.767818406183.issue11024@psf.upfronthosting.co.za>
Message-ID: <1296253639.81.0.788964269929.issue11024@psf.upfronthosting.co.za>


Changes by Joe Peterson <joe at skyrush.com>:


Added file: http://bugs.python.org/file20589/imaplib_Time2Internaldate_locale_fix.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11024>
_______________________________________

From report at bugs.python.org  Fri Jan 28 23:30:02 2011
From: report at bugs.python.org (Ivan Egorov)
Date: Fri, 28 Jan 2011 22:30:02 +0000
Subject: [issue11050] email.utils.getaddresses behavior contradicts RFC2822
In-Reply-To: <1296253802.55.0.925837101087.issue11050@psf.upfronthosting.co.za>
Message-ID: <1296253802.55.0.925837101087.issue11050@psf.upfronthosting.co.za>


New submission from Ivan Egorov <egorich.3.04 at gmail.com>:

email.utils.getaddresses behaves wrong in following folding cases (outer single quote is not a part of value): 
'"A\r\n (B)" <c at d.org>'
'(A\r\n C) <d at e.org>'

The misbehavior occurs in at least 2.6, 2.7 and branches/py3k.

Both these strings are RFC 2822 compliant, but current getaddresses() implementation misbehaves on 'quoted-string' and 'comment' containing CRLF.

Following references the related RFC sections:
http://tools.ietf.org/html/rfc2822#section-3.4
http://tools.ietf.org/html/rfc2822#section-3.2.5

Attachment contains tests and patch for the case.

----------
components: Library (Lib)
files: email.utils.getaddresses.patch
keywords: patch
messages: 127357
nosy: Ivan.Egorov
priority: normal
severity: normal
status: open
title: email.utils.getaddresses behavior contradicts RFC2822
type: behavior
versions: Python 3.3
Added file: http://bugs.python.org/file20590/email.utils.getaddresses.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11050>
_______________________________________

From report at bugs.python.org  Fri Jan 28 23:40:24 2011
From: report at bugs.python.org (Julien Miotte)
Date: Fri, 28 Jan 2011 22:40:24 +0000
Subject: [issue11040] After registering a project to PyPI,
	classifiers fields aren't displayed.
In-Reply-To: <1296214289.89.0.718507704088.issue11040@psf.upfronthosting.co.za>
Message-ID: <1296254424.54.0.397314640344.issue11040@psf.upfronthosting.co.za>


Julien Miotte <miotte.julien at gmail.com> added the comment:

This can reproduced with:
 - distutils2 r903:c3cf81fc64db
 - python 2.6.6
 - Ubuntu 10.10

----------
nosy:  -eric.araujo, tarek, tarek-ziade
versions: +3rd party -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11040>
_______________________________________

From report at bugs.python.org  Fri Jan 28 23:49:33 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 28 Jan 2011 22:49:33 +0000
Subject: [issue11051] system calls per import
In-Reply-To: <1296254973.71.0.897914319387.issue11051@psf.upfronthosting.co.za>
Message-ID: <1296254973.71.0.897914319387.issue11051@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

Here are the system calls when importing a single pure Python module:

stat("/home/antoine/py3k/py3k/Lib/copyreg", 0x7fff1ed1f740) = -1 ENOENT (No such file or directory)
open("/home/antoine/py3k/py3k/Lib/copyreg.cpython-32m.so", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/home/antoine/py3k/py3k/Lib/copyregmodule.cpython-32m.so", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/home/antoine/py3k/py3k/Lib/copyreg.abi3.so", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/home/antoine/py3k/py3k/Lib/copyregmodule.abi3.so", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/home/antoine/py3k/py3k/Lib/copyreg.so", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/home/antoine/py3k/py3k/Lib/copyregmodule.so", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/home/antoine/py3k/py3k/Lib/copyreg.py", O_RDONLY) = 5
fstat(5, {st_mode=S_IFREG|0664, st_size=6633, ...}) = 0
open("/home/antoine/py3k/py3k/Lib/__pycache__/copyreg.cpython-32.pyc", O_RDONLY) = 6
fstat(6, {st_mode=S_IFREG|0664, st_size=5595, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f28e6381000
read(6, "l\f\r\n\0\24\212Hc\0\0\0\0\0\0\0\0\0\0\0\0\f\0\0\0@\0\0\0s\307\0"..., 4096) = 4096
fstat(6, {st_mode=S_IFREG|0664, st_size=5595, ...}) = 0


This is per possible directory, which means that it can be repeated for each dir on sys.path:

stat("readline", 0x7fff1ed28760)        = -1 ENOENT (No such file or directory)
open("readline.cpython-32m.so", O_RDONLY) = -1 ENOENT (No such file or directory)
open("readlinemodule.cpython-32m.so", O_RDONLY) = -1 ENOENT (No such file or directory)
open("readline.abi3.so", O_RDONLY)      = -1 ENOENT (No such file or directory)
open("readlinemodule.abi3.so", O_RDONLY) = -1 ENOENT (No such file or directory)
open("readline.so", O_RDONLY)           = -1 ENOENT (No such file or directory)
open("readlinemodule.so", O_RDONLY)     = -1 ENOENT (No such file or directory)
open("readline.py", O_RDONLY)           = -1 ENOENT (No such file or directory)
open("readline.pyc", O_RDONLY)          = -1 ENOENT (No such file or directory)
stat("/home/antoine/py3k/py3k/Lib/readline", 0x7fff1ed28760) = -1 ENOENT (No such file or directory)
open("/home/antoine/py3k/py3k/Lib/readline.cpython-32m.so", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/home/antoine/py3k/py3k/Lib/readlinemodule.cpython-32m.so", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/home/antoine/py3k/py3k/Lib/readline.abi3.so", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/home/antoine/py3k/py3k/Lib/readlinemodule.abi3.so", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/home/antoine/py3k/py3k/Lib/readline.so", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/home/antoine/py3k/py3k/Lib/readlinemodule.so", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/home/antoine/py3k/py3k/Lib/readline.py", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/home/antoine/py3k/py3k/Lib/readline.pyc", O_RDONLY) = -1 ENOENT (No such file or directory)
stat("/home/antoine/py3k/py3k/Lib/plat-linux2", {st_mode=S_IFDIR|0775, st_size=4096, ...}) = 0
stat("/home/antoine/py3k/py3k/Lib/plat-linux2", {st_mode=S_IFDIR|0775, st_size=4096, ...}) = 0
stat("/home/antoine/py3k/py3k/Lib/plat-linux2/readline", 0x7fff1ed28760) = -1 ENOENT (No such file or directory)
open("/home/antoine/py3k/py3k/Lib/plat-linux2/readline.cpython-32m.so", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/home/antoine/py3k/py3k/Lib/plat-linux2/readlinemodule.cpython-32m.so", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/home/antoine/py3k/py3k/Lib/plat-linux2/readline.abi3.so", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/home/antoine/py3k/py3k/Lib/plat-linux2/readlinemodule.abi3.so", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/home/antoine/py3k/py3k/Lib/plat-linux2/readline.so", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/home/antoine/py3k/py3k/Lib/plat-linux2/readlinemodule.so", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/home/antoine/py3k/py3k/Lib/plat-linux2/readline.py", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/home/antoine/py3k/py3k/Lib/plat-linux2/readline.pyc", O_RDONLY) = -1 ENOENT (No such file or directory)
stat("/home/antoine/py3k/py3k/build/lib.linux-x86_64-3.2", {st_mode=S_IFDIR|0775, st_size=4096, ...}) = 0
stat("/home/antoine/py3k/py3k/build/lib.linux-x86_64-3.2", {st_mode=S_IFDIR|0775, st_size=4096, ...}) = 0
stat("/home/antoine/py3k/py3k/build/lib.linux-x86_64-3.2/readline", 0x7fff1ed28760) = -1 ENOENT (No such file or directory)
open("/home/antoine/py3k/py3k/build/lib.linux-x86_64-3.2/readline.cpython-32m.so", O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0775, st_size=59970, ...}) = 0
futex(0x7f28e605e0ec, FUTEX_WAKE_PRIVATE, 2147483647) = 0
open("/home/antoine/py3k/py3k/build/lib.linux-x86_64-3.2/readline.cpython-32m.so", O_RDONLY) = 4


Something has gone out of control here. Why do we need to check so many alternative locations?

----------
components: Interpreter Core
messages: 127359
nosy: barry, loewis, pitrou
priority: normal
severity: normal
status: open
title: system calls per import
type: performance
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11051>
_______________________________________

From report at bugs.python.org  Sat Jan 29 00:04:57 2011
From: report at bugs.python.org (Eric Smith)
Date: Fri, 28 Jan 2011 23:04:57 +0000
Subject: [issue11051] system calls per import
In-Reply-To: <1296254973.71.0.897914319387.issue11051@psf.upfronthosting.co.za>
Message-ID: <1296255897.11.0.938533619514.issue11051@psf.upfronthosting.co.za>


Changes by Eric Smith <eric at trueblade.com>:


----------
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11051>
_______________________________________

From report at bugs.python.org  Sat Jan 29 00:17:35 2011
From: report at bugs.python.org (Eric Smith)
Date: Fri, 28 Jan 2011 23:17:35 +0000
Subject: [issue11032] _string: formatter_field_name_split() and
	formatter_parser doesn't check input type
In-Reply-To: <1296169676.06.0.782920211182.issue11032@psf.upfronthosting.co.za>
Message-ID: <1296256655.09.0.656267586259.issue11032@psf.upfronthosting.co.za>


Changes by Eric Smith <eric at trueblade.com>:


----------
type:  -> crash

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11032>
_______________________________________

From report at bugs.python.org  Sat Jan 29 00:27:18 2011
From: report at bugs.python.org (Eric Smith)
Date: Fri, 28 Jan 2011 23:27:18 +0000
Subject: [issue11032] _string: formatter_field_name_split() and
	formatter_parser() don't check input type
In-Reply-To: <1296169676.06.0.782920211182.issue11032@psf.upfronthosting.co.za>
Message-ID: <1296257238.92.0.706865026586.issue11032@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

Release manager: You can decide if this fix should go in before 3.2. It's a trivial fix to a crasher, but it's extremely unlikely anyone would trip over it. It's been a crasher since 3.0.

It's also a crasher in 2.7, although there it's in the str module and the method names have leading underscores.

----------
assignee:  -> georg.brandl
components: +Extension Modules -Library (Lib)
nosy: +benjamin.peterson, georg.brandl
priority: normal -> release blocker
title: _string: formatter_field_name_split() and formatter_parser doesn't check input type -> _string: formatter_field_name_split() and formatter_parser() don't check input type
versions: +Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11032>
_______________________________________

From report at bugs.python.org  Sat Jan 29 00:33:23 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 28 Jan 2011 23:33:23 +0000
Subject: [issue11024] imaplib: Time2Internaldate() returns localized strings
In-Reply-To: <1296135301.42.0.767818406183.issue11024@psf.upfronthosting.co.za>
Message-ID: <1296257603.74.0.701541743237.issue11024@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

I would write the formatting code as follows:

('"%2d-%s-%04d %02d:%02d:%02d %+03d%02d"' %
 ((tt[2], _month_names[tt[1]], tt[0]) +
   tt[3:6] + divmod(zone//60, 60)))

The above also assumes that month names are stored in a 1-based array:

_month_names = [None, 'Jan', ...]

Note that %2d format code takes care of space-padding.

If you think the expression that I conjured is too cryptic, get the temporal data from timetuple first with say

y, m, d, H, M, S = tt[:6]

and use named variables in the formatting expression.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11024>
_______________________________________

From report at bugs.python.org  Sat Jan 29 00:53:20 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 28 Jan 2011 23:53:20 +0000
Subject: [issue10939] imaplib: Internaldate2tuple raises KeyError parsing
	month and does not work with negative TZ offset due to
	bytes/str issues
In-Reply-To: <1295389900.99.0.76199090445.issue10939@psf.upfronthosting.co.za>
Message-ID: <1296258800.91.0.672122882203.issue10939@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


----------
assignee: belopolsky -> georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10939>
_______________________________________

From report at bugs.python.org  Sat Jan 29 01:02:56 2011
From: report at bugs.python.org (Joe Peterson)
Date: Sat, 29 Jan 2011 00:02:56 +0000
Subject: [issue11024] imaplib: Time2Internaldate() returns localized strings
In-Reply-To: <1296135301.42.0.767818406183.issue11024@psf.upfronthosting.co.za>
Message-ID: <1296259376.7.0.172416278979.issue11024@psf.upfronthosting.co.za>


Changes by Joe Peterson <joe at skyrush.com>:


Removed file: http://bugs.python.org/file20589/imaplib_Time2Internaldate_locale_fix.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11024>
_______________________________________

From report at bugs.python.org  Sat Jan 29 01:03:54 2011
From: report at bugs.python.org (Matt Joiner)
Date: Sat, 29 Jan 2011 00:03:54 +0000
Subject: [issue10882] Add os.sendfile()
In-Reply-To: <1294691268.76.0.727179568007.issue10882@psf.upfronthosting.co.za>
Message-ID: <1296259434.91.0.805673790577.issue10882@psf.upfronthosting.co.za>


Matt Joiner <anacrolix at gmail.com> added the comment:

I have a few problems with these parts of the latest patch:

+   The second case may be used on Mac OS X and FreeBSD where *headers*
+   and *trailers* are arbitrary sequences of buffers that are written before and
+   after the data from *in* is written. It returns the same as the first case.

Why special case these? Why can't Mac OS X and FreeBSD write those manually into the output file descriptor. It's presumptious but I don't see why something so easy to do explicitly is mashed into the interface here, just pretend it doesn't exist. For the sake of simplicity (and sendfile might become very popular in future code), just drop this "feature".

for h in headers: out.write(h)
os.sendfile(out, in, offset, count)
for t in trailers: out.write(t)

+   On Mac OS X and FreeBSD, a value of 0 for *count* specifies to send until
+   the end of *in* is reached.

Again this should be emulated where it's not available, as it's very common, and a logical feature to have. However as indicated earlier, if os.sendfile is a minimal syscall wrapper, some thought needs to be given to a "higher-level" function, that also includes my other suggestions.

+   On Solaris, *out* may be the file descriptor of a regular file or the file
+   descriptor of a socket. On all other platforms, *out* must be the file
+   descriptor of an open socket

I'm pretty sure that Solaris isn't the only platform that supports non-socket file descriptors here, Linux (the platform I'm using), is one such case. As a general rule, we want to allow any file descriptors, and not restrict to sockets (except for awful platforms like Windows).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10882>
_______________________________________

From report at bugs.python.org  Sat Jan 29 01:06:42 2011
From: report at bugs.python.org (Joe Peterson)
Date: Sat, 29 Jan 2011 00:06:42 +0000
Subject: [issue11024] imaplib: Time2Internaldate() returns localized strings
In-Reply-To: <1296135301.42.0.767818406183.issue11024@psf.upfronthosting.co.za>
Message-ID: <1296259602.9.0.22482758408.issue11024@psf.upfronthosting.co.za>


Joe Peterson <joe at skyrush.com> added the comment:

Not cryptic at all - looks great!  New patch attached with associated tweaks.

----------
Added file: http://bugs.python.org/file20591/imaplib_Time2Internaldate_locale_fix.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11024>
_______________________________________

From report at bugs.python.org  Sat Jan 29 02:11:49 2011
From: report at bugs.python.org (Giampaolo Rodola')
Date: Sat, 29 Jan 2011 01:11:49 +0000
Subject: [issue10882] Add os.sendfile()
In-Reply-To: <1294691268.76.0.727179568007.issue10882@psf.upfronthosting.co.za>
Message-ID: <1296263509.92.0.341416226431.issue10882@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

> I'm pretty sure that Solaris isn't the only platform that supports non-
> socket file descriptors here, Linux (the platform I'm using), is one 
> such case. 

No, sendfile() on Linux supports only socket file descriptors:
http://linux.die.net/man/2/sendfile

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10882>
_______________________________________

From report at bugs.python.org  Sat Jan 29 02:37:01 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 29 Jan 2011 01:37:01 +0000
Subject: [issue10989] ssl.SSLContext(True).load_verify_locations(None,
	True) segfault
In-Reply-To: <1295820125.73.0.864692220479.issue10989@psf.upfronthosting.co.za>
Message-ID: <1296265021.35.0.928516789987.issue10989@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Should it be fixed in Python 3.2 or not? (load_verify_locations was introduced with SSLContext in Python 3.2)

----------
priority: high -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10989>
_______________________________________

From report at bugs.python.org  Sat Jan 29 02:37:04 2011
From: report at bugs.python.org (Carsten Klein)
Date: Sat, 29 Jan 2011 01:37:04 +0000
Subject: [issue2193] Cookie Colon Name Bug
In-Reply-To: <1203992843.27.0.867127322082.issue2193@psf.upfronthosting.co.za>
Message-ID: <1296265024.48.0.898796138247.issue2193@psf.upfronthosting.co.za>


Carsten Klein <carsten.klein at axn-software.de> added the comment:

Personally I believe that this is WONTFIX.

Why?

Because, the original RFC states that the colon is part of the unwanted characters, regardless of whether Perl or other similar implementations ignore the standard.

Besides that, and most important: The cookies are always set by the server or application thereof. Therefore, the server must behave just like what is stated in the original RFC. And it must also expect existing browsers to behave just like what is requested in the RFC.

IMO, the original requester and supporters, both here and over on the trac issue tracker are simply not able to figure out a proper cookie tracking mechanism for marketing or whatever purposes. Or, perhaps, they want to exploit some unwanted behaviour in existing user agents, who knows.

Besides that, if the original poster and follow up requesters supporting the issue persist on using a non standard implementation of the cookie library, hey, who cares. Let them figure out how to patch or rewrite the existing library, and how to include it with their favourite server/user agent exploiting implementation.

And the same is true for the request on the trac issue tracker. Since the cookies are set by the server, there is no need to actually weaken the existing pseudo standard by incorporating ways to hierarchically define a cookie name other than what is already present in the scheme or could be accomplished using different characters other than those blacklisted.

----------
nosy: +carsten.klein

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2193>
_______________________________________

From report at bugs.python.org  Sat Jan 29 02:38:00 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 29 Jan 2011 01:38:00 +0000
Subject: [issue10989] ssl.SSLContext(True).load_verify_locations(None,
	True) segfault
In-Reply-To: <1295820125.73.0.864692220479.issue10989@psf.upfronthosting.co.za>
Message-ID: <1296265080.42.0.597027131532.issue10989@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Well, I think you can commit.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10989>
_______________________________________

From report at bugs.python.org  Sat Jan 29 02:47:51 2011
From: report at bugs.python.org (Carsten Klein)
Date: Sat, 29 Jan 2011 01:47:51 +0000
Subject: [issue2193] Cookie Colon Name Bug
In-Reply-To: <1203992843.27.0.867127322082.issue2193@psf.upfronthosting.co.za>
Message-ID: <1296265671.86.0.168621650243.issue2193@psf.upfronthosting.co.za>


Carsten Klein <carsten.klein at axn-software.de> added the comment:

One more: if you look closer at the accepted patch by CMLENZ over @ t.e.o., you will find:


         if self.req.headers_in.has_key('Cookie'):
-            self.incookie.load(self.req.headers_in['Cookie'])
+            #self.incookie.load(self.req.headers_in['Cookie'])
+            cookie = self.req.headers_in['Cookie']
+            old_set = self.incookie._BaseCookie__set
+            bad_cookies = []
+            def safe_set(key, real_value, coded_value):
+                try:
+                    old_set(key, real_value, coded_value)
+                except CookieError:
+                    bad_cookies.append(key)
+                    dict.__setitem__(self.incookie, key, None)
+            # override Cookie.set to ignore cookies with parse errors
+            self.incookie._BaseCookie__set = safe_set
+           # load the cookie values
+            self.incookie.load(cookie)
+            # clean up the Cookie.set overriding
+            self.incookie._BaseCookie__set = old_set
+            for key in bad_cookies:
+                del self.incookie[key]
+


which will eventually delete all cookies that do not match the original production rule.

Besides that, the original poster of the issue forgot to properly limit the cookies set by the other site to just a single host path, so these invalid cookies got routed to the trac instance running on some different host.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2193>
_______________________________________

From report at bugs.python.org  Sat Jan 29 02:58:28 2011
From: report at bugs.python.org (R. David Murray)
Date: Sat, 29 Jan 2011 01:58:28 +0000
Subject: [issue11050] email.utils.getaddresses behavior contradicts RFC2822
In-Reply-To: <1296253802.55.0.925837101087.issue11050@psf.upfronthosting.co.za>
Message-ID: <1296266308.05.0.756144569901.issue11050@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
assignee:  -> r.david.murray
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11050>
_______________________________________

From report at bugs.python.org  Sat Jan 29 03:23:49 2011
From: report at bugs.python.org (Matt Joiner)
Date: Sat, 29 Jan 2011 02:23:49 +0000
Subject: [issue10882] Add os.sendfile()
In-Reply-To: <1294691268.76.0.727179568007.issue10882@psf.upfronthosting.co.za>
Message-ID: <1296267829.99.0.129434551457.issue10882@psf.upfronthosting.co.za>


Matt Joiner <anacrolix at gmail.com> added the comment:

Thanks for catching that:

Presently  (Linux  2.6.9):  in_fd, must correspond to a file which sup?
       ports mmap(2)-like operations (i.e., it cannot be a socket); and out_fd
       must refer to a socket.

Despite the fact the manpage hasn't changed since 2004, sendfile still only works for sockets. :(

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10882>
_______________________________________

From report at bugs.python.org  Sat Jan 29 03:42:28 2011
From: report at bugs.python.org (Ned Deily)
Date: Sat, 29 Jan 2011 02:42:28 +0000
Subject: [issue10940] IDLE 3.2 hangs with Cmd-M hotkey on OS X 10.6 with
	64-bit installer and A/S Tk 8.5
In-Reply-To: <1295391844.43.0.912463306116.issue10940@psf.upfronthosting.co.za>
Message-ID: <1296268948.54.0.0299622877473.issue10940@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

The attached temporary patch avoids the hang seen when IDLE is used with Cocoa Tk 8.5 by removing the menu accelerator hints from IDLE's menu on OS X.  The keyboard accelerators still work when typed but the character hints are not displayed on their menu items.  The affected commands are:
    Open Module       Cmd-M
    Go to Line        Cmd-J
    New Indent Width  Control-U

This should be applied to 3.2rc2.  I will leave the issue open for possible backport to 2.7 and to find a better resolution so that this patch can be reverted.

----------
keywords: +patch
priority: critical -> release blocker
Added file: http://bugs.python.org/file20592/issue10940_temporarily_dont_add_dialog_accelerators_on_osx.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10940>
_______________________________________

From report at bugs.python.org  Sat Jan 29 03:45:46 2011
From: report at bugs.python.org (Ned Deily)
Date: Sat, 29 Jan 2011 02:45:46 +0000
Subject: [issue10940] IDLE 3.2 hangs with Cmd-M hotkey on OS X 10.6 with
	64-bit installer and A/S Tk 8.5
In-Reply-To: <1295391844.43.0.912463306116.issue10940@psf.upfronthosting.co.za>
Message-ID: <1296269146.17.0.841089513582.issue10940@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


----------
stage: needs patch -> commit review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10940>
_______________________________________

From report at bugs.python.org  Sat Jan 29 03:52:58 2011
From: report at bugs.python.org (Ned Deily)
Date: Sat, 29 Jan 2011 02:52:58 +0000
Subject: [issue11052] Fix OS X IDLE menu accelerators for Save As and Save Copy
In-Reply-To: <1296269578.92.0.1087041883.issue11052@psf.upfronthosting.co.za>
Message-ID: <1296269578.92.0.1087041883.issue11052@psf.upfronthosting.co.za>


New submission from Ned Deily <nad at acm.org>:

On OS X, the menu accelerators for the Save As and Save Copy As commands are incorrect:

                Are            Should Be

Save            Cmd-S          Cmd-S
Save As..       Cmd-S          Shift-Cmd-S
Save Copy As..  Shift-Cmd-S    Option-Cmd-S

The attached patch fixes that.  It would be good to get into 3.2rc2 as part of the OS X IDLE clean up.

----------
assignee: ned.deily
components: IDLE, Macintosh
files: issue_osx_menu_accelerators.patch
keywords: patch
messages: 127371
nosy: georg.brandl, ned.deily
priority: high
severity: normal
stage: commit review
status: open
title: Fix OS X IDLE menu accelerators for Save As and Save Copy
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file20593/issue_osx_menu_accelerators.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11052>
_______________________________________

From report at bugs.python.org  Sat Jan 29 03:55:09 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 29 Jan 2011 02:55:09 +0000
Subject: [issue11032] _string: formatter_field_name_split() and
	formatter_parser() don't check input type
In-Reply-To: <1296257238.92.0.706865026586.issue11032@psf.upfronthosting.co.za>
Message-ID: <AANLkTimCUiA7YTNMdeX2KAvjCX=bu38T6NGWEFonNKX0@mail.gmail.com>


Benjamin Peterson <benjamin at python.org> added the comment:

2011/1/28 Eric Smith <report at bugs.python.org>:
>
> Eric Smith <eric at trueblade.com> added the comment:
>
> Release manager: You can decide if this fix should go in before 3.2. It's a trivial fix to a crasher, but it's extremely unlikely anyone would trip over it. It's been a crasher since 3.0.

Fine w/ me.

>
> It's also a crasher in 2.7, although there it's in the str module and the method names have leading underscores.
>
> ----------
> assignee: ?-> georg.brandl
> components: +Extension Modules -Library (Lib)
> nosy: +benjamin.peterson, georg.brandl
> priority: normal -> release blocker
> title: _string: formatter_field_name_split() and formatter_parser doesn't check input type -> _string: formatter_field_name_split() and formatter_parser() don't check input type
> versions: +Python 2.7
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue11032>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11032>
_______________________________________

From report at bugs.python.org  Sat Jan 29 04:05:19 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 29 Jan 2011 03:05:19 +0000
Subject: [issue10940] IDLE 3.2 hangs with Cmd-M hotkey on OS X 10.6 with
	64-bit installer and A/S Tk 8.5
In-Reply-To: <1295391844.43.0.912463306116.issue10940@psf.upfronthosting.co.za>
Message-ID: <1296270319.68.0.926569424492.issue10940@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Shouldn't this just be an edit to config-keys.def?
Why does it need to hit EditorWindow.py?
Also, instead of killing keys, would it make sense
to remap them to other non-exploding keys?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10940>
_______________________________________

From report at bugs.python.org  Sat Jan 29 04:07:36 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 29 Jan 2011 03:07:36 +0000
Subject: [issue11052] Fix OS X IDLE menu accelerators for Save As and Save Copy
In-Reply-To: <1296269578.92.0.1087041883.issue11052@psf.upfronthosting.co.za>
Message-ID: <1296270456.52.0.0681925232924.issue11052@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Looks fine.

----------
nosy: +rhettinger
resolution:  -> accepted

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11052>
_______________________________________

From report at bugs.python.org  Sat Jan 29 04:17:33 2011
From: report at bugs.python.org (Ned Deily)
Date: Sat, 29 Jan 2011 03:17:33 +0000
Subject: [issue11053] OS X IDLE 3 with Tk 8.4 appears to hang with syntax error
In-Reply-To: <1296271053.35.0.843403013415.issue11053@psf.upfronthosting.co.za>
Message-ID: <1296271053.35.0.843403013415.issue11053@psf.upfronthosting.co.za>


New submission from Ned Deily <nad at acm.org>:

When IDLE 3 is used with Aqua Tk 8.4 on OS X (as is the case with the 32-bit-only installer for Python 3.1.x or 3.2rc1), if the user tries to run a Python program with a syntax error from an editor window, the Run command causes the IDLE shell window to move to the front, generally obscuring the editor window.  For some unknown reason, a slight change between IDLE 2.x and IDLE 3.x causes the resulting modal Syntax Error message window to drop down from and be attached to the menu bar of the Editor Window. With Aqua Tk 8.4, the modal error only responds to a mouse click on the obscured Editor window's menu bar.  To an unsuspecting user, it appears that IDLE is hung.  In IDLE 2.x, the resulting modal error message is a top-level one, so it appears in a separate, unobscured window, the same as all other error messages in IDLE 2.x and 3.x.  From the svn checkin early in the Python 3 development cycle, it is not at all clear why this minor change was made but it causes a major usability problem for OS X users.

The attached patch reverts the change in this case restoring the behavior of IDLE 2.x.  This fix should be applied to 3.2rc2.

----------
assignee: ned.deily
files: issue_syntax_error_message.patch
keywords: patch
messages: 127375
nosy: benjamin.peterson, georg.brandl, ned.deily
priority: release blocker
severity: normal
stage: commit review
status: open
title: OS X IDLE 3 with Tk 8.4 appears to hang with syntax error
type: behavior
versions: Python 3.1, Python 3.2
Added file: http://bugs.python.org/file20594/issue_syntax_error_message.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11053>
_______________________________________

From report at bugs.python.org  Sat Jan 29 04:31:28 2011
From: report at bugs.python.org (Ned Deily)
Date: Sat, 29 Jan 2011 03:31:28 +0000
Subject: [issue10940] IDLE 3.2 hangs with Cmd-M hotkey on OS X 10.6 with
	64-bit installer and A/S Tk 8.5
In-Reply-To: <1295391844.43.0.912463306116.issue10940@psf.upfronthosting.co.za>
Message-ID: <1296271888.87.0.100844668153.issue10940@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Just editing config-keys.def does not eliminate the problem. The hang seems to occur because of the presence of any menu accelerator along with the detached windows produced by tkinter.simpledialog.Dialog().  Looking at the Cocoa Tk sources, there are some comments that indicate Cocoa Tk needs to handle menu accelerators differently than Carbon Tk, but there is more to do to get a reliable test case.  The patch as supplied does not kill the keys, rather the accelerator keys for the problematic items are effectively no longer passed to Tk 8.5 and to OS X Cocoa; they are still processed as keyboard events directly by IDLE so they still work when pressed, however the shortcut reminder does not appear to the right of the menu item for these three.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10940>
_______________________________________

From report at bugs.python.org  Sat Jan 29 04:32:46 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 29 Jan 2011 03:32:46 +0000
Subject: [issue10940] IDLE 3.2 hangs with Cmd-M hotkey on OS X 10.6 with
	64-bit installer and A/S Tk 8.5
In-Reply-To: <1295391844.43.0.912463306116.issue10940@psf.upfronthosting.co.za>
Message-ID: <1296271966.69.0.115216066788.issue10940@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <rhettinger at users.sourceforge.net>:


----------
resolution:  -> accepted

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10940>
_______________________________________

From report at bugs.python.org  Sat Jan 29 04:47:07 2011
From: report at bugs.python.org (Ned Deily)
Date: Sat, 29 Jan 2011 03:47:07 +0000
Subject: [issue11054] OS X installer build script for 3.2 can no longer build
	with system Python on OS X 10.5
In-Reply-To: <1296272827.91.0.103223659215.issue11054@psf.upfronthosting.co.za>
Message-ID: <1296272827.91.0.103223659215.issue11054@psf.upfronthosting.co.za>


New submission from Ned Deily <nad at acm.org>:

During the 3.2rc1 release cycle, it was discovered that it was no longer possible to build the 32-bit installer on OS X 10.5 as customary with the system Python 2.5 due to an inadvertent 2.6 feature ("with") added to the OS X installer build script.  This unnecessarily complicates the installer build process and violates past attempts to keep the installer script buildable with the system Python and compatible across current Python 2.x and 3.x releases.  The attached patch to the installer script removes the "with", properly guards a new Python 3 only build step, and updates the comments and README file.  The patched build script has been tested on both OS X 10.5 and 10.6.  This patch should be included in 3.2rc2.

----------
assignee: ned.deily
components: Build, Macintosh
files: issue_synch_installer_py3k.patch
keywords: patch
messages: 127377
nosy: georg.brandl, ned.deily, ronaldoussoren
priority: release blocker
severity: normal
stage: patch review
status: open
title: OS X installer build script for 3.2 can no longer build with system Python on OS X 10.5
versions: Python 3.2
Added file: http://bugs.python.org/file20595/issue_synch_installer_py3k.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11054>
_______________________________________

From report at bugs.python.org  Sat Jan 29 05:03:38 2011
From: report at bugs.python.org (Ned Deily)
Date: Sat, 29 Jan 2011 04:03:38 +0000
Subject: [issue11055] OS X IDLE 3.2 Save As menu accelerator opens two Save
	windows
In-Reply-To: <1296273818.82.0.517737090521.issue11055@psf.upfronthosting.co.za>
Message-ID: <1296273818.82.0.517737090521.issue11055@psf.upfronthosting.co.za>


New submission from Ned Deily <nad at acm.org>:

With the menu accelerators corrected (as patched in Issue10940), IDLE 3.2 with Cocoa Tk 8.5 opens two Save As dialog windows instead of one.  This doesn't happen when the Save As item is selected with the mouse nor does it happen with Carbon Tk 8.4.  The simple workaround is to dismiss the second dialog window.  This can be investigated and fixed post 3.2 release.

----------
assignee: ned.deily
components: IDLE, Macintosh
messages: 127378
nosy: ned.deily
priority: normal
severity: normal
stage: needs patch
status: open
title: OS X IDLE 3.2 Save As menu accelerator opens two Save windows
versions: Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11055>
_______________________________________

From report at bugs.python.org  Sat Jan 29 05:12:18 2011
From: report at bugs.python.org (Giampaolo Rodola')
Date: Sat, 29 Jan 2011 04:12:18 +0000
Subject: [issue11049] add tests for test.support
In-Reply-To: <1296241531.97.0.670133219758.issue11049@psf.upfronthosting.co.za>
Message-ID: <1296274338.16.0.71585487563.issue11049@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

Attached is a patch which tests about half the API.
Certain functions are not documented and/or it's not clear what they do, for others it seems unlikely they are actually used nowadays (although I haven't checked).
Also, it probably makes sense to get rid of some functions which look very old or completely useless.

----------
keywords: +patch
nosy: +giampaolo.rodola
Added file: http://bugs.python.org/file20596/test_support.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11049>
_______________________________________

From report at bugs.python.org  Sat Jan 29 05:37:38 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 29 Jan 2011 04:37:38 +0000
Subject: [issue11054] OS X installer build script for 3.2 can no longer build
	with system Python on OS X 10.5
In-Reply-To: <1296272827.91.0.103223659215.issue11054@psf.upfronthosting.co.za>
Message-ID: <1296275858.4.0.48586509677.issue11054@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

+1 for reversion.

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11054>
_______________________________________

From report at bugs.python.org  Sat Jan 29 05:40:55 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Sat, 29 Jan 2011 04:40:55 +0000
Subject: [issue11049] add tests for test.support
In-Reply-To: <1296241531.97.0.670133219758.issue11049@psf.upfronthosting.co.za>
Message-ID: <1296276055.25.0.54350731858.issue11049@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

Giampaolo, FYI I'm also working (issue 11015) in parallel on documenting some of the undocumented functions in Doc/library/test.rst that look useful to me. I think we can collaborate here to make sure they're both documented and tested.

I'll review your patch

P.S. see discussion on pydev about the removal of fcmp

----------
nosy: +eli.bendersky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11049>
_______________________________________

From report at bugs.python.org  Sat Jan 29 05:42:59 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Sat, 29 Jan 2011 04:42:59 +0000
Subject: [issue11049] add tests for test.support
In-Reply-To: <1296241531.97.0.670133219758.issue11049@psf.upfronthosting.co.za>
Message-ID: <1296276179.25.0.699905912163.issue11049@psf.upfronthosting.co.za>


Changes by Eli Bendersky <eliben at gmail.com>:


----------
nosy: +ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11049>
_______________________________________

From report at bugs.python.org  Sat Jan 29 05:43:23 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Sat, 29 Jan 2011 04:43:23 +0000
Subject: [issue11049] add tests for test.support
In-Reply-To: <1296241531.97.0.670133219758.issue11049@psf.upfronthosting.co.za>
Message-ID: <1296276203.85.0.882140318142.issue11049@psf.upfronthosting.co.za>


Changes by Eli Bendersky <eliben at gmail.com>:


----------
stage: needs patch -> patch review
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11049>
_______________________________________

From report at bugs.python.org  Sat Jan 29 05:59:35 2011
From: report at bugs.python.org (Ross Lagerwall)
Date: Sat, 29 Jan 2011 04:59:35 +0000
Subject: [issue10882] Add os.sendfile()
In-Reply-To: <1294691268.76.0.727179568007.issue10882@psf.upfronthosting.co.za>
Message-ID: <1296277175.15.0.337029421238.issue10882@psf.upfronthosting.co.za>


Ross Lagerwall <rosslagerwall at gmail.com> added the comment:

OK, updated documentation and tests.

> Why special case these? Why can't Mac OS X and FreeBSD write those manually into the output file descriptor.

These can be a crucial part of certain protocols such as HTTP to ensure that a minimal amount of TCP packets are sent. Also, the posix module is supposed to expose the OS functionality transparently. Besides, if you don't want to use headers/trailers, they can simply be left out.

----------
Added file: http://bugs.python.org/file20597/sendfile_v5.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10882>
_______________________________________

From report at bugs.python.org  Sat Jan 29 06:22:07 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Sat, 29 Jan 2011 05:22:07 +0000
Subject: [issue11049] add tests for test.support
In-Reply-To: <1296241531.97.0.670133219758.issue11049@psf.upfronthosting.co.za>
Message-ID: <1296278527.81.0.489936707258.issue11049@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

Giampaolo,

The patch looks good. Some minor comments below:

* class TestCase(unittest.TestCase): -> why not give the test class a more useful name?
* import_fresh_module is tested similarly to import_module - can't a test be added that it indeed performs its "special sauce"?
* test_DirsOnSysPath: you may want to use assertIn and assertNotIn here. [these were added to Python in 3.1]
* test_python_is_optimized: you may want to use assertIsInstance here.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11049>
_______________________________________

From report at bugs.python.org  Sat Jan 29 08:52:06 2011
From: report at bugs.python.org (shirish)
Date: Sat, 29 Jan 2011 07:52:06 +0000
Subject: [issue6715] xz compressor support
In-Reply-To: <1250502444.31.0.107447392137.issue6715@psf.upfronthosting.co.za>
Message-ID: <1296287526.45.0.816102240386.issue6715@psf.upfronthosting.co.za>


shirish <shirishag75 at gmail.com> added the comment:

no programmer or anything. Just adding that the wikipedia link given is not right. The correct link is https://secure.wikimedia.org/wikipedia/en/wiki/XZ_Utils

Just my 2 paise.

----------
nosy: +shirish

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6715>
_______________________________________

From report at bugs.python.org  Sat Jan 29 10:19:52 2011
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 29 Jan 2011 09:19:52 +0000
Subject: [issue11054] OS X installer build script for 3.2 can no longer build
	with system Python on OS X 10.5
In-Reply-To: <1296272827.91.0.103223659215.issue11054@psf.upfronthosting.co.za>
Message-ID: <1296292792.84.0.152545328756.issue11054@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Looks okay to me (and any bugs are likely to become apparent when the installers are built...)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11054>
_______________________________________

From report at bugs.python.org  Sat Jan 29 10:21:22 2011
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 29 Jan 2011 09:21:22 +0000
Subject: [issue10989] ssl.SSLContext(True).load_verify_locations(None,
	True) segfault
In-Reply-To: <1295820125.73.0.864692220479.issue10989@psf.upfronthosting.co.za>
Message-ID: <1296292882.86.0.289389895526.issue10989@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

It's reviewed by Antoine, so you can commit.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10989>
_______________________________________

From report at bugs.python.org  Sat Jan 29 10:23:19 2011
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 29 Jan 2011 09:23:19 +0000
Subject: [issue11032] _string: formatter_field_name_split() and
	formatter_parser() don't check input type
In-Reply-To: <1296169676.06.0.782920211182.issue11032@psf.upfronthosting.co.za>
Message-ID: <1296292999.61.0.251913736103.issue11032@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

I think the canonical message is "expected X, not Y".  Otherwise, fine to commit.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11032>
_______________________________________

From report at bugs.python.org  Sat Jan 29 10:23:31 2011
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 29 Jan 2011 09:23:31 +0000
Subject: [issue11032] _string: formatter_field_name_split() and
	formatter_parser() don't check input type
In-Reply-To: <1296169676.06.0.782920211182.issue11032@psf.upfronthosting.co.za>
Message-ID: <1296293011.31.0.682294052722.issue11032@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
assignee: georg.brandl -> haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11032>
_______________________________________

From report at bugs.python.org  Sat Jan 29 10:25:28 2011
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 29 Jan 2011 09:25:28 +0000
Subject: [issue10940] IDLE 3.2 hangs with Cmd-M hotkey on OS X 10.6 with
	64-bit installer and A/S Tk 8.5
In-Reply-To: <1295391844.43.0.912463306116.issue10940@psf.upfronthosting.co.za>
Message-ID: <1296293128.94.0.298566878146.issue10940@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

If this helps with hanging, okay to commit. (It doesn't have any effect on non-OSX anyway.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10940>
_______________________________________

From report at bugs.python.org  Sat Jan 29 10:34:26 2011
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Sat, 29 Jan 2011 09:34:26 +0000
Subject: [issue11037] State of PEP 382 or How does distutils2 handle
	namespaces?
In-Reply-To: <1296210890.87.0.618097241127.issue11037@psf.upfronthosting.co.za>
Message-ID: <1296293666.08.0.299170502153.issue11037@psf.upfronthosting.co.za>


?ukasz Langa <lukasz at langa.pl> added the comment:

Martin, could you shed some light on the state of that PEP?

----------
nosy: +lukasz.langa
title: How distutils2 handle namespaces -> State of PEP 382 or How does distutils2 handle namespaces?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11037>
_______________________________________

From report at bugs.python.org  Sat Jan 29 10:36:25 2011
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 29 Jan 2011 09:36:25 +0000
Subject: [issue11053] OS X IDLE 3 with Tk 8.4 appears to hang with syntax error
In-Reply-To: <1296271053.35.0.843403013415.issue11053@psf.upfronthosting.co.za>
Message-ID: <1296293785.16.0.153294356854.issue11053@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Good to go.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11053>
_______________________________________

From report at bugs.python.org  Sat Jan 29 10:40:57 2011
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 29 Jan 2011 09:40:57 +0000
Subject: [issue9124] Mailbox module should use binary I/O, not text I/O
In-Reply-To: <1277900903.38.0.556015912714.issue9124@psf.upfronthosting.co.za>
Message-ID: <1296294057.69.0.0548321372318.issue9124@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

I'd really like someone else to throw a pair of eyes at the code changes before it is committed.

But yes, I will allow this into rc2, and we'll buy some stabilizing time by adding an rc3 to the cycle.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9124>
_______________________________________

From report at bugs.python.org  Sat Jan 29 10:43:20 2011
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 29 Jan 2011 09:43:20 +0000
Subject: [issue9124] Mailbox module should use binary I/O, not text I/O
In-Reply-To: <1277900903.38.0.556015912714.issue9124@psf.upfronthosting.co.za>
Message-ID: <1296294200.1.0.38697931502.issue9124@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
Removed message: http://bugs.python.org/msg127391

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9124>
_______________________________________

From report at bugs.python.org  Sat Jan 29 10:43:53 2011
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 29 Jan 2011 09:43:53 +0000
Subject: [issue9124] Mailbox module should use binary I/O, not text I/O
In-Reply-To: <1277900903.38.0.556015912714.issue9124@psf.upfronthosting.co.za>
Message-ID: <1296294233.7.0.117641392264.issue9124@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

I'd really like someone else to throw a pair of eyes at the code changes before it is committed.

But yes, I will allow this into rc2, since a completely broken module isn't really what a minor release is about.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9124>
_______________________________________

From report at bugs.python.org  Sat Jan 29 10:50:21 2011
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 29 Jan 2011 09:50:21 +0000
Subject: [issue10939] imaplib: Internaldate2tuple raises KeyError parsing
	month and does not work with negative TZ offset due to
	bytes/str issues
In-Reply-To: <1295389900.99.0.76199090445.issue10939@psf.upfronthosting.co.za>
Message-ID: <1296294621.45.0.313076647687.issue10939@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

The new test is faulty; it appears to be specific to the timezone of the patch submitter.

The library fix should go in nevertheless, if you could add a correct test, Alexander, it would be great.

----------
priority: normal -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10939>
_______________________________________

From report at bugs.python.org  Sat Jan 29 11:07:26 2011
From: report at bugs.python.org (nw)
Date: Sat, 29 Jan 2011 10:07:26 +0000
Subject: [issue11056] 2to3 fails for inner __metaclass__ class definition
In-Reply-To: <1296295646.41.0.555218890155.issue11056@psf.upfronthosting.co.za>
Message-ID: <1296295646.41.0.555218890155.issue11056@psf.upfronthosting.co.za>


New submission from nw <nils.winter at googlemail.com>:

The attached code is not converted properly. No warning either.

Eventually it may be a good idea to reintroduce the old more versatile method.

----------
components: 2to3 (2.x to 3.0 conversion tool)
files: test.py
messages: 127394
nosy: Nils.Winter
priority: normal
severity: normal
status: open
title: 2to3 fails for inner __metaclass__ class definition
Added file: http://bugs.python.org/file20598/test.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11056>
_______________________________________

From report at bugs.python.org  Sat Jan 29 11:14:46 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Sat, 29 Jan 2011 10:14:46 +0000
Subject: [issue9124] Mailbox module should use binary I/O, not text I/O
In-Reply-To: <1277900903.38.0.556015912714.issue9124@psf.upfronthosting.co.za>
Message-ID: <1296296086.42.0.875280519576.issue9124@psf.upfronthosting.co.za>


Steffen Daode Nurpmeso <sdaoden at googlemail.com> added the comment:

RDM: it seems i was too tired to get your messages right last evening!
Indeed it's now completely my fault, i should inspect the content further in respect to the str/bytes etc. stuff!  Thus - i will now need three or four days to cleanup my hacky code before output of this broken thing is of any further use.  (If afterwards something new shows up i will of course post a feedback.)
It may be of interest for you, however, that speed broke down heavily once again, so that my dumb thing did not take 2 seconds as it did after applying the first patch, but almost 8 seconds.  (It takes max. 1.1 seconds on Python 2.7.)
Beside that there came to me a "hhuuuuh"!  Python is a lot about testing!  I would have been more of a help if i would have simply offered some test cases? !!  Next time!

RDM: thanks a lot for spending long hours of work on this issue!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9124>
_______________________________________

From report at bugs.python.org  Sat Jan 29 11:38:21 2011
From: report at bugs.python.org (Kelsey)
Date: Sat, 29 Jan 2011 10:38:21 +0000
Subject: [issue11057] Missing DistutilsOptionError
In-Reply-To: <1296297501.69.0.98662936413.issue11057@psf.upfronthosting.co.za>
Message-ID: <1296297501.69.0.98662936413.issue11057@psf.upfronthosting.co.za>


New submission from Kelsey <kelsey.hightower at gmail.com>:

Missing DistutilsOptionError import in distutil2.config causes the following error:

Traceback (most recent call last):
  File "/opt/OpenPython-2.7.1/lib/python2.7/runpy.py", line 162, in _run_module_as_main
    "__main__", fname, loader, pkg_name)
  File "/opt/OpenPython-2.7.1/lib/python2.7/runpy.py", line 72, in _run_code
    exec code in run_globals
  File "/opt/OpenPython-2.7.1/lib/python2.7/site-packages/Distutils2-1.0a3-py2.7.egg/distutils2/run.py", line 181, in <module>
    main()
  File "/opt/OpenPython-2.7.1/lib/python2.7/site-packages/Distutils2-1.0a3-py2.7.egg/distutils2/run.py", line 176, in main
    return commands_main()
  File "/opt/OpenPython-2.7.1/lib/python2.7/site-packages/Distutils2-1.0a3-py2.7.egg/distutils2/run.py", line 90, in commands_main
    dist.parse_config_files()
  File "/opt/OpenPython-2.7.1/lib/python2.7/site-packages/Distutils2-1.0a3-py2.7.egg/distutils2/dist.py", line 307, in parse_config_files
    return self.config.parse_config_files(filenames)
  File "/opt/OpenPython-2.7.1/lib/python2.7/site-packages/Distutils2-1.0a3-py2.7.egg/distutils2/config.py", line 193, in parse_config_files
    self._read_setup_cfg(parser)
  File "/opt/OpenPython-2.7.1/lib/python2.7/site-packages/Distutils2-1.0a3-py2.7.egg/distutils2/config.py", line 113, in _read_setup_cfg
    raise DistutilsOptionError(msg)
NameError: global name 'DistutilsOptionError' is not defined

----------
assignee: tarek
components: Distutils2
messages: 127396
nosy: eric.araujo, kelseyhightower, tarek
priority: normal
severity: normal
status: open
title: Missing DistutilsOptionError
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11057>
_______________________________________

From report at bugs.python.org  Sat Jan 29 11:40:02 2011
From: report at bugs.python.org (Kelsey)
Date: Sat, 29 Jan 2011 10:40:02 +0000
Subject: [issue11057] Missing DistutilsOptionError
In-Reply-To: <1296297501.69.0.98662936413.issue11057@psf.upfronthosting.co.za>
Message-ID: <1296297602.42.0.230145662496.issue11057@psf.upfronthosting.co.za>


Kelsey <kelsey.hightower at gmail.com> added the comment:

Link to patch:

https://bitbucket.org/khightower/distutils2/changeset/22f336b467b8

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11057>
_______________________________________

From report at bugs.python.org  Sat Jan 29 11:42:58 2011
From: report at bugs.python.org (Kelsey)
Date: Sat, 29 Jan 2011 10:42:58 +0000
Subject: [issue11057] Missing import of DistutilsOptionError
In-Reply-To: <1296297501.69.0.98662936413.issue11057@psf.upfronthosting.co.za>
Message-ID: <1296297778.37.0.888601589091.issue11057@psf.upfronthosting.co.za>


Changes by Kelsey <kelsey.hightower at gmail.com>:


----------
title: Missing DistutilsOptionError -> Missing import of DistutilsOptionError

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11057>
_______________________________________

From report at bugs.python.org  Sat Jan 29 11:45:02 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Sat, 29 Jan 2011 10:45:02 +0000
Subject: [issue11046] setup.py/configure [darwin]
In-Reply-To: <1296224784.81.0.0525228154056.issue11046@psf.upfronthosting.co.za>
Message-ID: <1296297902.54.0.474304883763.issue11046@psf.upfronthosting.co.za>


Steffen Daode Nurpmeso <sdaoden at googlemail.com> added the comment:

Let me summarize this thread:
- For darwin/MacOS X there exists an undocumented MACOSX_DEPLOYMENT_TARGET switch, which makes its way all through the build-system and the 'sysconfig' module.  Even though 'configure' auto-detects
    checking for OSX 10.5 SDK or later... yes
  it does not seem to take care about that.
  I thus request a (documented) --with-macosx-target[=10.5] 'configure' switch.
  GNU Autoconf is evil!  I cannot provide a patch for that.
- I've attached a patch (setup.3.patch is now the final version, which adds a 'does_library_chainload_library()' function to setup.py.  This one encapsulates the complexity of using different tools on different UNIX platforms and thus moves that out of the widespreaded code.  Due to this i'll think it should be merged into Py3K.
  However: it still contains lines 'sdaoden hack', which i need to get MacOS X running, and which need the eyes of RO or another MacOS X guru!
- Besides all that i think this issue thread can be closed.

----------
keywords: +patch
title: darwin/MacOS X setup.py hack -> setup.py/configure [darwin]
type:  -> behavior
Added file: http://bugs.python.org/file20599/setup.3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11046>
_______________________________________

From report at bugs.python.org  Sat Jan 29 11:47:02 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Sat, 29 Jan 2011 10:47:02 +0000
Subject: [issue11046] setup.py/configure [darwin]
In-Reply-To: <1296224784.81.0.0525228154056.issue11046@psf.upfronthosting.co.za>
Message-ID: <1296298022.25.0.162714377867.issue11046@psf.upfronthosting.co.za>


Changes by Steffen Daode Nurpmeso <sdaoden at googlemail.com>:


Removed file: http://bugs.python.org/file20575/DIFF

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11046>
_______________________________________

From report at bugs.python.org  Sat Jan 29 11:47:07 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Sat, 29 Jan 2011 10:47:07 +0000
Subject: [issue11046] setup.py/configure [darwin]
In-Reply-To: <1296224784.81.0.0525228154056.issue11046@psf.upfronthosting.co.za>
Message-ID: <1296298027.79.0.854273766267.issue11046@psf.upfronthosting.co.za>


Changes by Steffen Daode Nurpmeso <sdaoden at googlemail.com>:


Removed file: http://bugs.python.org/file20582/DIFF

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11046>
_______________________________________

From report at bugs.python.org  Sat Jan 29 11:48:53 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 29 Jan 2011 10:48:53 +0000
Subject: [issue10826] pass_fds sometimes fails
In-Reply-To: <1294152290.71.0.646502628705.issue10826@psf.upfronthosting.co.za>
Message-ID: <1296298133.87.0.52945068706.issue10826@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Here is a patch to ignore door files when running the fd_status script. It seems to eradicate the intermittent failures on the solaris buildbots.

----------
keywords: +patch
Added file: http://bugs.python.org/file20600/spdoors.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10826>
_______________________________________

From report at bugs.python.org  Sat Jan 29 12:18:02 2011
From: report at bugs.python.org (Eric Smith)
Date: Sat, 29 Jan 2011 11:18:02 +0000
Subject: [issue11032] _string: formatter_field_name_split() and
	formatter_parser() don't check input type
In-Reply-To: <1296169676.06.0.782920211182.issue11032@psf.upfronthosting.co.za>
Message-ID: <1296299882.73.0.0768573284137.issue11032@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

It looks like the canonical message is "expected X, got Y". With that change I've checked it in in r88226. I'll backport.

----------
assignee: haypo -> eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11032>
_______________________________________

From report at bugs.python.org  Sat Jan 29 12:27:01 2011
From: report at bugs.python.org (Kelsey)
Date: Sat, 29 Jan 2011 11:27:01 +0000
Subject: [issue11058] dist directory not created when running sdist command
In-Reply-To: <1296300421.59.0.468968378526.issue11058@psf.upfronthosting.co.za>
Message-ID: <1296300421.59.0.468968378526.issue11058@psf.upfronthosting.co.za>


New submission from Kelsey <kelsey.hightower at gmail.com>:

When trying to create a source distribution, I get the following error and no stack trace:


[openpython:yamlconfig]$ /opt/OpenPython-2.7.1/bin/python -m distutils2.run sdist
WARNING:root:warning: no files found matching 's'
WARNING:root:warning: no files found matching 'e'
WARNING:root:warning: no files found matching 't'
WARNING:root:warning: no files found matching 'u'
WARNING:root:warning: no files found matching 'p'
WARNING:root:warning: no files found matching '.'
WARNING:root:warning: no files found matching 'p'
WARNING:root:warning: no files found matching 'y'
error: dist/yamlconfig-0.3.1.tar.gz: No such file or directory

Not sure what all the WARNINGs are for, will file a separate issue for those.

----------
assignee: tarek
components: Distutils2
messages: 127401
nosy: eric.araujo, kelseyhightower, tarek
priority: normal
severity: normal
status: open
title: dist directory not created when running sdist command
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11058>
_______________________________________

From report at bugs.python.org  Sat Jan 29 12:30:30 2011
From: report at bugs.python.org (Eric Smith)
Date: Sat, 29 Jan 2011 11:30:30 +0000
Subject: [issue11032] _string: formatter_field_name_split() and
	formatter_parser() don't check input type
In-Reply-To: <1296169676.06.0.782920211182.issue11032@psf.upfronthosting.co.za>
Message-ID: <1296300630.36.0.682678716665.issue11032@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

Actually this error doesn't exist on older versions because these used to be methods on a string. The error was introduced in r85456 (issue 9418) when these became functions in the _string module.

No need to backport.

----------
resolution:  -> accepted
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11032>
_______________________________________

From report at bugs.python.org  Sat Jan 29 12:32:01 2011
From: report at bugs.python.org (Eric Smith)
Date: Sat, 29 Jan 2011 11:32:01 +0000
Subject: [issue9418] Move _formatter_* methods from string type into _string
	module
In-Reply-To: <1280416899.1.0.0890176421306.issue9418@psf.upfronthosting.co.za>
Message-ID: <1296300721.84.0.847627520296.issue9418@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

No further action required. I'm not going to remove format() and friends from stringlib as long as there's chatter about adding a .format() for bytes.

----------
resolution:  -> accepted
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9418>
_______________________________________

From report at bugs.python.org  Sat Jan 29 12:32:37 2011
From: report at bugs.python.org (Kelsey)
Date: Sat, 29 Jan 2011 11:32:37 +0000
Subject: [issue11058] dist directory not created when running sdist command
In-Reply-To: <1296300421.59.0.468968378526.issue11058@psf.upfronthosting.co.za>
Message-ID: <1296300757.04.0.212108176804.issue11058@psf.upfronthosting.co.za>


Kelsey <kelsey.hightower at gmail.com> added the comment:

Link to patch:
https://bitbucket.org/khightower/distutils2/changeset/6ef86fa5236b

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11058>
_______________________________________

From report at bugs.python.org  Sat Jan 29 12:32:56 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 29 Jan 2011 11:32:56 +0000
Subject: [issue10989] ssl.SSLContext(True).load_verify_locations(None,
	True) segfault
In-Reply-To: <1295820125.73.0.864692220479.issue10989@psf.upfronthosting.co.za>
Message-ID: <1296300776.46.0.440314124955.issue10989@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Ok, fixed in r88228. Not backport needed, SSLContext was introduced in Python 3.2.

----------
resolution: accepted -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10989>
_______________________________________

From report at bugs.python.org  Sat Jan 29 12:40:06 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 29 Jan 2011 11:40:06 +0000
Subject: [issue9124] Mailbox module should use binary I/O, not text I/O
In-Reply-To: <1277900903.38.0.556015912714.issue9124@psf.upfronthosting.co.za>
Message-ID: <1296301206.27.0.977659593851.issue9124@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

+            if isinstance(message, io.TextIOWrapper):
+                # Backward compatibility hack.
+                message = message.buffer

Is it a good thing to parse a mailbox using a text file? If not, we should emit a warning and maybe remove this feature in Python 3.3.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9124>
_______________________________________

From report at bugs.python.org  Sat Jan 29 13:20:59 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 29 Jan 2011 12:20:59 +0000
Subject: [issue11049] add tests for test.support
In-Reply-To: <1296241531.97.0.670133219758.issue11049@psf.upfronthosting.co.za>
Message-ID: <1296303659.04.0.790948337762.issue11049@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

test_warnings actually includes sanity checks for import_fresh_module - they could be adapted into a separate unit test easily enough.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11049>
_______________________________________

From report at bugs.python.org  Sat Jan 29 13:42:41 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Sat, 29 Jan 2011 12:42:41 +0000
Subject: [issue11059] code.python.org repo failures introduced!
In-Reply-To: <1296304961.11.0.1358070149.issue11059@psf.upfronthosting.co.za>
Message-ID: <1296304961.11.0.1358070149.issue11059@psf.upfronthosting.co.za>


New submission from Steffen Daode Nurpmeso <sdaoden at googlemail.com>:

... because i don't know where to place this message, i do place it here.
Whatever has happened in the last 90 minutes, cloning from code.python.org/hg results in mercurial panics!
Please see http://mercurial.selenic.com/bts/issue2239 for more on that.
Have a nice weekend.

----------
messages: 127408
nosy: sdaoden
priority: normal
severity: normal
status: open
title: code.python.org repo failures introduced!
type: behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11059>
_______________________________________

From report at bugs.python.org  Sat Jan 29 13:45:54 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 29 Jan 2011 12:45:54 +0000
Subject: [issue11049] add tests for test.support
In-Reply-To: <1296241531.97.0.670133219758.issue11049@psf.upfronthosting.co.za>
Message-ID: <1296305154.24.0.225323779244.issue11049@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

+        os.mkdir(os.path.join(TESTFN, TESTFN))

Please don't. This will break the day TESTFN becomes a non-trivial path.

+    def test_make_bad_fd(self):
+        fd = support.make_bad_fd()
+        self.assertRaises(OSError, os.write, fd, b"foo")

You should also check that the errno is EBADF.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11049>
_______________________________________

From report at bugs.python.org  Sat Jan 29 13:46:06 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Sat, 29 Jan 2011 12:46:06 +0000
Subject: [issue11059] code.python.org repo failures introduced!
In-Reply-To: <1296304961.11.0.1358070149.issue11059@psf.upfronthosting.co.za>
Message-ID: <1296305166.46.0.332285580637.issue11059@psf.upfronthosting.co.za>


Steffen Daode Nurpmeso <sdaoden at googlemail.com> added the comment:

MAN!! Forget it - it's ok again; it's maybe really a mercurial non-atomicity failure.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11059>
_______________________________________

From report at bugs.python.org  Sat Jan 29 13:46:14 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Sat, 29 Jan 2011 12:46:14 +0000
Subject: [issue11059] code.python.org repo failures introduced!
In-Reply-To: <1296304961.11.0.1358070149.issue11059@psf.upfronthosting.co.za>
Message-ID: <1296305174.51.0.126306448071.issue11059@psf.upfronthosting.co.za>


Changes by Steffen Daode Nurpmeso <sdaoden at googlemail.com>:


----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11059>
_______________________________________

From report at bugs.python.org  Sat Jan 29 13:48:40 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 29 Jan 2011 12:48:40 +0000
Subject: [issue11059] code.python.org repo failures introduced!
In-Reply-To: <1296304961.11.0.1358070149.issue11059@psf.upfronthosting.co.za>
Message-ID: <1296305320.18.0.230337563837.issue11059@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Works fine here.

----------
nosy: +pitrou
resolution:  -> works for me

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11059>
_______________________________________

From report at bugs.python.org  Sat Jan 29 13:57:37 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Sat, 29 Jan 2011 12:57:37 +0000
Subject: [issue11059] code.python.org repo failures introduced!
In-Reply-To: <1296304961.11.0.1358070149.issue11059@psf.upfronthosting.co.za>
Message-ID: <1296305857.9.0.910139681843.issue11059@psf.upfronthosting.co.za>


Steffen Daode Nurpmeso <sdaoden at googlemail.com> added the comment:

Nope.  In the meanwhile i've accomplished to clone py3k once again, but branches/release2.7-maint fails over and over again.  I've added another message to http://mercurial.selenic.com/bts/issue2239.
Have a nice weekend.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11059>
_______________________________________

From report at bugs.python.org  Sat Jan 29 14:14:51 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 29 Jan 2011 13:14:51 +0000
Subject: [issue10845] test_multiprocessing failure under Windows
In-Reply-To: <1294309581.41.0.731804987161.issue10845@psf.upfronthosting.co.za>
Message-ID: <1296306891.07.0.543642257285.issue10845@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Nick, a more problematic issue is that __main__ is always called __main__, regardless of whether it is actually imported as the real "main module" or through a regular import. This means that it is impossible to discriminate between both uses by using "if __name__ == '__main__'", which in turn means that top-level code will always get executed as a side-effect of importing, which means the "__main__.py" feature is completely broken for use with multiprocessing under Windows!

This also shows, IMO, how uselessly complicated and misleading the import system has become.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10845>
_______________________________________

From report at bugs.python.org  Sat Jan 29 14:29:32 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 29 Jan 2011 13:29:32 +0000
Subject: [issue10845] test_multiprocessing failure under Windows
In-Reply-To: <1294309581.41.0.731804987161.issue10845@psf.upfronthosting.co.za>
Message-ID: <1296307772.82.0.451932606692.issue10845@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Actually, forget that (!). The following patch seems to work:

Index: Lib/multiprocessing/forking.py
===================================================================
--- Lib/multiprocessing/forking.py	(r?vision 88224)
+++ Lib/multiprocessing/forking.py	(copie de travail)
@@ -474,7 +474,8 @@
             else:
                 dirs = [os.path.dirname(main_path)]
 
-            assert main_name not in sys.modules, main_name
+            if main_name != '__main__':
+                assert main_name not in sys.modules, main_name
             file, path_name, etc = imp.find_module(main_name, dirs)
             try:
                 # We would like to do "imp.load_module('__main__', ...)"
Index: Lib/test/__main__.py
===================================================================
--- Lib/test/__main__.py	(r?vision 88224)
+++ Lib/test/__main__.py	(copie de travail)
@@ -1,13 +1,16 @@
 from test import regrtest, support
 
+# Issue #10845: avoid executing toplevel code if imported by multiprocessing
+# (which is smart enough to import the module under another name).
+if __name__ == "__main__":
 
-TEMPDIR, TESTCWD = regrtest._make_temp_dir_for_build(regrtest.TEMPDIR)
-regrtest.TEMPDIR = TEMPDIR
-regrtest.TESTCWD = TESTCWD
+    TEMPDIR, TESTCWD = regrtest._make_temp_dir_for_build(regrtest.TEMPDIR)
+    regrtest.TEMPDIR = TEMPDIR
+    regrtest.TESTCWD = TESTCWD
 
-# Run the tests in a context manager that temporary changes the CWD to a
-# temporary and writable directory. If it's not possible to create or
-# change the CWD, the original CWD will be used. The original CWD is
-# available from support.SAVEDCWD.
-with support.temp_cwd(TESTCWD, quiet=True):
-    regrtest.main()
+    # Run the tests in a context manager that temporary changes the CWD to a
+    # temporary and writable directory. If it's not possible to create or
+    # change the CWD, the original CWD will be used. The original CWD is
+    # available from support.SAVEDCWD.
+    with support.temp_cwd(TESTCWD, quiet=True):
+        regrtest.main()

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10845>
_______________________________________

From report at bugs.python.org  Sat Jan 29 14:31:30 2011
From: report at bugs.python.org (Jesse Noller)
Date: Sat, 29 Jan 2011 13:31:30 +0000
Subject: [issue10845] test_multiprocessing failure under Windows
In-Reply-To: <1294309581.41.0.731804987161.issue10845@psf.upfronthosting.co.za>
Message-ID: <1296307890.33.0.924720763982.issue10845@psf.upfronthosting.co.za>


Jesse Noller <jnoller at gmail.com> added the comment:

I'm fine with that tweak antoine

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10845>
_______________________________________

From report at bugs.python.org  Sat Jan 29 14:50:26 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Sat, 29 Jan 2011 13:50:26 +0000
Subject: [issue11022] locale.setlocale() doesn't change I/O codec,
	os.environ does
In-Reply-To: <1296126025.04.0.965125504096.issue11022@psf.upfronthosting.co.za>
Message-ID: <1296309026.27.0.136733888368.issue11022@psf.upfronthosting.co.za>


Steffen Daode Nurpmeso <sdaoden at googlemail.com> added the comment:

Also in respect to Issue 6203 i could talk about a project which did not link against anything in the end, only ld(1) and syscalls and the undocumented third 'char **envp' arg to UNIX main()s.
Thus: all of you should be *very* happy about the warm and cosy environment of LibC etc.!
You've decided to re-Python as Py3k, is guess it has got something to do with, let me describe it as, UNICODE.
Thus: you need a locale.

- Environment: has an encoding, though keys are ok to parse in ASCII
  (unless your OS allows wide characters *optionally*).
  Still, LC_ values may be specified in a *lot* of different ways,
  but one thing is true: it's a hard to do in plain C without being
  able to use stuff which *may* depend upon an initialized library
- Path names: have an encoding
- Console I/O: has an encoding
- File I/O: this is all dumb bytes, just do what you want

Conclusion: you need a locale.

- Hardcode defaults
- Spread specific things all across the implementation.
  I.e., in path access, use some os.path._sysdep.default_codeset(),
  in console I/O do os.console._sysdep.default_codeset() etc.
  (i'm lying about names)
- Perform an initial global initialization

So - what are you all talking about?
Noone - and i really mean NOONE - can assume that a fully blown environment like python(1) can be used as an isolated sandbox thing
like ECMAScript!  File I/O, child processes ...  Shall an entire interpreter lifecycle be possible in a signal(3) handler
(uuhh, just kiddin')?  Even if that would be true for 2.7 (don't know), in Py3k there is graceful and neatless UNICODE support.
You need a locale.

I would indeed insist on the following:
- The interpreter *has* to be initialized in the cosy LibC
  (or whatever native thing) environment.
  Like this it embeds itself neatlessly in there.
  This *has* to be performed in an *unthreaded* state.
  If you are really concerned about anything here,
  add an additional argument (or is it there yet?  I did *not*
  look in there - i would/will need long months to get an idea
  of the entire python(1) system) to your interpreter's setup()
  like thing, or allow NULL to nevertheless use setlocale() directly.
  Like this the embedder can choose herself which approach she
  wants to adhere.
- Even if 3.DID_IT ends up with a lot of 'encoding=STRING' instead
  of 'codec=None' (aka 'codec=codec_instance'), i would implement
  the system in a way that a change at a single place is automatically
  reflected all through the system (on a no-arg-then-use-default)
  base.

After the end:
someone who earned about 150 bucks from me for two books i bought
almost a decade ago once i've started Thinking In ... programming
said some years ago (as i've read in the german magazine c't):
    "In Python i am even more productive than with Java."
(I always was in doubt about that person - someone who is productive
in Java, who may that be?)
Thanks for python(1), and have a nice weekend.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11022>
_______________________________________

From report at bugs.python.org  Sat Jan 29 14:51:48 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Sat, 29 Jan 2011 13:51:48 +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: <1296309108.67.0.685626021013.issue6203@psf.upfronthosting.co.za>


Steffen Daode Nurpmeso <sdaoden at googlemail.com> added the comment:

User lemburg pointed me to this, but no, i've posted msg127416 to Issue 11022.

----------
nosy: +sdaoden

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6203>
_______________________________________

From report at bugs.python.org  Sat Jan 29 15:31:32 2011
From: report at bugs.python.org (Giampaolo Rodola')
Date: Sat, 29 Jan 2011 14:31:32 +0000
Subject: [issue11015] Bring test.support docs up to date
In-Reply-To: <1296009969.38.0.282241852849.issue11015@psf.upfronthosting.co.za>
Message-ID: <1296311492.96.0.645924353543.issue11015@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/issue11015>
_______________________________________

From report at bugs.python.org  Sat Jan 29 15:35:22 2011
From: report at bugs.python.org (R. David Murray)
Date: Sat, 29 Jan 2011 14:35:22 +0000
Subject: [issue9124] Mailbox module should use binary I/O, not text I/O
In-Reply-To: <1277900903.38.0.556015912714.issue9124@psf.upfronthosting.co.za>
Message-ID: <1296311722.73.0.607720444594.issue9124@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Victor: yes, I was thinking that when I added that comment but forgot to come back to it.  Thanks for spotting that.

Another thing I forgot about yesterday is that I activated the commented out statements that do linesep transformations on the binary file data.  I'm guessing those were commented out when the module was converted to using text files, since the text file would do the transformation itself.  Your patch left them commented out, and the tests passed on Windows.  If the tests *still* pass on windows with them uncommented, then that will prove that, like the old email tests, the line ending variations aren't really being tested.

But, the important thing here is that I haven't run the tests on Windows yet, and that certainly needs to be done.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9124>
_______________________________________

From report at bugs.python.org  Sat Jan 29 15:40:16 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 29 Jan 2011 14:40:16 +0000
Subject: [issue10845] test_multiprocessing failure under Windows
In-Reply-To: <1294309581.41.0.731804987161.issue10845@psf.upfronthosting.co.za>
Message-ID: <1296312016.61.0.227321290687.issue10845@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

"Useless" is a rather strong word. Every change we've made to the import system (or, more accurately, the main module identification system) has been backed up with decent use cases - nearly all of the subsequent problems can be traced back to the information that gets thrown away due to the backwards compatibility concerns that forced the main module to always be called "__main__" without any record of its real name.

In the current case, it is the 3-way combination of that behaviour with the lack of real fork() functionality on Windows and an invalid assumption in multiprocessing as to the relationship between __file__ and __name__ that is causing problems.

Back on topic, Antoine's tweak looks very similar to the solution I was working on (although I hadn't made it as far as figuring out the need to change test/__main__.py to skip the execution of the top level code).

Seeing the need for that change, I think the right answer is actually to skip the find_module/load_module call completely when the module is a file called __main__.py. Such modules are implicitly part of a "if __name__ == '__main__'" clause, as that's their whole reason for existence.

The attached patch works along those lines, and I tested it by making the substantive change (the additional if clause) to an installed copy of 3.2rc1 on my Windows gaming rig.

----------
keywords: +patch
Added file: http://bugs.python.org/file20601/issue10845_mitigation.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10845>
_______________________________________

From report at bugs.python.org  Sat Jan 29 15:41:05 2011
From: report at bugs.python.org (Giampaolo Rodola')
Date: Sat, 29 Jan 2011 14:41:05 +0000
Subject: [issue11049] add tests for test.support
In-Reply-To: <1296241531.97.0.670133219758.issue11049@psf.upfronthosting.co.za>
Message-ID: <1296312065.6.0.276350685534.issue11049@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

> * class TestCase(unittest.TestCase): -> why not give the test class a 
> more useful name?

done

> * import_fresh_module is tested similarly to import_module - can't a 
> test be added that it indeed performs its "special sauce"?

Even by reading the source code I'm not sure what import_fresh_module does exactly.
Feel free to write a test for it if you want.

> * test_DirsOnSysPath: you may want to use assertIn and assertNotIn here. [these 
> were added to Python in 3.1]

done

> * test_python_is_optimized: you may want to use assertIsInstance here.

done

> +        os.mkdir(os.path.join(TESTFN, TESTFN))
> Please don't. This will break the day TESTFN becomes a non-trivial path.

done

> You should also check that the errno is EBADF.

Done. I just hope it's gonna be reliable on all platforms.

----------
Added file: http://bugs.python.org/file20602/test_support.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11049>
_______________________________________

From report at bugs.python.org  Sat Jan 29 15:42:50 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 29 Jan 2011 14:42:50 +0000
Subject: [issue10845] test_multiprocessing failure under Windows
In-Reply-To: <1294309581.41.0.731804987161.issue10845@psf.upfronthosting.co.za>
Message-ID: <1296312170.19.0.631173550061.issue10845@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

(Replaced patch file to fix a typo in a comment)

----------
Added file: http://bugs.python.org/file20603/issue10845_mitigation.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10845>
_______________________________________

From report at bugs.python.org  Sat Jan 29 15:42:57 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 29 Jan 2011 14:42:57 +0000
Subject: [issue10845] test_multiprocessing failure under Windows
In-Reply-To: <1294309581.41.0.731804987161.issue10845@psf.upfronthosting.co.za>
Message-ID: <1296312177.39.0.621418271639.issue10845@psf.upfronthosting.co.za>


Changes by Nick Coghlan <ncoghlan at gmail.com>:


Removed file: http://bugs.python.org/file20601/issue10845_mitigation.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10845>
_______________________________________

From report at bugs.python.org  Sat Jan 29 15:48:35 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 29 Jan 2011 14:48:35 +0000
Subject: [issue10845] test_multiprocessing failure under Windows
In-Reply-To: <1294309581.41.0.731804987161.issue10845@psf.upfronthosting.co.za>
Message-ID: <1296312515.62.0.571966754834.issue10845@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Georg, it would be very good to have this fix in for RC2. Otherwise any use of multiprocessing in conjunction with zipfile, package or directory execution will fail on Windows in 3.2.

----------
assignee:  -> georg.brandl
priority: critical -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10845>
_______________________________________

From report at bugs.python.org  Sat Jan 29 15:53:00 2011
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 29 Jan 2011 14:53:00 +0000
Subject: [issue10845] test_multiprocessing failure under Windows
In-Reply-To: <1294309581.41.0.731804987161.issue10845@psf.upfronthosting.co.za>
Message-ID: <1296312780.31.0.080450289087.issue10845@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

With issue10845_mitigation.diff applied, Antoine's patch is no longer necessary?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10845>
_______________________________________

From report at bugs.python.org  Sat Jan 29 15:53:47 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 29 Jan 2011 14:53:47 +0000
Subject: [issue10845] test_multiprocessing failure under Windows
In-Reply-To: <1296312170.19.0.631173550061.issue10845@psf.upfronthosting.co.za>
Message-ID: <1296312824.3687.5.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> (Replaced patch file to fix a typo in a comment)

Does that patch still work if the objects marshalled between parent and
child refer to classes living in the __main__.py module?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10845>
_______________________________________

From report at bugs.python.org  Sat Jan 29 15:55:44 2011
From: report at bugs.python.org (Godefroid Chapelle)
Date: Sat, 29 Jan 2011 14:55:44 +0000
Subject: [issue11060] distutils2 sdist does not complain about version that is
	not PEP 386 compliant
In-Reply-To: <1296312944.75.0.70099754625.issue11060@psf.upfronthosting.co.za>
Message-ID: <1296312944.75.0.70099754625.issue11060@psf.upfronthosting.co.za>


New submission from Godefroid Chapelle <gotcha at bubblenet.be>:

sdist does not complain about 

version = 0.4.5dev

which is not PEP 386 compliant

----------
assignee: tarek
components: Distutils2
messages: 127425
nosy: eric.araujo, gotcha, tarek
priority: normal
severity: normal
status: open
title: distutils2 sdist does not complain about version that is not PEP 386 compliant

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11060>
_______________________________________

From report at bugs.python.org  Sat Jan 29 16:02:31 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 29 Jan 2011 15:02:31 +0000
Subject: [issue10845] test_multiprocessing failure under Windows
In-Reply-To: <1294309581.41.0.731804987161.issue10845@psf.upfronthosting.co.za>
Message-ID: <1296313351.92.0.280470596608.issue10845@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

__main__.py files aren't like ordinary modules - they should *not* be defining classes or anything like that. Instead, they should be treated as if the entire file was implicitly inside an "if __name__ == '__main__':" clause - when "imported" they don't do anything.

That's why Antoine's patch set off alarm bells in my head - no normal __main__.py will include an explicit "if __name__ == '__main__':" check, so multiprocessing should just skip the file completely instead.

There's no doubt that either approach is a hack that will sometimes fail to work, but I think skipping the file execution completely will be the right decision most of the time (and we can easily say "don't do that then" if people rely on class definitions in __main__.py files).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10845>
_______________________________________

From report at bugs.python.org  Sat Jan 29 16:04:56 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 29 Jan 2011 15:04:56 +0000
Subject: [issue10845] test_multiprocessing failure under Windows
In-Reply-To: <1294309581.41.0.731804987161.issue10845@psf.upfronthosting.co.za>
Message-ID: <1296313496.67.0.341012164411.issue10845@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

To answer Antoine's question directly:

With the patch, it works just as well as multiprocessing on Windows currently does if the objects marshalled between parent and
child refer to classes defined inside a "if __name__ == '__main__':" clause in the main module (i.e. it doesn't, but that isn't really multiprocessing's fault)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10845>
_______________________________________

From report at bugs.python.org  Sat Jan 29 16:10:17 2011
From: report at bugs.python.org (Sebastien Douche)
Date: Sat, 29 Jan 2011 15:10:17 +0000
Subject: [issue11037] State of PEP 382 or How does distutils2 handle
	namespaces?
In-Reply-To: <1296210890.87.0.618097241127.issue11037@psf.upfronthosting.co.za>
Message-ID: <1296313817.56.0.313929598348.issue11037@psf.upfronthosting.co.za>


Sebastien Douche <sdouche at gmail.com> added the comment:

Thanks Martin for the response, but I cannot understand how implement it after reading the PEP.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11037>
_______________________________________

From report at bugs.python.org  Sat Jan 29 16:14:30 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 29 Jan 2011 15:14:30 +0000
Subject: [issue11037] How does distutils2 handle namespaces?
In-Reply-To: <1296210890.87.0.618097241127.issue11037@psf.upfronthosting.co.za>
Message-ID: <1296314070.11.0.710733192204.issue11037@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Hi S?bastien.  How does d2 handle namespaces?  It does not, because such a thing does not exist yet.  We don?t support setuptools? namespace packages, but wait for the cleaned-up standardization thanks to to PEP 382.  That PEP hasn?t reached consensus yet, so it?s too early to implement it.  If that answers your question, I think I?ll close this bug: There?s nothing we can do now, and when PEP 382 is accepted, support will be added to d2.

----------
title: State of PEP 382 or How does distutils2 handle namespaces? -> How does distutils2 handle namespaces?
versions: +3rd party

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11037>
_______________________________________

From report at bugs.python.org  Sat Jan 29 16:15:29 2011
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Sat, 29 Jan 2011 15:15:29 +0000
Subject: [issue11037] How does distutils2 handle namespaces?
In-Reply-To: <1296210890.87.0.618097241127.issue11037@psf.upfronthosting.co.za>
Message-ID: <1296314129.31.0.878817573557.issue11037@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

Yes me neither. The PEP is hard to understand, maybe a pseudo-code example could shed some light

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11037>
_______________________________________

From report at bugs.python.org  Sat Jan 29 16:18:32 2011
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Sat, 29 Jan 2011 15:18:32 +0000
Subject: [issue11037] How does distutils2 handle namespaces?
In-Reply-To: <1296210890.87.0.618097241127.issue11037@psf.upfronthosting.co.za>
Message-ID: <1296314312.7.0.894368214555.issue11037@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

Eric: the PEP was accepted already IIRC, and its status is not up-to-date.

So it's just a matter of adding the implementation now. This bug can be a placeholder for its implementation if no other bug was opened for this yet

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11037>
_______________________________________

From report at bugs.python.org  Sat Jan 29 16:19:41 2011
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Sat, 29 Jan 2011 15:19:41 +0000
Subject: [issue11037] Implementing PEP 382
In-Reply-To: <1296210890.87.0.618097241127.issue11037@psf.upfronthosting.co.za>
Message-ID: <1296314381.2.0.443485291126.issue11037@psf.upfronthosting.co.za>


Changes by Tarek Ziad? <ziade.tarek at gmail.com>:


----------
title: How does distutils2 handle namespaces? -> Implementing PEP 382

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11037>
_______________________________________

From report at bugs.python.org  Sat Jan 29 16:20:55 2011
From: report at bugs.python.org (Sebastien Douche)
Date: Sat, 29 Jan 2011 15:20:55 +0000
Subject: [issue11061] Verify command option before parsing config file
In-Reply-To: <1296314455.37.0.770288704329.issue11061@psf.upfronthosting.co.za>
Message-ID: <1296314455.37.0.770288704329.issue11061@psf.upfronthosting.co.za>


New submission from Sebastien Douche <sdouche at gmail.com>:

Distutils2 verify command (like sdist) when he use it. A small optimization is add the verification step at launch.

----------
assignee: tarek
components: Distutils2
messages: 127432
nosy: eric.araujo, sdouche, tarek
priority: normal
severity: normal
status: open
title: Verify command option before parsing config file
type: behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11061>
_______________________________________

From mal at egenix.com  Fri Jan 28 10:29:31 2011
From: mal at egenix.com (M.-A. Lemburg)
Date: Fri, 28 Jan 2011 10:29:31 +0100
Subject: [issue11022] locale.setlocale() doesn't change I/O codec,
	os.environ
In-Reply-To: <1296167575.93.0.54037501928.issue11022@psf.upfronthosting.co.za>
References: <1296167575.93.0.54037501928.issue11022@psf.upfronthosting.co.za>
Message-ID: <4D428C7B.9050106@egenix.com>

STINNER Victor wrote:
> 
> STINNER Victor <victor.stinner at haypocalc.com> added the comment:
> 
>> upon program startup, init LibC environment: setlocale(LC_ALL, "");
> 
> Python 3 does something like that: Py_InitializeEx() calls setlocale(LC_CTYPE, ""). But I (and others) consider that as a bug (see #6203 discussion): Python should not do that (nor any library) implicitly, but a *program* can do that (once) at startup (explicitly).

Agreed. See the discussion on the ticket for more details.

setlocale() should only be called by applications, not by libraries.
For Python this means: calling it in main() is fine, but not
in Py_InitializeEx().

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Jan 28 2011)
>>> Python/Zope Consulting and Support ...        http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ...             http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/
________________________________________________________________________

::: Try our new mxODBC.Connect Python Database Interface for free ! ::::


   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
    D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
           Registered at Amtsgericht Duesseldorf: HRB 46611
               http://www.egenix.com/company/contact/

From report at bugs.python.org  Sat Jan 29 17:06:55 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 29 Jan 2011 16:06:55 +0000
Subject: [issue11057] Missing import of DistutilsOptionError
In-Reply-To: <1296297501.69.0.98662936413.issue11057@psf.upfronthosting.co.za>
Message-ID: <1296317215.93.0.2971391911.issue11057@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Fixed two NameErrors in that file in 801c90825cc1, thanks.

----------
assignee: tarek -> eric.araujo
resolution:  -> fixed
stage:  -> committed/rejected
versions: +3rd party -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11057>
_______________________________________

From report at bugs.python.org  Sat Jan 29 17:19:36 2011
From: report at bugs.python.org (R. David Murray)
Date: Sat, 29 Jan 2011 16:19:36 +0000
Subject: [issue11062] mailbox fails to round-trip a file to a Babyl mailbox
In-Reply-To: <1296317976.28.0.825353703674.issue11062@psf.upfronthosting.co.za>
Message-ID: <1296317976.28.0.825353703674.issue11062@psf.upfronthosting.co.za>


New submission from R. David Murray <rdmurray at bitdance.com>:

One of the new tests introduced for #9124 fails for the Bably mailbox format.  The failing tests pass a file to the add method (test_add_binary_file, test_add_nonascii_binary_file, test_add_text_file_warns).  The failing part of the tests have been temporarily disabled for the Bably mailbox format since it is a pre-existing, unreported bug.

----------
components: Library (Lib)
keywords: easy
messages: 127434
nosy: r.david.murray
priority: normal
severity: normal
stage: needs patch
status: open
title: mailbox fails to round-trip a file to a Babyl mailbox
type: behavior
versions: Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11062>
_______________________________________

From report at bugs.python.org  Sat Jan 29 17:19:53 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 29 Jan 2011 16:19:53 +0000
Subject: [issue10932] distutils.core.setup - data_files misbehaviour ?
In-Reply-To: <1295353825.23.0.755300594789.issue10932@psf.upfronthosting.co.za>
Message-ID: <1296317993.36.0.521977899806.issue10932@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Thanks for the patch.  Would you like to complete it?  It lacks tests, and I think the fix may be in the wrong place: You fixed sdist but not bdists.  I think the root of the problem is in the manifest (distutils2) / filelist (distutils1) module.

(We want to fix bugs in distutils2 first and then backport them to d1, as explained in the short guidelines I linked to in msg126545, which I advise you to read.)

----------
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10932>
_______________________________________

From report at bugs.python.org  Sat Jan 29 17:32:14 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 29 Jan 2011 16:32:14 +0000
Subject: [issue11042] [PyPI CSS] Adding project urls onto a project page using
	register, apparition of an overhead over the title
In-Reply-To: <1296215178.29.0.349266521718.issue11042@psf.upfronthosting.co.za>
Message-ID: <1296318734.37.0.626257516344.issue11042@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

This tracker is for bugs found in the CPython distribution (or distutils2, which is temporarily developed outside of it), not other codebases like PyPI or the tracker itself.  Your bug report will be welcome on the catalog-sig at python.org mailing list, especially if you can provide a patch (instructions on http://wiki.python.org/moin/CheeseShopDev).

----------
assignee: tarek -> 
nosy:  -tarek, tarek-ziade
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11042>
_______________________________________

From report at bugs.python.org  Sat Jan 29 17:33:55 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 29 Jan 2011 16:33:55 +0000
Subject: [issue10939] imaplib: Internaldate2tuple raises KeyError parsing
	month and does not work with negative TZ offset due to
	bytes/str issues
In-Reply-To: <1295389900.99.0.76199090445.issue10939@psf.upfronthosting.co.za>
Message-ID: <1296318835.54.0.0585969883369.issue10939@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Attached patch fixes the test (hopefully we don't have to support systems with non-POSIX epoch) and cleans up whitespace.

----------
resolution:  -> accepted
stage: patch review -> commit review
Added file: http://bugs.python.org/file20604/issue10939.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10939>
_______________________________________

From report at bugs.python.org  Sat Jan 29 17:34:35 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 29 Jan 2011 16:34:35 +0000
Subject: [issue10939] imaplib: Internaldate2tuple raises KeyError parsing
	month and does not work with negative TZ offset due to
	bytes/str issues
In-Reply-To: <1295389900.99.0.76199090445.issue10939@psf.upfronthosting.co.za>
Message-ID: <1296318875.16.0.434746557844.issue10939@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


Removed file: http://bugs.python.org/file20604/issue10939.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10939>
_______________________________________

From report at bugs.python.org  Sat Jan 29 17:35:35 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 29 Jan 2011 16:35:35 +0000
Subject: [issue10939] imaplib: Internaldate2tuple raises KeyError parsing
	month and does not work with negative TZ offset due to
	bytes/str issues
In-Reply-To: <1295389900.99.0.76199090445.issue10939@psf.upfronthosting.co.za>
Message-ID: <1296318935.39.0.55856001451.issue10939@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


Added file: http://bugs.python.org/file20605/issue10939.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10939>
_______________________________________

From report at bugs.python.org  Sat Jan 29 17:35:52 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 29 Jan 2011 16:35:52 +0000
Subject: [issue11044] The description-file isn't handled by distutils2
In-Reply-To: <1296216054.85.0.726988451009.issue11044@psf.upfronthosting.co.za>
Message-ID: <1296318952.49.0.387949371981.issue11044@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Probably fixed by Ga?l in changeset c8dfb3c63894.  (BTW, please never use local revision numbers for Mercurial, they?re confusing.)

----------
resolution: out of date -> fixed
stage:  -> committed/rejected

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11044>
_______________________________________

From report at bugs.python.org  Sat Jan 29 17:38:29 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 29 Jan 2011 16:38:29 +0000
Subject: [issue11040] After registering a project to PyPI,
	classifiers fields aren't displayed.
In-Reply-To: <1296214289.89.0.718507704088.issue11040@psf.upfronthosting.co.za>
Message-ID: <1296319109.06.0.310602215757.issue11040@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Please report this to catalog-sig.

----------
assignee: tarek -> 
components:  -Distutils2
nosy: +eric.araujo
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed
type: behavior -> 
versions:  -3rd party

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11040>
_______________________________________

From report at bugs.python.org  Sat Jan 29 17:43:19 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 29 Jan 2011 16:43:19 +0000
Subject: [issue11038] Some commands should stop if Name and Version are missing
In-Reply-To: <1296211155.96.0.0798615868084.issue11038@psf.upfronthosting.co.za>
Message-ID: <1296319399.55.0.317223458646.issue11038@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Thanks for the report and fix (da2f3527ef02).  I think you wanted to use a global object to list required fields, but you defined it without using it:

_345_REQUIRED = ('Name', 'Version')
[...]
-        for attr in ('Name', 'Version', 'Home-page'):
+
+        for attr in ('Name', 'Version'):

----------
assignee: tarek -> eric.araujo
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
type: feature request -> behavior
versions: +3rd party

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11038>
_______________________________________

From report at bugs.python.org  Sat Jan 29 17:53:48 2011
From: report at bugs.python.org (And Clover)
Date: Sat, 29 Jan 2011 16:53:48 +0000
Subject: [issue2193] Cookie Colon Name Bug
In-Reply-To: <1203992843.27.0.867127322082.issue2193@psf.upfronthosting.co.za>
Message-ID: <1296320028.41.0.156383470149.issue2193@psf.upfronthosting.co.za>


And Clover <and at doxdesk.com> added the comment:

@carsten.klein: there is no such thing as an ?original RFC?. The RFCs that have been produced on the subject of cookies, 2109 and 2965, were drawn up long after user-agents implemented cookies. Their attempts to clean up the warts of cookies and implement new features have completely failed. Their strictures are not obeyed by user agents; they are irrelevant and should not be used as the basis for any server-side cookie implementation.

The nearest to an original standard for cookies is the Netscape cookie-spec (see eg http://curl.haxx.se/rfc/cookie_spec.html), which is far too woolly to really count as a real specification, but which allows all but `;`, `,` and space, and in practice browsers do typically allow all characters that do not already serve as delimiters. Python should be liberal in what it accepts.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2193>
_______________________________________

From report at bugs.python.org  Sat Jan 29 18:11:00 2011
From: report at bugs.python.org (Keith Dart)
Date: Sat, 29 Jan 2011 17:11:00 +0000
Subject: [issue11063] uuid.py module import has heavy side effects
In-Reply-To: <1296321060.32.0.846037411239.issue11063@psf.upfronthosting.co.za>
Message-ID: <1296321060.32.0.846037411239.issue11063@psf.upfronthosting.co.za>


New submission from Keith Dart <keith.dart at gmail.com>:

When the uuid.py module is simply imported it has the side effect of forking a subprocess (/sbin/ldconfig) and doing a lot of stuff find a uuid implementation by ctypes. This is undesirable in many contexts. It would be better to perform those tasks on demand, when the first UUID is actually requested. In general, imports should avoid unnecessary system call side effects. This also makes testing easier.

----------
components: Library (Lib)
messages: 127442
nosy: Keith.Dart
priority: normal
severity: normal
status: open
title: uuid.py module import has heavy side effects
type: resource usage
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11063>
_______________________________________

From report at bugs.python.org  Sat Jan 29 18:17:43 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 29 Jan 2011 17:17:43 +0000
Subject: [issue11037] Implementing PEP 382
In-Reply-To: <1296210890.87.0.618097241127.issue11037@psf.upfronthosting.co.za>
Message-ID: <1296321463.54.0.647870896667.issue11037@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

This message makes me think it is not accepted: http://mail.python.org/pipermail/python-dev/2010-May/100457.html

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11037>
_______________________________________

From report at bugs.python.org  Sat Jan 29 18:19:38 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 29 Jan 2011 17:19:38 +0000
Subject: [issue10939] imaplib: Internaldate2tuple raises KeyError parsing
	month and does not work with negative TZ offset due to
	bytes/str issues
In-Reply-To: <1295389900.99.0.76199090445.issue10939@psf.upfronthosting.co.za>
Message-ID: <1296321578.14.0.640073790207.issue10939@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Committed in revision 88231.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10939>
_______________________________________

From report at bugs.python.org  Sat Jan 29 18:20:01 2011
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 29 Jan 2011 17:20:01 +0000
Subject: [issue10845] test_multiprocessing failure under Windows
In-Reply-To: <1294309581.41.0.731804987161.issue10845@psf.upfronthosting.co.za>
Message-ID: <1296321601.42.0.00350273208503.issue10845@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Looks like Antoine agreed, so this should be fine to go in.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10845>
_______________________________________

From report at bugs.python.org  Sat Jan 29 18:25:46 2011
From: report at bugs.python.org (R. David Murray)
Date: Sat, 29 Jan 2011 17:25:46 +0000
Subject: [issue9124] Mailbox module should use binary I/O, not text I/O
In-Reply-To: <1277900903.38.0.556015912714.issue9124@psf.upfronthosting.co.za>
Message-ID: <1296321946.36.0.123499479928.issue9124@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

OK, I've added deprecation warnings for using StringIO or text mode files as input.  I found one bug thereby, but it is a bug that pre-existed the patch (see issue 11062).  

I've completed my code review.

To address Victor's question about the mh-sequences file: nmh rejects non-ascii sequence names, so the file should contain only ASCII.  The man page specifies that sequences are composed only of alphanumeric characters.  I think opening the file in text mode using the system default encoding is probably fine, since if any mh program does support non-ascii sequence names that is likely what it would do as well.  Of course, in the future I would think utf-8 would be preferred, but I guess we can deal with that issue if we get a bug report.  We're maintaining backward compatibility with 3.1 here, so it's not really an issue for this patch.  As far as the 'if bytes' business goes, the tests pass for me without those lines, and it looks to me like they should not be needed.  On IRC Victor said he thought he may have introduced those before the patch was finished.  We have decided to omit them.

I think I've address the remainder of Victor's issues already.

The last step is running the tests on Windows.  Attached is the updated patch.

----------
Added file: http://bugs.python.org/file20606/mailbox4.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9124>
_______________________________________

From report at bugs.python.org  Sat Jan 29 18:30:57 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 29 Jan 2011 17:30:57 +0000
Subject: [issue11036] Allow multiple files in the description-file metadata
In-Reply-To: <1296210652.15.0.670840085537.issue11036@psf.upfronthosting.co.za>
Message-ID: <1296322257.03.0.561271671019.issue11036@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

+1, this was agreed upon last summer: https://bitbucket.org/Merwok/sample-distutils2-project/src/tip/new-config-file.rst#cl-255 (see also fellowship archive).  Fixed by Ga?l in c8dfb3c63894.

----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11036>
_______________________________________

From report at bugs.python.org  Sat Jan 29 18:35:30 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 29 Jan 2011 17:35:30 +0000
Subject: [issue11025] Distutils2 install command without setup.py or setup.cfg
	create an UNKNOWN-UNKNOWN.dist-info distribution
In-Reply-To: <1296137822.54.0.488417839066.issue11025@psf.upfronthosting.co.za>
Message-ID: <1296322530.73.0.660703445617.issue11025@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Closing as duplicate, please comment on the other bug report if the unwanted behavior is still here.

----------
nosy:  -tarek, tarek-ziade
resolution:  -> duplicate
stage:  -> committed/rejected
status: open -> closed
superseder:  -> Some commands should stop if Name and Version are missing
versions: +3rd party -Python 2.5, Python 2.6, Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11025>
_______________________________________

From report at bugs.python.org  Sat Jan 29 18:38:12 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 29 Jan 2011 17:38:12 +0000
Subject: [issue10639] reindent.py converts newlines to platform default
In-Reply-To: <1291653413.79.0.461728889357.issue10639@psf.upfronthosting.co.za>
Message-ID: <1296322692.45.0.712653390955.issue10639@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I?m not opposed to reindent normalizing EOLs, given that our VCS hooks will translate them to the right thing (for example, making sure that files specific to the Windows build use CRLF, not LF, even if edited on POSIX).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10639>
_______________________________________

From report at bugs.python.org  Sat Jan 29 18:41:03 2011
From: report at bugs.python.org (Pavel Labushev)
Date: Sat, 29 Jan 2011 17:41:03 +0000
Subject: [issue11048] "import ctypes" causes segfault on read-only filesystem
In-Reply-To: <1296234309.62.0.290829997988.issue11048@psf.upfronthosting.co.za>
Message-ID: <1296322863.33.0.627796347149.issue11048@psf.upfronthosting.co.za>


Pavel Labushev <p.labushev at gmail.com> added the comment:

How to reproduce:

# mkdir /mnt/readonly
# mount --bind / /mnt/readonly
# mount -o remount,ro /mnt/readonly
# mount -t proc proc /mnt/readonly/proc
# chroot /mnt/readonly python3.2 -c "import ctypes"
Segmentation fault

If your python build expected to have this bug, you'll see something like this (the -1 EROFS lines):

# chroot /mnt/readonly strace -f -e trace=open python3.2 -c "import ctypes" 2>&1 | grep ffi
open("/usr/lib/libffi.so.5", O_RDONLY)  = 5
open("/tmp/.private/root/ffiicoh8G", O_RDWR|O_CREAT|O_EXCL, 0600) = -1 ENOENT (No such file or directory)
open("/tmp/ffiFjqUa9", O_RDWR|O_CREAT|O_EXCL, 0600) = -1 EROFS (Read-only file system)
open("/var/tmp/ffidTdydB", O_RDWR|O_CREAT|O_EXCL, 0600) = -1 EROFS (Read-only file system)
open("/dev/shm/ffiemIcg3", O_RDWR|O_CREAT|O_EXCL, 0600) = -1 EROFS (Read-only file system)
open("/root/ffiXfWRiv", O_RDWR|O_CREAT|O_EXCL, 0600) = -1 EROFS (Read-only file system)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11048>
_______________________________________

From report at bugs.python.org  Sat Jan 29 18:42:49 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 29 Jan 2011 17:42:49 +0000
Subject: [issue11045] shutil._make_tarball
In-Reply-To: <1296222490.15.0.786706157889.issue11045@psf.upfronthosting.co.za>
Message-ID: <1296322969.81.0.254754163574.issue11045@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/issue11045>
_______________________________________

From report at bugs.python.org  Sat Jan 29 18:46:04 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 29 Jan 2011 17:46:04 +0000
Subject: [issue11047] Bad description for an entry in whatsnew/2.7
In-Reply-To: <1296233608.02.0.630598474753.issue11047@psf.upfronthosting.co.za>
Message-ID: <1296323164.41.0.241056561872.issue11047@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +barry, brett.cannon, flox, gangesmaster, loewis, meador.inge
title: Bad description for a change -> Bad description for an entry in whatsnew/2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11047>
_______________________________________

From report at bugs.python.org  Sat Jan 29 18:48:28 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 29 Jan 2011 17:48:28 +0000
Subject: [issue11023] pep 227 missing text
In-Reply-To: <1296134235.25.0.738218358402.issue11023@psf.upfronthosting.co.za>
Message-ID: <1296323308.18.0.244676443698.issue11023@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

This tracker is for reporting bugs found in the CPython distribution, not PEPs, PyPI or other websites.  You can write to the python-dev mailing list if the XXX bother you.

----------
assignee: docs at python -> 
components:  -Documentation
nosy: +eric.araujo -docs at python
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed
type: feature request -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11023>
_______________________________________

From report at bugs.python.org  Sat Jan 29 18:49:48 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 29 Jan 2011 17:49:48 +0000
Subject: [issue11057] Missing import of DistutilsOptionError
In-Reply-To: <1296297501.69.0.98662936413.issue11057@psf.upfronthosting.co.za>
Message-ID: <1296323388.28.0.914436093126.issue11057@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11057>
_______________________________________

From report at bugs.python.org  Sat Jan 29 18:53:07 2011
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sat, 29 Jan 2011 17:53:07 +0000
Subject: [issue11063] uuid.py module import has heavy side effects
In-Reply-To: <1296321060.32.0.846037411239.issue11063@psf.upfronthosting.co.za>
Message-ID: <1296323587.28.0.481169590579.issue11063@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/issue11063>
_______________________________________

From report at bugs.python.org  Sat Jan 29 19:08:43 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 29 Jan 2011 18:08:43 +0000
Subject: [issue11058] dist directory not created when running sdist command
In-Reply-To: <1296300421.59.0.468968378526.issue11058@psf.upfronthosting.co.za>
Message-ID: <1296324523.9.0.904128925638.issue11058@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

The warnings mean that some code is iterating over the string 'setup.py' instead of a list like ['setup.py'].  This message comes from the manifest module, but I don?t know more.

Regarding the bug and proposed patch, I wonder.  This was not needed previously, so why is it now?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11058>
_______________________________________

From report at bugs.python.org  Sat Jan 29 19:08:52 2011
From: report at bugs.python.org (Dustin Farris)
Date: Sat, 29 Jan 2011 18:08:52 +0000
Subject: [issue11064] abc documentation version conflict
In-Reply-To: <1296324532.36.0.0952185002021.issue11064@psf.upfronthosting.co.za>
Message-ID: <1296324532.36.0.0952185002021.issue11064@psf.upfronthosting.co.za>


New submission from Dustin Farris <dustin.farris at gmail.com>:

Running help(abc) in Python 2.6.1 displays syntax for Py3k.

----------
assignee: docs at python
components: Documentation
messages: 127453
nosy: docs at python, dustin.farris
priority: normal
severity: normal
status: open
title: abc documentation version conflict
type: behavior
versions: Python 2.6, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11064>
_______________________________________

From report at bugs.python.org  Sat Jan 29 19:11:28 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 29 Jan 2011 18:11:28 +0000
Subject: [issue11064] abc documentation version conflict
In-Reply-To: <1296324532.36.0.0952185002021.issue11064@psf.upfronthosting.co.za>
Message-ID: <1296324688.69.0.734041634177.issue11064@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Not for me:
     |      class C:
     |          __metaclass__ = ABCMeta
     |          @abstractproperty

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11064>
_______________________________________

From report at bugs.python.org  Sat Jan 29 19:14:08 2011
From: report at bugs.python.org (Dustin Farris)
Date: Sat, 29 Jan 2011 18:14:08 +0000
Subject: [issue11064] abc documentation version conflict
In-Reply-To: <1296324532.36.0.0952185002021.issue11064@psf.upfronthosting.co.za>
Message-ID: <1296324848.67.0.145026906547.issue11064@psf.upfronthosting.co.za>


Dustin Farris <dustin.farris at gmail.com> added the comment:

This is what I get:


Python 2.6.1 (r261:67515, Jun 24 2010, 21:47:49) 
[GCC 4.2.1 (Apple Inc. build 5646)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import abc
>>> help(abc)

NAME
    abc - Abstract Base Classes (ABCs) according to PEP 3119.

FILE
    /System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/abc.py


.....


|  Usage:
     |  
     |      class C(metaclass=ABCMeta):
     |          @abstractproperty
     |          def my_abstract_property(self):
     |              ...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11064>
_______________________________________

From report at bugs.python.org  Sat Jan 29 19:14:22 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 29 Jan 2011 18:14:22 +0000
Subject: [issue11061] Verify command option before parsing config file
In-Reply-To: <1296314455.37.0.770288704329.issue11061@psf.upfronthosting.co.za>
Message-ID: <1296324862.61.0.405106934569.issue11061@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I?m afraid I don?t understand your report.

----------
versions: +3rd party

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11061>
_______________________________________

From report at bugs.python.org  Sat Jan 29 19:15:26 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 29 Jan 2011 18:15:26 +0000
Subject: [issue11064] abc documentation version conflict
In-Reply-To: <1296324532.36.0.0952185002021.issue11064@psf.upfronthosting.co.za>
Message-ID: <1296324926.99.0.611291205229.issue11064@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Can you reproduce with 2.6.6?

----------
assignee: docs at python -> 
components: +Library (Lib) -Documentation
nosy:  -docs at python
versions:  -Python 2.6, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11064>
_______________________________________

From report at bugs.python.org  Sat Jan 29 19:18:20 2011
From: report at bugs.python.org (Dustin Farris)
Date: Sat, 29 Jan 2011 18:18:20 +0000
Subject: [issue11064] abc documentation version conflict
In-Reply-To: <1296324532.36.0.0952185002021.issue11064@psf.upfronthosting.co.za>
Message-ID: <1296325100.44.0.325876479699.issue11064@psf.upfronthosting.co.za>


Dustin Farris <dustin.farris at gmail.com> added the comment:

Negative.

2.6.6 is correct.  Apologies.

----------
resolution:  -> rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11064>
_______________________________________

From report at bugs.python.org  Sat Jan 29 19:18:41 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 29 Jan 2011 18:18:41 +0000
Subject: [issue9124] Mailbox module should use binary I/O, not text I/O
In-Reply-To: <1277900903.38.0.556015912714.issue9124@psf.upfronthosting.co.za>
Message-ID: <1296325121.04.0.278530206682.issue9124@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> The last step is running the tests on Windows.
> Attached is the updated patch.

mailbox4.patch doesn't pass on Windows, Raymond is working on a patch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9124>
_______________________________________

From report at bugs.python.org  Sat Jan 29 19:20:08 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 29 Jan 2011 18:20:08 +0000
Subject: [issue11064] abc documentation version conflict
In-Reply-To: <1296324532.36.0.0952185002021.issue11064@psf.upfronthosting.co.za>
Message-ID: <1296325208.88.0.586313981176.issue11064@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

No problem, thanks for wanting to help.  Don?t hesitate to report other bugs you may find in the future, if you find them in the latest versions :)

----------
resolution: rejected -> out of date
stage:  -> committed/rejected

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11064>
_______________________________________

From report at bugs.python.org  Sat Jan 29 19:31:53 2011
From: report at bugs.python.org (Keith Dart)
Date: Sat, 29 Jan 2011 18:31:53 +0000
Subject: [issue11063] uuid.py module import has heavy side effects
In-Reply-To: <1296321060.32.0.846037411239.issue11063@psf.upfronthosting.co.za>
Message-ID: <1296325913.91.0.681978418384.issue11063@psf.upfronthosting.co.za>


Changes by Keith Dart <keith.dart at gmail.com>:


----------
nosy: +kdart

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11063>
_______________________________________

From report at bugs.python.org  Sat Jan 29 19:32:05 2011
From: report at bugs.python.org (Ned Deily)
Date: Sat, 29 Jan 2011 18:32:05 +0000
Subject: [issue10940] IDLE 3.2 hangs with Cmd-M hotkey on OS X 10.6 with
	64-bit installer and A/S Tk 8.5
In-Reply-To: <1295391844.43.0.912463306116.issue10940@psf.upfronthosting.co.za>
Message-ID: <1296325925.32.0.398733380437.issue10940@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Committed in r88232 for 3.2rc2.  Pending 2.7 backport, if necessary.

----------
priority: release blocker -> 
resolution: accepted -> fixed
stage: commit review -> committed/rejected
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10940>
_______________________________________

From report at bugs.python.org  Sat Jan 29 19:37:46 2011
From: report at bugs.python.org (nw)
Date: Sat, 29 Jan 2011 18:37:46 +0000
Subject: [issue11056] 2to3 fails for inner __metaclass__ class definition
In-Reply-To: <1296295646.41.0.555218890155.issue11056@psf.upfronthosting.co.za>
Message-ID: <1296326266.07.0.495777837249.issue11056@psf.upfronthosting.co.za>


Changes by nw <nils.winter at googlemail.com>:


----------
keywords: +patch
Added file: http://bugs.python.org/file20607/fix.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11056>
_______________________________________

From report at bugs.python.org  Sat Jan 29 19:45:10 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 29 Jan 2011 18:45:10 +0000
Subject: [issue10939] imaplib: Internaldate2tuple raises KeyError parsing
	month and does not work with negative TZ offset due to
	bytes/str issues
In-Reply-To: <1295389900.99.0.76199090445.issue10939@psf.upfronthosting.co.za>
Message-ID: <1296326710.15.0.550154520685.issue10939@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Merged to 3.1 in r88233.

----------
nosy: +benjamin.peterson
resolution: accepted -> fixed
stage: commit review -> committed/rejected
versions: +Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10939>
_______________________________________

From report at bugs.python.org  Sat Jan 29 19:45:45 2011
From: report at bugs.python.org (Ned Deily)
Date: Sat, 29 Jan 2011 18:45:45 +0000
Subject: [issue11053] OS X IDLE 3 with Tk 8.4 appears to hang with syntax error
In-Reply-To: <1296271053.35.0.843403013415.issue11053@psf.upfronthosting.co.za>
Message-ID: <1296326745.19.0.366606249115.issue11053@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Committed in r88234 for 3.2rc2.  Pending backport to 3.1.

----------
priority: release blocker -> 
resolution:  -> fixed
stage: commit review -> committed/rejected
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11053>
_______________________________________

From report at bugs.python.org  Sat Jan 29 19:58:05 2011
From: report at bugs.python.org (Ned Deily)
Date: Sat, 29 Jan 2011 18:58:05 +0000
Subject: [issue11054] OS X installer build script for 3.2 can no longer build
	with system Python on OS X 10.5
In-Reply-To: <1296272827.91.0.103223659215.issue11054@psf.upfronthosting.co.za>
Message-ID: <1296327485.72.0.487998045661.issue11054@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Committed in r88235 for 3.2rc2 with release manager approval.
Pending 2.7 backport.

----------
priority: release blocker -> 
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> pending
versions: +Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11054>
_______________________________________

From report at bugs.python.org  Sat Jan 29 20:09:54 2011
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 29 Jan 2011 19:09:54 +0000
Subject: [issue11056] 2to3 fails for inner __metaclass__ class definition
In-Reply-To: <1296295646.41.0.555218890155.issue11056@psf.upfronthosting.co.za>
Message-ID: <1296328194.13.0.752032340137.issue11056@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
assignee:  -> benjamin.peterson
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11056>
_______________________________________

From report at bugs.python.org  Sat Jan 29 20:10:38 2011
From: report at bugs.python.org (karl)
Date: Sat, 29 Jan 2011 19:10:38 +0000
Subject: [issue2193] Cookie Colon Name Bug
In-Reply-To: <1203992843.27.0.867127322082.issue2193@psf.upfronthosting.co.za>
Message-ID: <1296328238.1.0.938505878919.issue2193@psf.upfronthosting.co.za>


karl <karl+pythonbugs at la-grange.net> added the comment:

@aclover
see my comment http://bugs.python.org/issue2193#msg125423
Adam Barth is working for Google on Chrome. 
The RFC being written is made in cooperation with other browser developers.

If you have comments about this RFC you are welcome to add comment on freenode at #whatwg.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2193>
_______________________________________

From report at bugs.python.org  Sat Jan 29 20:12:16 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 29 Jan 2011 19:12:16 +0000
Subject: [issue10975] #10961: Pydoc touchups in new 3.2 Web server
	(issue4090042)
In-Reply-To: <00221532cc70620113049a5fa977@google.com>
Message-ID: <90e6ba6e8cc8dacee9049b00f501@google.com>


?ric Araujo <merwok at netwok.org> added the comment:

XP.
I think Firefox 3.5 is still widely used, maybe older version too.  For
Windows, I guess IE 7 and 8 are used too.  Opera seems to be compliant,
so a good test; on Mac OS X, I understand other browsers are used.

clear="all">&nbsp;</div>'
> at the end of the header.  I think these should be "both" instead of
"all".
> "all" works, but "both" seems to be more correct.
I?m afraid my Web skills are a bit rusty; I don?t know anymore the
various quirks of various browsers and required kludges.  If you?re
making a patch, you should do the research :)

(name, name)
> On 2011/01/21 18:46:01, merwok wrote:
>> I see no reason for polluting the key value with ?.html?

changed
> in 3.3 if it's desirable to do so.

Thinking again about that: The other ?key request you mention have been
added in 3.2, right?  If there is no released version with those
?thing=spam.html request, I repeat my -1 on appending .html.

http://codereview.appspot.com/4090042/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10975>
_______________________________________

From report at bugs.python.org  Sat Jan 29 20:12:30 2011
From: report at bugs.python.org (Ned Batchelder)
Date: Sat, 29 Jan 2011 19:12:30 +0000
Subject: [issue11065] Fatal "can't locate locale" errors when zip file with
	directories is on the PYTHONPATH.
In-Reply-To: <1296328350.27.0.0987051728598.issue11065@psf.upfronthosting.co.za>
Message-ID: <1296328350.27.0.0987051728598.issue11065@psf.upfronthosting.co.za>


New submission from Ned Batchelder <nedbat at users.sourceforge.net>:

Run this shell script against 3.2, and it will fail. Against 3.1, it succeeds. I've been running tests on Ubuntu 10.10.


mkdir -p sub
cat >sub/modzip.py <<END_PY
j = 1
END_PY
zip zipmod.zip sub/modzip.py
PYTHONPATH=zipmod.zip python3 -c "import sys; print(sys.version)"


The failure I get is:

Fatal Python error: Py_Initialize: Unable to get the locale encoding
LookupError: no codec search functions registered: can't find encoding

----------
components: None
messages: 127467
nosy: nedbat
priority: normal
severity: normal
status: open
title: Fatal "can't locate locale" errors when zip file with directories is on the PYTHONPATH.
type: behavior
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11065>
_______________________________________

From report at bugs.python.org  Sat Jan 29 20:14:03 2011
From: report at bugs.python.org (Daniel Urban)
Date: Sat, 29 Jan 2011 19:14:03 +0000
Subject: [issue11048] "import ctypes" causes segfault on read-only filesystem
In-Reply-To: <1296234309.62.0.290829997988.issue11048@psf.upfronthosting.co.za>
Message-ID: <1296328443.59.0.246582726942.issue11048@psf.upfronthosting.co.za>


Daniel Urban <urban.dani+py at gmail.com> added the comment:

Thanks for the instructions. You're right, this way I can reproduce the segfault.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11048>
_______________________________________

From report at bugs.python.org  Sat Jan 29 20:14:11 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 29 Jan 2011 19:14:11 +0000
Subject: [issue10961] Pydoc touchups in new browser for 3.2
In-Reply-To: <1295545738.06.0.604274599052.issue10961@psf.upfronthosting.co.za>
Message-ID: <1296328451.97.0.850888891122.issue10961@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Replied on Rietveld.

Ezio, I think you have good HTML/CSS knowledge, so I?m adding you to nosy.  If you could read the short discussion and Rietveld and weigh in, it would be very helpful.

----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10961>
_______________________________________

From report at bugs.python.org  Sat Jan 29 20:15:38 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 29 Jan 2011 19:15:38 +0000
Subject: [issue10975] #10961: Pydoc touchups in new 3.2 Web server
	(issue4090042)
In-Reply-To: <00221532cc70620113049a5fa977@google.com>
Message-ID: <1296328538.17.0.908665177043.issue10975@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
Removed message: http://bugs.python.org/msg127466

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10975>
_______________________________________

From report at bugs.python.org  Sat Jan 29 20:16:43 2011
From: report at bugs.python.org (Joe Peterson)
Date: Sat, 29 Jan 2011 19:16:43 +0000
Subject: [issue10939] imaplib: Internaldate2tuple raises KeyError parsing
	month and does not work with negative TZ offset due to
	bytes/str issues
In-Reply-To: <1295389900.99.0.76199090445.issue10939@psf.upfronthosting.co.za>
Message-ID: <1296328603.16.0.351457674123.issue10939@psf.upfronthosting.co.za>


Joe Peterson <joe at skyrush.com> added the comment:

Good catch on the test.  Note that for issue 10941, we'll want a new non-timezone-dependent test case that can catch the DST-related problem.  I'll post a new patch to issue 10941 now and describe this some more there.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10939>
_______________________________________

From report at bugs.python.org  Sat Jan 29 20:20:42 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 29 Jan 2011 19:20:42 +0000
Subject: [issue10939] imaplib: Internaldate2tuple raises KeyError parsing
	month and does not work with negative TZ offset due to
	bytes/str issues
In-Reply-To: <1295389900.99.0.76199090445.issue10939@psf.upfronthosting.co.za>
Message-ID: <1296328842.6.0.671261804209.issue10939@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

It looks like my test is not robust enough:

http://www.python.org/dev/buildbot/all/builders/x86%20OpenIndiana%203.1/builds/298

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10939>
_______________________________________

From report at bugs.python.org  Sat Jan 29 20:24:40 2011
From: report at bugs.python.org (R. David Murray)
Date: Sat, 29 Jan 2011 19:24:40 +0000
Subject: [issue9124] Mailbox module should use binary I/O, not text I/O
In-Reply-To: <1277900903.38.0.556015912714.issue9124@psf.upfronthosting.co.za>
Message-ID: <1296329080.85.0.272108662086.issue9124@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

(I hope you meant I was working on a patch :)

Patch is done, but there is one remaining test failure that I'm not sure how to handle.  The test is test_add_text_file_warns.  The code checks to see if a file is a subclass of io.TextIOWrapper, and if so warns that this is deprecated, grabs the buffer attribute, and reads the file as binary.  This works fine, except that in testing it I used a temporary file.  On Linux that works great, but on Windows the temporary file is a tempfile._TemporaryFileWrapper, and that is *not* a subclass of io.TextIOWrapper.  So the code falls through to the "this must be a binary file" code and fails with a TypeError.

Any thoughts on how to handle this edge case?

I've got stuff to do this afternoon but I'll check back later to see if anybody has any ideas and, if all else fails, will disable that test on Windows.  It means the module doesn't handle temporary-text-file input on Windows correctly, but since we are deprecating text files anyway I think that is not a show stopper.

----------
Added file: http://bugs.python.org/file20608/mailbox5.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9124>
_______________________________________

From report at bugs.python.org  Sat Jan 29 20:29:22 2011
From: report at bugs.python.org (Kelsey)
Date: Sat, 29 Jan 2011 19:29:22 +0000
Subject: [issue11045] shutil._make_tarball
In-Reply-To: <1296222490.15.0.786706157889.issue11045@psf.upfronthosting.co.za>
Message-ID: <1296329362.35.0.681415620442.issue11045@psf.upfronthosting.co.za>


Kelsey <kelsey.hightower at gmail.com> added the comment:

Adding patch to ticket

----------
keywords: +patch
Added file: http://bugs.python.org/file20609/check-logger-is-none.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11045>
_______________________________________

From report at bugs.python.org  Sat Jan 29 20:31:53 2011
From: report at bugs.python.org (Ned Deily)
Date: Sat, 29 Jan 2011 19:31:53 +0000
Subject: [issue11052] Fix OS X IDLE menu accelerators for Save As and Save Copy
In-Reply-To: <1296269578.92.0.1087041883.issue11052@psf.upfronthosting.co.za>
Message-ID: <1296329513.55.0.163863817462.issue11052@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Committed in r88236 (with release manager approval) for 3.2rc2, r88237 for 3.1, and r88238 for 2.7.

----------
resolution: accepted -> fixed
stage: commit review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11052>
_______________________________________

From report at bugs.python.org  Sat Jan 29 20:36:21 2011
From: report at bugs.python.org (Ned Batchelder)
Date: Sat, 29 Jan 2011 19:36:21 +0000
Subject: [issue11065] Fatal "can't locate locale" errors when zip file with
	directories is on the PYTHONPATH.
In-Reply-To: <1296328350.27.0.0987051728598.issue11065@psf.upfronthosting.co.za>
Message-ID: <1296329781.64.0.530343597387.issue11065@psf.upfronthosting.co.za>


Ned Batchelder <nedbat at users.sourceforge.net> added the comment:

With help from ned_deily in #python-dev, we confirmed this is a dup of http://bugs.python.org/issue10955, and is already fixed.

----------
resolution:  -> duplicate

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11065>
_______________________________________

From report at bugs.python.org  Sat Jan 29 20:37:19 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 29 Jan 2011 19:37:19 +0000
Subject: [issue11045] shutil._make_tarball
In-Reply-To: <1296222490.15.0.786706157889.issue11045@psf.upfronthosting.co.za>
Message-ID: <1296329839.82.0.100755129087.issue11045@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I?ve checked the code and this is the only place where logger.* is not protected by a check for None.  There is no unit test, though.

My patch adds two things: Make one formatting call lazy (use logging.info(one, two) instead of one % two), lower-case one message for consistent output).  If we want to be ultra-conservative, Kelsey?s patch is to be preferred.

----------
nosy: +georg.brandl
Added file: http://bugs.python.org/file20610/fix-11045.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11045>
_______________________________________

From report at bugs.python.org  Sat Jan 29 20:38:23 2011
From: report at bugs.python.org (Ned Deily)
Date: Sat, 29 Jan 2011 19:38:23 +0000
Subject: [issue11065] Fatal "can't locate locale" errors when zip file with
	directories is on the PYTHONPATH.
In-Reply-To: <1296328350.27.0.0987051728598.issue11065@psf.upfronthosting.co.za>
Message-ID: <1296329903.9.0.903813430784.issue11065@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


----------
status: open -> closed
superseder:  -> Possible regression with stdlib in zipfile

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11065>
_______________________________________

From report at bugs.python.org  Sat Jan 29 20:39:08 2011
From: report at bugs.python.org (Kelsey)
Date: Sat, 29 Jan 2011 19:39:08 +0000
Subject: [issue11058] dist directory not created when running sdist command
In-Reply-To: <1296300421.59.0.468968378526.issue11058@psf.upfronthosting.co.za>
Message-ID: <1296329948.19.0.40658299112.issue11058@psf.upfronthosting.co.za>


Kelsey <kelsey.hightower at gmail.com> added the comment:

This could be my mistake. . I think an early attempt at patching Issue 11045, I disabled os.makedirs(archive_dir) in shutil. I am going to retest

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11058>
_______________________________________

From report at bugs.python.org  Sat Jan 29 20:46:00 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 29 Jan 2011 19:46:00 +0000
Subject: [issue11045] shutil._make_tarball
In-Reply-To: <1296222490.15.0.786706157889.issue11045@psf.upfronthosting.co.za>
Message-ID: <1296330360.11.0.267327546541.issue11045@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Please apply right away.

----------
nosy: +rhettinger
resolution:  -> accepted
versions:  -Python 3.1, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11045>
_______________________________________

From report at bugs.python.org  Sat Jan 29 20:46:12 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 29 Jan 2011 19:46:12 +0000
Subject: [issue11045] shutil._make_tarball
In-Reply-To: <1296222490.15.0.786706157889.issue11045@psf.upfronthosting.co.za>
Message-ID: <1296330372.82.0.237173560231.issue11045@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <rhettinger at users.sourceforge.net>:


----------
versions: +Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11045>
_______________________________________

From report at bugs.python.org  Sat Jan 29 20:47:45 2011
From: report at bugs.python.org (Kelsey)
Date: Sat, 29 Jan 2011 19:47:45 +0000
Subject: [issue11058] dist directory not created when running sdist command
In-Reply-To: <1296300421.59.0.468968378526.issue11058@psf.upfronthosting.co.za>
Message-ID: <1296330465.27.0.805690974318.issue11058@psf.upfronthosting.co.za>


Kelsey <kelsey.hightower at gmail.com> added the comment:

I have retested; this issue was related to a bug I introduced in shutil (fixed now, and patch sent upstream)

----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11058>
_______________________________________

From report at bugs.python.org  Sat Jan 29 20:57:55 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 29 Jan 2011 19:57:55 +0000
Subject: [issue11045] shutil._make_tarball
In-Reply-To: <1296222490.15.0.786706157889.issue11045@psf.upfronthosting.co.za>
Message-ID: <1296331075.42.0.684224992751.issue11045@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

For 3.2, just make the one-line fix.  I'm worry that a test may be hard to get right and would be a risk in and of itself this late in the release cycle.

For the backports, a test would be nice (since we have time to fix a test if it turns out to be problematic).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11045>
_______________________________________

From report at bugs.python.org  Sat Jan 29 21:04:41 2011
From: report at bugs.python.org (Jason R. Coombs)
Date: Sat, 29 Jan 2011 20:04:41 +0000
Subject: [issue10639] reindent.py converts newlines to platform default
In-Reply-To: <1296322692.45.0.712653390955.issue10639@psf.upfronthosting.co.za>
Message-ID: <A2A66F57550F50449EC38E10458E27FF059BC989BC@VA3DIAXVS381.RED001.local>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

That's great that reindent works in your environment, but that's no help in my environment.

Here's the use case: We have a software package developed in Unix and with Unix LF line endings. The code base may also contain files with CRLF line endings (I can't be certain).

I'm developing in Windows (which includes reindent.py installed by default). I'd like to use that tool to reindent the code base without munging the line endings. I can't do this without first modifying reindent.py or using another tool to convert the line endings afterword (at which point I don't know if the Windows line endings were created by reindent.py or were there natively).

If someone wants the line endings normalized on their code base, they should use another tool (or possibly an option to reindent.py), but there's definitely a case for using reindent.py without altering the line endings.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10639>
_______________________________________

From report at bugs.python.org  Sat Jan 29 21:09:15 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 29 Jan 2011 20:09:15 +0000
Subject: [issue10639] reindent.py converts newlines to platform default
In-Reply-To: <1291653413.79.0.461728889357.issue10639@psf.upfronthosting.co.za>
Message-ID: <1296331755.8.0.754170463387.issue10639@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

That is a valid use case, so +1 on not changing behavior and adding a new option in 3.3 (in another bug report).

What is your reply to msg125818?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10639>
_______________________________________

From report at bugs.python.org  Sat Jan 29 21:25:02 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 29 Jan 2011 20:25:02 +0000
Subject: [issue11045] shutil._make_tarball
In-Reply-To: <1296222490.15.0.786706157889.issue11045@psf.upfronthosting.co.za>
Message-ID: <1296332702.57.0.938338972326.issue11045@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Indeed, I tried writing a small test to go into the faulty code path, but without calling the private function directly it?s not trivial.

I?ll apply the minimal change shortly if there is no opposition from Georg.

----------
assignee: tarek -> eric.araujo
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11045>
_______________________________________

From report at bugs.python.org  Sat Jan 29 21:34:41 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 29 Jan 2011 20:34:41 +0000
Subject: [issue11045] shutil._make_tarball
In-Reply-To: <1296222490.15.0.786706157889.issue11045@psf.upfronthosting.co.za>
Message-ID: <1296333281.51.0.970862179392.issue11045@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Fixed for 3.2rc2 in r88240.  Would it be right to call the internal function in the test?

----------
priority: high -> normal
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11045>
_______________________________________

From report at bugs.python.org  Sat Jan 29 21:37:09 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 29 Jan 2011 20:37:09 +0000
Subject: [issue10939] imaplib: Internaldate2tuple raises KeyError parsing
	month and does not work with negative TZ offset due to
	bytes/str issues
In-Reply-To: <1295389900.99.0.76199090445.issue10939@psf.upfronthosting.co.za>
Message-ID: <1296333429.87.0.474215004004.issue10939@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Some systems don't like times too close to epoch.  Fixed in revision 88239.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10939>
_______________________________________

From report at bugs.python.org  Sat Jan 29 21:43:16 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 29 Jan 2011 20:43:16 +0000
Subject: [issue10939] imaplib: Internaldate2tuple raises KeyError parsing
	month and does not work with negative TZ offset due to
	bytes/str issues
In-Reply-To: <1295389900.99.0.76199090445.issue10939@psf.upfronthosting.co.za>
Message-ID: <1296333796.24.0.00559989816027.issue10939@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10939>
_______________________________________

From report at bugs.python.org  Sat Jan 29 21:56:15 2011
From: report at bugs.python.org (Pierre Quentel)
Date: Sat, 29 Jan 2011 20:56:15 +0000
Subject: [issue10911] cgi: add more tests
In-Reply-To: <1295040877.8.0.0807786274615.issue10911@psf.upfronthosting.co.za>
Message-ID: <1296334575.8.0.60923864775.issue10911@psf.upfronthosting.co.za>


Pierre Quentel <pierre.quentel at gmail.com> added the comment:

Here is the diff file for test_cgi.py
I added a test for a multipart/form-data form with non ASCII data to test the "encoding" parameter of FieldStorage

----------
keywords: +patch
Added file: http://bugs.python.org/file20611/test_cgi.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10911>
_______________________________________

From report at bugs.python.org  Sat Jan 29 22:15:41 2011
From: report at bugs.python.org (Pierre Quentel)
Date: Sat, 29 Jan 2011 21:15:41 +0000
Subject: [issue11066] cgi.py proposals : sys.stdout encoding + rewriting of
	parsing functions
In-Reply-To: <1296335741.52.0.506773731017.issue11066@psf.upfronthosting.co.za>
Message-ID: <1296335741.52.0.506773731017.issue11066@psf.upfronthosting.co.za>


New submission from Pierre Quentel <pierre.quentel at gmail.com>:

Python 3.2rc1 introduced a new version of cgi.py that handles correctly file uploads

In this version, the FieldStorage constructor receives an argument "encoding" which is the encoding used by the document holding the submitted form

On the CGI script side, there is currently no easy way to print the received form fields with another encoding than sys.stdout.encoding. 

The proposed version introduces a function, set_stdout_encoding(charset), which can be used in the CGI script to set sys.stdout to an instance of a class that uses the charset encoding. This way, print() will use this encoding. "charset" must be the encoding defined in the content-type header sent by the CGI scrpt

This class (IOMix) was written by Glen Linderman and proposed in the 3.2rc1 version, but no consensus could be reached on time for the release

Another proposed change is a rewriting of the module-level functions parse() and parse_multipart() : they now use the FieldStorage methods instead

----------
components: Library (Lib)
files: cgi_20110129.diff
keywords: patch
messages: 127487
nosy: quentel
priority: normal
severity: normal
status: open
title: cgi.py proposals : sys.stdout encoding + rewriting of parsing functions
type: behavior
versions: Python 3.3
Added file: http://bugs.python.org/file20612/cgi_20110129.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11066>
_______________________________________

From report at bugs.python.org  Sat Jan 29 22:34:47 2011
From: report at bugs.python.org (Peter Eisentraut)
Date: Sat, 29 Jan 2011 21:34:47 +0000
Subject: [issue11067] Py_LIMITED_API breaks most PySomething_Check() functions
In-Reply-To: <1296336887.12.0.12161660566.issue11067@psf.upfronthosting.co.za>
Message-ID: <1296336887.12.0.12161660566.issue11067@psf.upfronthosting.co.za>


New submission from Peter Eisentraut <peter_e at gmx.net>:

When setting Py_LIMITED_API, functions such as PyUnicode_Check() can no longer be used.  Example:

#define Py_LIMITED_API

#include <Python.h>

void foo()
{
    PyObject *o;

    PyUnicode_Check(o); 
}

test.c: In function ?foo?:
test.c:9: error: dereferencing pointer to incomplete type

PEP 384 contains some nested language that suggests that the _Check macros should be available under the limited API.  And it seems to me that they easily could be, if Py_TYPE were implemented as a function instead of a macro.

----------
components: None
messages: 127488
nosy: petere
priority: normal
severity: normal
status: open
title: Py_LIMITED_API breaks most PySomething_Check() functions
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11067>
_______________________________________

From report at bugs.python.org  Sat Jan 29 22:38:06 2011
From: report at bugs.python.org (Joe Peterson)
Date: Sat, 29 Jan 2011 21:38:06 +0000
Subject: [issue10939] imaplib: Internaldate2tuple raises KeyError parsing
	month and does not work with negative TZ offset due to
	bytes/str issues
In-Reply-To: <1295389900.99.0.76199090445.issue10939@psf.upfronthosting.co.za>
Message-ID: <1296337086.96.0.702704993547.issue10939@psf.upfronthosting.co.za>


Joe Peterson <joe at skyrush.com> added the comment:

Alexander, looks like you hit a weirdness in the Europe/London timezone for dates before 31-Oct-1971, as if DST was in effect even in winter.  And the fail of the test is caused by the same bug that causes issue 10941: the use of mktime to interpret the values from an internal time string (which should not be dealing with timezones, but rather explicit offsets from UTC, before converting to localtime).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10939>
_______________________________________

From report at bugs.python.org  Sat Jan 29 22:39:40 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 29 Jan 2011 21:39:40 +0000
Subject: [issue11067] Py_LIMITED_API breaks most PySomething_Check() functions
In-Reply-To: <1296336887.12.0.12161660566.issue11067@psf.upfronthosting.co.za>
Message-ID: <1296337180.15.0.467216058445.issue11067@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
components: +Interpreter Core -None
nosy: +loewis
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11067>
_______________________________________

From report at bugs.python.org  Sat Jan 29 22:45:15 2011
From: report at bugs.python.org (Joe Peterson)
Date: Sat, 29 Jan 2011 21:45:15 +0000
Subject: [issue10941] imaplib: Internaldate2tuple produces wrong result if
	date is near a DST change
In-Reply-To: <1295394107.36.0.490316527511.issue10941@psf.upfronthosting.co.za>
Message-ID: <1296337515.04.0.573251204161.issue10941@psf.upfronthosting.co.za>


Joe Peterson <joe at skyrush.com> added the comment:

Here is a new patch that adds a test to the tests committed for issue 10939.

This new test case is needed to trigger the DST issue.  This test is not timezone-dependent (in the sense that one does not have to have a specific timezone set for it to work), but it does depend on the DST change happening at 02:00 on the first Sunday in April, 2000.  This is the case for most of the United States, but to make it work everywhere, I have added code that sets the TZ to one that works, and then reverts the temporary TZ change after the test.

The bug is triggered when the time described in the internal date string, ignoring the time offset, is between 02:00 and 03:00.  This is because the raw time in the string is interpreted as local time, and local times in this range are basically invalid, since time advances to 03:00 when 02:00 is reached because of the DST change.  This causes the final result to be off by one hour.

[This patch is only for Python 3]

----------
Added file: http://bugs.python.org/file20613/issue10941.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10941>
_______________________________________

From report at bugs.python.org  Sat Jan 29 22:56:16 2011
From: report at bugs.python.org (R. David Murray)
Date: Sat, 29 Jan 2011 21:56:16 +0000
Subject: [issue9124] Mailbox module should use binary I/O, not text I/O
In-Reply-To: <1277900903.38.0.556015912714.issue9124@psf.upfronthosting.co.za>
Message-ID: <1296338176.44.0.266447520646.issue9124@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Benjamin suggested using hasattr(message, 'buffer'), and that works great.  The test revealed a bug in the patch, which is now fixed.

All tests pass on windows.  As far as I'm concerned the patch is ready to go.  Other reviews would of course be welcome (and perhaps required by Georg).

----------
Added file: http://bugs.python.org/file20614/mailbox6.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9124>
_______________________________________

From report at bugs.python.org  Sat Jan 29 23:21:42 2011
From: report at bugs.python.org (David Meier)
Date: Sat, 29 Jan 2011 22:21:42 +0000
Subject: [issue11068] Python 2.7.1 Idle Segmentation Fault OS X (10.6.6)
In-Reply-To: <1296339702.88.0.766799420032.issue11068@psf.upfronthosting.co.za>
Message-ID: <1296339702.88.0.766799420032.issue11068@psf.upfronthosting.co.za>


New submission from David Meier <djmeier at gmail.com>:

After IDLE launches I select 'File->Open' browse to a blank .py file, when I select the particular file I get the segfault below...

silverbox:~ user$ (idle&)
silverbox:~ user$ Traceback (most recent call last):
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/idlelib/run.py", line 93, in main
    seq, request = rpc.request_queue.get(block=True, timeout=0.05)
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/Queue.py", line 177, in get
    self.not_empty.wait(remaining)
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/threading.py", line 257, in wait
    _sleep(delay)
TypeError: 'int' object is not callable

----------
components: IDLE
messages: 127492
nosy: David.Meier
priority: normal
severity: normal
status: open
title: Python 2.7.1 Idle Segmentation Fault OS X (10.6.6)
type: crash
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11068>
_______________________________________

From report at bugs.python.org  Sat Jan 29 23:28:45 2011
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 29 Jan 2011 22:28:45 +0000
Subject: [issue11068] Python 2.7.1 Idle traceback on OS X (10.6.6)
In-Reply-To: <1296339702.88.0.766799420032.issue11068@psf.upfronthosting.co.za>
Message-ID: <1296340125.1.0.483772356602.issue11068@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
assignee:  -> ned.deily
nosy: +ned.deily
title: Python 2.7.1 Idle Segmentation Fault OS X (10.6.6) -> Python 2.7.1 Idle traceback on OS X (10.6.6)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11068>
_______________________________________

From report at bugs.python.org  Sat Jan 29 23:35:41 2011
From: report at bugs.python.org (Ned Deily)
Date: Sat, 29 Jan 2011 22:35:41 +0000
Subject: [issue11068] Python 2.7.1 Idle traceback on OS X (10.6.6)
In-Reply-To: <1296339702.88.0.766799420032.issue11068@psf.upfronthosting.co.za>
Message-ID: <1296340541.06.0.408358049822.issue11068@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Does it matter what the contents of the file are, i.e. what do you mean by a "blank .py" file?  I am not able to reproduce that problem.

Be aware that, because of problems with the Apple-suppled Cocoa Tk 8.5 in OS X 10.6, the 2.7.1 IDLE from the 10.6-only 64-bit/32-bit installer from python.org is problematic.  In the interim, we recommend you use 2.7.1 IDLE from the 10.3-through-10.6 32-bit-only installer.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11068>
_______________________________________

From report at bugs.python.org  Sat Jan 29 23:47:59 2011
From: report at bugs.python.org (Joe Peterson)
Date: Sat, 29 Jan 2011 22:47:59 +0000
Subject: [issue10939] imaplib: Internaldate2tuple raises KeyError parsing
	month and does not work with negative TZ offset due to
	bytes/str issues
In-Reply-To: <1295389900.99.0.76199090445.issue10939@psf.upfronthosting.co.za>
Message-ID: <1296341279.99.0.372488457466.issue10939@psf.upfronthosting.co.za>


Joe Peterson <joe at skyrush.com> added the comment:

More info on the Europe/London "near the epoch" thing (there is no weirdness in the tz stuff - it's just issue 10941 causing the test to fail)...

I looked at the sources for the tz data, and here is the definition for Europe/London:

# Zone	NAME		GMTOFF	RULES	FORMAT	[UNTIL]
Zone	Europe/London	-0:01:15 -	LMT	1847 Dec  1 0:00s
			 0:00	GB-Eire	%s	1968 Oct 27
			 1:00	-	BST	1971 Oct 31 2:00u
			 0:00	GB-Eire	%s	1996
			 0:00	EU	GMT/BST

I appears that London was always 1 hour ahead (BST time) from 1968 Oct 27 until 1971 Oct 31 2:00u, thus triggering issue 10941:

Internaldate2tuple() actually returns the wrong local time (00:00 rather than [the correct] 01:00) in its tuple for the epoch, so mktime(), doing the right thing, returns -3600.  The patch in issue 10941 fixes this, so the right local time in London (01:00) is returned for the epoch (internal date string "01-Jan-1970 00:00:00 +0000").

Note that this also exposes another problem with Time2Internaldate(), since it uses time.timezone/time.altzone, which are only valid for the current rules, not old rules as in the London case near the epoch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10939>
_______________________________________

From report at bugs.python.org  Sun Jan 30 00:04:48 2011
From: report at bugs.python.org (David Meier)
Date: Sat, 29 Jan 2011 23:04:48 +0000
Subject: [issue11068] Python 2.7.1 Idle traceback on OS X (10.6.6)
In-Reply-To: <1296339702.88.0.766799420032.issue11068@psf.upfronthosting.co.za>
Message-ID: <1296342288.55.0.312554008304.issue11068@psf.upfronthosting.co.za>


David Meier <djmeier at gmail.com> added the comment:

It doesn't matter what's in the file itself.  By 'blank' I mean, literally, an empty file (i.e. `touch file.py`).

You are correct that this was installed from the 10.6 specific 2.7.1, I will try to install from the other version.  Is there a recommended uninstallation before trying this?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11068>
_______________________________________

From report at bugs.python.org  Sun Jan 30 00:07:13 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 29 Jan 2011 23:07:13 +0000
Subject: [issue10939] imaplib: Internaldate2tuple raises KeyError parsing
	month and does not work with negative TZ offset due to
	bytes/str issues
In-Reply-To: <1296341279.99.0.372488457466.issue10939@psf.upfronthosting.co.za>
Message-ID: <AANLkTi=TYDRA1P5KU2nb+g8UYjpkJu6VDCcBKN5s346i@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Sat, Jan 29, 2011 at 5:48 PM, Joe Peterson <report at bugs.python.org> wrote:
..
> Note that this also exposes another problem with Time2Internaldate(), since it uses
> time.timezone/time.altzone, which are only valid for the current rules, not old rules as in the London case
> near the epoch.

This is a known issue.  Hopefully this example will raise more
interest for issue 9527.  See also issue 1647654 which suggests a
python-only work-around.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10939>
_______________________________________

From report at bugs.python.org  Sun Jan 30 00:08:24 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 29 Jan 2011 23:08:24 +0000
Subject: [issue9527] Add aware local time support to datetime module
In-Reply-To: <1281066500.35.0.441616276688.issue9527@psf.upfronthosting.co.za>
Message-ID: <1296342504.85.0.65163272273.issue9527@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


----------
dependencies: +Time zone-capable variant of time.localtime

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9527>
_______________________________________

From report at bugs.python.org  Sun Jan 30 00:09:06 2011
From: report at bugs.python.org (Ned Deily)
Date: Sat, 29 Jan 2011 23:09:06 +0000
Subject: [issue11068] Python 2.7.1 Idle traceback on OS X (10.6.6)
In-Reply-To: <1296339702.88.0.766799420032.issue11068@psf.upfronthosting.co.za>
Message-ID: <1296342546.93.0.571464969775.issue11068@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

To uninstall, you can do the following:

sudo rm -rf /Library/Frameworks/Python.framework/Versions/2.7
sudo rm -rf /Applications/"Python 2.7"

If you've installed any site-packages, you would need to re-install them.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11068>
_______________________________________

From report at bugs.python.org  Sun Jan 30 00:11:11 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 29 Jan 2011 23:11:11 +0000
Subject: [issue9527] Add aware local time support to datetime module
In-Reply-To: <1281066500.35.0.441616276688.issue9527@psf.upfronthosting.co.za>
Message-ID: <1296342671.3.0.834955814009.issue9527@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


----------
dependencies: +No obvious and correct way to get the time zone offset

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9527>
_______________________________________

From report at bugs.python.org  Sun Jan 30 00:16:38 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 29 Jan 2011 23:16:38 +0000
Subject: [issue1667546] Time zone-capable variant of time.localtime
Message-ID: <1296342998.9.0.084299645366.issue1667546@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1667546>
_______________________________________

From report at bugs.python.org  Sun Jan 30 00:17:36 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 29 Jan 2011 23:17:36 +0000
Subject: [issue1647654] No obvious and correct way to get the time zone offset
Message-ID: <1296343056.54.0.321022305309.issue1647654@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1647654>
_______________________________________

From report at bugs.python.org  Sun Jan 30 00:26:59 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 29 Jan 2011 23:26:59 +0000
Subject: [issue11063] uuid.py module import has heavy side effects
In-Reply-To: <1296321060.32.0.846037411239.issue11063@psf.upfronthosting.co.za>
Message-ID: <1296343619.17.0.1038963792.issue11063@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
keywords: +easy
stage:  -> needs patch
versions: +Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11063>
_______________________________________

From report at bugs.python.org  Sun Jan 30 00:36:29 2011
From: report at bugs.python.org (Ned Deily)
Date: Sat, 29 Jan 2011 23:36:29 +0000
Subject: [issue11053] OS X IDLE 3 with Tk 8.4 appears to hang with syntax error
In-Reply-To: <1296271053.35.0.843403013415.issue11053@psf.upfronthosting.co.za>
Message-ID: <1296344189.54.0.909940963263.issue11053@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

r88242 for 3.1

----------
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11053>
_______________________________________

From report at bugs.python.org  Sun Jan 30 00:45:41 2011
From: report at bugs.python.org (Ned Deily)
Date: Sat, 29 Jan 2011 23:45:41 +0000
Subject: [issue9763] Crashes upon run after syntax error encountered in OSX
	10.5.8
In-Reply-To: <1283542973.95.0.133487128669.issue9763@psf.upfronthosting.co.za>
Message-ID: <1296344741.58.0.825880578454.issue9763@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

The problem was caused by a minor change in IDLE during the port of IDLE from 2.x to 3.x.  It is fixed by the changes for Issue11053: r88234 (3.2rc2) and r88242 (planned for 3.1.4).

----------
resolution:  -> duplicate
stage:  -> committed/rejected
status: open -> closed
superseder:  -> OS X IDLE 3 with Tk 8.4 appears to hang with syntax error

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9763>
_______________________________________

From report at bugs.python.org  Sun Jan 30 00:47:34 2011
From: report at bugs.python.org (Ned Deily)
Date: Sat, 29 Jan 2011 23:47:34 +0000
Subject: [issue6628] IDLE freezes after encountering a syntax error
In-Reply-To: <1249254946.68.0.209899290876.issue6628@psf.upfronthosting.co.za>
Message-ID: <1296344854.96.0.430917762001.issue6628@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

For the record: The problem was caused by a minor change in IDLE during the port of IDLE from 2.x to 3.x.  It is fixed by the changes for Issue11053: r88234 (3.2rc2) and r88242 (planned for 3.1.4).

----------
assignee: ronaldoussoren -> ned.deily
stage:  -> committed/rejected
superseder: Crashes upon run after syntax error encountered in OSX 10.5.8 -> OS X IDLE 3 with Tk 8.4 appears to hang with syntax error

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6628>
_______________________________________

From report at bugs.python.org  Sun Jan 30 01:23:13 2011
From: report at bugs.python.org (Ned Deily)
Date: Sun, 30 Jan 2011 00:23:13 +0000
Subject: [issue10907] OS X installer: warn users of buggy Tcl/Tk in OS X 10.6
In-Reply-To: <1295020361.6.0.15646249296.issue10907@psf.upfronthosting.co.za>
Message-ID: <1296346993.87.0.287247185403.issue10907@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

7. Backported to 2.7 in r88243 (to appear in 2.7.2).

----------
priority: release blocker -> 
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10907>
_______________________________________

From report at bugs.python.org  Sun Jan 30 01:23:35 2011
From: report at bugs.python.org (Ned Deily)
Date: Sun, 30 Jan 2011 00:23:35 +0000
Subject: [issue10907] OS X installer: warn users of buggy Tcl/Tk in OS X 10.6
In-Reply-To: <1295020361.6.0.15646249296.issue10907@psf.upfronthosting.co.za>
Message-ID: <1296347015.79.0.213498352935.issue10907@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/issue10907>
_______________________________________

From report at bugs.python.org  Sun Jan 30 01:48:55 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sun, 30 Jan 2011 00:48:55 +0000
Subject: [issue10941] imaplib: Internaldate2tuple produces wrong result if
	date is near a DST change
In-Reply-To: <1296337515.04.0.573251204161.issue10941@psf.upfronthosting.co.za>
Message-ID: <AANLkTikLj3o9Kpz-E=3har8RX+_J_GNwg74VqE_=H1kd@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Sat, Jan 29, 2011 at 4:45 PM, Joe Peterson <report at bugs.python.org> wrote:
..
> I have added code that sets the TZ to one that works, and then reverts the temporary
> TZ change after the test.
>

Your test will not restore TZ if it fails.  This is not nice.  To fix
that, code restoring the TZ should go into a finally clause.  Even
better, set TZ in a setUp() method and restore it in a tearDown()
method of the test case class.  Ultimately, if you want to be fancy,
take a look at the @run_with_locale decorator defined in
Lib/test/support.py.  We may have more than one use for @run_with_tz.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10941>
_______________________________________

From report at bugs.python.org  Sun Jan 30 02:25:21 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 30 Jan 2011 01:25:21 +0000
Subject: [issue10845] test_multiprocessing failure under Windows
In-Reply-To: <1294309581.41.0.731804987161.issue10845@psf.upfronthosting.co.za>
Message-ID: <1296350721.21.0.8811771485.issue10845@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Committed for 3.2 in r88247.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10845>
_______________________________________

From report at bugs.python.org  Sun Jan 30 02:46:27 2011
From: report at bugs.python.org (Ned Deily)
Date: Sun, 30 Jan 2011 01:46:27 +0000
Subject: [issue10842] Update third-party libraries for OS X installer builds
In-Reply-To: <1294305637.23.0.341106753223.issue10842@psf.upfronthosting.co.za>
Message-ID: <1296351987.59.0.747242429486.issue10842@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Merged to 2.7 in r88248 (for 2.7.2).

----------
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10842>
_______________________________________

From report at bugs.python.org  Sun Jan 30 02:51:27 2011
From: report at bugs.python.org (Ned Deily)
Date: Sun, 30 Jan 2011 01:51:27 +0000
Subject: [issue11054] OS X installer build script for 3.2 can no longer build
	with system Python on OS X 10.5
In-Reply-To: <1296272827.91.0.103223659215.issue11054@psf.upfronthosting.co.za>
Message-ID: <1296352287.99.0.0529190137693.issue11054@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Merged to 2.7 in r88248 (for 2.7.2).

----------
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11054>
_______________________________________

From report at bugs.python.org  Sun Jan 30 03:06:57 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 30 Jan 2011 02:06:57 +0000
Subject: [issue11037] State of PEP 382 or How does distutils2
	handle	namespaces?
In-Reply-To: <1296293666.08.0.299170502153.issue11037@psf.upfronthosting.co.za>
Message-ID: <4D44C7BE.9020109@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> Martin, could you shed some light on the state of that PEP?

It's implemented in a branch, and will likely be included in Python 3.3.

----------
title: Implementing PEP 382 -> State of PEP 382 or How does distutils2 handle	namespaces?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11037>
_______________________________________

From report at bugs.python.org  Sun Jan 30 03:08:33 2011
From: report at bugs.python.org (Joe Peterson)
Date: Sun, 30 Jan 2011 02:08:33 +0000
Subject: [issue10941] imaplib: Internaldate2tuple produces wrong result if
	date is near a DST change
In-Reply-To: <1295394107.36.0.490316527511.issue10941@psf.upfronthosting.co.za>
Message-ID: <1296353313.59.0.797949593002.issue10941@psf.upfronthosting.co.za>


Changes by Joe Peterson <joe at skyrush.com>:


Removed file: http://bugs.python.org/file20613/issue10941.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10941>
_______________________________________

From report at bugs.python.org  Sun Jan 30 03:08:59 2011
From: report at bugs.python.org (Joe Peterson)
Date: Sun, 30 Jan 2011 02:08:59 +0000
Subject: [issue10941] imaplib: Internaldate2tuple produces wrong result if
	date is near a DST change
In-Reply-To: <1295394107.36.0.490316527511.issue10941@psf.upfronthosting.co.za>
Message-ID: <1296353339.71.0.4245423498.issue10941@psf.upfronthosting.co.za>


Joe Peterson <joe at skyrush.com> added the comment:

I like the idea of adding the decorator.  New patch added.

----------
Added file: http://bugs.python.org/file20615/issue10941.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10941>
_______________________________________

From report at bugs.python.org  Sun Jan 30 03:28:46 2011
From: report at bugs.python.org (Joe Peterson)
Date: Sun, 30 Jan 2011 02:28:46 +0000
Subject: [issue10941] imaplib: Internaldate2tuple produces wrong result if
	date is near a DST change
In-Reply-To: <1295394107.36.0.490316527511.issue10941@psf.upfronthosting.co.za>
Message-ID: <1296354526.72.0.379825137164.issue10941@psf.upfronthosting.co.za>


Joe Peterson <joe at skyrush.com> added the comment:

[just carrying over some info from issue 10939 that is related to this issue]

Here is another manifestation of this issue, related to the local time assumption, but not to DST, per se:

Here is the definition for Europe/London in the unix tz data:

# Zone	NAME		GMTOFF	RULES	FORMAT	[UNTIL]
Zone	Europe/London	-0:01:15 -	LMT	1847 Dec  1 0:00s
			 0:00	GB-Eire	%s	1968 Oct 27
			 1:00	-	BST	1971 Oct 31 2:00u
			 0:00	GB-Eire	%s	1996
			 0:00	EU	GMT/BST

So London's local time was always 1 hour ahead of UTC (BST time) from 1968 Oct 27 until 1971 Oct 31 2:00u.

Because of this, Internaldate2tuple() returns the wrong local time (00:00 rather than [the correct] 01:00) in its tuple when input is "01-Jan-1970 00:00:00 +0000" (the epoch).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10941>
_______________________________________

From report at bugs.python.org  Sun Jan 30 03:36:17 2011
From: report at bugs.python.org (Yakov Blum)
Date: Sun, 30 Jan 2011 02:36:17 +0000
Subject: [issue11069] IDLE crashes when Stack Viewer opened
In-Reply-To: <1296354977.38.0.0551219398601.issue11069@psf.upfronthosting.co.za>
Message-ID: <1296354977.38.0.0551219398601.issue11069@psf.upfronthosting.co.za>


New submission from Yakov Blum <yak2718 at gmail.com>:

This problem was asked about on Stack Overflow, where there's some more information on it:
http://stackoverflow.com/questions/4046021/python-idle-windows-pressing-stack-viewer-exits-all-idle-windows

But I didn't see it listed as a bug here. I've also experienced it in Python 3.1.3

----------
components: IDLE
messages: 127509
nosy: Yakov.Blum
priority: normal
severity: normal
status: open
title: IDLE crashes when Stack Viewer opened
type: crash
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11069>
_______________________________________

From report at bugs.python.org  Sun Jan 30 03:47:33 2011
From: report at bugs.python.org (Ned Deily)
Date: Sun, 30 Jan 2011 02:47:33 +0000
Subject: [issue11069] IDLE crashes when Stack Viewer opened
In-Reply-To: <1296354977.38.0.0551219398601.issue11069@psf.upfronthosting.co.za>
Message-ID: <1296355653.51.0.772714479176.issue11069@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

According to the StackOverflow report, the crash occurs on Python 3.1.2 with IDLE 3.1.2 on Windows 7.

----------
components: +Windows
nosy: +brian.curtin, kbk, ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11069>
_______________________________________

From report at bugs.python.org  Sun Jan 30 03:49:31 2011
From: report at bugs.python.org (Yakov Blum)
Date: Sun, 30 Jan 2011 02:49:31 +0000
Subject: [issue11069] IDLE crashes when Stack Viewer opened
In-Reply-To: <1296354977.38.0.0551219398601.issue11069@psf.upfronthosting.co.za>
Message-ID: <1296355771.09.0.640890443705.issue11069@psf.upfronthosting.co.za>


Yakov Blum <yak2718 at gmail.com> added the comment:

A few additional details:

I'm also running Windows 7.

Reproducing the crash is as simple as opening IDLE, typing, e.g.,
raise TypeError
and clicking Debug > Stack Viewer

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11069>
_______________________________________

From report at bugs.python.org  Sun Jan 30 03:56:04 2011
From: report at bugs.python.org (rmtew)
Date: Sun, 30 Jan 2011 02:56:04 +0000
Subject: [issue11070] test_capi crashes and fails
In-Reply-To: <1296356164.16.0.546388773568.issue11070@psf.upfronthosting.co.za>
Message-ID: <1296356164.16.0.546388773568.issue11070@psf.upfronthosting.co.za>


New submission from rmtew <richard.m.tew at gmail.com>:

OS: Windows 7
Compiler: Visual Studio 2008
Build: Win32 (Debug and Release)

The main problem is observed in both debug and release builds, and even though the test effectively passes in both it also fails in release build.

** In a debug build I see the following:

  test_instancemethod (__main__.CAPITest) ... ok
  test_no_FatalError_infinite_loop (__main__.CAPITest) ...

Then a dialog pops up telling me that Python has crashed.  The unit test execution pauses until this dialog is dealt with.  This then becomes:

  test_no_FatalError_infinite_loop (__main__.CAPITest) ... ok

And the unit tests proceed to pass.

** In a release build I see the following:

  test_instancemethod (__main__.CAPITest) ... ok
  test_no_FatalError_infinite_loop (__main__.CAPITest) ...

Then the crash dialog also pops up.  Dismissing it results in the test failing however.

  test_no_FatalError_infinite_loop (__main__.CAPITest) ... FAIL

  ======================================================================
  FAIL: test_no_FatalError_infinite_loop (__main__.CAPITest)
  ----------------------------------------------------------------------
  Traceback (most recent call last):
    File "Lib\test\test_capi.py", line 50, in test_no_FatalError_infinite_loop
      b'Fatal Python error:'
  AssertionError: b"Fatal Python error: PyThreadState_Get: no current thread\n\r\nThis application has requested the Runtime to terminate it in an unusual way.\nPlease contact the application's support team for more information." != b'Fatal Python error: PyThreadState_Get: no current thread'

Is there some information I am missing somewhere (that I have not found via googling) or is this part of the gauntlet of unit test execution on Python now?

----------
components: Tests, Windows
messages: 127512
nosy: rmtew
priority: normal
severity: normal
status: open
title: test_capi crashes and fails
type: crash
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11070>
_______________________________________

From report at bugs.python.org  Sun Jan 30 03:57:57 2011
From: report at bugs.python.org (Brian Curtin)
Date: Sun, 30 Jan 2011 02:57:57 +0000
Subject: [issue11070] test_capi crashes and fails
In-Reply-To: <1296356164.16.0.546388773568.issue11070@psf.upfronthosting.co.za>
Message-ID: <1296356277.16.0.735119591603.issue11070@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

Duplicate of #9116.

----------
nosy: +brian.curtin
resolution:  -> duplicate
stage:  -> committed/rejected
status: open -> closed
superseder:  -> test_capi.test_no_FatalError_infinite_loop crash on Windows
versions: +Python 3.1 -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11070>
_______________________________________

From report at bugs.python.org  Sun Jan 30 03:58:11 2011
From: report at bugs.python.org (Brian Curtin)
Date: Sun, 30 Jan 2011 02:58:11 +0000
Subject: [issue11070] test_capi crashes and fails
In-Reply-To: <1296356164.16.0.546388773568.issue11070@psf.upfronthosting.co.za>
Message-ID: <1296356291.36.0.0350169794283.issue11070@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
versions: +Python 3.2 -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11070>
_______________________________________

From report at bugs.python.org  Sun Jan 30 04:11:11 2011
From: report at bugs.python.org (Brian Curtin)
Date: Sun, 30 Jan 2011 03:11:11 +0000
Subject: [issue11069] IDLE crashes when Stack Viewer opened
In-Reply-To: <1296354977.38.0.0551219398601.issue11069@psf.upfronthosting.co.za>
Message-ID: <1296357071.03.0.900605959405.issue11069@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

I don't get a crash, but it certainly doesn't work. Once IDLE is open I type "raise TypeError", then open the stack viewer as you did. Here's what I'm seeing:


[WINSEVEN] 2011-01-29 21:05:30.18
c:\Users\brian
>c:\python31\python.exe -m idlelib.idle
*** Internal Error: rpc.py:SocketIO.localcall()

 Object: 49395136
 Method: <bound method WrappedObjectTreeItem._GetSubList of <idlelib.RemoteObjec
tBrowser.WrappedObjectTreeItem object at 0x0000000002F1B5C0>>
 Args: ()

Traceback (most recent call last):
  File "c:\python31\lib\idlelib\rpc.py", line 188, in localcall
    ret = method(*args, **kwargs)
  File "c:\python31\lib\idlelib\RemoteObjectBrowser.py", line 21, in _GetSubList

    return list(map(remote_object_tree_item, list))
TypeError: 'list' object is not callable
Exception in Tkinter callback
Traceback (most recent call last):
  File "c:\python31\lib\tkinter\__init__.py", line 1399, in __call__
    return self.func(*args)
  File "c:\python31\lib\idlelib\PyShell.py", line 1171, in open_stack_viewer
    return self.interp.remote_stack_viewer()
  File "c:\python31\lib\idlelib\PyShell.py", line 572, in remote_stack_viewer
    node.expand()
  File "c:\python31\lib\idlelib\TreeWidget.py", line 131, in expand
    self.update()
  File "c:\python31\lib\idlelib\TreeWidget.py", line 170, in update
    self.draw(7, 2)
  File "c:\python31\lib\idlelib\TreeWidget.py", line 184, in draw
    sublist = self.item._GetSubList()
  File "c:\python31\lib\idlelib\RemoteObjectBrowser.py", line 36, in _GetSubList

    return [StubObjectTreeItem(self.sockio, oid) for oid in list]
TypeError: 'NoneType' object is not iterable

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11069>
_______________________________________

From report at bugs.python.org  Sun Jan 30 04:12:03 2011
From: report at bugs.python.org (Brian Curtin)
Date: Sun, 30 Jan 2011 03:12:03 +0000
Subject: [issue11069] IDLE crashes when Stack Viewer opened
In-Reply-To: <1296354977.38.0.0551219398601.issue11069@psf.upfronthosting.co.za>
Message-ID: <1296357123.66.0.810845350772.issue11069@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
type: crash -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11069>
_______________________________________

From report at bugs.python.org  Sun Jan 30 04:32:27 2011
From: report at bugs.python.org (Brian Curtin)
Date: Sun, 30 Jan 2011 03:32:27 +0000
Subject: [issue11069] IDLE crashes when Stack Viewer opened
In-Reply-To: <1296354977.38.0.0551219398601.issue11069@psf.upfronthosting.co.za>
Message-ID: <1296358347.31.0.93076061299.issue11069@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

The following patch will fix it. Another example of why 'list' isn't a great name :)

Index: Lib/idlelib/RemoteObjectBrowser.py
===================================================================
--- Lib/idlelib/RemoteObjectBrowser.py  (revision 88248)
+++ Lib/idlelib/RemoteObjectBrowser.py  (working copy)
@@ -17,8 +17,8 @@
         return value

     def _GetSubList(self):
-        list = self.__item._GetSubList()
-        return list(map(remote_object_tree_item, list))
+        sub_list = self.__item._GetSubList()
+        return list(map(remote_object_tree_item, sub_list))

 class StubObjectTreeItem:
     # Lives in IDLE process

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11069>
_______________________________________

From report at bugs.python.org  Sun Jan 30 05:56:23 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 30 Jan 2011 04:56:23 +0000
Subject: [issue9527] Add aware local time support to datetime module
In-Reply-To: <1281066500.35.0.441616276688.issue9527@psf.upfronthosting.co.za>
Message-ID: <1296363383.09.0.963872226996.issue9527@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

I think Tim and Guido had deliberately avoided local timezone awareness when they designed the module.

Also, I question whether the proposed API is correct.  ISTM that any code that sets the *dst* parameter is guaranteed to be wrong (hardwiring-in a value that will change every few months).

Have you studied the solutions used in other libraries and other languages?  This path has been well-traveled, so original work may be less helpful than just researching existing solutions.

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9527>
_______________________________________

From report at bugs.python.org  Sun Jan 30 06:52:56 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sun, 30 Jan 2011 05:52:56 +0000
Subject: [issue9527] Add aware local time support to datetime module
In-Reply-To: <1296363383.09.0.963872226996.issue9527@psf.upfronthosting.co.za>
Message-ID: <AANLkTi=SVtH=HKSkRyAkd1N++mFbhTt7Dz45=CMWSPzQ@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Sat, Jan 29, 2011 at 11:56 PM, Raymond Hettinger
<report at bugs.python.org> wrote:
..
> Also, I question whether the proposed API is correct. ?ISTM that any code that sets the *dst*
> parameter is guaranteed to be wrong (hardwiring-in a value that will change every few months).

Can you elaborate on this?  ISTM that your argument would equally
apply to C/POSIX mktime() API.  It won't be the first time C/POSIX got
time handling wrong, but I doubt it is the case in this instance.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9527>
_______________________________________

From report at bugs.python.org  Sun Jan 30 07:23:57 2011
From: report at bugs.python.org (R. David Murray)
Date: Sun, 30 Jan 2011 06:23:57 +0000
Subject: [issue9124] Mailbox module should use binary I/O, not text I/O
In-Reply-To: <1277900903.38.0.556015912714.issue9124@psf.upfronthosting.co.za>
Message-ID: <1296368637.17.0.121199802501.issue9124@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Committed (with RM approval on IRC) in r88252.

Note that this does not necessarily solve the performance problem.  A new issue should be opened for that if it still exist.

----------
resolution:  -> fixed
stage: commit review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9124>
_______________________________________

From report at bugs.python.org  Sun Jan 30 07:28:01 2011
From: report at bugs.python.org (Ron Adam)
Date: Sun, 30 Jan 2011 06:28:01 +0000
Subject: [issue10961] Pydoc touchups in new browser for 3.2
In-Reply-To: <1295545738.06.0.604274599052.issue10961@psf.upfronthosting.co.za>
Message-ID: <1296368881.49.0.516331077853.issue10961@psf.upfronthosting.co.za>


Ron Adam <ron_adam at users.sourceforge.net> added the comment:

New and hopefully last patch... pydoc_misc_fix_e.diff

I removed the .html in the ?key= links as Eric suggested.

I checked the navbar float behavior on browsershots.org.  Multiple versions of MSIE, firefox, opera, chrome, and safari were tested on Ubuntu and Windows XP.  They all looked very close to each other. Better than I expected. :-)

As for clearing floats, there is the html clear="all" attribute, and a css style="clear:both;".  The browsershots.org tests confirms style="clear:both;" works as it should where I used it.

Cheers, and hopefully this is ready to go.  I believe it is.

----------
Added file: http://bugs.python.org/file20616/pydoc_misc_fix_e.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10961>
_______________________________________

From report at bugs.python.org  Sun Jan 30 08:49:34 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Sun, 30 Jan 2011 07:49:34 +0000
Subject: [issue6715] xz compressor support
In-Reply-To: <1250502444.31.0.107447392137.issue6715@psf.upfronthosting.co.za>
Message-ID: <1296373774.43.0.750979509011.issue6715@psf.upfronthosting.co.za>


Changes by Nadeem Vawda <nadeem.vawda at gmail.com>:


----------
nosy: +nvawda

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6715>
_______________________________________

From report at bugs.python.org  Sun Jan 30 09:13:34 2011
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 30 Jan 2011 08:13:34 +0000
Subject: [issue10845] test_multiprocessing failure under Windows
In-Reply-To: <1294309581.41.0.731804987161.issue10845@psf.upfronthosting.co.za>
Message-ID: <1296375214.61.0.644726944119.issue10845@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
priority: release blocker -> critical

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10845>
_______________________________________

From report at bugs.python.org  Sun Jan 30 09:16:52 2011
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 30 Jan 2011 08:16:52 +0000
Subject: [issue11069] IDLE crashes when Stack Viewer opened
In-Reply-To: <1296354977.38.0.0551219398601.issue11069@psf.upfronthosting.co.za>
Message-ID: <1296375412.58.0.749188540882.issue11069@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Thanks, applied in r88258.

----------
nosy: +georg.brandl
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11069>
_______________________________________

From report at bugs.python.org  Sun Jan 30 09:37:41 2011
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 30 Jan 2011 08:37:41 +0000
Subject: [issue10961] Pydoc touchups in new browser for 3.2
In-Reply-To: <1295545738.06.0.604274599052.issue10961@psf.upfronthosting.co.za>
Message-ID: <1296376661.91.0.697993179775.issue10961@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

I fixed two instances of missing HTML escaping and committed as r88261.  The code should be checked thoroughly for more such missing escaping.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10961>
_______________________________________

From report at bugs.python.org  Sun Jan 30 10:04:50 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Sun, 30 Jan 2011 09:04:50 +0000
Subject: [issue11051] system calls per import
In-Reply-To: <1296254973.71.0.897914319387.issue11051@psf.upfronthosting.co.za>
Message-ID: <1296378290.31.0.235427559692.issue11051@psf.upfronthosting.co.za>


Changes by Nadeem Vawda <nadeem.vawda at gmail.com>:


----------
nosy: +nvawda

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11051>
_______________________________________

From report at bugs.python.org  Sun Jan 30 10:19:20 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 30 Jan 2011 09:19:20 +0000
Subject: [issue11051] system calls per import
In-Reply-To: <1296254973.71.0.897914319387.issue11051@psf.upfronthosting.co.za>
Message-ID: <4D452D16.1020503@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> Something has gone out of control here. Why do we need to check so many alternative locations?

What change do you propose?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11051>
_______________________________________

From report at bugs.python.org  Sun Jan 30 10:30:06 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 30 Jan 2011 09:30:06 +0000
Subject: [issue11051] system calls per import
In-Reply-To: <1296254973.71.0.897914319387.issue11051@psf.upfronthosting.co.za>
Message-ID: <1296379806.08.0.789494655322.issue11051@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <rhettinger at users.sourceforge.net>:


----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11051>
_______________________________________

From report at bugs.python.org  Sun Jan 30 10:38:06 2011
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 30 Jan 2011 09:38:06 +0000
Subject: [issue11051] system calls per import
In-Reply-To: <1296254973.71.0.897914319387.issue11051@psf.upfronthosting.co.za>
Message-ID: <1296380286.58.0.207154315876.issue11051@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11051>
_______________________________________

From report at bugs.python.org  Sun Jan 30 11:56:18 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 30 Jan 2011 10:56:18 +0000
Subject: [issue11051] system calls per import
In-Reply-To: <4D452D16.1020503@v.loewis.de>
Message-ID: <1296384975.3683.2.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> > Something has gone out of control here. Why do we need to check so many alternative locations?
> 
> What change do you propose?

First, I don't understand why we need to check both "foo.so" and
"foomodule.so". Second, I don't understand why we need to check both
"foo.cpython32.so" and "foo.so". If you fix both these, the number of
stat() calls per would-be extension module goes down from 6 to 2 per
directory path.

Then there seems to be a couple of redundant stat/fstat calls on some
files.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11051>
_______________________________________

From report at bugs.python.org  Sun Jan 30 12:56:47 2011
From: report at bugs.python.org (Steven Bethard)
Date: Sun, 30 Jan 2011 11:56:47 +0000
Subject: [issue10680] argparse: titles and add_mutually_exclusive_group don't
	mix (even with workaround)
In-Reply-To: <1292083248.97.0.928495782189.issue10680@psf.upfronthosting.co.za>
Message-ID: <1296388607.14.0.135861888085.issue10680@psf.upfronthosting.co.za>


Steven Bethard <steven.bethard at gmail.com> added the comment:

Looks great, thanks. I've updated the patch so it applies okay to both release27-maint and py3k. All tests pass on both branches.

It's a one line fix and the test case looks good, so there should be no problem applying this to release27-maint.

For 3.2, the py3k branch is frozen for rc2, and Georg has said that he hopes for "zero commits between rc2 and final". If anyone feels very strongly about this getting into 3.2, please ask Georg for permission.

----------
assignee:  -> bethard
stage: unit test needed -> patch review
Added file: http://bugs.python.org/file20617/issue10680_withTestcase.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10680>
_______________________________________

From report at bugs.python.org  Sun Jan 30 12:57:36 2011
From: report at bugs.python.org (Steven Bethard)
Date: Sun, 30 Jan 2011 11:57:36 +0000
Subject: [issue10680] argparse: titles and add_mutually_exclusive_group don't
	mix (even with workaround)
In-Reply-To: <1292083248.97.0.928495782189.issue10680@psf.upfronthosting.co.za>
Message-ID: <1296388656.56.0.654039778643.issue10680@psf.upfronthosting.co.za>


Changes by Steven Bethard <steven.bethard at gmail.com>:


Removed file: http://bugs.python.org/file20548/issue10680_withTestcase.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10680>
_______________________________________

From report at bugs.python.org  Sun Jan 30 12:57:41 2011
From: report at bugs.python.org (Steven Bethard)
Date: Sun, 30 Jan 2011 11:57:41 +0000
Subject: [issue10680] argparse: titles and add_mutually_exclusive_group don't
	mix (even with workaround)
In-Reply-To: <1292083248.97.0.928495782189.issue10680@psf.upfronthosting.co.za>
Message-ID: <1296388661.9.0.88430993507.issue10680@psf.upfronthosting.co.za>


Changes by Steven Bethard <steven.bethard at gmail.com>:


Removed file: http://bugs.python.org/file20114/argparse.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10680>
_______________________________________

From report at bugs.python.org  Sun Jan 30 13:19:51 2011
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 30 Jan 2011 12:19:51 +0000
Subject: [issue10680] argparse: titles and add_mutually_exclusive_group don't
	mix (even with workaround)
In-Reply-To: <1292083248.97.0.928495782189.issue10680@psf.upfronthosting.co.za>
Message-ID: <1296389991.03.0.204551352134.issue10680@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

I haven't started yet actually releasing, so this got in as r88263.

----------
nosy: +georg.brandl
resolution:  -> fixed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10680>
_______________________________________

From report at bugs.python.org  Sun Jan 30 13:42:34 2011
From: report at bugs.python.org (=?utf-8?q?C=C3=A9dric_Krier?=)
Date: Sun, 30 Jan 2011 12:42:34 +0000
Subject: [issue7502] All DocTestCase instances compare and hash equal to each
	other
In-Reply-To: <1260757418.81.0.639344471031.issue7502@psf.upfronthosting.co.za>
Message-ID: <1296391354.83.0.108927452732.issue7502@psf.upfronthosting.co.za>


C?dric Krier <cedric.krier at b2ck.com> added the comment:

Here is a patch that defines __eq__ and __hash__ on DocTestCase.

----------
keywords: +patch
nosy: +ced
Added file: http://bugs.python.org/file20618/doctestcase_eq_hash.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7502>
_______________________________________

From report at bugs.python.org  Sun Jan 30 13:53:18 2011
From: report at bugs.python.org (Brian Curtin)
Date: Sun, 30 Jan 2011 12:53:18 +0000
Subject: [issue11069] IDLE crashes when Stack Viewer opened
In-Reply-To: <1296354977.38.0.0551219398601.issue11069@psf.upfronthosting.co.za>
Message-ID: <1296391998.35.0.998875982323.issue11069@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

This should be back-ported to the maintenance branch as well. I can take care of that if Georg is busy with release-related stuff.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11069>
_______________________________________

From report at bugs.python.org  Sun Jan 30 14:21:09 2011
From: report at bugs.python.org (Steven Bethard)
Date: Sun, 30 Jan 2011 13:21:09 +0000
Subject: [issue10680] argparse: titles and add_mutually_exclusive_group don't
	mix (even with workaround)
In-Reply-To: <1292083248.97.0.928495782189.issue10680@psf.upfronthosting.co.za>
Message-ID: <1296393669.94.0.927444381353.issue10680@psf.upfronthosting.co.za>


Steven Bethard <steven.bethard at gmail.com> added the comment:

Awesome, thanks! Do you want to apply to 2.7 or should I?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10680>
_______________________________________

From report at bugs.python.org  Sun Jan 30 14:29:45 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 30 Jan 2011 13:29:45 +0000
Subject: [issue11071] What's New review comments
In-Reply-To: <1296394185.46.0.874389567772.issue11071@psf.upfronthosting.co.za>
Message-ID: <1296394185.46.0.874389567772.issue11071@psf.upfronthosting.co.za>


New submission from Nick Coghlan <ncoghlan at gmail.com>:

Reviewing the What's New docs, this seemed like the easiest way to give Raymond a list of things I noticed:

- first sentence in the "ast" module section needs rewording (currently includes fragments from a couple of different phrasings)

- in the "dis" module section, dis.dis has also acquired the ability to disassemble source string directly, avoiding the need to compile them manually first (see issue 6507).

- in the "dbm" module section, there is another case of a sentence containing fragments from two different phrasings

- the new "handler of last resort" functionality in the logging module deserves a mention (see issue 10626 and the explanation at http://docs.python.org/dev/howto/logging.html#what-happens-if-no-configuration-is-provided)

- Vinay's rewrite of the logging module docs to be significantly more approachable (by splitting them into the raw logging API docs and the "read-as-much-as-you-need-to" logging HOWTO) is also a notable and welcome change.

----------
assignee: rhettinger
components: Documentation
messages: 127529
nosy: ncoghlan, rhettinger
priority: normal
severity: normal
status: open
title: What's New review comments
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11071>
_______________________________________

From report at bugs.python.org  Sun Jan 30 14:43:02 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 30 Jan 2011 13:43:02 +0000
Subject: [issue11071] What's New review comments
In-Reply-To: <1296394185.46.0.874389567772.issue11071@psf.upfronthosting.co.za>
Message-ID: <1296394982.56.0.140212121503.issue11071@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

A couple more in the Build and CAPI section:

- "The is a new function" should be "There is a new function"

- "The PyUnicode_CompareWithASCIIString() now" either needs to drop the "The" or add "function" before the "now". 

It's fascinating to read all that and realise how much actually has been done since 3.1 came out.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11071>
_______________________________________

From report at bugs.python.org  Sun Jan 30 14:55:36 2011
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 30 Jan 2011 13:55:36 +0000
Subject: [issue10680] argparse: titles and add_mutually_exclusive_group don't
	mix (even with workaround)
In-Reply-To: <1292083248.97.0.928495782189.issue10680@psf.upfronthosting.co.za>
Message-ID: <1296395736.76.0.846481035951.issue10680@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Please do.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10680>
_______________________________________

From report at bugs.python.org  Sun Jan 30 14:55:47 2011
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 30 Jan 2011 13:55:47 +0000
Subject: [issue11069] IDLE crashes when Stack Viewer opened
In-Reply-To: <1296354977.38.0.0551219398601.issue11069@psf.upfronthosting.co.za>
Message-ID: <1296395747.4.0.603133388607.issue11069@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Please do.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11069>
_______________________________________

From report at bugs.python.org  Sun Jan 30 15:05:00 2011
From: report at bugs.python.org (Alan Isaac)
Date: Sun, 30 Jan 2011 14:05:00 +0000
Subject: [issue11023] pep 227 missing text
In-Reply-To: <1296134235.25.0.738218358402.issue11023@psf.upfronthosting.co.za>
Message-ID: <1296396300.23.0.00488866884519.issue11023@psf.upfronthosting.co.za>


Alan Isaac <alan.isaac at gmail.com> added the comment:

Bear with my confusion about your response.  Are you saying that CPython documentation bugs cannot be submitted here, or that this does not constitute a CPython documentation bug?  I assume the latter.  But then, can you tell me where to find the correct CPython documentation after I read the following quote from PEP 277?

http://www.python.org/dev/peps/pep-0227/
    "Implementation

    XXX Jeremy, is this still the case?

    The implementation for C Python uses flat closures [1]."

In case you might care about a user confusion ...  Your reply left me puzzled that PEPs that have reached the standards track would not be considered part of the CPython documentation distribution.

Thank you,
Alan Isaac

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11023>
_______________________________________

From report at bugs.python.org  Sun Jan 30 15:05:59 2011
From: report at bugs.python.org (Steven Bethard)
Date: Sun, 30 Jan 2011 14:05:59 +0000
Subject: [issue10680] argparse: titles and add_mutually_exclusive_group don't
	mix (even with workaround)
In-Reply-To: <1292083248.97.0.928495782189.issue10680@psf.upfronthosting.co.za>
Message-ID: <1296396359.74.0.242662447823.issue10680@psf.upfronthosting.co.za>


Steven Bethard <steven.bethard at gmail.com> added the comment:

Done in r88268. Thanks again everyone!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10680>
_______________________________________

From report at bugs.python.org  Sun Jan 30 15:07:41 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 30 Jan 2011 14:07:41 +0000
Subject: [issue11071] What's New review comments
In-Reply-To: <1296394185.46.0.874389567772.issue11071@psf.upfronthosting.co.za>
Message-ID: <1296396461.44.0.306276453059.issue11071@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Another significant logging change: the addition of the "style" parameter for Formatter objects (allowing the use of str.format and string.Template style substitution instead of percent formatting)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11071>
_______________________________________

From report at bugs.python.org  Sun Jan 30 15:18:13 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 30 Jan 2011 14:18:13 +0000
Subject: [issue11071] What's New review comments
In-Reply-To: <1296394185.46.0.874389567772.issue11071@psf.upfronthosting.co.za>
Message-ID: <1296397093.04.0.521556187292.issue11071@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

The last two logging changes potentially worth mentioning that I noticed:

- simple callables can now be supplied as logging filters (see the version 3.2 note in http://docs.python.org/dev/library/logging#filter-objects)

- the logging API docs now include a section dedicated to the available attributes on LogRecord instances (http://docs.python.org/dev/library/logging#filter-objects). This makes it much easier to write Filter and Formatter objects that reference these attributes.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11071>
_______________________________________

From report at bugs.python.org  Sun Jan 30 15:23:33 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 30 Jan 2011 14:23:33 +0000
Subject: [issue11071] What's New review comments
In-Reply-To: <1296394185.46.0.874389567772.issue11071@psf.upfronthosting.co.za>
Message-ID: <1296397413.9.0.743485399501.issue11071@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

I was wrong, I found one more potentially notable logging change:
http://docs.python.org/dev/library/logging#logging.setLogRecordFactory

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11071>
_______________________________________

From report at bugs.python.org  Sun Jan 30 15:26:08 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 30 Jan 2011 14:26:08 +0000
Subject: [issue11071] What's New review comments
In-Reply-To: <1296394185.46.0.874389567772.issue11071@psf.upfronthosting.co.za>
Message-ID: <1296397568.38.0.60156875266.issue11071@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Adding Vinay, given the number of logging changes in 3.2 that don't appear to be in the What's New yet (the only logging change noted there at the moment is the inclusion of PEP 391)

----------
nosy: +vinay.sajip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11071>
_______________________________________

From report at bugs.python.org  Sun Jan 30 15:44:08 2011
From: report at bugs.python.org (David Meier)
Date: Sun, 30 Jan 2011 14:44:08 +0000
Subject: [issue11068] Python 2.7.1 Idle traceback on OS X (10.6.6)
In-Reply-To: <1296339702.88.0.766799420032.issue11068@psf.upfronthosting.co.za>
Message-ID: <1296398648.59.0.282983997077.issue11068@psf.upfronthosting.co.za>


David Meier <djmeier at gmail.com> added the comment:

Removing the 10.6 specific Python 2.7.1 installation (with the instructions provided by Ned) and reinstalling the 10.3-10.6 32bit installation fixed the aforementioned segfault.  Thanks for the information, however, I do think it should be noted on the download page that there are problems with the 10.6 32/64-bit version and it is safer to go the 32-bit only installer unless there is a specific need.  I did not see any caveats mentioned when I went to download it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11068>
_______________________________________

From report at bugs.python.org  Sun Jan 30 16:17:10 2011
From: report at bugs.python.org (Miki Tebeka)
Date: Sun, 30 Jan 2011 15:17:10 +0000
Subject: [issue9527] Add aware local time support to datetime module
In-Reply-To: <1281066500.35.0.441616276688.issue9527@psf.upfronthosting.co.za>
Message-ID: <1296400630.89.0.392310347149.issue9527@psf.upfronthosting.co.za>


Changes by Miki Tebeka <miki.tebeka at gmail.com>:


----------
nosy:  -tebeka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9527>
_______________________________________

From report at bugs.python.org  Sun Jan 30 16:50:34 2011
From: report at bugs.python.org (Marcin Bachry)
Date: Sun, 30 Jan 2011 15:50:34 +0000
Subject: [issue11048] "import ctypes" causes segfault on read-only filesystem
In-Reply-To: <1296234309.62.0.290829997988.issue11048@psf.upfronthosting.co.za>
Message-ID: <1296402634.04.0.519957258003.issue11048@psf.upfronthosting.co.za>


Marcin Bachry <hegel666 at gmail.com> added the comment:

This patch fixes issue with unitialized variable which makes ctypes crash in error handler.

Note that for you it merely turns "Segmentation fault" into MemoryError exception.  Python ships with buggy version of libffi, which tries to allocate memory using mmap() over a temporary file (the one seen in strace output above) instead of just doing mmap(MAP_ANONYMOUS|MAP_PRIVATE).  The bug is fixed in this libffi commit:

  https://github.com/atgreen/libffi/commit/eaf444eabc4c78703c0f98ac0197b1619c1b1bef

Until Python's libffi is updated, you can do "mount -t tmpfs none /dev/shm".  It's good to have "tmpfs" mounted anyway, just like "proc" and "sysfs".

----------
keywords: +patch
nosy: +marcin.bachry
Added file: http://bugs.python.org/file20619/ctypes-erofs-crash.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11048>
_______________________________________

From report at bugs.python.org  Sun Jan 30 16:52:56 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Sun, 30 Jan 2011 15:52:56 +0000
Subject: [issue11059] Mercurial fails on code.python.org repo
In-Reply-To: <1296304961.11.0.1358070149.issue11059@psf.upfronthosting.co.za>
Message-ID: <1296402776.28.0.151199525461.issue11059@psf.upfronthosting.co.za>


Steffen Daode Nurpmeso <sdaoden at googlemail.com> added the comment:

'Had to look on a sunday once again, and it is still impossible to clone branches/release2.7-maint.
In the meanwhile the Mercurial people from <http://mercurial.selenic.com> reacted - they play the ball back to python.org.
*However*: there are a lot of Issues at <http://mercurial.selenic.com/bts/issueXY> (try 2606, 2602, 2595, my 2239 and possibly others).

----------
status: closed -> open
title: code.python.org repo failures introduced! -> Mercurial fails on code.python.org repo
versions: +Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11059>
_______________________________________

From report at bugs.python.org  Sun Jan 30 17:12:36 2011
From: report at bugs.python.org (Ron Adam)
Date: Sun, 30 Jan 2011 16:12:36 +0000
Subject: [issue10716] Modernize pydoc to use CSS
In-Reply-To: <1292491539.55.0.135732310832.issue10716@psf.upfronthosting.co.za>
Message-ID: <1296403956.94.0.696729594684.issue10716@psf.upfronthosting.co.za>


Ron Adam <ron_adam at users.sourceforge.net> added the comment:

A reminder: Check for instances where html.escape is not called on data inserted into the html pages.

I'll update the patch as the non-css (error handling) parts made it into python 3.2.  :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10716>
_______________________________________

From report at bugs.python.org  Sun Jan 30 17:15:58 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Sun, 30 Jan 2011 16:15:58 +0000
Subject: [issue11059] Mercurial fails on code.python.org repo
In-Reply-To: <1296304961.11.0.1358070149.issue11059@psf.upfronthosting.co.za>
Message-ID: <1296404158.8.0.771338486351.issue11059@psf.upfronthosting.co.za>


Steffen Daode Nurpmeso <sdaoden at googlemail.com> added the comment:

<http://mercurial.selenic.com/bts/issue2595> says "code.python.org/hg often seems unstable.", so it seems to be a well known thing.  I leave this issue now open nevertheless, and let some experienced Python.org user  decide what to do with it.  (Antoine Pitrou, you are nosy, and it seems i have completely missed your hint ("Works fine here" did not count for me) - will you close that as approbiate?)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11059>
_______________________________________

From report at bugs.python.org  Sun Jan 30 17:17:39 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 30 Jan 2011 16:17:39 +0000
Subject: [issue11059] Mercurial fails on code.python.org repo
In-Reply-To: <1296304961.11.0.1358070149.issue11059@psf.upfronthosting.co.za>
Message-ID: <1296404259.36.0.656567853642.issue11059@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> 'Had to look on a sunday once again, and it is still impossible to
> clone branches/release2.7-maint.

It failed here on one attempt and succeeded on others. "hg verify" ran fine too, including on the server.

I'm closing the issue again; in all likelihood, this is either a transient network issue, or a Mercurial bug - and certainly not a bug in Python itself which is what this tracker is for ;)

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11059>
_______________________________________

From report at bugs.python.org  Sun Jan 30 17:46:02 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sun, 30 Jan 2011 16:46:02 +0000
Subject: [issue11048] "import ctypes" causes segfault on read-only filesystem
In-Reply-To: <1296234309.62.0.290829997988.issue11048@psf.upfronthosting.co.za>
Message-ID: <1296405962.69.0.840459622834.issue11048@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

It would be nice to add a unit test to this patch.  I don't think messing with read-only filesystems is feasible in regrtest, but it seems from reading _ctypes_alloc_callback() source that similar behavior can be triggered by passing a failing converters list to a ctypes function constructor.

A nit-pick: it would be easier to verify that all CThunkObject fields are initialized if initialization was done in the same order as declaration:


typedef struct {
    PyObject_VAR_HEAD
    ...
    PyObject *callable;
    PyObject *restype;
    SETFUNC setfunc;
    ffi_type *ffi_restype;
    ffi_type *atypes[1];
} CThunkObject;


In other words, "p->restype = NULL;" should go after "p->callable = NULL;".

----------
nosy: +belopolsky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11048>
_______________________________________

From report at bugs.python.org  Sun Jan 30 18:50:03 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 30 Jan 2011 17:50:03 +0000
Subject: [issue11071] What's New review comments
In-Reply-To: <1296394185.46.0.874389567772.issue11071@psf.upfronthosting.co.za>
Message-ID: <1296409803.62.0.635766723188.issue11071@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Nick, thanks for the read-through and comments.

Later this week, will get add a section of logging.

Other people are also welcome to use this tracker item for other comments.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11071>
_______________________________________

From report at bugs.python.org  Sun Jan 30 18:56:33 2011
From: report at bugs.python.org (devurandom)
Date: Sun, 30 Jan 2011 17:56:33 +0000
Subject: [issue6715] xz compressor support
In-Reply-To: <1250502444.31.0.107447392137.issue6715@psf.upfronthosting.co.za>
Message-ID: <1296410193.02.0.945942799758.issue6715@psf.upfronthosting.co.za>


Changes by devurandom <devurandom at gmx.net>:


----------
nosy:  -devurandom

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6715>
_______________________________________

From report at bugs.python.org  Sun Jan 30 20:40:09 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 30 Jan 2011 19:40:09 +0000
Subject: [issue7502] All DocTestCase instances compare and hash equal to each
	other
In-Reply-To: <1260757418.81.0.639344471031.issue7502@psf.upfronthosting.co.za>
Message-ID: <1296416409.02.0.234297476914.issue7502@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
stage: needs patch -> patch review
versions: +Python 3.3 -Python 2.6, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7502>
_______________________________________

From report at bugs.python.org  Sun Jan 30 20:42:34 2011
From: report at bugs.python.org (Brian Curtin)
Date: Sun, 30 Jan 2011 19:42:34 +0000
Subject: [issue11069] IDLE crashes when Stack Viewer opened
In-Reply-To: <1296354977.38.0.0551219398601.issue11069@psf.upfronthosting.co.za>
Message-ID: <1296416554.27.0.632249435675.issue11069@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

Fixed in release31-maint in r88269.

----------
stage:  -> committed/rejected

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11069>
_______________________________________

From report at bugs.python.org  Sun Jan 30 21:26:09 2011
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 30 Jan 2011 20:26:09 +0000
Subject: [issue10990] tests mutating sys.gettrace() w/o re-instating previous
	state
In-Reply-To: <1295824876.68.0.687534068337.issue10990@psf.upfronthosting.co.za>
Message-ID: <1296419169.27.0.91725069719.issue10990@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


Removed file: http://bugs.python.org/file20581/issue10990.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10990>
_______________________________________

From report at bugs.python.org  Sun Jan 30 21:26:39 2011
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 30 Jan 2011 20:26:39 +0000
Subject: [issue10990] tests mutating sys.gettrace() w/o re-instating previous
	state
In-Reply-To: <1295824876.68.0.687534068337.issue10990@psf.upfronthosting.co.za>
Message-ID: <1296419199.74.0.589471204054.issue10990@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Sorry about that. New patch attached.

----------
Added file: http://bugs.python.org/file20620/issue_10990.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10990>
_______________________________________

From report at bugs.python.org  Sun Jan 30 21:44:19 2011
From: report at bugs.python.org (Paul Moore)
Date: Sun, 30 Jan 2011 20:44:19 +0000
Subject: [issue9931] test_ttk_guionly hangs on XP5
In-Reply-To: <1285273632.39.0.298869124825.issue9931@psf.upfronthosting.co.za>
Message-ID: <1296420259.31.0.313126787428.issue9931@psf.upfronthosting.co.za>


Paul Moore <p.f.moore at gmail.com> added the comment:

Patch looks good to me. Can this be applied? As a temporary workaround I have set my buildbot to run interactively. Once the fix is applied, I will switch back to running as a service.

----------
keywords: +buildbot

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9931>
_______________________________________

From report at bugs.python.org  Sun Jan 30 21:47:37 2011
From: report at bugs.python.org (Paul Moore)
Date: Sun, 30 Jan 2011 20:47:37 +0000
Subject: [issue9931] test_ttk_guionly hangs on XP5
In-Reply-To: <1285273632.39.0.298869124825.issue9931@psf.upfronthosting.co.za>
Message-ID: <1296420457.51.0.267653260392.issue9931@psf.upfronthosting.co.za>


Changes by Paul Moore <p.f.moore at gmail.com>:


----------
nosy: +gpolo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9931>
_______________________________________

From report at bugs.python.org  Sun Jan 30 21:56:34 2011
From: report at bugs.python.org (Isaul Vargas)
Date: Sun, 30 Jan 2011 20:56:34 +0000
Subject: [issue571767] string.capitlize() documentation
Message-ID: <1296420994.35.0.989017224477.issue571767@psf.upfronthosting.co.za>


Isaul Vargas <isaulv at gmail.com> added the comment:

Internal python docs need to be updated.
help(str.capitalize)
still has the old incorrect documentation.

I tested this on Python 2.6 on Windows, and Python 2.7 in Ubuntu 11.04 alpha.

----------
nosy: +Dude-X -fdrake, mdcowles
type:  -> behavior
versions: +Python 2.5, Python 2.6, Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue571767>
_______________________________________

From report at bugs.python.org  Sun Jan 30 22:12:52 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Sun, 30 Jan 2011 21:12:52 +0000
Subject: [issue5863] bz2.BZ2File should accept other file-like objects.
In-Reply-To: <1240898269.47.0.592056792771.issue5863@psf.upfronthosting.co.za>
Message-ID: <1296421972.79.0.442339363972.issue5863@psf.upfronthosting.co.za>


Nadeem Vawda <nadeem.vawda at gmail.com> added the comment:

OK, I've rewritten the whole bz2 module (patch attached), and I think it is now ready for review. The BZ2File implementation is a cleaned-up version of the one from my previous patch, with some further additions. I've factored out the common compressor/decompressor stuff into classes Compressor and Decompressor in the _bz2 extension module; with these, BZ2Compressor, BZ2Decompressor, compress() and decompress() are trivial to implement in Python.

My earlier efficiency concerns seem to have been unfounded; I ran some quick tests with a 4MB bz2 file, and there wasn't any measurable performance difference from the existing all-C implementation.

I have added a peek() method to BZ2File, in accordance with Antoine's suggestion, but it's not clear how it should interpret its argument. I followed the lead of io.BufferedReader, and simply ignored the arg, returning whatever data as is already buffered. The patch also includes tests for peek() in test_bz2, based on test_io's BufferedRWPairTest.

Also, while looking at io.BufferedReader's implementation, I noticed that it doesn't actually seem to use raw.peek() at all. If this is correct, then perhaps peek() is unnecessary, and shouldn't be added.

The patch also adds a property 'eof' to BZ2Decompressor, so that the user can test whether EOF has been reached on the compressed stream.

For the new files (Modules/_bz2module.c and Lib/bz2.py), I'm guessing there should be some license boilerplate stuff added at the top of each. I wasn't sure exactly what this should look like, though - some advice would be helpful here.

----------
Added file: http://bugs.python.org/file20621/bz2-v3.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5863>
_______________________________________

From report at bugs.python.org  Sun Jan 30 22:15:08 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 30 Jan 2011 21:15:08 +0000
Subject: [issue9973] Sometimes buildbot fails to cleanup working copy
In-Reply-To: <1285691660.36.0.731785440446.issue9973@psf.upfronthosting.co.za>
Message-ID: <1296422108.63.0.147955803783.issue9973@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

As far as I can tell, the same change also needs to be done in build-amd64.bat and clean-amd64.bat.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9973>
_______________________________________

From report at bugs.python.org  Sun Jan 30 22:19:43 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 30 Jan 2011 21:19:43 +0000
Subject: [issue9973] Sometimes buildbot fails to cleanup working copy
In-Reply-To: <1285691660.36.0.731785440446.issue9973@psf.upfronthosting.co.za>
Message-ID: <1296422383.82.0.617191090326.issue9973@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

By the way, the order of these lines in clean-amd64.bat looks wrong:

cd PCbuild
@echo Deleting .pyc/.pyo files ...
del /s Lib\*.pyc Lib\*.pyo

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9973>
_______________________________________

From report at bugs.python.org  Sun Jan 30 22:23:44 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 30 Jan 2011 21:23:44 +0000
Subject: [issue9973] Sometimes buildbot fails to cleanup working copy
In-Reply-To: <1285691660.36.0.731785440446.issue9973@psf.upfronthosting.co.za>
Message-ID: <1296422624.94.0.742418120207.issue9973@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Oh, and the regrtest command line in test-amd64.bat lacks some options ("-rwW -n") compared to test.bat.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9973>
_______________________________________

From report at bugs.python.org  Sun Jan 30 22:29:05 2011
From: report at bugs.python.org (David Bolen)
Date: Sun, 30 Jan 2011 21:29:05 +0000
Subject: [issue9973] Sometimes buildbot fails to cleanup working copy
In-Reply-To: <1285691660.36.0.731785440446.issue9973@psf.upfronthosting.co.za>
Message-ID: <1296422945.45.0.0851649170404.issue9973@psf.upfronthosting.co.za>


David Bolen <db3l.net at gmail.com> added the comment:

Probably - it's just a general sequencing change, so I suppose should apply equally to all platforms.  I suppose even better would be to consolidate the two clean scripts into one (with a parameter for 32 v. 64), but just patching both is less of a change.  Unrelated, but it's interesting how the amd64 script makes sure to be in the PCBuild tree before deleting byte compiled files, but the standard script doesn't.

Oh, I should probably also update my prior thought in this ticket, since based on a python-dev thread Hirokazu pointed out that just having things at the end of test.bat could be exposed if the actual test itself never returns to the script.

That might have higher odds than the build master losing contact with the slave between build and clean step, so the original patch is likely the better choice.  Or maybe do it in both both places.  

But just moving things to clean first would cover the vast majority of cases I seem to see on my build slaves, which only rarely lose contact with the master.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9973>
_______________________________________

From report at bugs.python.org  Sun Jan 30 22:52:43 2011
From: report at bugs.python.org (David Bolen)
Date: Sun, 30 Jan 2011 21:52:43 +0000
Subject: [issue9931] test_ttk_guionly hangs on XP5
In-Reply-To: <1285273632.39.0.298869124825.issue9931@psf.upfronthosting.co.za>
Message-ID: <1296424363.72.0.748774981766.issue9931@psf.upfronthosting.co.za>


David Bolen <db3l.net at gmail.com> added the comment:

Perhaps somewhat orthogonal to the patch, but in terms of the original hang issue, does your service definition have the "interact with desktop" option checked?  That ought to permit any normal UI processing to take place as if you were running it interactively.

----------
nosy: +db3l

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9931>
_______________________________________

From report at bugs.python.org  Sun Jan 30 23:07:58 2011
From: report at bugs.python.org (John J Lee)
Date: Sun, 30 Jan 2011 22:07:58 +0000
Subject: [issue2193] Cookie Colon Name Bug
In-Reply-To: <1203992843.27.0.867127322082.issue2193@psf.upfronthosting.co.za>
Message-ID: <1296425278.53.0.550730919237.issue2193@psf.upfronthosting.co.za>


John J Lee <jjlee at users.sourceforge.net> added the comment:

I agree with And Clover that Carsten Klein's comments in #msg127366 are not correct, for the reason that And stated.

Also, Carsten repeats again the idea that the trac issue is about the trac server failing to generate appropriate cookies -- but that issue was in fact about trac's processing of cookies generated by servers other than trac.  In that particular case, the other server was probably under the control of the same group of people, but that isn't true in general.  Please read all the comments before adding more comments.

Re #msg127368: I don't think the patch applied to trac is relevant here.  "Somebody" should write a patch for module Cookie, and then it can be reviewed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2193>
_______________________________________

From report at bugs.python.org  Sun Jan 30 23:13:30 2011
From: report at bugs.python.org (Giampaolo Rodola')
Date: Sun, 30 Jan 2011 22:13:30 +0000
Subject: [issue11051] system calls per import
In-Reply-To: <1296254973.71.0.897914319387.issue11051@psf.upfronthosting.co.za>
Message-ID: <1296425610.75.0.23868213152.issue11051@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/issue11051>
_______________________________________

From report at bugs.python.org  Sun Jan 30 23:28:24 2011
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 30 Jan 2011 22:28:24 +0000
Subject: [issue10512] regrtest ResourceWarning - unclosed sockets and files
In-Reply-To: <1290506536.77.0.313292165719.issue10512@psf.upfronthosting.co.za>
Message-ID: <1296426504.2.0.962225719643.issue10512@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Attached is a simpler fix for test_cgi so it can get in for Python 3.2. You can reproduce the failure if you run ``./python -W error -m test test_cgi``.

Georg, can I commit?

----------
assignee:  -> georg.brandl
nosy: +brett.cannon, georg.brandl
Added file: http://bugs.python.org/file20622/issue10512.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10512>
_______________________________________

From report at bugs.python.org  Sun Jan 30 23:44:14 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 30 Jan 2011 22:44:14 +0000
Subject: [issue9931] test_ttk_guionly hangs on XP5
In-Reply-To: <1285273632.39.0.298869124825.issue9931@psf.upfronthosting.co.za>
Message-ID: <1296427454.06.0.481256109047.issue9931@psf.upfronthosting.co.za>


Changes by Nick Coghlan <ncoghlan at gmail.com>:


----------
priority: normal -> high

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9931>
_______________________________________

From report at bugs.python.org  Sun Jan 30 23:52:00 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 30 Jan 2011 22:52:00 +0000
Subject: [issue11071] What's New review comments
In-Reply-To: <1296394185.46.0.874389567772.issue11071@psf.upfronthosting.co.za>
Message-ID: <1296427920.21.0.680997553835.issue11071@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Correct docs links for LogRecord attributes section: http://docs.python.org/dev/library/logging#logrecord-attributes

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11071>
_______________________________________

From report at bugs.python.org  Mon Jan 31 00:06:04 2011
From: report at bugs.python.org (Paul Moore)
Date: Sun, 30 Jan 2011 23:06:04 +0000
Subject: [issue9931] test_ttk_guionly hangs on XP5
In-Reply-To: <1296424363.72.0.748774981766.issue9931@psf.upfronthosting.co.za>
Message-ID: <AANLkTi=ZBaum7cBFWKwkmNmUuNEetAUsXq21wsYsMo5a@mail.gmail.com>


Paul Moore <p.f.moore at gmail.com> added the comment:

> Perhaps somewhat orthogonal to the patch, but in terms of the original hang issue, does your service definition have the "interact with desktop" option checked? ?That ought to permit any normal UI processing to take place as if you were running it interactively.

It runs as a specific user, not as LocalSystem (and only LocalSystem
has the "interact with desktop" checkbox, so yes, I think it does...)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9931>
_______________________________________

From report at bugs.python.org  Mon Jan 31 00:16:23 2011
From: report at bugs.python.org (David Bolen)
Date: Sun, 30 Jan 2011 23:16:23 +0000
Subject: [issue9931] test_ttk_guionly hangs on XP5
In-Reply-To: <1285273632.39.0.298869124825.issue9931@psf.upfronthosting.co.za>
Message-ID: <1296429383.68.0.1746111366.issue9931@psf.upfronthosting.co.za>


David Bolen <db3l.net at gmail.com> added the comment:

If I recall correctly, if you're not using localsystem then its much tougher, as by default it won't have access to your interactive desktop, just something internal that you won't see, maybe just a hidden windows station.  You're right that the interact setting is only for localsystem.

It's been many years, but I think I had some code that located and attached to the interactive desktop (if one was currently available) from within a background service that I used in a remote management system.  Our remote service (functioned similarly to rshd) also ran under a specific user.

At least in theory I think you might be able to tweak the local buildbot code to execute any tests from within a child process that does the same thing first.  In the end it's only the executing test code that needs the access, not the buildbot itself.

If I get a chance I'll see if I can scrounge up what I did, but will take that off-line from this ticket since it's a broader question.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9931>
_______________________________________

From report at bugs.python.org  Mon Jan 31 00:37:31 2011
From: report at bugs.python.org (Giampaolo Rodola')
Date: Sun, 30 Jan 2011 23:37:31 +0000
Subject: [issue11072] Add MLSD command support to ftplib
In-Reply-To: <1296430651.22.0.68039486547.issue11072@psf.upfronthosting.co.za>
Message-ID: <1296430651.22.0.68039486547.issue11072@psf.upfronthosting.co.za>


New submission from Giampaolo Rodola' <g.rodola at gmail.com>:

>From RFC-3659:

   The MLST and MLSD commands are intended to standardize the file and
   directory information returned by the server-FTP process.  These
   commands differ from the LIST command in that the format of the
   replies is strictly defined although extensible.

The patch in attachment adds support for MLSD command.
This should ease the development of ftp clients which are forced to parse un-standardized LIST responses via dir() or retrlines() methods to obtain meaningful data for the directory listing.

Example:


>>> import ftplib
>>> from pprint import pprint as pp
>>> f = ftplib.FTP()
>>> f.connect("localhost")
>>> f.login("anonymous")
>>> ls = f.mlsd()
>>> pp(ls)
 {'modify': 20100814164724,
  'name': 'svnmerge.py',
  'perm': 'r',
  'size': 90850,
  'type': 'file',
  'unique': '80718b568'},
 {'modify': 20101207185033,
  'name': 'README',
  'perm': 'r',
  'size': 53731,
  'type': 'file',
  'unique': '80718aafe'},
 {'modify': 20100417183215,
  'name': 'install-sh',
  'perm': 'r',
  'size': 7122,
  'type': 'file',
  'unique': '80718b2d2'},
 {'modify': 20110129210053,
  'name': 'Include',
  'perm': 'el',
  'size': 4096,
  'type': 'dir',
  'unique': '8071a2bc4'}]
>>>

----------
files: ftplib_mlsd.patch
keywords: patch
messages: 127562
nosy: giampaolo.rodola, pitrou
priority: normal
severity: normal
status: open
title: Add MLSD command support to ftplib
versions: Python 3.3
Added file: http://bugs.python.org/file20623/ftplib_mlsd.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11072>
_______________________________________

From report at bugs.python.org  Mon Jan 31 01:54:31 2011
From: report at bugs.python.org (Ned Deily)
Date: Mon, 31 Jan 2011 00:54:31 +0000
Subject: [issue10940] IDLE 3.2 hangs with Cmd-M hotkey on OS X 10.6 with
	64-bit installer and A/S Tk 8.5
In-Reply-To: <1295391844.43.0.912463306116.issue10940@psf.upfronthosting.co.za>
Message-ID: <1296435271.51.0.307784680297.issue10940@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Committed in r88270 for release in 2.7.2.

----------
status: pending -> closed
versions: +Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10940>
_______________________________________

From report at bugs.python.org  Mon Jan 31 02:26:13 2011
From: report at bugs.python.org (Giampaolo Rodola')
Date: Mon, 31 Jan 2011 01:26:13 +0000
Subject: [issue10882] Add os.sendfile()
In-Reply-To: <1294691268.76.0.727179568007.issue10882@psf.upfronthosting.co.za>
Message-ID: <1296437173.79.0.947463517879.issue10882@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

In case someone is interested in statistics, I wrote a sendfile() wrapper by using ctypes for pyftpdlib and benchmark results are quite impressive:
http://code.google.com/p/pyftpdlib/issues/detail?id=152#c5

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10882>
_______________________________________

From report at bugs.python.org  Mon Jan 31 02:40:24 2011
From: report at bugs.python.org (=?utf-8?q?Westley_Mart=C3=ADnez?=)
Date: Mon, 31 Jan 2011 01:40:24 +0000
Subject: [issue9362] Make exit/quit hint more novice friendly
In-Reply-To: <1279913042.97.0.618415832845.issue9362@psf.upfronthosting.co.za>
Message-ID: <1296438024.73.0.844477338215.issue9362@psf.upfronthosting.co.za>


Westley Mart?nez <anikom15 at gmail.com> added the comment:

This is annoying. Every beginner's Python tutorial I've read made it very clear how to exactly exit the interactive shell. Ctrl has been in use for years. Changing it for novices' sake is ridiculous. Do we need to expand every abbreviation? Python will turn into Java (joke). As for Ctrl-D or Ctrl-Z, I think it's fine the way it is. Python is used for scripting, and Windows administators are familiar with Ctrl-Z for EOF but may not necessarily be familiar with Ctrl-D.

Ok, in final, I think the only thing that might be changed is the shell's opening message:

Python 3.1.3 (r313:86834, Jan 28 2011, 20:00:55) 
[GCC 4.5.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
Type "exit()", "quit()" or Ctrl-D (i.e. EOF) to exit.
>>> 

On Windows, Ctrl-D is replaced with Ctrl-Z.

----------
nosy: +anikom15

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9362>
_______________________________________

From report at bugs.python.org  Mon Jan 31 02:42:52 2011
From: report at bugs.python.org (Roy Smith)
Date: Mon, 31 Jan 2011 01:42:52 +0000
Subject: [issue11073] threading.Thread documentation can be improved
In-Reply-To: <1296438172.29.0.214693848128.issue11073@psf.upfronthosting.co.za>
Message-ID: <1296438172.29.0.214693848128.issue11073@psf.upfronthosting.co.za>


New submission from Roy Smith <roy at panix.com>:

The documentation for the threading.Thread constructor says:

"target is the callable object to be invoked by the run() method. Defaults to None, meaning nothing is called."

This could be improved by explicitly stating that target is called in a static context.  As written, it takes a bit of thought (and experimentation) to be sure of that.

----------
assignee: docs at python
components: Documentation
messages: 127566
nosy: docs at python, roysmith
priority: normal
severity: normal
status: open
title: threading.Thread documentation can be improved
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11073>
_______________________________________

From report at bugs.python.org  Mon Jan 31 03:16:46 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Mon, 31 Jan 2011 02:16:46 +0000
Subject: [issue11016] Add S_ISDOOR to the stat module
In-Reply-To: <1296039446.69.0.66523737586.issue11016@psf.upfronthosting.co.za>
Message-ID: <1296440206.13.0.525338019083.issue11016@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

Martin, what if C posix module (or whoever) would export the symbolic constants, and update "stat.py" to use those symbolic constants?.

Do you think that would be an improvement?.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11016>
_______________________________________

From report at bugs.python.org  Mon Jan 31 03:18:05 2011
From: report at bugs.python.org (Eric Smith)
Date: Mon, 31 Jan 2011 02:18:05 +0000
Subject: [issue11072] Add MLSD command support to ftplib
In-Reply-To: <1296430651.22.0.68039486547.issue11072@psf.upfronthosting.co.za>
Message-ID: <1296440285.79.0.48807059552.issue11072@psf.upfronthosting.co.za>


Changes by Eric Smith <eric at trueblade.com>:


----------
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11072>
_______________________________________

From report at bugs.python.org  Mon Jan 31 04:10:49 2011
From: report at bugs.python.org (R. David Murray)
Date: Mon, 31 Jan 2011 03:10:49 +0000
Subject: [issue11073] threading.Thread documentation can be improved
In-Reply-To: <1296438172.29.0.214693848128.issue11073@psf.upfronthosting.co.za>
Message-ID: <1296443449.43.0.320095931032.issue11073@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I have no idea what "a static context" means, so it wouldn't make it any clearer to me.  Can you explain further what your confusion is?

----------
nosy: +r.david.murray
type:  -> feature request
versions: +Python 2.7, Python 3.1, Python 3.2 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11073>
_______________________________________

From report at bugs.python.org  Mon Jan 31 04:23:23 2011
From: report at bugs.python.org (Roy Smith)
Date: Mon, 31 Jan 2011 03:23:23 +0000
Subject: [issue11073] threading.Thread documentation can be improved
In-Reply-To: <1296438172.29.0.214693848128.issue11073@psf.upfronthosting.co.za>
Message-ID: <1296444203.23.0.0742778973692.issue11073@psf.upfronthosting.co.za>


Roy Smith <roy at panix.com> added the comment:

What I meant was whether target should be declared as @staticmethod or not.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11073>
_______________________________________

From report at bugs.python.org  Mon Jan 31 05:04:11 2011
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 31 Jan 2011 04:04:11 +0000
Subject: [issue11074] fix tokenize so it can be reloaded
In-Reply-To: <1296446651.43.0.796363573653.issue11074@psf.upfronthosting.co.za>
Message-ID: <1296446651.43.0.796363573653.issue11074@psf.upfronthosting.co.za>


New submission from Brett Cannon <brett at python.org>:

The tokenize module stores the built-in open() module in a global assignment statement. Problem is that if you reload the module, that global assignment picks up the module's own open() that came into existence during the initial import.

The attached patch fixes this by having tokenize.open() use builtins.open() instead of its own cached global version.

----------
assignee: georg.brandl
components: Library (Lib)
files: tokenize_reload.diff
keywords: easy, patch
messages: 127570
nosy: brett.cannon, georg.brandl, haypo
priority: normal
severity: normal
stage: commit review
status: open
title: fix tokenize so it can be reloaded
type: behavior
versions: Python 3.2
Added file: http://bugs.python.org/file20624/tokenize_reload.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11074>
_______________________________________

From report at bugs.python.org  Mon Jan 31 05:31:08 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 31 Jan 2011 04:31:08 +0000
Subject: [issue11071] What's New review comments
In-Reply-To: <1296394185.46.0.874389567772.issue11071@psf.upfronthosting.co.za>
Message-ID: <1296448268.82.0.45337505789.issue11071@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Eli, put your suggestions here.

Do not edit the document directly.
Right now, it's conflicting with
my pending edits.  Also, see
the instruction at the top of
the document.

----------
assignee: rhettinger -> eli.bendersky
nosy: +eli.bendersky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11071>
_______________________________________

From report at bugs.python.org  Mon Jan 31 05:33:46 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Mon, 31 Jan 2011 04:33:46 +0000
Subject: [issue11071] What's New review comments
In-Reply-To: <1296394185.46.0.874389567772.issue11071@psf.upfronthosting.co.za>
Message-ID: <1296448426.91.0.753279129374.issue11071@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

Raymond, as I said in the email sorry I wasn't aware of the issue, and Georg permitted me to commit directly to the file once the freeze is over. Maybe there was a misunderstanding.

Also, can you refer me to the part of the file you mean? I see it says "Anyone can add text to the document" but then warns that you may change it later. I have no problem with that, and I split my commit to several to make it easier to fix/reject.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11071>
_______________________________________

From report at bugs.python.org  Mon Jan 31 05:34:47 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 31 Jan 2011 04:34:47 +0000
Subject: [issue11071] What's New review comments
In-Reply-To: <1296394185.46.0.874389567772.issue11071@psf.upfronthosting.co.za>
Message-ID: <1296448487.36.0.377934010334.issue11071@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Can you join IRC #python for a bit?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11071>
_______________________________________

From report at bugs.python.org  Mon Jan 31 05:43:33 2011
From: report at bugs.python.org (Glenn Linderman)
Date: Mon, 31 Jan 2011 04:43:33 +0000
Subject: [issue10479] cgitb.py should assume a binary stream for output
In-Reply-To: <1290317837.02.0.152908438377.issue10479@psf.upfronthosting.co.za>
Message-ID: <1296449013.51.0.99114300484.issue10479@psf.upfronthosting.co.za>


Glenn Linderman <v+python at g.nevcal.com> added the comment:

So since cgi.py was fixed to use the .buffer attribute of sys.stdout, that leaves sys.stdout itself as a character stream, and cgitb.py can successfully write to that.

If cgitb.py never writes anything but ASCII, then maybe that should be documented, and this issue closed.

If cgitb.py writes non-ASCII, then it should use an appropriate encoding for the web application, which isn't necessarily the default encoding on the system.  Some user control over the appropriate encoding should be given, or it should be documented that the encoding of sys.stdout should be changed to an appropriate encoding, because that is where cgitb.py will write its character stream.  Guidance on how to do that would be appropriate for the documentation also, as a CGI application may be the first one a programmer might write that can't just use the default encoding configured for the system.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10479>
_______________________________________

From report at bugs.python.org  Mon Jan 31 05:45:53 2011
From: report at bugs.python.org (Glenn Linderman)
Date: Mon, 31 Jan 2011 04:45:53 +0000
Subject: [issue10480] cgi.py should document the need for binary stdin/stdout
In-Reply-To: <1290318189.86.0.129478140251.issue10480@psf.upfronthosting.co.za>
Message-ID: <1296449153.25.0.699088964306.issue10480@psf.upfronthosting.co.za>


Glenn Linderman <v+python at g.nevcal.com> added the comment:

Fixed by issue 10841 and issue 4953.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10480>
_______________________________________

From report at bugs.python.org  Mon Jan 31 06:01:48 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Mon, 31 Jan 2011 05:01:48 +0000
Subject: [issue10512] regrtest ResourceWarning - unclosed sockets and files
In-Reply-To: <1290506536.77.0.313292165719.issue10512@psf.upfronthosting.co.za>
Message-ID: <1296450108.29.0.880594957468.issue10512@psf.upfronthosting.co.za>


Nadeem Vawda <nadeem.vawda at gmail.com> added the comment:

Looks good to me. My earlier patch was more defensive because I wasn't sure whether any of the other tests might be using cgi.log(), but it seems that this isn't the case.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10512>
_______________________________________

From report at bugs.python.org  Mon Jan 31 06:26:32 2011
From: report at bugs.python.org (Alex McNerney)
Date: Mon, 31 Jan 2011 05:26:32 +0000
Subject: [issue11075] Turtle crash with IDLE on Mac OS X 10.6
In-Reply-To: <1296451592.7.0.220170284749.issue11075@psf.upfronthosting.co.za>
Message-ID: <1296451592.7.0.220170284749.issue11075@psf.upfronthosting.co.za>


New submission from Alex McNerney <amcnerney13 at yahoo.com>:

Info: I have Python 2.7.1:86832 (32-bit) installed using ActiveState Tcl/Tk 8.5.9 on Mac OS X 10.6

Problem:
Whenever I try to run (from the IDLE) a Python script using the turtle module, the window that shows up will draw anything passed to it, but it will not come to the front using the listen() function, nor will clicking on the window do anything more than cause the spinning beach ball to appear. Because it does not come the the foreground, functions like onkey() and onclick() are completely unusable.

However, when said Python script is run from the Terminal, the window is completely responsive. I believe this to be some sort of problem with the IDLE.app

Things that I have tried:
Tried different versions of tcl/tk: 8.4.19, 8.4.7, 8.5.9
Tried different versions of Python 2.7.1: 32-bit, 32/64-bit, 32-bit compiled from source.

Other things that may be useful:
This probably has no relevancy, but just in case:
In the .mpkg installed Python 2.7.1 (32-bit), the IDLE says the GCC version is 4.0.1
In the source compiled version, it says 4.2.1

It is quite annoying to not be able to use the IDLE to create and test programs using the turtle module. Please help.

----------
assignee: ronaldoussoren
components: IDLE, Macintosh, Tkinter
messages: 127577
nosy: amcnerney13, ronaldoussoren
priority: normal
severity: normal
status: open
title: Turtle crash with IDLE on Mac OS X 10.6
type: crash
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11075>
_______________________________________

From report at bugs.python.org  Mon Jan 31 06:57:14 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 31 Jan 2011 05:57:14 +0000
Subject: [issue11071] What's New review comments
In-Reply-To: <1296394185.46.0.874389567772.issue11071@psf.upfronthosting.co.za>
Message-ID: <1296453434.65.0.502804566238.issue11071@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <rhettinger at users.sourceforge.net>:


----------
Removed message: http://bugs.python.org/msg127573

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11071>
_______________________________________

From report at bugs.python.org  Mon Jan 31 07:33:49 2011
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 31 Jan 2011 06:33:49 +0000
Subject: [issue11071] What's New review comments
In-Reply-To: <1296394185.46.0.874389567772.issue11071@psf.upfronthosting.co.za>
Message-ID: <1296455629.83.0.0986183706023.issue11071@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

I was just told about typo and grammar fixes though :)

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11071>
_______________________________________

From report at bugs.python.org  Mon Jan 31 07:57:39 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 31 Jan 2011 06:57:39 +0000
Subject: [issue11071] What's New review comments
In-Reply-To: <1296394185.46.0.874389567772.issue11071@psf.upfronthosting.co.za>
Message-ID: <1296457059.53.0.133393696564.issue11071@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <rhettinger at users.sourceforge.net>:


----------
assignee: eli.bendersky -> rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11071>
_______________________________________

From report at bugs.python.org  Mon Jan 31 08:06:03 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 31 Jan 2011 07:06:03 +0000
Subject: [issue11016] Add S_ISDOOR to the stat module
In-Reply-To: <1296440206.13.0.525338019083.issue11016@psf.upfronthosting.co.za>
Message-ID: <4D465F59.7020608@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> Martin, what if C posix module (or whoever) would export the symbolic
> constants, and update "stat.py" to use those symbolic constants?.
> 
> Do you think that would be an improvement?.

Improvement compared to what? The status quo? Certainly.
Compared to a path where the stat module is deprecated?
Certainly not.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11016>
_______________________________________

From report at bugs.python.org  Mon Jan 31 08:06:13 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Mon, 31 Jan 2011 07:06:13 +0000
Subject: [issue11071] What's New review comments
In-Reply-To: <1296394185.46.0.874389567772.issue11071@psf.upfronthosting.co.za>
Message-ID: <1296457573.29.0.980609378336.issue11071@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

r88274 - python/branches/py3k/Doc/whatsnew/3.2.rst
"Revert r88272 -- the examples are more readable with spacing."


Raymond - then perhaps we should consider revising PEP 8 as well. When I first read it, the "no spaces around =" rule for kwargs was strange at first, but then it grew on me. Regardless of personal style preferences, what we can't do (IMvHO) is have our official docs not follow PEP 8, and be inconsistent among themselves for that matter (very similar examples in argparse.rst and whatsnew/3.2.rst formatted differently)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11071>
_______________________________________

From report at bugs.python.org  Mon Jan 31 09:00:01 2011
From: report at bugs.python.org (R. David Murray)
Date: Mon, 31 Jan 2011 08:00:01 +0000
Subject: [issue11073] threading.Thread documentation can be improved
In-Reply-To: <1296438172.29.0.214693848128.issue11073@psf.upfronthosting.co.za>
Message-ID: <1296460801.56.0.866238681087.issue11073@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I still don't understand.  I haven't used threading much, but I don't believe I've ever used a static method with it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11073>
_______________________________________

From report at bugs.python.org  Mon Jan 31 09:05:03 2011
From: report at bugs.python.org (Virgil Dupras)
Date: Mon, 31 Jan 2011 08:05:03 +0000
Subject: [issue11076] Iterable argparse Namespace
In-Reply-To: <1296461103.49.0.397676179483.issue11076@psf.upfronthosting.co.za>
Message-ID: <1296461103.49.0.397676179483.issue11076@psf.upfronthosting.co.za>


New submission from Virgil Dupras <hsoft at hardcoded.net>:

Currently, there is no (documented) way to easily extract arguments in an argparse Namespace as a dictionary. This way, it would me easy to interface a function taking a lot of kwargs like this:

>>> args = parser.parse_args()
>>> my_function(**dict(args))

There's "_get_kwargs()" but it's a private undocumented method. I guess that making it public would be problematic because of the namespace pollution that would occur. That's why I'm proposing to make it iterable.

If it isn't rejected, I'd gladly work on the required patch.

----------
components: Library (Lib)
keywords: easy
messages: 127582
nosy: vdupras
priority: normal
severity: normal
status: open
title: Iterable argparse Namespace
type: feature request
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11076>
_______________________________________

From report at bugs.python.org  Mon Jan 31 09:15:25 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 31 Jan 2011 08:15:25 +0000
Subject: [issue11073] threading.Thread documentation can be improved
In-Reply-To: <1296438172.29.0.214693848128.issue11073@psf.upfronthosting.co.za>
Message-ID: <1296461725.26.0.569930266531.issue11073@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Roy, it's not clear what you're after.  What is it that you think is special about the way the target is called?

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11073>
_______________________________________

From report at bugs.python.org  Mon Jan 31 09:18:02 2011
From: report at bugs.python.org (Sebastien Douche)
Date: Mon, 31 Jan 2011 08:18:02 +0000
Subject: [issue11061] Verify command option before parsing config file
In-Reply-To: <1296314455.37.0.770288704329.issue11061@psf.upfronthosting.co.za>
Message-ID: <1296461882.49.0.939979309848.issue11061@psf.upfronthosting.co.za>


Sebastien Douche <sdouche at gmail.com> added the comment:

Oups sorry Eric. I created the report very quickly after a discussion with Tarek. If you type a wrong command like "python -m distutils2:run wrong", disutils2 still parses the setup.cfg. How resolve this? Don't know, maybe a migration to optparse.

Anyway, close the bug if you think it's irrevelant.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11061>
_______________________________________

From report at bugs.python.org  Mon Jan 31 09:33:03 2011
From: report at bugs.python.org (Ned Deily)
Date: Mon, 31 Jan 2011 08:33:03 +0000
Subject: [issue11075] Turtle crash with IDLE on Mac OS X 10.6
In-Reply-To: <1296451592.7.0.220170284749.issue11075@psf.upfronthosting.co.za>
Message-ID: <1296462783.49.0.162911537862.issue11075@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Since IDLE and the turtle modules both use Tkinter and thus are both Tcl/Tk applications, it wouldn't be surprising if you had problems trying to run a program using the IDLE module from within IDLE.  However, I find I can successfully run at least one of the supplied Turtle demos from IDLE 2.7.1 and IDLE 2.6:

  cd /Applications/Python 2.7/Extras/Demo/turtle
  idle2.7 tdemo_paint.py # or idle2.6

and with either of the two IDLE variants (32-bit -> Tk 8.4, 64-/32-bit -> Tk 8.5).  Can you supply a simple script to demonstrate the problem you see?

Keep in mind that, at the moment, neither of the standard python.org 2.7.1 installers support using ActiveState Tk 8.5.9.  The 32-bit-only installer will use ActiveState Tk 8.4, if installed, otherwise use the Apple-supplied Tk 8.4.19(?) in 10.6.  Python 2.7.1 was released before a 64-bit capable version of ActiveState Tk 8.5 was available so, as released, it will only link to the Apple-supplied Cocoa Tk 8.5.7 in 10.6 and that version has proven to be very unreliable when used with IDLE.  You should be able to build from source a Python 2.7.1 that will link to ActiveState 8.5.9 if it is present during the build but beware that there are a number of issues both major and minor that have been recently fixed in Python (and are in the current release-2.7 maintenance branch that should appear as a 2.7.2 release in the future) as well as a few issues in Cocoa Tk itself which should be fixed in an upcoming release of ActiveState Tk 8.5.

----------
assignee: ronaldoussoren -> ned.deily
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11075>
_______________________________________

From report at bugs.python.org  Mon Jan 31 09:35:09 2011
From: report at bugs.python.org (Ned Deily)
Date: Mon, 31 Jan 2011 08:35:09 +0000
Subject: [issue11075] Turtle crash with IDLE on Mac OS X 10.6
In-Reply-To: <1296451592.7.0.220170284749.issue11075@psf.upfronthosting.co.za>
Message-ID: <1296462909.06.0.866833164362.issue11075@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

er, "trying to run a program using the turtle module from within IDLE"

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11075>
_______________________________________

From report at bugs.python.org  Mon Jan 31 09:38:06 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 31 Jan 2011 08:38:06 +0000
Subject: [issue11071] What's New review comments
In-Reply-To: <1296394185.46.0.874389567772.issue11071@psf.upfronthosting.co.za>
Message-ID: <1296463086.27.0.0390205095389.issue11071@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Do yourself a favor and don't become a PEP 8 nut ;-)

The primary purpose of the example in whatsnew is to teach, demonstrate, and explain.  Any PEP 8 considerations take a back seat to that purpose (even PEP 8 itself admonishes the reader with the famous foolish consistency quotation).

The purpose behind the usual space conventions for keyword arguments is to allow them to be visually grouped when more than one is used on a line.  In the case of the argparse example, the important parameters are being listed one per line along with an explanatory comment.  In my judgement, the example is more readable with the spacing as it allows the eye to easily pick-out the argument list.  

Am sorry, but it is not really open for debate.  Whatsnew is a single-author document reflecting an enormous amount of my time culling changes, crafting expository text, and creating strong examples.  As such, it is going to very much reflect my style and judgement.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11071>
_______________________________________

From report at bugs.python.org  Mon Jan 31 10:56:07 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 31 Jan 2011 09:56:07 +0000
Subject: [issue11076] Iterable argparse Namespace
In-Reply-To: <1296461103.49.0.397676179483.issue11076@psf.upfronthosting.co.za>
Message-ID: <1296467767.43.0.709344541377.issue11076@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

+1 for making the object readily convertible to a dictionary.  That would also serve to make it more introspectable without losing the simplicity of the current design.

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11076>
_______________________________________

From report at bugs.python.org  Mon Jan 31 11:14:46 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 31 Jan 2011 10:14:46 +0000
Subject: [issue10891] Tweak sorting howto to eliminate redundancy
In-Reply-To: <1294828188.31.0.578827978132.issue10891@psf.upfronthosting.co.za>
Message-ID: <1296468886.39.0.0539473123567.issue10891@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

You can put in the backslashes before the two periods, but not the other changes.  I want the method names to continue to be spelled-out in full so that it is more clear what they are referring to.  Even in spoken English, I typically say "list sort" or "sort method of the builtin list type".  This helps distinguish it from the sorted() builtin.

----------
assignee: rhettinger -> eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10891>
_______________________________________

From report at bugs.python.org  Mon Jan 31 11:58:43 2011
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 31 Jan 2011 10:58:43 +0000
Subject: [issue11071] What's New review comments
In-Reply-To: <1296394185.46.0.874389567772.issue11071@psf.upfronthosting.co.za>
Message-ID: <1296471523.78.0.104800565028.issue11071@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

I agree with Raymond: whoever puts in 95% of work for a single document should have artistic license over the style.

I also don't complain if people use a different indentation style in module docs they write (but I reserve the right to use mine if I edit these docs).

It is very nice having standards, but well, I hope you know about the hobgoblin :)

And particularly about keyword arg spacing, I found that it very much depends on the manner of arguments you're dealing with.  For dict()-style functions with lots of kwargs, it can really be much easier on the eyes to use space around the '=', or even use this style:

foo = dict(
    some_key        = some_value,
    some_longer_key = some_other_value,
)

even if PEP 8 doesn't approve of that either.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11071>
_______________________________________

From report at bugs.python.org  Mon Jan 31 12:10:46 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 31 Jan 2011 11:10:46 +0000
Subject: [issue3080] Full unicode import system
In-Reply-To: <1213208697.49.0.984990811807.issue3080@psf.upfronthosting.co.za>
Message-ID: <1296472246.27.0.0751361047453.issue3080@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

As explained in issue #10828: Python 3.2 doesn't support non-ASCII module names on Windows because module names are encoded to UTF-8 instead of the filesystem encoding (the ANSI code page).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3080>
_______________________________________

From report at bugs.python.org  Mon Jan 31 12:46:03 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Mon, 31 Jan 2011 11:46:03 +0000
Subject: [issue11016] Add S_ISDOOR to the stat module
In-Reply-To: <1296039446.69.0.66523737586.issue11016@psf.upfronthosting.co.za>
Message-ID: <1296474363.6.0.287806699302.issue11016@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

Martin, I guess "stat" deprecation could require a few years and it would be an extra incompatibility burden between 2.7 and 3.x.

Beside the symbolic constants, why would you see "stat" deprecated?.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11016>
_______________________________________

From report at bugs.python.org  Mon Jan 31 12:50:15 2011
From: report at bugs.python.org (SilentGhost)
Date: Mon, 31 Jan 2011 11:50:15 +0000
Subject: [issue8973] Inconsistent docstrings in struct module
In-Reply-To: <1276270357.95.0.610857929794.issue8973@psf.upfronthosting.co.za>
Message-ID: <1296474615.93.0.734702455541.issue8973@psf.upfronthosting.co.za>


SilentGhost <ghost.adh at gmail.com> added the comment:

r81947 introduced this issue:

>>> from struct import *
>>> pack_into
Traceback (most recent call last):
  File "<pyshell#1>", line 1, in <module>
    pack_into
NameError: name 'pack_into' is not defined

struct.__all__ has a duplicate entry and misses pack_into.

Patch is attached, test passes. Seems quite innocent to me, could it make into 3.2, George?

----------
nosy: +SilentGhost, georg.brandl
status: closed -> open
Added file: http://bugs.python.org/file20625/struct.py.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8973>
_______________________________________

From report at bugs.python.org  Mon Jan 31 13:52:31 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 31 Jan 2011 12:52:31 +0000
Subject: [issue11071] What's New review comments
In-Reply-To: <1296394185.46.0.874389567772.issue11071@psf.upfronthosting.co.za>
Message-ID: <1296478351.3.0.641762679525.issue11071@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

"Python?s import mechanism can now load modules installed in directories with non-ASCII characters in the path name: import m??se.bites"

m??se is not a module *path*, but a module *name*... This example doesn't work on Windows: see #3080. Module paths is the sys.path list. An use case is Python installed in the user directory with diacritics in the user name (eg. Python installed in C:\Users\Am?lie\...).

"The biggest news for Python 3.2 is that the email package and nntplib modules now work correctly with the bytes/text model in Python 3."

You can also include mailbox in this list.

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11071>
_______________________________________

From report at bugs.python.org  Mon Jan 31 14:05:04 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 31 Jan 2011 13:05:04 +0000
Subject: [issue11071] What's New review comments
In-Reply-To: <1296394185.46.0.874389567772.issue11071@psf.upfronthosting.co.za>
Message-ID: <1296479104.03.0.866940900392.issue11071@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Should we add imports in all examples? Eg. add import math in:

>>> repr(math.pi)
'3.141592653589793'
>>> str(math.pi)
'3.141592653589793'

At least, accumulate should be replaced by itertools.accumulate in the following example:

>>> list(accumulate(8, 2, 50))
[8, 10, 60]

Because it looks like accumulate() is a builtin function.

Some other examples without the module name: "tally = Counter(dogs=5, cat=3)", "d = OrderedDict...", "d = deque('simsalabim')", "all_polls_closed = Barrier(len(sites))", ...

I prefer to have the module name in examples because it is easy to test them: just copy/paste in an interpreter. It's even more easier if there is the import statement :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11071>
_______________________________________

From report at bugs.python.org  Mon Jan 31 14:07:44 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 31 Jan 2011 13:07:44 +0000
Subject: [issue11071] What's New review comments
In-Reply-To: <1296394185.46.0.874389567772.issue11071@psf.upfronthosting.co.za>
Message-ID: <1296479264.73.0.5234422541.issue11071@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

The import in the following example is wrong :

>>> import datetime
>>> datetime.now(timezone.utc)
...

It should be replaced by: from datetime import datetime, timezone.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11071>
_______________________________________

From report at bugs.python.org  Mon Jan 31 14:19:15 2011
From: report at bugs.python.org (Roy Smith)
Date: Mon, 31 Jan 2011 13:19:15 +0000
Subject: [issue11073] threading.Thread documentation can be improved
In-Reply-To: <1296438172.29.0.214693848128.issue11073@psf.upfronthosting.co.za>
Message-ID: <1296479955.54.0.0108216353033.issue11073@psf.upfronthosting.co.za>


Roy Smith <roy at panix.com> added the comment:

Here's the code I ended up writing:

class Foo():
   def __init__(self):
       self.thread = Thread(target=Foo.runner, args=[self])
       self.thread.start()

   @staticmethod
   def runner(self):
      # blah, blah, blah

It was not immediately clear from the documentation if my runner() method should be declared static or not.  In retrospect, it must be (since this can be used with target functions which are not class methods at all), but it took a bit of thought to get from what the documentation said (i.e. 'callable object to be invoked by the run() method') to that conclusion.  

It seems to me the documentation could be a bit more explicit that your target does not get called as a method of some object.  Changing the text to read, "static function or other callable object" would remove any such confusion.

It could be that some of my confusion is due to my previously working with a C++ threading package where the thread runner functions *were* class methods.  Still, it seems like the potential for other people to be similarly confused exists and a little tweaking of the documentation text would help.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11073>
_______________________________________

From report at bugs.python.org  Mon Jan 31 14:30:58 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Mon, 31 Jan 2011 13:30:58 +0000
Subject: [issue11071] What's New review comments
In-Reply-To: <1296394185.46.0.874389567772.issue11071@psf.upfronthosting.co.za>
Message-ID: <1296480658.02.0.879465664013.issue11071@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

Nick, thanks for highlighting the logging changes. In addition to what you mentioned, there's still more, at least some of which deserves to get into "what's new" :-)

1. QueueHandler and QueueListener classes were added to help with logging in multiprocessing applications.
2. Logger got a getChild(suffix) method which returns a child logger with the given suffix.
3. An optional stack_info parameter to logging calls provides complete stack information (not just the parts unwound during exception handling).
4. Logger got a hasHandlers() method which returns True if any handlers are available for the logger (including those in ancestor loggers).
5. The LoggerAdapter implementation was changed to improve its usability, during which its public API gained the isEnabledFor(),   getEffectiveLevel(), hasHandlers() and setLevel() methods.
6. HTTPHandler gained secure and credentials keyword arguments for use with SSL and sites needing authentication.
7. StreamHandler now has a terminator attribute (defaults to '\n' for backward compatibility) but can now be set on a per-handler basis.
8. SysLogHandler gained a socktype keyword argument which defaults to SOCK_DGRAM but can accept SOCK_STREAM for use with newer syslog daemons which can listen using TCP.
9. basicConfig() also takes an optional style argument (default '%', also accepts '{' or '$').
10. SMTPHandler takes optional "secure" kwarg for use with TLS.
11. SysLogHandler now treats Unicode as per RFC 5424.

Er ... that's it for now.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11071>
_______________________________________

From report at bugs.python.org  Mon Jan 31 14:48:06 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 31 Jan 2011 13:48:06 +0000
Subject: [issue11071] What's New review comments
In-Reply-To: <1296394185.46.0.874389567772.issue11071@psf.upfronthosting.co.za>
Message-ID: <1296481686.44.0.678773362705.issue11071@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

ABCMeta should be replaced by abc.ABCMeta, or other "abc." prefixes should be removed.

class Temperature(metaclass=ABCMeta):
    @abc.abstractclassmethod
    def from_fahrenheit(self, t):
        ...
    @abc.abstractclassmethod
    def from_celsius(self, t):
        ...

I don't know/understand the "->" syntax:

>>> print(byte_stream.getvalue())
b'G3805  showroom   Main chassis    ' ->
b'X7899  warehouse  Reserve cog     ' ->
b'L6988  receiving  Primary sprocket'

If you would like to split record by record, use something like:

>>> x=byte_stream.getvalue()
>>> [x[index:index+REC_LEN] for index in range(0,len(x),REC_LEN)]
[b'G3805  showroom   Main chassis    ', b'X7899  warehouse  Reserve cog     ', b'L6988  receiving  Primary sprocket']

--

$ ./python 
Python 3.2rc2+ (py3k:88277, Jan 31 2011, 14:24:09) 
>>> from ast import literalrequest
ImportError: cannot import name literalrequest

--

>>> import shutil, pprint
...
>>> f = make_archive(...)

It's shutil.make_archive(), not make_archive() here.

>>> shutil.register_archive_format(                  # register a new archive format
        name = 'xz',
        function = 'xz.compress',
        extra_args = [('level', 8)],
        description = 'xz compression'
)

The function have to be callable: a str is not callable.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11071>
_______________________________________

From report at bugs.python.org  Mon Jan 31 15:35:35 2011
From: report at bugs.python.org (Brian Curtin)
Date: Mon, 31 Jan 2011 14:35:35 +0000
Subject: [issue11073] threading.Thread documentation can be improved
In-Reply-To: <1296438172.29.0.214693848128.issue11073@psf.upfronthosting.co.za>
Message-ID: <1296484535.28.0.308115912558.issue11073@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

> It was not immediately clear from the documentation if my runner() method should be declared static or not.

The doc doesn't mention static methods at all, and my uses and others that I've seen have never used static methods.

----------
nosy: +brian.curtin

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11073>
_______________________________________

From report at bugs.python.org  Mon Jan 31 15:40:19 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 31 Jan 2011 14:40:19 +0000
Subject: [issue11073] threading.Thread documentation can be improved
In-Reply-To: <1296438172.29.0.214693848128.issue11073@psf.upfronthosting.co.za>
Message-ID: <1296484819.03.0.648963830001.issue11073@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

You don't have to use any staticmethod here (actually, staticmethod is an anti-pattern in Python). Just write:

class Foo():
   def __init__(self):
       self.thread = Thread(target=self.runner)
       self.thread.start()

   def runner(self):
      # blah, blah, blah

----------
nosy: +pitrou
resolution:  -> works for me
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11073>
_______________________________________

From report at bugs.python.org  Mon Jan 31 15:45:36 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 31 Jan 2011 14:45:36 +0000
Subject: [issue11071] What's New review comments
In-Reply-To: <1296394185.46.0.874389567772.issue11071@psf.upfronthosting.co.za>
Message-ID: <1296485136.91.0.638853449548.issue11071@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Thanks Victor.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11071>
_______________________________________

From report at bugs.python.org  Mon Jan 31 16:39:48 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 31 Jan 2011 15:39:48 +0000
Subject: [issue11071] What's New review comments
In-Reply-To: <1296394185.46.0.874389567772.issue11071@psf.upfronthosting.co.za>
Message-ID: <1296488388.88.0.582088134676.issue11071@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Please consider mentioning that several modules can now be called with -m: pickle, pickletools and tkinter.

----------
nosy: +belopolsky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11071>
_______________________________________

From report at bugs.python.org  Mon Jan 31 16:40:32 2011
From: report at bugs.python.org (Scott M)
Date: Mon, 31 Jan 2011 15:40:32 +0000
Subject: [issue11077] Tkinter is not thread safe. This is a bug.
In-Reply-To: <1296488432.58.0.0945320697853.issue11077@psf.upfronthosting.co.za>
Message-ID: <1296488432.58.0.0945320697853.issue11077@psf.upfronthosting.co.za>


New submission from Scott M <scott.mayo at comcast.net>:

The more I look at GUI support in Python, the more I realize that the lack of basic thread safety in GUI support is simply a bug. I know Java's Swing has the same thread limitation, but that doesn't make it right. Xlib is thread safe. The Windows SDK is thread safe. Python is supposed to be the language that's easy to use, and there is nothing easy about teaching new programmers that they have to mess with queues and timers just to get a basic set of displays running, just because when threads are in use.

I'm in the position of teaching folk with little-to-no programming experience, how to script simple applications in Python. The modules they have to use are inherently threaded, and delivery hunks of data from multiple sources to them. The most natural instinct is to put up some graphs and other widgits to display the data, and all of it is completely trivial right up until I have to explain that drawing a line isn't canvas.line(from, to), but becomes an exercise in Queue.Queue and theRoot.after(n, myself), before you even get to learn about widgits. Threading is supposed to simplify problems, not add to them. Having to hack around with special timers and polling, just to get some simple graphs up, is plain unpythonic.

Please consider this a bug, a glaring misfeature, in a language that is otherwise a very reasonable choice to get technical but non-programmerish people into toolmaking self-sufficiency.

----------
components: Tkinter
messages: 127604
nosy: PythonInTheGrass
priority: normal
severity: normal
status: open
title: Tkinter is not thread safe. This is a bug.
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11077>
_______________________________________

From report at bugs.python.org  Mon Jan 31 16:43:27 2011
From: report at bugs.python.org (stan mihai)
Date: Mon, 31 Jan 2011 15:43:27 +0000
Subject: [issue8275] callback function on win64 results in bad behavior. mem
	corruption?
In-Reply-To: <1270061625.47.0.601780173179.issue8275@psf.upfronthosting.co.za>
Message-ID: <1296488607.96.0.632909139114.issue8275@psf.upfronthosting.co.za>


stan mihai <stanmihai4 at gmail.com> added the comment:

attached patch with tests

I have no experience with python development so the tests will actually need a more detailed review. Also I only checked it on win64.

----------
Added file: http://bugs.python.org/file20626/ctypes_win64_tests.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8275>
_______________________________________

From report at bugs.python.org  Mon Jan 31 16:48:47 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 31 Jan 2011 15:48:47 +0000
Subject: [issue8973] Inconsistent docstrings in struct module
In-Reply-To: <1276270357.95.0.610857929794.issue8973@psf.upfronthosting.co.za>
Message-ID: <1296488927.32.0.709447953623.issue8973@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

The proposed patch looks fine to me, but it is attached to the wrong issue.  It belongs to #8973 or better yet to follow RC2 rules pedantically, it should be posted in a separate issue.

This is important, because this issue is limited to docstrings and may be considered documentation only, but the proposed parch affects behavior.  Still I would be +1 on applying it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8973>
_______________________________________

From report at bugs.python.org  Mon Jan 31 16:51:17 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 31 Jan 2011 15:51:17 +0000
Subject: [issue8973] Inconsistent docstrings in struct module
In-Reply-To: <1276270357.95.0.610857929794.issue8973@psf.upfronthosting.co.za>
Message-ID: <1296489077.56.0.771655571729.issue8973@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Wait, #8973 *is* this issue.  But r81947 is clearly not about docstrings.  We definitely need a saparate issue.  This is too confusing.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8973>
_______________________________________

From report at bugs.python.org  Mon Jan 31 16:55:33 2011
From: report at bugs.python.org (R. David Murray)
Date: Mon, 31 Jan 2011 15:55:33 +0000
Subject: [issue11078] Have test___all__ check for duplicates
In-Reply-To: <1296489333.39.0.726513534716.issue11078@psf.upfronthosting.co.za>
Message-ID: <1296489333.39.0.726513534716.issue11078@psf.upfronthosting.co.za>


New submission from R. David Murray <rdmurray at bitdance.com>:

Inspired by what happened in issue 8973, I offer the attached patch for test__all__ to have it check the __all__ list for duplicates.  Interestingly, the first failure is not in struct, but in os.  Obviously the patch can't be applied until the test succeeds, so I'll be coming back to this later.  Figured I'd post the test patch in case anyone else wants to play with fixing things before I get to it.

----------
components: Tests
files: check_all_for_duplicates.patch
keywords: patch
messages: 127608
nosy: SilentGhost, pitrou, r.david.murray
priority: normal
severity: normal
stage: needs patch
status: open
title: Have test___all__ check for duplicates
type: feature request
versions: Python 3.3
Added file: http://bugs.python.org/file20627/check_all_for_duplicates.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11078>
_______________________________________

From report at bugs.python.org  Mon Jan 31 16:55:42 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 31 Jan 2011 15:55:42 +0000
Subject: [issue8973] Inconsistent docstrings in struct module
In-Reply-To: <1276270357.95.0.610857929794.issue8973@psf.upfronthosting.co.za>
Message-ID: <1296489342.39.0.204311263544.issue8973@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


----------
Removed message: http://bugs.python.org/msg127607

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8973>
_______________________________________

From report at bugs.python.org  Mon Jan 31 16:56:05 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 31 Jan 2011 15:56:05 +0000
Subject: [issue8973] Inconsistent docstrings in struct module
In-Reply-To: <1276270357.95.0.610857929794.issue8973@psf.upfronthosting.co.za>
Message-ID: <1296489365.27.0.38389939158.issue8973@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Wait, #8973 *is* this issue.  But r81947 is clearly not only about docstrings.  We definitely need a separate issue.  This is too confusing.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8973>
_______________________________________

From report at bugs.python.org  Mon Jan 31 17:00:32 2011
From: report at bugs.python.org (=?utf-8?b?SsOpcsO0bWUgUmFkaXg=?=)
Date: Mon, 31 Jan 2011 16:00:32 +0000
Subject: [issue6792] Distutils-based installer does not detect 64bit versions
	of Python
In-Reply-To: <1251449540.11.0.0670330819334.issue6792@psf.upfronthosting.co.za>
Message-ID: <1296489632.14.0.990485731056.issue6792@psf.upfronthosting.co.za>


Changes by J?r?me Radix <jerome.radix at gmail.com>:


----------
nosy: +J?r?me Radix

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6792>
_______________________________________

From report at bugs.python.org  Mon Jan 31 17:09:22 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 31 Jan 2011 16:09:22 +0000
Subject: [issue1252236] Simplying Tkinter's event loop
Message-ID: <1296490162.23.0.19121559649.issue1252236@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


----------
nosy: +PythonInTheGrass -BreamoreBoy
resolution: wont fix -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1252236>
_______________________________________

From report at bugs.python.org  Mon Jan 31 17:11:27 2011
From: report at bugs.python.org (Brian Curtin)
Date: Mon, 31 Jan 2011 16:11:27 +0000
Subject: [issue11077] Tkinter is not thread safe
In-Reply-To: <1296488432.58.0.0945320697853.issue11077@psf.upfronthosting.co.za>
Message-ID: <1296490287.54.0.951082231355.issue11077@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
title: Tkinter is not thread safe. This is a bug. -> Tkinter is not thread safe

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11077>
_______________________________________

From report at bugs.python.org  Mon Jan 31 17:16:47 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 31 Jan 2011 16:16:47 +0000
Subject: [issue8275] callback function on win64 results in bad behavior. mem
	corruption?
In-Reply-To: <1270061625.47.0.601780173179.issue8275@psf.upfronthosting.co.za>
Message-ID: <1296490607.71.0.332610864047.issue8275@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Patch verified to work under Linux and win32. It looks good, except for tab characters in the Modules/_ctypes/_ctypes_test.c (indentation of C files should use 4 spaces); that's a detail that we can fix ourselves.

----------
assignee: theller -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8275>
_______________________________________

From report at bugs.python.org  Mon Jan 31 17:18:49 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 31 Jan 2011 16:18:49 +0000
Subject: [issue11077] Tkinter is not thread safe
In-Reply-To: <1296488432.58.0.0945320697853.issue11077@psf.upfronthosting.co.za>
Message-ID: <1296490729.46.0.674817414951.issue11077@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

One possible solution was presented in issue1252236: move tkinter event loop into Python main loop.  However, to consider this report a bug, we need an example code that shows the behavior that you consider incorrect.  Even then, it is likely that fixing the behavior won't be possible without introducing new features.  I am reclassifying this as a feature request.

----------
nosy: +belopolsky
stage:  -> unit test needed
type: behavior -> feature request
versions: +Python 3.3 -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11077>
_______________________________________

From report at bugs.python.org  Mon Jan 31 17:19:03 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 31 Jan 2011 16:19:03 +0000
Subject: [issue11079] Make OS X entry in Applications like that in Windows
In-Reply-To: <1296490743.96.0.234780831636.issue11079@psf.upfronthosting.co.za>
Message-ID: <1296490743.96.0.234780831636.issue11079@psf.upfronthosting.co.za>


New submission from Raymond Hettinger <rhettinger at users.sourceforge.net>:

In Applications, the 3.2 entry includes:
* Python Launcher
* IDLE
* Update Shell.Profile Command
* Extras directory

The latter should be dropped (most of the tools only make sense from the command-line) and should be replaced by a link to the docs:

file:///Library/Frameworks/Python.framework/Versions/3.2/Resources/English.lproj/Documentation/index.html

This setup better matches what we offer in Windows and it makes the docs more accessible.

The Windows setup also includes an uninstall option.  It would be nice if OS X did the same, but I don't know if that is the way of the Mac.

----------
assignee: ned.deily
components: Build
messages: 127612
nosy: ned.deily, rhettinger, ronaldoussoren
priority: normal
severity: normal
status: open
title: Make OS X entry in Applications like that in Windows
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11079>
_______________________________________

From report at bugs.python.org  Mon Jan 31 17:27:44 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 31 Jan 2011 16:27:44 +0000
Subject: [issue11078] Have test___all__ check for duplicates
In-Reply-To: <1296489333.39.0.726513534716.issue11078@psf.upfronthosting.co.za>
Message-ID: <1296491264.59.0.985364301272.issue11078@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

+1.  This is a fairly common mistake.  Usually benign, but as issue 8973 shows, may highlight a visible error.

----------
nosy: +belopolsky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11078>
_______________________________________

From report at bugs.python.org  Mon Jan 31 17:34:15 2011
From: report at bugs.python.org (Tres Seaver)
Date: Mon, 31 Jan 2011 16:34:15 +0000
Subject: [issue10360] _weakrefset.WeakSet.__contains__ should not propagate
	TypeErrors
In-Reply-To: <1289225563.5.0.586847358991.issue10360@psf.upfronthosting.co.za>
Message-ID: <1296491655.23.0.0204259573124.issue10360@psf.upfronthosting.co.za>


Tres Seaver <tseaver at agendaless.com> added the comment:

georg.brandl (2010-12-03 10:20):

> Don't worry, it will be ported.

When?  Why would it *not* be merged to the 2.7 and 3.1 branches at the
time the bug is closed?  Delaying the port only increases the chance
that the fix will fall between the cracks.

In particular, I would like confirmation that the fix *will* be ported
before 2.7.2 is released:  this bug causes the 2.7 Zope buildbots
to fail, which means they are disabled until the fix is released.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10360>
_______________________________________

From report at bugs.python.org  Mon Jan 31 17:42:11 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 31 Jan 2011 16:42:11 +0000
Subject: [issue10360] _weakrefset.WeakSet.__contains__ should not propagate
	TypeErrors
In-Reply-To: <1289225563.5.0.586847358991.issue10360@psf.upfronthosting.co.za>
Message-ID: <1296492131.54.0.711840015803.issue10360@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Let's reopen until then.

----------
assignee: pitrou -> 
resolution: fixed -> accepted
stage:  -> committed/rejected
status: closed -> open
versions:  -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10360>
_______________________________________

From report at bugs.python.org  Mon Jan 31 17:46:19 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 31 Jan 2011 16:46:19 +0000
Subject: [issue11023] pep 227 missing text
In-Reply-To: <1296134235.25.0.738218358402.issue11023@psf.upfronthosting.co.za>
Message-ID: <1296492379.11.0.614697403042.issue11023@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

The ?Documentation? component is used for bugs found in files under the Doc directory of a CPython checkout or source tarball.  PEPs are tracked in their own repository and are not part of the CPython distribution.  They are not part of the docs.  Hope this clarifies things.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11023>
_______________________________________

From report at bugs.python.org  Mon Jan 31 17:48:20 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 31 Jan 2011 16:48:20 +0000
Subject: [issue11061] Verify command option before parsing config file
In-Reply-To: <1296314455.37.0.770288704329.issue11061@psf.upfronthosting.co.za>
Message-ID: <1296492500.65.0.334043735997.issue11061@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Well, the setup.cfg could register a command named ?wrong?, so d2 really has to parse all config files before rejecting a command.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11061>
_______________________________________

From report at bugs.python.org  Mon Jan 31 17:56:51 2011
From: report at bugs.python.org (=?utf-8?b?SsOpcsO0bWUgUmFkaXg=?=)
Date: Mon, 31 Jan 2011 16:56:51 +0000
Subject: [issue6792] Distutils-based installer does not detect 64bit versions
	of Python
In-Reply-To: <1251449540.11.0.0670330819334.issue6792@psf.upfronthosting.co.za>
Message-ID: <1296493011.28.0.255941657376.issue6792@psf.upfronthosting.co.za>


J?r?me Radix <jerome.radix at gmail.com> added the comment:

Could you please change the priority of this Issue to 'High' as this problem is a big annoyance for all Windows 64bits users which is a rather large niche of users (a niche getting larger and larger everyday), don't you think ?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6792>
_______________________________________

From report at bugs.python.org  Mon Jan 31 17:58:56 2011
From: report at bugs.python.org (Terry M. Topka)
Date: Mon, 31 Jan 2011 16:58:56 +0000
Subject: [issue11080] Win32Serial.read coding error for non-blocking read
In-Reply-To: <1296493135.79.0.311076655892.issue11080@psf.upfronthosting.co.za>
Message-ID: <1296493135.79.0.311076655892.issue11080@psf.upfronthosting.co.za>


New submission from Terry M. Topka <topka at ge.com>:

Attempting to read a fixed amount of data when the serial port is configured for non-blocking reads (i.e. self.timeout == 0) will occasionally throw an invalid memory access exception, due to an error in the following code:

### pyserial-2.5-rc2 serialWin32.py Line 219
            if self.timeout == 0:
                n = min(comstat.cbInQue, size)
                if n > 0:
                    buf = ctypes.create_string_buffer(n)
                    rc = win32.DWORD()
                    err = win32.ReadFile(self.hComPort, buf, size, ctypes.byref(rc), ctypes.byref(self._overlappedRead))

The buffer length passed to win32.ReadFile should be 'n', not 'size'. This may not have been noticed since it is timing dependent: only if additional input is enqueued inbetween accessing the input queue length and the ReadFile call will the inappropriate invalid memory access exception be raised when 'size' is greater than 'n'.

----------
components: Extension Modules, Windows
files: serialwin32.py
messages: 127619
nosy: tmtopka
priority: normal
severity: normal
status: open
title: Win32Serial.read coding error for non-blocking read
type: crash
versions: 3rd party, Python 2.6
Added file: http://bugs.python.org/file20628/serialwin32.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11080>
_______________________________________

From report at bugs.python.org  Mon Jan 31 17:59:53 2011
From: report at bugs.python.org (Brian Curtin)
Date: Mon, 31 Jan 2011 16:59:53 +0000
Subject: [issue11080] Win32Serial.read coding error for non-blocking read
In-Reply-To: <1296493135.79.0.311076655892.issue11080@psf.upfronthosting.co.za>
Message-ID: <1296493193.2.0.721371420324.issue11080@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

You should contact pyserial.

----------
nosy: +brian.curtin
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11080>
_______________________________________

From report at bugs.python.org  Mon Jan 31 18:00:37 2011
From: report at bugs.python.org (SilentGhost)
Date: Mon, 31 Jan 2011 17:00:37 +0000
Subject: [issue11078] Have test___all__ check for duplicates
In-Reply-To: <1296489333.39.0.726513534716.issue11078@psf.upfronthosting.co.za>
Message-ID: <1296493237.64.0.470113582574.issue11078@psf.upfronthosting.co.za>


SilentGhost <ghost.adh at gmail.com> added the comment:

At the moment test fails only for os module on windows. 

These are the offending names: putenv, spawnv, spawnve

The reason is that __all__ is extended with ntpath.__all__ and then again in the body of os.py (I'm not entirely sure how this could be fixed elegantly).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11078>
_______________________________________

From report at bugs.python.org  Mon Jan 31 18:01:19 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Mon, 31 Jan 2011 17:01:19 +0000
Subject: [issue8998] add crypto routines to stdlib
In-Reply-To: <1276551598.69.0.32913607148.issue8998@psf.upfronthosting.co.za>
Message-ID: <1296493279.41.0.971290460726.issue8998@psf.upfronthosting.co.za>


Changes by Jes?s Cea Avi?n <jcea at jcea.es>:


----------
versions: +Python 3.3 -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8998>
_______________________________________

From report at bugs.python.org  Mon Jan 31 18:09:30 2011
From: report at bugs.python.org (R. David Murray)
Date: Mon, 31 Jan 2011 17:09:30 +0000
Subject: [issue11078] Have test___all__ check for duplicates
In-Reply-To: <1296489333.39.0.726513534716.issue11078@psf.upfronthosting.co.za>
Message-ID: <1296493770.53.0.665243078494.issue11078@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Well, the test stops testing after the first failure.  Perhaps another enhancement request would be to make test__all__ a parameterized test so that it tests all modules even if one or more fail.

On linux, the dups are putenv and unsetenv.  And yes, deeper investigation of why os.py is adding them is required to fix this :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11078>
_______________________________________

From report at bugs.python.org  Mon Jan 31 18:15:20 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 31 Jan 2011 17:15:20 +0000
Subject: [issue11078] Have test___all__ check for duplicates
In-Reply-To: <1296493770.53.0.665243078494.issue11078@psf.upfronthosting.co.za>
Message-ID: <AANLkTikUz+57v27epKs8keDULaN8uC2L0JnJGxWm88jO@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Mon, Jan 31, 2011 at 12:09 PM, R. David Murray
<report at bugs.python.org> wrote:
..
> On linux, the dups are putenv and unsetenv. ?And yes, deeper investigation of why
> os.py is adding them is required to fix this :)

Too bad __all__ cannot be specified as a set.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11078>
_______________________________________

From report at bugs.python.org  Mon Jan 31 18:18:33 2011
From: report at bugs.python.org (R. David Murray)
Date: Mon, 31 Jan 2011 17:18:33 +0000
Subject: [issue11078] Have test___all__ check for duplicates
In-Reply-To: <1296489333.39.0.726513534716.issue11078@psf.upfronthosting.co.za>
Message-ID: <1296494313.49.0.849656176621.issue11078@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Well, checking if the token is there before adding it would certainly be a fix, but I think it would be worth understanding why it gets added if it is already there, because instead perhaps it is possible to simply remove the adding code from os.py.  Removing code is nice.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11078>
_______________________________________

From report at bugs.python.org  Mon Jan 31 18:21:59 2011
From: report at bugs.python.org (SilentGhost)
Date: Mon, 31 Jan 2011 17:21:59 +0000
Subject: [issue11081] from struct import * misses pack_into
In-Reply-To: <1296494519.33.0.0318665786587.issue11081@psf.upfronthosting.co.za>
Message-ID: <1296494519.33.0.0318665786587.issue11081@psf.upfronthosting.co.za>


New submission from SilentGhost <ghost.adh at gmail.com>:

the following issue was introduced in r81947:

>>> from struct import *
>>> pack_into
Traceback (most recent call last):
  File "<pyshell#1>", line 1, in <module>
    pack_into
NameError: name 'pack_into' is not defined

struct.__all__ has a duplicate entry for "unpack" and misses "pack_into".

Patch is attached, test passes. Seems quite innocent to me, could it make into 3.2, George?

Related: #8973 and #11078

----------
components: Library (Lib)
files: struct.py.diff
keywords: easy, patch
messages: 127625
nosy: SilentGhost, belopolsky, georg.brandl, mark.dickinson
priority: normal
severity: normal
status: open
title: from struct import * misses pack_into
type: behavior
versions: Python 3.3
Added file: http://bugs.python.org/file20629/struct.py.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11081>
_______________________________________

From report at bugs.python.org  Mon Jan 31 18:23:55 2011
From: report at bugs.python.org (SilentGhost)
Date: Mon, 31 Jan 2011 17:23:55 +0000
Subject: [issue8973] Inconsistent docstrings in struct module
In-Reply-To: <1276270357.95.0.610857929794.issue8973@psf.upfronthosting.co.za>
Message-ID: <1296494635.41.0.815588115298.issue8973@psf.upfronthosting.co.za>


SilentGhost <ghost.adh at gmail.com> added the comment:

new issue #11081 was created for struct.__all__ fix

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8973>
_______________________________________

From report at bugs.python.org  Mon Jan 31 18:29:54 2011
From: report at bugs.python.org (R. David Murray)
Date: Mon, 31 Jan 2011 17:29:54 +0000
Subject: [issue6792] Distutils-based installer does not detect 64bit versions
	of Python
In-Reply-To: <1251449540.11.0.0670330819334.issue6792@psf.upfronthosting.co.za>
Message-ID: <1296494994.11.0.156521206792.issue6792@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I'll leave priority setting to tarek, but it doesn't look to me like raising the priority is going to make any difference, since it doesn't sound from reading the ticket like anyone has found a solution yet (other than offering 64bit installers).

----------
nosy: +r.david.murray
stage:  -> needs patch
versions: +Python 3.3 -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6792>
_______________________________________

From report at bugs.python.org  Mon Jan 31 18:33:43 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 31 Jan 2011 17:33:43 +0000
Subject: [issue11081] from struct import * misses pack_into
In-Reply-To: <1296494519.33.0.0318665786587.issue11081@psf.upfronthosting.co.za>
Message-ID: <1296495223.12.0.91417817776.issue11081@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

I would say if anything can go in after rc2 at all, this should be accepted.  George?

I ran a few sanity checks with the patch applied:

>>> set(struct.__all__) - set(dir(struct))
set()
>>> set(dir(struct)) - set(struct.__all__)
{'_clearcache', '__all__', '__builtins__', '__file__', '__package__', '__cached__', '__name__', '__doc__'}
>>> len(set(struct.__all__)) == len(struct.__all__)
True

LGTM.  Maybe one of the tests above can be converted to a unit test.

----------
assignee:  -> georg.brandl
versions: +Python 3.2 -Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11081>
_______________________________________

From report at bugs.python.org  Mon Jan 31 18:34:27 2011
From: report at bugs.python.org (R. David Murray)
Date: Mon, 31 Jan 2011 17:34:27 +0000
Subject: [issue11068] Python 2.7.1 Idle traceback on OS X (10.6.6)
In-Reply-To: <1296339702.88.0.766799420032.issue11068@psf.upfronthosting.co.za>
Message-ID: <1296495267.29.0.852526237952.issue11068@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

FYI, a python traceback is not a segfault.  Nor is it a 'crash' in the sense we use in this tracker.

The warning has been added to the download page, though there is discussion about whether or not it should be more prominent.

----------
nosy: +r.david.murray
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed
type: crash -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11068>
_______________________________________

From report at bugs.python.org  Mon Jan 31 18:34:29 2011
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Mon, 31 Jan 2011 17:34:29 +0000
Subject: [issue6792] Distutils-based installer does not detect 64bit versions
	of Python
In-Reply-To: <1251449540.11.0.0670330819334.issue6792@psf.upfronthosting.co.za>
Message-ID: <1296495269.82.0.620361751315.issue6792@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

Yeah I agree. Until we get a solution + patch the priority here does not really matter.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6792>
_______________________________________

From report at bugs.python.org  Mon Jan 31 18:35:17 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 31 Jan 2011 17:35:17 +0000
Subject: [issue11078] Have test___all__ check for duplicates
In-Reply-To: <1296489333.39.0.726513534716.issue11078@psf.upfronthosting.co.za>
Message-ID: <1296495317.46.0.317299555074.issue11078@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


----------
dependencies: +from struct import * misses pack_into

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11078>
_______________________________________

From report at bugs.python.org  Mon Jan 31 18:35:45 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 31 Jan 2011 17:35:45 +0000
Subject: [issue11081] from struct import * misses pack_into
In-Reply-To: <1296494519.33.0.0318665786587.issue11081@psf.upfronthosting.co.za>
Message-ID: <1296495345.96.0.538520651922.issue11081@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


----------
stage:  -> commit review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11081>
_______________________________________

From report at bugs.python.org  Mon Jan 31 18:41:56 2011
From: report at bugs.python.org (David Meier)
Date: Mon, 31 Jan 2011 17:41:56 +0000
Subject: [issue11068] Python 2.7.1 Idle traceback on OS X (10.6.6)
In-Reply-To: <1296339702.88.0.766799420032.issue11068@psf.upfronthosting.co.za>
Message-ID: <1296495716.78.0.850431949022.issue11068@psf.upfronthosting.co.za>


David Meier <djmeier at gmail.com> added the comment:

Sorry that what I had pasted in does not show a segfault, however if you run it as `idle` (i.e. no `(idle&)) the command line reports a generic "Segmentation fault" with no traceback.  So, yes, it is a segmentation fault - but I figured it was more useful if you had the traceback when running it that way.  Whether or not the two are related I do not know.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11068>
_______________________________________

From report at bugs.python.org  Mon Jan 31 18:46:24 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 31 Jan 2011 17:46:24 +0000
Subject: [issue8176] Interpreter crash with "double free or corruption" message
In-Reply-To: <1268995268.42.0.577572952388.issue8176@psf.upfronthosting.co.za>
Message-ID: <1296495984.52.0.622348194158.issue8176@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


Removed file: http://bugs.python.org/file16584/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8176>
_______________________________________

From report at bugs.python.org  Mon Jan 31 18:46:30 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 31 Jan 2011 17:46:30 +0000
Subject: [issue8176] Interpreter crash with "double free or corruption" message
In-Reply-To: <1268995268.42.0.577572952388.issue8176@psf.upfronthosting.co.za>
Message-ID: <1296495990.72.0.17804938659.issue8176@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


Removed file: http://bugs.python.org/file16615/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8176>
_______________________________________

From report at bugs.python.org  Mon Jan 31 18:50:43 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 31 Jan 2011 17:50:43 +0000
Subject: [issue8176] Interpreter crash with "double free or corruption" message
In-Reply-To: <1268995268.42.0.577572952388.issue8176@psf.upfronthosting.co.za>
Message-ID: <1296496243.76.0.126375604442.issue8176@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

It looks like the bug cannot be reproduced anymore.  Since it was discovered using a python instance with third-party extension modules, it may not even be a python bug to begin with.

----------
assignee:  -> belopolsky
nosy: +belopolsky -Alexander.Belopolsky
resolution:  -> works for me
stage:  -> committed/rejected
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8176>
_______________________________________

From report at bugs.python.org  Mon Jan 31 19:01:48 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 31 Jan 2011 18:01:48 +0000
Subject: [issue7358] cPickle crash on failed assertion
In-Reply-To: <1258645822.27.0.150067328286.issue7358@psf.upfronthosting.co.za>
Message-ID: <1296496908.51.0.712738144648.issue7358@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Ryan,

Do you still have the setup that can reproduce this error?  If so, can you try running it with pickle rather than cPickle?  If it works with pickle, please see if you can reproduce the error by unpickling the result of pickle and repickling it with cPickle.  This may allow you to create a self-contained script that you can post together with a pickle file.

----------
nosy: +belopolsky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7358>
_______________________________________

From report at bugs.python.org  Mon Jan 31 19:04:23 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 31 Jan 2011 18:04:23 +0000
Subject: [issue9197] Crash when importer an extension after Py_Initialize,
	Py_Finalize and Py_Initialize
In-Reply-To: <1278579237.82.0.673928899274.issue9197@psf.upfronthosting.co.za>
Message-ID: <1296497063.41.0.0185405469577.issue9197@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


Removed file: http://bugs.python.org/file17899/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9197>
_______________________________________

From report at bugs.python.org  Mon Jan 31 19:04:42 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 31 Jan 2011 18:04:42 +0000
Subject: [issue7358] cPickle crash on failed assertion
In-Reply-To: <1258645822.27.0.150067328286.issue7358@psf.upfronthosting.co.za>
Message-ID: <1296497082.34.0.507344675682.issue7358@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/issue7358>
_______________________________________

From report at bugs.python.org  Mon Jan 31 19:10:44 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 31 Jan 2011 18:10:44 +0000
Subject: [issue9197] Crash when importing an extension after Py_Initialize,
	Py_Finalize and Py_Initialize
In-Reply-To: <1278579237.82.0.673928899274.issue9197@psf.upfronthosting.co.za>
Message-ID: <1296497444.77.0.689568669863.issue9197@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Amaury,

Can you post your Linux code reproducing the issue?  I would like to take a look, but don't want to dig through an XCode project.

----------
assignee:  -> belopolsky
nosy: +belopolsky
title: Crash when importer an extension after Py_Initialize, Py_Finalize and Py_Initialize -> Crash when importing an extension after Py_Initialize, Py_Finalize and Py_Initialize

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9197>
_______________________________________

From report at bugs.python.org  Mon Jan 31 19:10:51 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 31 Jan 2011 18:10:51 +0000
Subject: [issue8176] Interpreter crash with "double free or corruption" message
In-Reply-To: <1268995268.42.0.577572952388.issue8176@psf.upfronthosting.co.za>
Message-ID: <1296497451.88.0.673868794055.issue8176@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

If you are still able to reproduce the bug, you may try the following module to get a backtrace: https://github.com/haypo/faulthandler/

----------
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8176>
_______________________________________

From report at bugs.python.org  Mon Jan 31 19:18:59 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 31 Jan 2011 18:18:59 +0000
Subject: [issue8176] Interpreter crash with "double free or corruption" message
In-Reply-To: <1268995268.42.0.577572952388.issue8176@psf.upfronthosting.co.za>
Message-ID: <1296497939.87.0.489586461416.issue8176@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Victor,

I was thinking about pointing the OP to your faulthandler module, but decided not to because in the failing thread python has already finished execution and most of finalization.  It is very unlikely that faulthandler will be helpful in this scenario.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8176>
_______________________________________

From report at bugs.python.org  Mon Jan 31 19:24:57 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 31 Jan 2011 18:24:57 +0000
Subject: [issue7358] cStringIO not 64-bit safe
In-Reply-To: <1258645822.27.0.150067328286.issue7358@psf.upfronthosting.co.za>
Message-ID: <1296498297.76.0.227843294079.issue7358@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

The issue looks quite clear: cStringIO.write() asserts that the required storage size is less than INT_MAX. Therefore, in all likelihood, the pickle dump is simply larger than 2GB.

Now, the cStringIO structures seem 64-bit safe, so the comparison to INT_MAX seems useless. Also, in non-debug builds, the assert is skipped but the Py_ssize_t values are first cast to int before being saved into a Py_ssize_t struct member! Which would lead to data corruption and/or crashes.

The INT_MAX asserts were added in r42382 which also made cStringIO internals 64-bit safe. Martin, do you remember why you did this?

The asserts don't even protect against the following crash:

$ ./python -c "from cStringIO import StringIO; b=b'x'*(2**31+1); s=StringIO(); s.write(b)"
Erreur de segmentation

gdb shows the following stack excerpt:

#0  0x00007ffff724e8c2 in memcpy () from /lib64/libc.so.6
#1  0x00007ffff6b47a46 in O_cwrite (self=<unknown at remote 0xa3f790>, c=0x7fff76b44054 'x' <repeats 200 times>..., 
    l=-2147483647) at /home/antoine/cpython/27/Modules/cStringIO.c:415


Now, onto the problem of reproducing, here's another interesting thing: while some internal structures of cStringIO are 64-bit safe, the Python-facing API isn't:

>>> from cStringIO import StringIO
>>> b = b"x" * (2**32+1)
>>> s = StringIO()
>>> s.write(b)
>>> s.tell()
1

(the module doesn't use Py_SSIZE_T_CLEAN)

----------
nosy: +loewis, pitrou
title: cPickle crash on failed assertion -> cStringIO not 64-bit safe
versions: +Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7358>
_______________________________________

From report at bugs.python.org  Mon Jan 31 19:29:48 2011
From: report at bugs.python.org (Scott M)
Date: Mon, 31 Jan 2011 18:29:48 +0000
Subject: [issue11077] Tkinter is not thread safe (and that's... bad)
In-Reply-To: <1296488432.58.0.0945320697853.issue11077@psf.upfronthosting.co.za>
Message-ID: <1296498588.09.0.0925939649982.issue11077@psf.upfronthosting.co.za>


Scott M <scott.mayo at comcast.net> added the comment:

I don't have an opinion on 1252236. I'm not certain it would help.

I have an extension that runs a bunch of (alien) threads into Python code. The threads deliver information for all sorts of real world events, asynchronously. Multiple threads are used, because people occasionally want to do blocking operations in these alien threads, but still want to be able to handle other incoming information at full speed, with the other threads.

If any of these threads attempts to update a Tkinter widgit - and this is the first thing I tried to do - then tkinter will except or crash in some horrible way, sooner or later. 

The attached .py (in Python 2.7.1) does it without any extensions. Click on Launch quickly 10-15 times; if it doesn't crash, kill and restart. It rarely takes more than 4-5 runs to get a traceback, or occasionally python itself just crashes. Bottom line, one thread in .mainloop() and another thread calling virtually any Tkinter function, even something as simple as .after(), is an invitation a crash.

----------
title: Tkinter is not thread safe -> Tkinter is not thread safe (and that's... bad)
Added file: http://bugs.python.org/file20630/TkinterCrash2.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11077>
_______________________________________

From report at bugs.python.org  Mon Jan 31 19:34:55 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 31 Jan 2011 18:34:55 +0000
Subject: [issue8176] Interpreter crash with "double free or corruption" message
In-Reply-To: <1268995268.42.0.577572952388.issue8176@psf.upfronthosting.co.za>
Message-ID: <1296498895.73.0.11313199118.issue8176@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I wouldn't be surprised if the crash was related to some concurrency issues during shutdown. Other (Python or not Python) threads can continue running while the main thread is running Py_Finalize; this might be the reason; or perhaps some extension modules don't really support reloading.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8176>
_______________________________________

From report at bugs.python.org  Mon Jan 31 19:41:42 2011
From: report at bugs.python.org (R. David Murray)
Date: Mon, 31 Jan 2011 18:41:42 +0000
Subject: [issue11023] pep 227 missing text
In-Reply-To: <1296134235.25.0.738218358402.issue11023@psf.upfronthosting.co.za>
Message-ID: <1296499302.67.0.64892169977.issue11023@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Eric, what you say is technically true, but we don't have any other place to track PEP bugs.

----------
assignee:  -> docs at python
components: +Documentation
nosy: +docs at python, r.david.murray
resolution: invalid -> 
stage: committed/rejected -> needs patch
status: closed -> open
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11023>
_______________________________________

From report at bugs.python.org  Mon Jan 31 19:48:45 2011
From: report at bugs.python.org (Brian Curtin)
Date: Mon, 31 Jan 2011 18:48:45 +0000
Subject: [issue11077] Tkinter is not thread safe
In-Reply-To: <1296488432.58.0.0945320697853.issue11077@psf.upfronthosting.co.za>
Message-ID: <1296499725.88.0.996375223802.issue11077@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
title: Tkinter is not thread safe (and that's... bad) -> Tkinter is not thread safe

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11077>
_______________________________________

From report at bugs.python.org  Mon Jan 31 19:53:39 2011
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 31 Jan 2011 18:53:39 +0000
Subject: [issue11081] from struct import * misses pack_into
In-Reply-To: <1296494519.33.0.0318665786587.issue11081@psf.upfronthosting.co.za>
Message-ID: <1296500019.32.0.211454712767.issue11081@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Yes, this can go in.

----------
assignee: georg.brandl -> belopolsky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11081>
_______________________________________

From report at bugs.python.org  Mon Jan 31 19:55:14 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 31 Jan 2011 18:55:14 +0000
Subject: [issue9197] Crash when importing an extension after Py_Initialize,
	Py_Finalize and Py_Initialize
In-Reply-To: <1278579237.82.0.673928899274.issue9197@psf.upfronthosting.co.za>
Message-ID: <1296500114.35.0.220030431662.issue9197@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Here are the files I used to reproduce the crash.
See "build.sh" for the build command, there may be better ways...

----------
Added file: http://bugs.python.org/file20631/simpletest.zip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9197>
_______________________________________

From report at bugs.python.org  Mon Jan 31 19:59:59 2011
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 31 Jan 2011 18:59:59 +0000
Subject: [issue10360] _weakrefset.WeakSet.__contains__ should not propagate
	TypeErrors
In-Reply-To: <1289225563.5.0.586847358991.issue10360@psf.upfronthosting.co.za>
Message-ID: <1296500399.35.0.934694448532.issue10360@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Because I don't think porting every change immediately is worth my time when I can do it much faster in mass-merges.

I know other developers do this differently, but since I use svnmerge to do my mass-merges, there won't be any falling through cracks.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10360>
_______________________________________

From report at bugs.python.org  Mon Jan 31 20:03:33 2011
From: report at bugs.python.org (R. David Murray)
Date: Mon, 31 Jan 2011 19:03:33 +0000
Subject: [issue571767] string.capitlize() documentation
Message-ID: <1296500613.22.0.791959150918.issue571767@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I see correct doc strings on both 2.7 head and 3.1.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue571767>
_______________________________________

From report at bugs.python.org  Mon Jan 31 20:11:21 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 31 Jan 2011 19:11:21 +0000
Subject: [issue11077] Tkinter is not thread safe
In-Reply-To: <1296488432.58.0.0945320697853.issue11077@psf.upfronthosting.co.za>
Message-ID: <1296501081.74.0.420257274445.issue11077@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Hmm, either my hand is too slow or my laptop is too fast, but I cannot reproduce the crash. Can you create a non-interactive script?  Maybe start a separate thread generating "launch" events?

What do you mean by "crash"?  Do you get a python backtrace or OS diagnostic saying that the process was killed by a signal of some sort?  If it is the former, please post the backtrace.  If the latter, can you produce C backtrace?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11077>
_______________________________________

From report at bugs.python.org  Mon Jan 31 20:14:17 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89tienne_BERSAC?=)
Date: Mon, 31 Jan 2011 19:14:17 +0000
Subject: [issue2504] Add gettext.pgettext() and variants support
In-Reply-To: <1206756624.13.0.664664048525.issue2504@psf.upfronthosting.co.za>
Message-ID: <1296501257.92.0.0438989528127.issue2504@psf.upfronthosting.co.za>


Changes by ?tienne BERSAC <bersace03 at gmail.com>:


----------
nosy:  -Felix Schwarz

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2504>
_______________________________________

From report at bugs.python.org  Mon Jan 31 20:14:36 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89tienne_BERSAC?=)
Date: Mon, 31 Jan 2011 19:14:36 +0000
Subject: [issue2504] Add gettext.pgettext() and variants support
In-Reply-To: <1206756624.13.0.664664048525.issue2504@psf.upfronthosting.co.za>
Message-ID: <1296501276.81.0.131031995956.issue2504@psf.upfronthosting.co.za>


Changes by ?tienne BERSAC <bersace03 at gmail.com>:


----------
nosy: +bersace

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2504>
_______________________________________

From report at bugs.python.org  Mon Jan 31 20:15:02 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89tienne_BERSAC?=)
Date: Mon, 31 Jan 2011 19:15:02 +0000
Subject: [issue2504] Add gettext.pgettext() and variants support
In-Reply-To: <1206756624.13.0.664664048525.issue2504@psf.upfronthosting.co.za>
Message-ID: <1296501302.99.0.787181313017.issue2504@psf.upfronthosting.co.za>


Changes by ?tienne BERSAC <bersace03 at gmail.com>:


----------
nosy: +Felix Schwarz

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2504>
_______________________________________

From report at bugs.python.org  Mon Jan 31 20:18:12 2011
From: report at bugs.python.org (William Wu)
Date: Mon, 31 Jan 2011 19:18:12 +0000
Subject: [issue11082] ValueError: Content-Length should be specified
In-Reply-To: <1296501492.73.0.362770141375.issue11082@psf.upfronthosting.co.za>
Message-ID: <1296501492.73.0.362770141375.issue11082@psf.upfronthosting.co.za>


New submission from William Wu <willie.tw at gmail.com>:

I found this bug when I started to trying Python 3.2 release candidate 1.

When using urllib.request.urlopen to handle HTTP POST, I got the error message:

ValueError: Content-Length should be specified     for iterable data of type <class 'str'> 'foo=bar'

I'll attach the patch and test case.

----------
components: Library (Lib)
messages: 127646
nosy: William.Wu
priority: normal
severity: normal
status: open
title: ValueError: Content-Length should be specified
type: behavior
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11082>
_______________________________________

From report at bugs.python.org  Mon Jan 31 20:22:23 2011
From: report at bugs.python.org (Federico Culloca)
Date: Mon, 31 Jan 2011 19:22:23 +0000
Subject: [issue11083] threading.Thread - start() rises RuntimeException?
In-Reply-To: <1296501743.29.0.748896290236.issue11083@psf.upfronthosting.co.za>
Message-ID: <1296501743.29.0.748896290236.issue11083@psf.upfronthosting.co.za>


New submission from Federico Culloca <djthrottle at gmail.com>:

In the threading module documentation, about the start() method of the threading.Thread class, it says that, upon calling start() more then once, a RuntimeException is raised. I couldn't find in the whole documentation other references to this "RuntimeException".

Maybe it's RuntimeError?

----------
assignee: docs at python
components: Documentation
messages: 127647
nosy: Federico.Culloca, docs at python
priority: normal
severity: normal
status: open
title: threading.Thread - start() rises RuntimeException?
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11083>
_______________________________________

From report at bugs.python.org  Mon Jan 31 20:24:11 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 31 Jan 2011 19:24:11 +0000
Subject: [issue11077] Tkinter is not thread safe
In-Reply-To: <1296488432.58.0.0945320697853.issue11077@psf.upfronthosting.co.za>
Message-ID: <1296501851.7.0.791879579632.issue11077@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

I converted TkinterCrash2.py to 3.x using 2to3 (result attached as TkinterCrash3.py) and it works with 3.2rc2 just fine.

----------
Added file: http://bugs.python.org/file20632/TkinterCrash3.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11077>
_______________________________________

From report at bugs.python.org  Mon Jan 31 20:28:38 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 31 Jan 2011 19:28:38 +0000
Subject: [issue11081] from struct import * misses pack_into
In-Reply-To: <1296494519.33.0.0318665786587.issue11081@psf.upfronthosting.co.za>
Message-ID: <1296502118.92.0.397551704864.issue11081@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Committed in revision 88280.

----------
resolution:  -> fixed
stage: commit review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11081>
_______________________________________

From report at bugs.python.org  Mon Jan 31 20:34:15 2011
From: report at bugs.python.org (William Wu)
Date: Mon, 31 Jan 2011 19:34:15 +0000
Subject: [issue11082] ValueError: Content-Length should be specified
In-Reply-To: <1296501492.73.0.362770141375.issue11082@psf.upfronthosting.co.za>
Message-ID: <1296502455.84.0.0916157645338.issue11082@psf.upfronthosting.co.za>


Changes by William Wu <willie.tw at gmail.com>:


----------
keywords: +patch
Added file: http://bugs.python.org/file20633/test_urllib_request.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11082>
_______________________________________

From report at bugs.python.org  Mon Jan 31 20:34:51 2011
From: report at bugs.python.org (William Wu)
Date: Mon, 31 Jan 2011 19:34:51 +0000
Subject: [issue11082] ValueError: Content-Length should be specified
In-Reply-To: <1296501492.73.0.362770141375.issue11082@psf.upfronthosting.co.za>
Message-ID: <1296502491.67.0.385533585398.issue11082@psf.upfronthosting.co.za>


Changes by William Wu <willie.tw at gmail.com>:


Added file: http://bugs.python.org/file20634/urllib_request.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11082>
_______________________________________

From report at bugs.python.org  Mon Jan 31 20:36:18 2011
From: report at bugs.python.org (Brian Curtin)
Date: Mon, 31 Jan 2011 19:36:18 +0000
Subject: [issue11083] threading.Thread - start() rises RuntimeException?
In-Reply-To: <1296501743.29.0.748896290236.issue11083@psf.upfronthosting.co.za>
Message-ID: <1296502578.66.0.65657455335.issue11083@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

Thanks, fixed in r88281. Back porting to the other branches as well.

----------
nosy: +brian.curtin
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
versions: +Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11083>
_______________________________________

From report at bugs.python.org  Mon Jan 31 20:37:31 2011
From: report at bugs.python.org (GDR!)
Date: Mon, 31 Jan 2011 19:37:31 +0000
Subject: [issue11084] Serialization of decimal.Decimal to XML-RPC
In-Reply-To: <1296502651.44.0.847909816314.issue11084@psf.upfronthosting.co.za>
Message-ID: <1296502651.44.0.847909816314.issue11084@psf.upfronthosting.co.za>


New submission from GDR! <gdr at go2.pl>:

xmlrpc.client (and xmlrpclib in 2.x) can't serialize instances of Decimal, throwing TypeError instead. Because XML is a textual format, converting from decimal to float may cause loss of data.

According to http://www.xmlrpc.com/spec, encoding Decimal as XML-RPC <double /> is allowed: "The range of allowable values is implementation-dependent, is not specified." Therefore, including decimal numbers that can not be represented by IEEE double is allowed by the spec.

Also, in my opinion, making a numeric type available in standard library unsupported by another part of standard library, is counterintuitive, but it's just my personal point of view.

I can provide a patch if this bug report is considered proper.

----------
components: Library (Lib)
messages: 127651
nosy: gdr
priority: normal
severity: normal
status: open
title: Serialization of decimal.Decimal to XML-RPC
type: behavior
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11084>
_______________________________________

From report at bugs.python.org  Mon Jan 31 20:42:22 2011
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 31 Jan 2011 19:42:22 +0000
Subject: [issue11074] fix tokenize so it can be reloaded
In-Reply-To: <1296446651.43.0.796363573653.issue11074@psf.upfronthosting.co.za>
Message-ID: <1296502942.95.0.154550490923.issue11074@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
assignee: georg.brandl -> brett.cannon
versions: +Python 3.3 -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11074>
_______________________________________

From report at bugs.python.org  Mon Jan 31 20:44:26 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 31 Jan 2011 19:44:26 +0000
Subject: [issue11085] expose _abcoll as collections.abc
In-Reply-To: <1296503066.28.0.738947830383.issue11085@psf.upfronthosting.co.za>
Message-ID: <1296503066.28.0.738947830383.issue11085@psf.upfronthosting.co.za>


New submission from Raymond Hettinger <rhettinger at users.sourceforge.net>:

For the 3.3, make _abcoll (which is full of the collections abstract base classes) visible as a module called collections.abc and document that as the preferred way to access them.

For backwards compatibility, continue to import the names directly into the collections.py namespace so that no one has to change existing code.

Background:  Experience with teaching ABCs and dealing with bug reports has shown that it is creating some confusion having the long list of abstract APIs commingled with the concrete APIs (for example, seeing collections.Mapping and thinking it is one of the various concrete types in the collections module).  If it were to become a practice to write collections.abc.Mapping, it would be immediately clear that an ABC was being used rather than a concrete class like OrderedDict.

The other reason to separate them is that the use cases tend to be different.  People look to the abstract APIs either for a specification (reference purposes), for mixin methods (aid in building their own classes), or for registration (to control isinstance and issubclass).  In contrast, people use concrete APIs directly for managing data.  Accordingly, it makes senses to group the two different types of tools into separate toolboxes.

----------
components: Library (Lib)
messages: 127652
nosy: rhettinger
priority: low
severity: normal
status: open
title: expose _abcoll as collections.abc
type: feature request
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11085>
_______________________________________

From report at bugs.python.org  Mon Jan 31 20:48:28 2011
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 31 Jan 2011 19:48:28 +0000
Subject: [issue10992] tests failing when run under coverage
In-Reply-To: <1295836026.73.0.339636680883.issue10992@psf.upfronthosting.co.za>
Message-ID: <1296503308.23.0.255873394559.issue10992@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
assignee:  -> brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10992>
_______________________________________

From report at bugs.python.org  Mon Jan 31 20:49:23 2011
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 31 Jan 2011 19:49:23 +0000
Subject: [issue10512] regrtest ResourceWarning - unclosed sockets and files
In-Reply-To: <1290506536.77.0.313292165719.issue10512@psf.upfronthosting.co.za>
Message-ID: <1296503363.34.0.0780241549081.issue10512@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Once Python 3.3 is open I will apply the cgi fix. Just to double-check, can I close this issue once the test_cgi patch goes in?

----------
assignee: georg.brandl -> brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10512>
_______________________________________

From report at bugs.python.org  Mon Jan 31 20:49:40 2011
From: report at bugs.python.org (Matt Cain)
Date: Mon, 31 Jan 2011 19:49:40 +0000
Subject: [issue5803] email/quoprimime: encode and decode are very slow on
	large messages
In-Reply-To: <1240254091.33.0.632025917195.issue5803@psf.upfronthosting.co.za>
Message-ID: <1296503380.04.0.917074281739.issue5803@psf.upfronthosting.co.za>


Matt Cain <cainmatt at gmail.com> added the comment:

I re-wrote encode() to be simpler and faster.
My version runs about 10 times faster on a 30KB message.

I have tested it somewhat but not rigorously

see attached patch

----------
keywords: +patch
nosy: +cainmatt
Added file: http://bugs.python.org/file20635/quoprimime.py.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5803>
_______________________________________

From report at bugs.python.org  Mon Jan 31 21:02:15 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 31 Jan 2011 20:02:15 +0000
Subject: [issue11084] Serialization of decimal.Decimal to XML-RPC
In-Reply-To: <1296502651.44.0.847909816314.issue11084@psf.upfronthosting.co.za>
Message-ID: <1296504135.99.0.154486166039.issue11084@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

-1 on an implicit, lossy conversion.

The principal reasons for using decimal in the first place is avoid representation error.  For example, when money is being represented as a decimal, it is improper to convert it to float (where it can no longer be compared for equality and where the representable range is smaller).

A user needs explicit control in this situation, converting to float when it doesn't matter, or using an API that allows the decimal repr to be handled.

One other issue is that in an RPC environment, good design suggests that the client do its best to match the type expectations for of the functions on the server.  Implicit signature changing makes even less sense for RPC than it does in a regular application.

----------
nosy: +rhettinger
type: behavior -> feature request
versions: +Python 3.3 -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11084>
_______________________________________

From report at bugs.python.org  Mon Jan 31 21:06:56 2011
From: report at bugs.python.org (R. David Murray)
Date: Mon, 31 Jan 2011 20:06:56 +0000
Subject: [issue5803] email/quoprimime: encode and decode are very slow on
	large messages
In-Reply-To: <1240254091.33.0.632025917195.issue5803@psf.upfronthosting.co.za>
Message-ID: <1296504416.96.0.369418411476.issue5803@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
assignee:  -> r.david.murray
nosy: +r.david.murray
stage: needs patch -> patch review
versions: +Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5803>
_______________________________________

From report at bugs.python.org  Mon Jan 31 21:18:22 2011
From: report at bugs.python.org (R. David Murray)
Date: Mon, 31 Jan 2011 20:18:22 +0000
Subject: [issue11085] expose _abcoll as collections.abc
In-Reply-To: <1296503066.28.0.738947830383.issue11085@psf.upfronthosting.co.za>
Message-ID: <1296505102.27.0.059466338549.issue11085@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Why not just put them in the 'abc' namespace?  IMO, collections.abc.Callable makes a lot less sense than abc.Mapping.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11085>
_______________________________________

From report at bugs.python.org  Mon Jan 31 21:35:31 2011
From: report at bugs.python.org (stan mihai)
Date: Mon, 31 Jan 2011 20:35:31 +0000
Subject: [issue8275] callback function on win64 results in bad behavior. mem
	corruption?
In-Reply-To: <1270061625.47.0.601780173179.issue8275@psf.upfronthosting.co.za>
Message-ID: <1296506131.73.0.911363932311.issue8275@psf.upfronthosting.co.za>


stan mihai <stanmihai4 at gmail.com> added the comment:

ok, please also fix the first parameter of the tests. Because it has the same value in the first call and the callback it will always be right by accident, since the first call puts the value in both standard and floating point registers.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8275>
_______________________________________

From report at bugs.python.org  Mon Jan 31 21:44:35 2011
From: report at bugs.python.org (O.C.)
Date: Mon, 31 Jan 2011 20:44:35 +0000
Subject: [issue3405] Add support for the new data option supported by event
	generate (Tk 8.5)
In-Reply-To: <1216385566.01.0.7972232454.issue3405@psf.upfronthosting.co.za>
Message-ID: <1296506675.35.0.169096714594.issue3405@psf.upfronthosting.co.za>


O.C. <oc-spam66 at laposte.net> added the comment:

Hello,

I read the proposed patch "event_generate__data2.diff" and the Tcl/Tk manual http://www.tcl.tk/man/tcl8.5/TkCmd/bind.htm#M24

* Could you please also add a field "e.user_data" ? This would simply be a copy of 'd' :
---
e.detail = d
e.user_data = d
---
My reasoning is that the Tcl/Tk manual mentions the two names "detail" and "user_data". However, "user_data" may often be preferred because it has a clear meaning, whereas "detail" is quite vague.

* I did not understand why you try to get a widget reference from the "%d" field. Is it supposed to contain a widget name at some point ? According to the manual (and if I understood it well), it should never. 

Best regards,

O.C.

----------
nosy: +dghjfrdj

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3405>
_______________________________________

From report at bugs.python.org  Mon Jan 31 21:52:47 2011
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 31 Jan 2011 20:52:47 +0000
Subject: [issue11086] add lib2to3/__main__.py
In-Reply-To: <1296507167.64.0.584286117272.issue11086@psf.upfronthosting.co.za>
Message-ID: <1296507167.64.0.584286117272.issue11086@psf.upfronthosting.co.za>


New submission from Brett Cannon <brett at python.org>:

There is no reason why the 2to3 script can't be gutted and turned into just a stub that uses runpy to call lib2to3.__main__. Also has the nice benefit that one can use ``-m lib2to3`` instead of having to use the 2to3 script.

----------
components: Library (Lib)
keywords: easy
messages: 127659
nosy: brett.cannon
priority: low
severity: normal
stage: needs patch
status: open
title: add lib2to3/__main__.py
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11086>
_______________________________________

From report at bugs.python.org  Mon Jan 31 21:53:53 2011
From: report at bugs.python.org (GDR!)
Date: Mon, 31 Jan 2011 20:53:53 +0000
Subject: [issue11084] Serialization of decimal.Decimal to XML-RPC
In-Reply-To: <1296502651.44.0.847909816314.issue11084@psf.upfronthosting.co.za>
Message-ID: <1296507233.29.0.429772541007.issue11084@psf.upfronthosting.co.za>


GDR! <gdr at go2.pl> added the comment:

I didn't mean to implicitly convert Decimal to float. My point was that xmlrpclib should serialize Decimals natively to avoid loss of precision when converting to float and then to string.

Whether other party will be able to represent this number exactly or not should not be our issue. 

To make it more clear, this is what Python currently does:
http://gdr.pastebin.pl/35766
this is what I propose it shoud do:
http://gdr.pastebin.pl/35765

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11084>
_______________________________________

From report at bugs.python.org  Mon Jan 31 21:56:17 2011
From: report at bugs.python.org (GDR!)
Date: Mon, 31 Jan 2011 20:56:17 +0000
Subject: [issue11084] Serialization of decimal.Decimal to XML-RPC
In-Reply-To: <1296502651.44.0.847909816314.issue11084@psf.upfronthosting.co.za>
Message-ID: <1296507377.23.0.381671726354.issue11084@psf.upfronthosting.co.za>


GDR! <gdr at go2.pl> added the comment:

Also, I think that <double> should be represented as Decimal when unmarshalling XML-RPC data, because the standard doesn't give any limits on size on precision of data, and the only representation it allows is the one with decimal point, making it an excellent fit for Decimal.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11084>
_______________________________________

From report at bugs.python.org  Mon Jan 31 21:59:09 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 31 Jan 2011 20:59:09 +0000
Subject: [issue11085] expose _abcoll as collections.abc
In-Reply-To: <1296503066.28.0.738947830383.issue11085@psf.upfronthosting.co.za>
Message-ID: <1296507549.16.0.594297393242.issue11085@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

> Why not just put them in the 'abc' namespace?

Two reasons:
* There are lots of ABCs scattered throughout the standard libary that aren't collections ABCs (the importlib ABCs and IO ABCs for example).
* Guido viewed collections ABCs as tightly associated with collections.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11085>
_______________________________________

From report at bugs.python.org  Mon Jan 31 22:06:06 2011
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 31 Jan 2011 21:06:06 +0000
Subject: [issue11086] add lib2to3/__main__.py
In-Reply-To: <1296507167.64.0.584286117272.issue11086@psf.upfronthosting.co.za>
Message-ID: <1296507966.13.0.0416961627821.issue11086@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

The attached patch adds lib2to3.__main__ and tweaks 2to3.

----------
keywords: +patch
Added file: http://bugs.python.org/file20636/2to3_main.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11086>
_______________________________________

From report at bugs.python.org  Mon Jan 31 22:06:35 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 31 Jan 2011 21:06:35 +0000
Subject: [issue11084] Serialization of decimal.Decimal to XML-RPC
In-Reply-To: <1296502651.44.0.847909816314.issue11084@psf.upfronthosting.co.za>
Message-ID: <1296507995.34.0.605796007755.issue11084@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

>>> x = decimal.Decimal('9999999999999.11111111111111')
>>> c.dumps(x,), 'whatever')
"<?xml version='1.0'?>\n<methodCall>\n<methodName>whatever</methodName>\n<params>\n<param>\n<value><double>9999999999999.11111111111111</double></value>\n</param>\n</params>\n</methodCall>\n"

That's what I though you meant and I don't think it is wise.  The RPC spec is all about interoperability.  The <double> tag means "double-precision signed floating point number" so what you're proposing an implicit type conversion (i.e. the client sends a decimal and the server receives a float).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11084>
_______________________________________

From report at bugs.python.org  Mon Jan 31 22:08:42 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Mon, 31 Jan 2011 21:08:42 +0000
Subject: [issue10512] regrtest ResourceWarning - unclosed sockets and files
In-Reply-To: <1290506536.77.0.313292165719.issue10512@psf.upfronthosting.co.za>
Message-ID: <1296508122.31.0.161327675196.issue10512@psf.upfronthosting.co.za>


Nadeem Vawda <nadeem.vawda at gmail.com> added the comment:

No objections here. The other remaining leaks that I am aware of are covered by issue10883.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10512>
_______________________________________

From report at bugs.python.org  Mon Jan 31 22:24:29 2011
From: report at bugs.python.org (GDR!)
Date: Mon, 31 Jan 2011 21:24:29 +0000
Subject: [issue11084] Serialization of decimal.Decimal to XML-RPC
In-Reply-To: <1296502651.44.0.847909816314.issue11084@psf.upfronthosting.co.za>
Message-ID: <1296509069.24.0.541966949396.issue11084@psf.upfronthosting.co.za>


GDR! <gdr at go2.pl> added the comment:

While it would be allowed by the spec in the quotation I pasted in the original post, I understand your point, it makes sense. 

I still think, however, that it should be available at least as an option. There already is allow_none parameter available when marshaling. Another solution would be to allow something like json.JSONEncoder.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11084>
_______________________________________

From report at bugs.python.org  Mon Jan 31 22:42:16 2011
From: report at bugs.python.org (R. David Murray)
Date: Mon, 31 Jan 2011 21:42:16 +0000
Subject: [issue11085] expose _abcoll as collections.abc
In-Reply-To: <1296503066.28.0.738947830383.issue11085@psf.upfronthosting.co.za>
Message-ID: <1296510136.44.0.0155616076581.issue11085@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Hmm.  OK, so it is just Callable that is the odd man out.

But in that case, shouldn't the pattern be adopted by the other modules that define abcs as well?  And if the distinction isn't sharp enough in those other modules to justify that, then I question whether it is a good idea to special-case collections.  The docs already make the distinction pretty clear.

My "flat is better than nested" alarm is going off here :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11085>
_______________________________________

From report at bugs.python.org  Mon Jan 31 22:48:34 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 31 Jan 2011 21:48:34 +0000
Subject: [issue8275] callback function on win64 results in bad behavior. mem
	corruption?
In-Reply-To: <1270061625.47.0.601780173179.issue8275@psf.upfronthosting.co.za>
Message-ID: <1296510514.2.0.254770540996.issue8275@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Ok, committed in r88284 (3.2), r88285 (3.1) and r88286 (2.7). Thank you!

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8275>
_______________________________________

From report at bugs.python.org  Mon Jan 31 22:50:24 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 31 Jan 2011 21:50:24 +0000
Subject: [issue11086] add lib2to3/__main__.py
In-Reply-To: <1296507167.64.0.584286117272.issue11086@psf.upfronthosting.co.za>
Message-ID: <1296510624.95.0.446952158972.issue11086@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11086>
_______________________________________

From report at bugs.python.org  Mon Jan 31 23:49:34 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 31 Jan 2011 22:49:34 +0000
Subject: [issue11086] add lib2to3/__main__.py
In-Reply-To: <1296507167.64.0.584286117272.issue11086@psf.upfronthosting.co.za>
Message-ID: <1296514174.18.0.211360992926.issue11086@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Uh, I must say I find typing "lib2to3" quite ugly.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11086>
_______________________________________

From report at bugs.python.org  Mon Jan 31 23:52:59 2011
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 31 Jan 2011 22:52:59 +0000
Subject: [issue11086] add lib2to3/__main__.py
In-Reply-To: <1296507167.64.0.584286117272.issue11086@psf.upfronthosting.co.za>
Message-ID: <1296514379.37.0.122607391666.issue11086@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

I don't find it ideal either, but ``python -m lib2to3`` gives complete control over which VM is used since it's specified right on the command line. I don't expect this to become the common way to invoke 2to3, just **a** way to invoke it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11086>
_______________________________________

From report at bugs.python.org  Mon Jan 31 23:53:05 2011
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 31 Jan 2011 22:53:05 +0000
Subject: [issue11086] add lib2to3/__main__.py
In-Reply-To: <1296507167.64.0.584286117272.issue11086@psf.upfronthosting.co.za>
Message-ID: <1296514385.98.0.506896637211.issue11086@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
stage: needs patch -> commit review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11086>
_______________________________________